We have been working on MobileWebapp and found that after every upload of wlapp , we need to clear the cache on browser to check new changes. Is there any thing which needs to configure at server end to reload new change if newly deployed.
Have you explored the application manifest feature for Mobile Web apps? See here: http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.1.0/com.ibm.worklight.dev.doc/devref/c_optimizing_apps_appcache_procedure.html?lang=en
Related
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 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.
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
With Direct Update, the mobile application can be automatically update with a new version of the web resources. In order to update the native resource, a new version of application must be uploaded to application store.
Consider the case that I have an update for my Worklight app with both native and web resources code update which has already been in application store.
Questions:
Is the following a correct way to update the app?
Step 1. Package the app in .ipa / .apk (with native + web code) and submit to application store
Step 2. Deploy an updated .wlapp file (with web code) to Worklight Server.
In application store, I can specify the application version when uploading the application. Will the application version be incremented automatically once I deploy the .wlapp to Worklight Server?
If the user does not update his application in application store and open the application, since there is a new web resource update in Worklight Server, it means that there will be a direct update alert box to prompt the user to download the latest application and in this case only web resource will be downloaded. There are some problems when the native code and web code are correlated?
Thanks a lot.
This would essentially be the correct order of steps, yes.
However, since you say you're updating both the native and web resources, I would make sure that the existing app can work with just the web resources update (without updating the native), because once deploying the .wlapp to the Worklight Server, existing users will receive a Direct Update.
If this scenario is not one you want to support, then in application-descriptor.xml you should also up the value of the version=" " attribute in the environment's element. When building the app after doing so, this will create a new .wlapp (for example: myProjectNameMyAppName-1.1.wlapp instead of ...-1.0.wlapp).
This means that the existing 1.0 users will not receive any Direct Updates, unless you deploy an updated ...-1.0.wlapp to the Worklight Server.
In relation to the above, no, the application version is not incremented automatically, it is something you need to control manually.
Also, I don't think the version value is something you control in the application store interface...
IFAIK the application version is changeable in Xcode prior to creating the .ipa for iOS and in AndroidManifest.xml prior to generating the .apk for Android (and in similar fashion for other environments).
EDIT: Actually... I think that changing the version value in application-descriptor.xml will also up the application's version number. Need to look at the end result (in AndroidManifest.xml or the Xcode project, in Xcode).
This would really depend on the behavior of your application and how resilient you've written it to be in the face of updates. I have slightly covered this in #1 above.
Other than talking about it theoretically I would suggest taking the jump actually upload an app to an application store, and test it privately, of course. This would be the most convenient to do using Google Play where publishing an app is near-instant.
Afternoon All,
Here is my context:
I am setting up an existing worklight project with App Envs for IPhone, Android, and Mobile Web.
When using the Worklight Console to preview the apps, I get context root errors from the iPhone app only. (I get the Error: The Server was unable to process the request from the appl...)
When I open the browsers JS console, I see the problem is that the app is requesting the wrong context root. It is accessing the /worklight/ context, which is not there.
The contextroot that does work is the following:
http://localhost:8080/apps/services/api/[APPNAME]/iphone/init
The Context root that the iphone is trying to hit:
http://localhost:8080/worklight/apps/services/api/[APPNAME]/iphone/init
Here is the weird part. The context root is fine for the Android, and Mobile Web environments. Only the iPhone environment is having context root issues.
All three environments are sharing the same application-descriptor.xml file and same server.
Below are some file outputs.
Files below:
/server/conf/worklight.properties
publicWorkLightHostname=localhost
publicWorkLightProtocol=http
publicWorkLightPort=8080
publicWorkLightContext=/worklight/
/apps/[APPNAME]/application-descriptor.xml
<worklightServerRootURL>http://localhost:8080</worklightServerRootURL>
So a couple of questions.
1) When setting the context roots, what is the relationship between the client and server. Do the context roots have to match between the two? Is one a master and the other simply slaves from that and does not need settings?
2) (Somewhat unrelated) While debugging this issue I have come across zero documentation about how to go about "un-deploying" the server in the Eclipse dev ide. (un-deploy the server is right from IBM's documentation) I need to know how to redeploy the server when I make changes to the server settings (worklight.properties). I have seen references to cracking open the war manually, to just stopping and starting the server in the IDE.
Any help is greatly appreciated.
If you are using a context root, it must exist in both worklight.properties and application-descriptor.xml. make sure both match, then re-build and deploy and see if the problem persists.
When using the development edition of Worklight, your server is based on Jetty which is run within Eclipse (it is bundled with the Worklight Studio plug-in you have installed in Eclipse). You do not need to "undeploy" anything. Simply make the changes to worklight.properties and application-descriptor.xml and re-build your application. The changes will make their way to both the server and client.
Do note, though, that using a context root is mainly for when using application servers such as Tomcat, Liberty or WAS.