It's convenient while developing with the MFP studio (Once any files change, the client will get a update notification which is so-called "direct-update"). But how could make this in a MF production server ?
Do we have to do "Replace project war file" in the MF Server configuration Tool and then the re-select a large version number .wlapp file in the worklightconsole ?
Unlike what Srik wrote - you shouldn't carelessly delete the old .wlapp. By doing so, users who use the version of said .wlapp will not longer be able to connect to the server.
So you if need to trigger a direct update, re-deploy the updated .wlapp file when you need to, don't first delete it.
Do not delete it even if deploying a new version (1.1 instead of 1.0).
You should delete only after you are certain that all of the users of 1.0 have migrated to 1.1.
1.1 constitutes of a new version that was also uploaded to the app store.
You can force users to upgrade by "remote disable"ing v1.0 (and point to download the new version). When everyone migrated, you can then delete the old version if you really feel like it.
Deletion is done via MobileFirst Console.
Load the console URL
Click on Applications
You can delete:
The entire all with all of its environments:
or a specific environment, or a specific version of an environment (if you had for example 1.0 and 1.1):
You can delete the old .wlapp file and put in your new .wlapp file. There is no need to replace the .war file
Agree with what #Idan Adar wrote, and make some addtion IMO:
You are doing iterative development of your app and upgrade your product frequentlyly, but just in UI level and adapter level, you can just update .wlapp files (DO NOT delete it ) which will trigger a direct update;
I don't think version number in WL console is so important to the end user (they cannot see it and they don't care), so you can just define a version number inside the app then update by direct update;
If you changed something big, and changed something platform related ,e.g : in iOS developing you change worklight.plist (in this file, which WL server your app is connecting to or WL platformVersion is defined here), then you have to rebuild your app and publish them to App Store or Android market.
Related
I'm working on an IBM MobileFirst Platform 7.1 project where there are many name value pairs in the worklight.properties file.
Say for example,
HOST_NAME = www.google.com
I access these variables form the MobileFirst adapter.
var hostName = WL.Server.configuration["HOST_NAME"]
There will be cases where I'll have to change the HOST_NAME in the worklight.properties to a different value. But sometimes, even after the value is changed in the worklight.properties file, they are not getting updated in the adapter.
Every time when I change the values I do the following,
Clean the project
Restart the server
Deploy the adapter again
Nothing seemed to change the value.
I suspect, the MobileFirst server caches the values and reuses the old values without updating the new ones. I say this because, I tried deleting the values in the worklight.properties file, and even tried deleting the file itself. Still the adapter was using the old value.
I tried deleting the MobileFirstServerConfig Folder in my workspace. Even that didn't work.
It would be great if someone could help me clear the cache or find a work around to this issue. Thanks in advance.
I kind of followed the above method but initially it didn't work.
But later I tried to follow these steps in this exact order and it seemed to work.
Stop Worklight Server.
Remove your project from Mobile First Development Server.
Go to the "bin" directory and remove your project war.
Clean and Build the entire workspace.
Start the server
Deploy the adapters
Run your app.
The worklight.properties file is embedded into the project runtime WAR file. So, if you change anything in worklight.properties, you must rebuild the WAR file and redeploy it. Based on your description, it sounds like you're only building the adapter (and not the app). At minimum, I would suggest to remove the runtime WAR file from the project "bin" directory (just to ensure that it gets rebuilt) and build all app environments. That should build / redeploy the WAR file and restart the server, and then what you're doing should work.
Here are the steps to follow:
1. If worklight server is up and running, stop it or restart your system.
2. Clear bin folder.
3. Do Clean Project and Build for enviournment.
4. Open Mobile first Console(Start server)
5. Deploy All adapters
6. Run your app.
If wlq or wl error is comming we can give an alert message 'test' in our main file where we have all the javascript files.
We have a worklight i/OS hybrid application built and deployed to the worklight console using RTC jazz team build and the ant-builder ant tasks (6.1.0.1). The ipa packaging is done on a separate machine, though using the same level of Worklight Studio (6.1.0.1).
I've compared the wlapp files that are generated, and they are basically identical except for some whitespace characters (tabs, line feeds), probably due to the different environments (Windows vs AIX), and the following:
index.html
"WORKLIGHT_NATIVE_VERSION": "3921556017",
"WORKLIGHT_PLATFORM_VERSION": "6.1.0.01.20140311-2356",
"WORKLIGHT_NATIVE_VERSION": "1475155033",
"WORKLIGHT_PLATFORM_VERSION": "6.1.0.01.20140311-2356",
deployment.data
native=3921556017
native=1475155033
However, the direct update never happens when the wlapp is updated on the server.
on the WL.Client.connect call, the following json comes back as part of the response
gadgetProps":{"directUpdate":{},"ENVIRONMENT":"iphone"}
What are we missing here? What can be preventing the direct update from triggering?
Any help would be greatly appreciated.
The 6.1.0.1 iFix version 6.1.0.01.20140518-1532 from IBM Fix Central seems to have resolved this problem for us.
And what if you are not using ant, but rather built the project in Worklight Studio straight to Xcode from then install the .ipa and test Direct Update. Does it work?
From your question it is not clear whether or not you've confirmed one or the other.
Regardless, since the v6.1.0.1 build you are using, several Direct Update-related fixes were introduce; one with close proximity to the error you mention (directUpdate:{ }), so I suggest to to open a PMR in order to receive the latest available iFix (not yet available at IBM Fix Central).
I have some server with corrupted WL 6.1.0.0 install - the IIM does not show it in history, so I can not apply a fixpack in traditional way.
I need to update WL 6.1.0.0 to 6.1.0.1, in some non-traditional way.
Initially I thought that FixPack 001 major task is to update in /opt/IBM/Worklight/WorklightServer/ files worklight-ant-builder.jar, worklight-ant-deployer.jar, worklight-jee-library.jar (besides WAR application update, which I don't need - we don't use App Center Console, and WL applications are built with Studio 6.1.0.1 - no need to update)
I planned to copy the JAR files from the updated server, but comparing with another server which was updated (via IIM) to 6.1.0.1 I see that these files are just the same (however About menu tells 6.1.0.1 server version).
App Center Console is not used on the 6.1.0.0 server (actually I uninstalled it via WAS web admin console)
So, my question is: how to update WL 6.1.0.0 to 6.1.0.1 manually, possibly in non-supported way?
I'm not familiar with a manual way, however you should probably read and execute the recommended steps that are written in this user documentation topic: Upgrading from Worklight Server V6.1.0 to V6.1.0.1 in a production environment.
Highly suggested to also take a look at the parent topic.
I use Worklight 5.0.6 and can't use direct update for a Windows 8 application.
IBM Worklight Information Center tells that windows 8 app can use direct update.
My way to test direct update as follows.
Please tell me how to use direct update in Windows8.
make windows8 env project
change wlInitOptions.connectOnStartup value "true" (in common\js\initOptions.js )
select [Build All and Deploy]
double click .jsproj file run simulator in visual studio 2012 for Windows8
make app "back ground"
change html file and "re [Build All and Deploy]"
make app "foreground"
This documentation page is misleading (I will open a defect to correct it).
Direct Update (as in the process of updating the web resources of the application after it has already been installed on the device) is available ONLY for iOS and Android. In those environments following your steps will indeed trigger a Direct Update.
The update (or rather, upgrade) of Desktop applications has no relation what-so-ever to the Direct Update mechanism mentioned above.
For Desktop enviornments consider it like updating any other desktop application - where you up the version number, and the app detects that there is an update available or so.
In the case of Adobe Air and Windows 7/Vista Gadgets:
Build your application and install it
In application-descriptor.xml, up the value of the version attribute in the envrionment's element (for instance from "1.0" to "1.1")
Build again
I believe that now you need to go to the Worklight Console and re-download the installer, and it will detect that it needs to upgrade rather than install afresh).
Note: iGoogle, Facebook, Windows 7/Vista Gadgets and Dashboard environments will be removed in the next version of Worklight. All have ample replacements with other supported Worklight environments.
In the case of Windows 8:
Direct Update most certainly does not exist for it
The steps above are also not relevant as it is not a downloadable executable
i'm looking for a way to manage application upgrades for my compact framework app.
let's say i have v1 of the app installed on my device, and v1.1 has been released. I want the app to make a call to my server to see if there is a new version. since a new version is found, i want to send down the new version of the app to the device and have it installed, replacing the old version.
my first thought was just to have the app download the .cab file and kick off the cab file just before exiting the app. this would mostly get the job done but it would prompt the user to pick the installation location if they have a storage card or other partitions on their device. i would like to prevent any user input and just have the new version of the app installed, replacing the old app.
i'm certain that there are others doing this already and i don't want to reinvent the wheel, here. what application management tools and systems exist for this type of process? how can I facilitate this type of process?
...
EDIT:
in spite of my previous searches before posting this, i just now found this question: How to Auto-Update Windows Mobile application
When I wrote one I relied on launching the .cab file. It was definitely the path of least resistance.
Otherwise, I'd write a simple "upgrade.exe" executable that gets distributed with your app. When upgrading, you'd download the new package, launch your upgrade.exe just before exiting your app, then have that program copy over the new files to your app.