I'm developing a Worklight Hybrid apps targeting iOS and Android, on top of Worklight security feature we have another Web Server doing the Authentication and ACL.
Basically the Direct update feature should be available to any user without the needs to Login, therefore I've added a few White List into the ACL to make sure those user didn't get prompted for Login just for the update.
So far I've whitelisted below URL, it works in my development Machine.
apps/services/api/MYAPP/android/setup
apps/services/api/MYAPP/android/update
apps/services/api/MYAPP/iphone/setup
apps/services/api/MYAPP/iphone/update
But surprisingly it failed in Production server as the URL to perform direct update was actually as below:
apps/services/api/MYAPP/iphone/0/update?action=base64....
Why the /0/ was in place and what are the possible value?
Thank in advance.
It is based on your Worklight studio version.
For Worklight Studio version < 6.2, the direct update URL is PROTOCOL://<DOMAIN>:<PORT>/<CONTEXT_PATH>/apps/services/api/<APP_NAME>/<ENVIRONMENT>/updates?action=getzip&skin=<SKIN_NAME>&x-wl-app-version=<VERSION>
For Worklight Studio version >= 6.2, the direct update URL is PROTOCOL://<DOMAIN>:<PORT>/<CONTEXT_PATH>/directUpdate/<APP_NAME>/<ENVIRONMENT>/<VERSION>?skin=<skinName>&action= getzip
Related
(1). MobileFirst APP will crash or unstable (sometimes) when the following conditions occur :
We used WL.Client.connect API to trigger direct update at the same time when iOS native code is running (some native process we wrote) .
(2). We found that different version of timestamp will not trigger direct update. for example:
Our MobileFirst console version is 7.1.0.00-20151107-1647.We deployed wlapp(builded by 7.1.0.00-20151107-1647 Studio) to that console.
If the mobile client APP version is 7.1.0.00-20151114-1616 then the direct update won't trigger
Should we make sure that MobileFirst server and client version must be the same?
If so, How to deal with old MobileFirst version APP in Apple store or Google Play to connect new version of MobileFirst server and make sure the direct update , notify and remote disable still work.
If the Studio build that you're using contains fixes/changes to the underlying native component of MobileFirst, then Direct Update may not work. You can see this when building in Studio - you get a warning stating this.
In such cases you will need to up the environment version value in application-descriptor.xml and upload a new .ipa/.apk to the App Store/Google Play.
I am migrating worklight hybrid projects from 6.0.2 to 6.3. When i do this and install the application on to android device, I am unable to edit worklight settings and change the URL.However the same feature is working on IOS devices.
But when I create new project on 6.3 , the above feature works fine in android as well.
In application-descriptor.xml worklight settings is enabled though.
.
However when I try to change the URL in android device by editing the settings, below exception is thrown.
02-16 18:48:27.173: E/EnterpriseContainerManager(552): ContainerPolicy Service is not yet ready!!!
02-16 18:48:27.173: E/ViewRootImpl(27590): sendUserActionEvent() mView == null
02-16 18:48:50.155: E/Watchdog(552): !#Sync 706
Settings pop up is not showing up , to change the URL. Please suggest.
Worklight Settings is unreliable on Android devices using API Level 10 and above. The settings screen may appear but not work, or the Options Menu that invokes it may not appear at all, etc.
However, starting MobileFirst Platform 6.3 there is dedicated API for setting & getting the Server URL, enabling you to change it during runtime: WL.App.getServerUrl and WL.App.setServerUrl.
There is a blog post on this new ability that explains how to use the API methods as well as provides a sample application. You can follow it and integrate it in your application instead of using the Worklight Settings screen in Android.
Blog post: https://developer.ibm.com/mobilefirstplatform/2015/02/02/changing-server-url-runtime/
I want to automate the disable access feature of my worklight application ( version :- 6.1.0.2 ) , I have created the below links referring info center links, Can any one please let me know, how can i get the value of gadgetAppID in the below mentioned urls. Also i have added the snap shot of the mysql DB.
Disable App post url below.
http://localhost:10080/AppName/console/api/applications/setAccessRule?gadgetAppId=""&action="disabled"&message="please try later”
Enable App post url below
http://localhost:10080/AppName/console/api/applications/setAccessRule?gadgetAppId=""&action="enabled"&message="please try later”
Thanks
djrekcer.
It is a bit complex in 6.1, see - http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.1.0/com.ibm.worklight.apiref.doc/admin/r_http_interface_of_the_prod_server.html (search for setAccessRule)
Starting with 6.2 there's a RESTful server API for that, see http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.2.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_app_version_access_rule_put.html%23App-Version-Access-Rule--PUT-?lang=en
We have already delivered the 1.0 version of our Worklight application. By mistake we have disabled the Direct update feature by updating the attribute "connectOnStartup = false"
We dont want to redeploy the application to markets (AppStore/GooglePlay) again, but wanted to make our users to utilize the direct update feature. We do have the access to WL server.
Our issue is little different from the one which is already discussed here "IBM Worklight - How to disable Direct Update?"
How can we provide the direct update feature to our end users without redeploying the application to AppStore/Googleplay. And just by changing the Webresources of the application.
We are using the adapters in our application but no where we are explicitly calling the "WL.Client.connect".
The Direct Update feature is always enabled by default.
You need to edit your question and explain what it is you've done in your Worklight project.
The feature will not work if:
You have set connectOnStartup:false
You are not using WL.Client.connect
You are not invoking adapters
You disabled it via the checkbox in Worklight Console
Otherwise, the feature will work, and a check for Direct Update will be performed:
On application startup
On return to foreground
The application will need Re-deployment on the App stores.
So the solution to your problem is
Rebuild the Application with connectOnStartup:true.
Redeploy the Application on App Stores
Once the users download the updated application, future updates will go to the users directly.
While rebuilding, make sure that you change the Version of your application within ApplicationDescriptor.
I do not understand the purpose of the properties listed in worklight.properties:
publicWorkLightHostname
publicWorkLightProtocol
publicWorkLightPort
Those properties are set when you do in eclipse the Run As -> "Build settings and deploy target..."
Are they duplicated? Which one is the valid one? Are they used in different ways?
I have read the documentation in info center:
https://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.deploy.doc%2Fadmin%2Fr_configuring_the_ibm_worklight_server_location.html
But there is no mention to the "Build settings and...".
See this question and answer: worklight server configuration - separating adapters and server
The properties that are found in worklight.properties relate to the
Worklight Server. The properties you have mentioned:
publicWorklightHostname, publicWorklightPort, publicWorklightProtocol,
are required because the server itself needs to know what is its URL
to the outside world, so that it can embed it in redirects and such.
These are also required for the Mobile Web, Desktop Browser
environments and Worklight Console.
For example:
Create a new application and add the Mobile Web environment > Run on Worklight Development Server deploy. Open Worklight Console and click on "Get application URL". Copy the URL. Go to worklight.properties, change the publicWorklightPort to "100"; Go back to console, compare the previous URL with the current.
From Javier:
They are not used by the mobile apps. They are shipped with the .war and are used by the .war to provide information to the user like the web url, but the server does not use them for the execution of a mobile app.