How does IBM MobileFirst detect what is the type of application update (Direct Update , Version Update)
I want to keep my JSONstore data while minor update (direct update - Upgrade app from v1.01 to v1.02. )
I want to destroy my JSONstore data while major update (version update - Upgrade app from v1.01 to v2.00.)
Any suggestion to perform this function ?
Any API to get current version of App ?
The framework checks for Direct Update by comparing a checksum value of the web resources that reside in the application and the web resources that reside in the server. If they differ, then there will be a Direct Update.
There is no check between major version numbers (1.0 and 2.0), as that update is done via the update mechanism provided by the various app stores.
What you could do store either in your JSONStore or using HTML5 LocalStorage the current version of your application, and when you release a new version then to add logic in your app to compare the existing version with the new version and act upon based on the result.
Related
Today we have an app in applestore with a version labeled as 7.6.2 and internal build number as 1.0.0. We are using mobilefirst 7.1 to develop. Problem is that now we have a new app, that is 7.6.2.1, but we would like to know if is possible continue to use 7.6.2 app from applestore onto 7.6.2.1 mobilefirst app (asking it because we would like to keep our customers using just a single app from applestore). We also have an app on google play and would like to apply same idea.
Maybe this is an edge case, so do we have a way to control this directupdate by ourselves?
Customization of direct update is limited to the UI and options when you receive a direct update push.
As for version management, if both versions 7.6.2 and 7.6.2.1 are deployed in the MFP server, end users can have these versions deployed on their devices. Direct update or other configurations can be separately configured for these different versions.
However, if an end user is on v 7.6.2 and they take an update from AppStore or Playstore, and the version on the device becomes v7.6.2.1, this updated application on the device will start connecting to only v7.6.2.1 in the server. And only direct updates this version on the device ( 7.6.2.1) will receive are the ones uploaded to 7.6.2.1 in the server.
Direct update feature is meant only to push small web resources changes into your application. If the MFP Application Version numbers for both app versions(i.e 7.6.2 and 7.6.2.1) are different, you can continue to use both the versions and push direct update indvidually based on version number.
I wonder how direct update works. What is the full process (checksum, build version, etc.) that links the war, wlapp and the apk or the ipa files in order to show direct update notification when the application is launched?
You can find this information about Direct Update in MobileFirst Platform Foundation 6.2 - 7.1, here: https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/7.1/advanced-client-side-development/using-direct-update-to-quickly-update-your-application/
The .war file is not related to Direct Update
The .apk and .ipa (binary files) are not related either
Direct Update relates only to the web resources that are bundled in the Hybrid application.
When you want to make such an update you need to:
Update the resources in your project
Build the project, which generates an updated .wlapp file
Deploy the updated .wlapp file
Now the server holds updated web resources for the application. As part of this a checksum value of the web resources is stored in the server. A similar checksum value is also stored in the application.
The next time the application attempts to connect to the server, be it via WL.Client.connect or an adapter request, the server will will compare the checksum value of the application (which is send as part of the request to the server) with the checksum value it has stored. If the values differ this means that the server will serve the updated web resources back to the application.
Notes:
If you are using MobileFirst Platform Foundation 7.1 the frequency of checking for an update is determined based on your token expiration value. Refer to the link above to learn more about this.
Direct Update works only on the same app version. i.e. if your application is at v1.0 and you want to update it using Direct Update, make sure that when building the application in MobileFirst Studio, the environment version is also set to 1.0. If your application is at a different version, Direct Update will not be done due to version mismatch.
(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.
As I understand it, a Worklight JSONStore is only available to hybrid Worklight applications.
Correction: A Worklight JSONStore is available to both hybrid and native applications as of Worklight 6.2. My mistake.
For either type of application, under what application upgrade circumstances would the data in it be permanently lost? For example, I see at least three variations of upgrade:
Upgrade using Direct Update - I would assume the contents of the JSONStore will be kept as-is in these circumstances.
Complete deletion of the application followed by installation of the new version - I would assume the content of the JSONStore would be completely lost in these circumstances.
Binary upgrade of the application from AppCenter / App Store / Play Store / MDM solution / etc. - In this case, will the JSONStore continue to exist between one version and the next with the same data?
Worklight JSONStore is available for Hybrid applications and also for Native applications (starting Worklight 6.2).
Per the JSONStore documentation:
Reliable Storage means that your data is not deleted unless one of the
following events occurs:
The application is removed from the device.
One of the methods that removes data is called.
To cover your mentioned cases:
Direct Update: JSONStore data remains as-is (unless your update triggers code that will cause code deletion...)
Deletion of application: this will remove the application and any associated data, including JSONStore
Application update: this will not remove the JSONStore
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.