I'm making tests with Direct Update because a requirement of making daily updates to an Android App with look & feel changes.
What I have seen is that all the web files are uploaded and not only the new ones or the updated ones.
Is it possible to make a direct update of specific files?
For example I have an application with images and the size of all those images is 20mg, I make a change to a .css file. The direct update will contain my updated .css but also the 20mg of images that already are in the app and are exactly the same. Is it possible to upload only the .css?
This is not possible in the current releases of Worklight.
However, starting Worklight 6.3, which will be publically available in December 2014, the Direct Update feature is extended to support "Differential Direct Update".
With this feature it will no longer be necessary for the client application to download the entire web resources on every update. Instead, only the resources that were changed will be downloaded and updated.
More on that as 6.3 goes public and documentation becomes publicly available.
Related
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.
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.
I read about Worklight's Direct Update feature already. However, I still have some questions that would like to clarify:
Q1: Is it true that Apple allows Worklight Apps to be published to APP
Store even there is a direct update feature?
Q2: How will Apple review and monitor the Worklight Apps' content if
there is a huge change after the direct update? Or, Apple does not
worry about the cached web resource in the application, does it?
Q3: Is there any limitation or pre-condition about the direct update
for the web resource? For example, the major entries of html and js
script files must be existed... etc.
Q1: Is it true that Apple allows Worklight Apps to be published to APP Store even there is a direct update feature?
A1: There are existing Worklight customers that have submitted an application to the App Store and passed Apple's app submission process. For best results, make sure you use Worklight v5.0.6.1 or later.
Q2: How will Apple review and monitor the Worklight Apps' content if there is a huge change after the direct update? Or, Apple does not worry about the cached web resource in the application, does it?
A2: Apple only reviews app submissions to the App Store and whether or not they follow their guidelines. They do not review future updates to the application (as long as it was not re-submitted), for example in the form of a Direct Update unless there are some extra-ordinary circumstances (like inappropriate content that was discovered afterwards, for example...)
Q3: Is there any limitation or pre-condition about the direct update for the web resource? For example, the major entries of html and js script files must be existed... etc.
A3: I am not entirely sure I understand the question. There is no limitation in Direct Update - this feature replaces the existing web resources of an application with new ones. The only thing I can think of is that both the Worklight Studio (that the app was created on) and Worklight Server (that the app lives on) must be of the same version number.
An update.
Apple now allows code updates if you use a webview
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts,
code and interpreters are packaged in the Application and not
downloaded. The only exception to the foregoing is scripts and code
downloaded and run by Apple's built- in WebKit framework, provided
that such scripts and code do not change the primary purpose of the
Application by providing features or functionality that are
inconsistent with the intended and advertised purpose of the
Application as submitted to the App Store.
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.
Is there a way to manage images uploaded into a plone system, but have them be synced and automatically served with Amazon S3/Cloudfront?
I've seen reference to a project that doesn't look like it's been touched since early 2011: http://plone.org/products/collective.cdn.core/ and that only has experimental image support, and not necessarily for Amazon s3/cloudfront
There is not yet an add-on product that makes this "point-and-click" easy. https://github.com/collective/collective.cdn.core suggest that collective.cdn.core has continued to be developed, although the authors haven't pushed their releases to plone.org (shame shame!). It still does not appear to include "native" Amazon/CloudFront support, but I suspect the add-on authors would welcome either code contributions or sponsorship to add that end.