I have used an Android device (Samsung Galaxy S3 Android version 4.1.1) to view the App Info of my hybrid app. The "Application" size is around 10MB and the "Data" size is around 1MB. After that, I clicked "Clear data" button so that the "Data" size became 0MB and "Application" size remained the same.
When I launch the app again, the direct update box comes out although there is no new app release (No second build has been done). Is it an expected behavior?
Worklight version: 5.0.6
Steps:
1. Deploy an app to Worklight Server and install it in the device
2. Update the HTML file and make a build
3. At this moment, the device shows the direct update dialog. Update the app to latest version.
4. Click "Clear data" in App Info
5. Launch the app again. It shows the direct update dialog again although there is no second build occurs after "Clear data" was done
Thanks!
Based on your edit with the steps you have taken, yes, this is expected.
When installing an application on a device a chucksum is generated for it in both the client and server. After triggering a Direct Update this checksum value changes and remembered. After clearing the data, you basically return the application to its previous checksum and thus when the app is re-launched (or brought to the foreground from the background), the server detects that the value in the server differs from that in the client, and sends a Direct Update request.
Related
When attempting to implement Firebase Cloud Messaging into my application, I am receiving the following error at runtime:
I am receiving an FCM token, so it appears to be establishing a connection with firebase. I have read many suggestions on what the problem could be, many seem to indicate that there is a problem with my provisioning profile not allowing push notifications. I have checked these settings under "Signing & Capabilities" and it appears that the profile allows for push notifications, and has the aps-environment value in the entitlements section:
Is there something else I'm missing?
Here is my development environment:
macOS 10.15 (Catalina)
Xcode 11.5
iPad Air 2 (test deployment device)
I finally found the answer. Although my provisioning profile states that I have the aps-environment entitlement, and that I have Push Notification capability included, I STILL had to enable push notifications manually in the project. Additionally, the Background Modes (Remote notifications) capability needed to be added as well. These menus have changed in recent versions of xcode (for instance, the capabilities menu is now called signing and capabilities, and the add capability button is nestled up above all the settings).
In Xcode 11.5, follow these steps:
Click on your workspace name
Select your project in the target list
Select Signing & Capabilities
Click the +Capability button
Add Push Notifications and Background Modes (Remote notifications) from the list.
I have a question regarding to native app version management and direct update on Mobilefirst 8.0.
We may publish native app updates every couple weeks. We want to avoid creating a new app version on mobilefirst console (1.0, 1.1.. etc), unless the update is significant enough for us to force users to update (disabling older version on mfp console.) To achieve that, we have been updating android-versionCode and ios-CFBundleVersion in config.xml while keeping "version" the same. All works fine for previous versions of MFP (6~7). Direct update works as expected.
However, for MFP 8.0 we noticed following scenario behave abnormally.
Package app v1.0 with web_resource v1.0. Submit to app store.
Build web_resource v1.1, upload to MFP console.
--- Download app from app store, direct update triggers without a problem.
Package app v1.2 with web_resource v1.2. Submit to app store. (Note app "version" doesn't change, no new app created on MFP console)
--- new app goes on app store, user receives update notification and decides to ignore it.
Build web_resource v1.3, upload to MFP console.
User decides to open app and receive direct update for web_resource v1.3.
User finally decides to update app through app store.
--- After updating the app, the app runs web_resource v1.2 instead of v1.3. And no direct update triggered. This is not what we expected...
I understand this app version management may not be officially supported but there is an obvious reason we are doing it this way, that is to keep the MFP console app versions from going out of control.
The question becomes.. why didn't app run web_resource v1.3 after step 6? The app storage is never cleared as far as I can tell so web_resource v1.3 should still exist. Even if web_resource v1.3 is invalidated after app update, app should still starts and ping MFP server with web_resource v1.2 and triggers direct update to download web_resource v1.3.
Is there some underlying mechanism that's causing this? I suspect there is another "timestamp/last updated time" stored somewhere that's causing this. I hope this can work as it was in MFP 6~7.
When looking at the contents of Version 6.1.0 Fix Pack 1, it doesn't appear to list PI06519 as one of it's constituents, yet when applying the fix pack in a bid to address the slow start up issue, it appears to fix the problem.
Is this supposed to be the definitive list of the contents of the fix pack and is simply an oversight, or should I be looking somewhere else for the full contents of it?
There is some problem with listing this APAR in the list of fixes which has yet to be resolved.
Here is a copy of the fixed APARs in Worklight 6.1.0.1:
Changes since: 6.1.0.0
Fixes (APARs):
PI12596 A HYBRID APPLICATION MAY FORCE CLOSE OR FAIL TO CAPTURE DATA WHEN RETURNING FROM THE CAMERA VIEW.
PI12471 RICH PAGE EDITOR'S PERFORMANCE SUFFERS WHILE TYPING.
PI12337 WHITE LINE AT THE BOTTOM IN IOS 7.1
PI11962 SECURITY ISSUE WITH WORKLIGHT CONSOLE
PI11561 STUCK IN A DIALOG ENDLESS LOOP IN ECLIPSE WORKLIGHT PREFERENCES
PI11502 EVENT LISTENERS ATTACHED WHEN CONNECT() IS INVOKED BUT NEVER UNBOUND.
PI11350 IN THE WL STUDIO WITH BUILT-IN SERVER, THE FEATURE OPEN WORKLIGHT CONSOLE DOES NOT START THE SERVER AUTOMATICALLY.
PI11168 WORKIGHT PAGE DOES NOT RESPOND TO CHANGING RICH PAGE EDITOR DEVICE ORIENTATION TO PORTRAIT
PI10959 JSONSTORE FAILS TO REMOVE ALL DOCS IN THE DOC ARRAY WHEN A DOC ARRAY IS PASSED
PI10818 FAILURE WHEN DEPLOYING WORKLIGHT APPLICATION ON WORKLIGHT PUREAPPLICATION PATTERN WHEN SCALING POLICY IS IN EFFECT
PI10775 SERVER CONFIGURATION TOOL DEPLOYMENT CAN NOT PROCEED WHEN USING DB2 DATABASE IF DB2 INSTANCE OWNER ID DOES NOT HAVE SSH ACCESS
PI10398 PROBLEM CUSTOMIZING TIMEOUTS WITH WL.CLIENT.CONNECT API.
PI10149 MOBILE BROWSER SIMULATOR IS BLOCKED IN BROWSER WHEN USING ORACLE JAVA 7 UPDATE 51 WITH "HIGH" SECURITY SETTING
PI10127 NATIVEPAGE FEATURE DOES NOT WORK PROPERLY ON WINDOWS PHONE 8
PI09913 WORKLIGHT UNDER HIGH VOLUMES SHOWS MEMORY INCREASE WHEN REPORTING ENABLED
PI09863 IF REMOVING THE OPTIONAL FIELD "BADGE", AN ERROR IS RECEIVED: "MANDATORY FIELD 'BADGE' NOT FOUND."
PI09770 IOS PUSH NOTIFICATION ERROR AFTER UPGRADING OR APPLYING FIX
PI09711 [WINDOWS 8] - CANNOT OPEN A WL.SIMPLEDIALOG AFTER IT WAS OPENED AND CLOSED
PI09666 ADDING ENVIRONMENT WAITS ON "BUILD PREVIEW PAGES"
PI09569 WHEN BACKEND IS STALE/SLOW UNDER LOAD THEN GOES BACK TO NORMAL SERVER CANNOT RECOVER UNTIL RESTART
PI09530 ADAPTER INVOCATION IS FAILING IN IOS 5 IN WORKLIGHT 6.1 ENVIRONMENT.
PI09432 CALLING ACQUIREPOSITION AFTER STARTACQUISITION HAS BEEN CALLED WITH A GEO POLICY, MAY NOT ACTIVATE TRIGGERS FOR NEW POSITIONS.
PI09373 RARELY, ON NATIVE ANDROID, MULTIPLE SUCCESS CALLBACK EXECUTIONS CAN TAKE PLACE FOR WLDEVICE.ACQUIREGEOPOSITION.
PI09372 IN NATIVE ANDROID, USE OF THE WLGEOACQUISITIONPOLICY MUST BE DONE IN A LOOPER THREAD.
PI09370 WHEN USING GEO DWELL TRIGGERS, WLGEOFAILURECALLBACK INSTANCES MAY BE EXECUTED AFTER WLDEVICE.STOPACQUISITION() IS CALLED.
PI09356 ADAPT APPLICATION CENTER PUBLISH SHORTCUT TO HANDLE XAP FILES
PI09349 WHEN IMPORTING THE IBMAPPCENTER HYBRID PROJECT, AN INCORRECT WARNING SUGGESTS TO INCREASE THE VERSION
PI09326 APPCENTER OTA INSTALLER: TITLE TRUNCATION ON DETAILS VIEW
PI09325 APPCENTER CLIENT TABLET PORTRAIT, BUTTON TRUNCATION ON DETAILS VIEW
PI09324 APPCENTER CLIENT IOS: DATES APPEAR A PHONE NUMBERS
PI09323 APPCENTER OTA CAN START IN TABLET MODE ON A PHONE IN LANDSCAPE ORIENTATION.
PI09321 WORKLIGHT APPCENTER MOBILE CLIENT: AFTER SENDING A REVIEW, THE APP IS MISSING FROM LISTS IF ITS POSITION CHANGED
PI09315 APPLICATION CENTER MOBILE CLIENT ON TABLET: SOME APPLICATIONS MAY NOT BE DISPLAYED IN CATALOG.
PI09233 WORKLIGHT SERVER THROWS EXCEPTION WHEN RE-AUTHENTICATING WITH THE ANTIXSRF REALM
PI09224 WHEN MIGRATING A PROJECT FROM WORKLIGHT 6.0 TO 6.1, AN ERROR OCCURS STATING THAT THE UPGRADE PATH IS NOT SUPPORTED
PI09029 IOS APP LINK FAILS WHEN SETTING IOS DEPLOYMENT TARGET TO 7.0
PI08960 WL RUNTIME LOGS THE FULL CLIENT REQUEST WHEN AN ERROR HAPPENS
PI08819 INCORRECT DATA MAY RETURNED WHEN SUBSCRIBING/UNSUBSCRIBING FOR SMS EVENTS
PI08807 DESIGN PANE FOR JSF PAGES FAILS TO UPDATE
PI08806 INACCURATE JSP VALIDATION
PI08789 FIX WLJQ.JS TO SUPPORT WINDOWS 8 AND WINDOWS PHONE 8
PI08777 "ITMS-SERVICES" PROTOCOL DOES NOT WORK
PI08689 INCORRECT DATA MAY BE RETURNED FROM THE SERVER TO THE APPLICATION
PI08685 IMPROVE PERFORMANCE WHEN USING THE IBM SDK FOR JAVA
PI08632 APP CLIENT CLOSES WHEN CONNECTING TO SERVER WITH ANALYTICS ENABLED.
PI08609 CLUSTER SYNC TASK REPEATEDLY TRIES TO DEPLOY OLD APP FROM THE DB TO A NEW PROJECT
PI08601 WL.SERVER.INVOKEHTTP WITH DELETE METHOD DOESN'T ACCEPT QUERY PARAM
PI08583 BLACK LINE APPEARS AT TOP OF SPLASH SCREEN ON IPAD RUNNING IOS7
PI08580 ECLIPSE CRASHES WHEN OPENING WORKLIGHT APPLICATION FRAMEWORK VIEW.HTML ON WINDOWS
PI08574 FAILURE TO MIGRATE WORKLIGHT PRE-5.0.5.0 APPLICATIONS TO WORKLIGHT 6.1.0.0
PI08511 OLD LTPA TOKEN IS BEING USED WHEN USER LOGIN AGAIN WITHIN A MINUTE OF LOGOUT
PI08189 ERROR WHEN CONNECTING TO SERVER AFTER SETTING APP TO ACTIVE IN THE CONSOLE.
PI08127 SLOW SERVER PERFORMANCE AND REPEATED DATABASE QUERIES WHEN REMOTE DISABLE IS ENABLED
PI07660 MISSING API GETDEFAULTMOBILECONFIGURATION4ANDROID_IOS() IN LOGINCONFIGURATIONSERVICE INTERFACE
PI07549 SHELL COMPONENT CHANGES ARE NOT SHOWN PROPERLY IN BROWSER DURING PREVIEW
PI07263 SCREEN TURNS BLACK ON IPAD DURING DIRECT UPDATE
PI07256 INAPPBROWSER NOT ABLE TO OPEN LOCAL URL LINKS ON ANDROID 4.4
PI06943 DIRECT UPDATE NOTIFICATION WHEN NONE AVAILABLE, THEN FAILS UPON UPDATE ATTEMPT
PI06828 ANT DEPLOMENT TASKS DON'T WORK WHEN CONSOLE IS PROTECTED WITH LTPA AUTHENTICATION
PI06652 DIRECT UPDATE ALLOWS USERS TO KEEP USING OUTDATED VERSIONS.
PI06586 INCORRECT PUSH NOTIFICATION RECEIVED WHEN MULTIPLE WL APPS ON AN ANDROID DEVICE
PI06568 DIFFERENT VERSIONS OF A WORKLIGHT APPLICATION ENVIRONMENT GET WR ONG SECURITY TEST IF SECURITY TEST IS CHANGED BETWEEN VERSIONS.
PI05454 WORKLIGHT APPLICATION CENTER ON LIBERTY PROFILE 8.5.5 PRODUCES "LAST-MODIFIED" DATES IN BAD FORMAT.
PI05447 NULLPOINTEREXCEPTION OCCURS WHEN CALLING WL.SERVER.LOGACTIVITY.
Status: Fix Pack
Additional Information: Please see http://www-01.ibm.com/support/docview.wss?uid=swg27028172 for information on installing the fix.
I have created a VB NET application that is installed with a installer project (MSI). Installer works perfectly, app functions as designed.
On a Windows 2008 Server R2 (Standard), the first time I log in the application starts with the wrong icon/task bar group. It starts with the IBM Tivoli command line icon or GUI icon with those options in the group.
After I close my application and open it a second time, I have the correct icon and taskbar group.
If I log into the box and start a different application, then my application, I get the correct icon/group.
Things I have tried...
Uninstalling/reinstalling multiple times
Confirmed my application is advertised
Deleted the icon cache for my profile
More information (from continued trouble-shooting)...
If I set taskbar buttons to "Never Combine" I get the correct icon for my app, but not the correct group options (right click).
If I pin the IBM Tivoli command line to the taskbar, this problem goes away. My app starts with the correct icon/group every time.
If I pin my app to the taskbar, the problem also is resolved every time.
So this problem is only occuring when neither app is pinned to the taskbar.
Another update...
This issue occurs in multiple environments (same server configuration).
This issue does not occur with a user account that did not perform the install. Only the installing account gets the behavior.
Solution...
This had nothing to do with my application or IBM Tivoli, it is a bug in certain versions of Windows...
KB 2519550
This KB hung up the box on restart, but once I hard cycled it, the problem was resolved.
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.