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.
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 developing both Android and iOS B2C app (will upload it to Store). Reading from here, it seems there are some restrictions for Direct Update.
- The update is for the app web resources only
- To update native resources, a new app version must be uploaded to the respective app store
- Android: no restrictions
- Windows Phone 8: no restrictions
- iOS:
B2C: according to the terms of service of your company; usually at least bug fixes are allowed
B2E: through the iOS Developer Enterprise Program
But the requirement is:
User want to update some .txt files in production without want to use Adapter.
Is this allowable and able to be done as in the doc saying for web resources only?
I don't know how do you intend to use this "txt file" in the application but I am pretty sure you can classify it as a web resource without worries.
working on app for android
in which using livesdk (for android) provided by microsoft to access skydrive on device
the problem is out to work offline???
how to initialize LiveConnectClient in that case
really needed help
ty in advance
The LiveSDKs and OneDrive-APIs are not meant to function offline as they require connectivity to their service components to retrieve data.
If you are looking to use the data retrieved by the LiveSDK while the client is not connected to the internet I would recommend coming up with an appropriate caching scheme so your application has the data it needs on hand.
When your application comes back online, you can synchronize its state with the view.changes to start the reconciling process.
With a company App configured on a Windows phone there is the posibiltiy to push the installation of an App. When the user starts the pushed App some configuration data must be introduced. I would like to save the user this step but I still don't know how. Isn't it possible to push files over the company App/Exchange, as it is on a Windows machine? So I could read the configuration out of this file.
your use case does raise many questions (probably just terminology)
The only way to push an APP to a device is through the Windows Phone store or website.
If you want to push configuration to a device for an app then the app must be run at least once to enable that ability and you could then use a background task to periodically check for new configuration and download it.
The other thing you can investigate is push notifications but they are not really meant for pushing data, you can sent simple objects or data to the device as a raw push but the app must be running first.
The most common way to achieve what you describe is to have the app load config at launch, locally first and then update it from a web call (if web is available, as these are mobile devices you can not guarantee connectivity). We do something very similar with AdRotator where we try to download config at start and if that fails use a locally cached version.
As of WP 8.0 there isn't the possibility to push Apps or Files through the company App.
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.