Is there any way in workight where we can create different version of desktopwebapp as we can do for other enviornment like Android, iOs to ignore risk.
There is no "versioning" support for Mobile Web and Desktop Browser environments in MobileFirst Platform. The only workaround to this would be to create another app in your project and add to it the environment, then copy/paste the contents of the previous app and use that as another "version".
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 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/
WL.EncryptedCache in Worklight.
Can WL.EncryptedCache be created for different worklight application ?
If so how many Encrypted boxes it can create for a single device ?
If no y it cant create ?
This Question arrised because the worklight makes of use of Webstorage of HTML for EncryptedCache.
Yes. EncryptedCache uses the HTML5 local storage to store the data. In iOS it is app level and you can find the cached resources in Library/Caches/yourBundleId/ ApplicationCache.db
Depends on your number of apps. each apps has its own size. Once it is reached the level you will get javascript errors
You can create more than one EncryptedCache in a single device again it is for per application
The cache is created per application, so if you have 2 Worklight applications that in both of them you use WL.EncryptedCache then each app will have its own cache.
This is because every app is sandboxed and do not share the cache of another app.
This is not related to Worklight, but to the way the device works be it Android or iOS, etc.
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.
I have to create an iPhone app which displays some sentences.
I would to download these sentences from a server and save them in a local db (for example using JSON).
The user can flag a sentence as favorite and do some other stuff.
I would to give the possibility to download other sentences, updating the corresponding table in the local db.
I don't know where to begin to build the server side.
Try to use Node.js its quite easy to use but do it in combination of ExpressJS... This is necessary to create the server side. You can even use some PHP framework if you prefer this...
Next you can choose between HTML5 or native programming for client side... It's up to you with which one you are more familiar... I think in your case you can create an HTML5 app to get the result as you need it... But of course its even possible native on the phone it just may take longer depending on your experience
So to sum up:
NODEJS + ExpressJS plugin
Phonegap (if you want to use html5 to create your app) or Native SDK (like iOS sdk or Android SDK or Windows mobile SDK)