I followed the recommended solution:
IBM Worklight v6.0 - Error while adding an application to the Mobile Test Workbench
still got the error even though my jdk seems to be already correct
I didn't see any errors in the test workbench mobile client log (emulator), which log should I be looking at?
I suppose that you are using Android 4.4 and not Android 4.4W or 4.4L which are not yet supported. And you should have made recently an update of the Android SDK tools to version 23 (you can verify by opening the SDK Manager)
Google has modified in this release the way the tools are organized and this made MTWW regressed when instrumenting.
There is a workaround: copy <android-sdk-dir>/build-tools/20.0.0/zipalign[.exe] to <android-sdk-dir>/tools.
Dominique
I had same problem. You may need hotfix or uptdate to RTW8.6.
https://www-304.ibm.com/support/docview.wss?uid=swg21678859
Related
I am trying to migrate the IBM Ready Healthcare app (https://github.com/IBM-MIL/IBM-Ready-App-for-Healthcare) from v6.3 to v8.0.
I ran "mfpmigrate client ..." command from 'healthcare-mfpf' folder (folder structure shown below), and I got "No supported platforms were detected to migrate" error. Next, I ran the command "mfp add environment" in order to add the environment, that would add the platform. However, I get an error saying that there needs to be a hybrid app available to add environment. I had no luck on running the commands from apps folder as well (folder structure shown below).
Would anyone please kindly let me know the folder I should run the command from, or do I need to go through some extra steps before I can run the "mfpmigrage client ..." command.
Folder structure
Notice: please note that the Ready Apps are no longer maintained by IBM. Just take this under considerations
This project is a Hybrid app, meaning you need to first add it to MobileFirst Studio and then add a supported environment. The project does not come with environments by default.
Only once you do this step will the migration tool find a platform (= environment) to migrate from...
Looking at the file structure you've provided, it's wrong.
It shows:
Apps
- android
- iphone
It's supposed to be:
Apps
- some app
--- android
--- iphone
--- common
It could be that they call the app in the platform name, but that doesn't matter, it still needs to have the environment folder, so maybe to "Android" you need to add the "Android environment" (right-click > add environment...).
It could be because you thought this is Cordova app and used mfp add environment in the wrong filesystem location (also looks like you're trying to use a CLI instead of Studio?).
Looking at the GitHub repository, this whole structure is unconventional and it's not clear why they did it this way.
The links to the documentation there are also dead. This looks like a dead project.
I have recently updated my eclipse mobilefirst studio to 6.3.0.00-20150106-1717
There after when I make any changes in HTML/Css/Js the changes are not reflected in the worklight we based simulator. Inorder to get the changes on the weh based simulator, i have to use run as -> run on mobilefirst development server.
In the previous version before this update what all changes in HTML/CSS/js was immediately reflected in the web based worklight simulator
Please advice
Update: the fix is now available from either IBM Fix Central or by updating from Eclipse Marketplace.
Duplicate of: MobileFirst Platform 6.3 - web resource changes do not get applied
This is a known regression. A fix will be available, soon.
Check back for updates in either IBM Fix Central, or via Eclipse > Help > Check for updates in the near future.
There is no local workaround.
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 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 have just upgrade my Eclipse client running Juno to Worklight 5.0.6 developer edition (5.0.6.20130311-0918)
The projects upgrade fine, but when building them and deploying to the local worklight server I get a constant 'persistency data access problem' This occurs across all of my projects and has only been seen since the update.
Any idea on what is causing this problem and how to solve?
I would add a screen shot of the issue but I am not allowed
Based on your comment - in 5.0.6, the database schema has changed, so you have missing tables now. In the Developer Edition of Worklight, upgrade is not supported (this is handled when purchasing a license and using the IBM Installation Mananger for installing Worklight).
Do you mean "HSQL"? What is "Web SQL?"
In any case you will need to clean your database so that it will be re-created, this time with the missing tables.
If you use the default database provided by Worklight (HSQL), go to your Eclipse Workspace and delete the WorklightServerHome folder. Then, re-build your application.