We are using MobileFirst 8.0 adapters for mobile application development.
Earlier we were using Mobile first 7.1 where we use to invoke java files as below.
var salt =com.Base64EncoderDecoder.decode(salt);
The above file Base64EncoderDecoder.class was part of worklight .war file.
Can same approach be achieved using Mobile first 8.0 ? Please suggest how this can be achieved in 8.0.
You can still achieve the same functionality with IBM MFP 8.0.
The difference is that , with MFP 8.0, the Java class will be packaged within your adapter project itself.
For more details and a working sample, refer to this link.
Related
I would like to know what are the prerequisites to migrate plugin from v6.3 to 8.0. The code written for the plugin is in Java, should we any additional steps? or the same code(6.3) will continue to work for migration?
Can any one suggest any tool for plugin migration (like how we have for MFP Cordova application)?
As of MFP 8.0, MFP client SDK is a Cordova plugin. If you have developed a custom Cordova plugin, this should work fine with MFP 8.0 as well. You can add your custom plugin to the Cordova project and use it as you would any other plugin.
Custom plugins are developed to meet specific requirements and the native implementation is specific to respective platforms. This is outside of MFP and there is no tool for custom plugin migration. Developer needs to do it themselves if a code change to their custom plugin is warranted.
We are using MobileFirst 7.1.0.0-MFPF-IF201703150904 version. We have built a hybrid mobile application for iPhone and Android. In the backend, we have all Java Adapters.
Recently we have decided to extend the scope and add MobileWeb and DesktopBrowser Application. To achieve that I have created the new environment in eclipse studio and tried to test the new environments. I found this error "errorMsg":"Unsupported environment"
I found this article where the same issue is discussed. The article states a workaround would be to use JavaScript adapters.
My question is how can we create these environments now, we only have Java adapters in the backend. Do we need to replicate all the adapters in JavaScript? Is there any other way to achieve this?
What is the best way to package a resource (file) into a Java adapter? It is not clear from the documentation the best way to deploy this with the adapter archive so that it can be used by the adapter. Thanks for any help.
MFPF 6.3 does not support Java adapters, so that's moot there. If you want to use Java code in your JavaScript adapter in 6.3, then you can do so as demonstrated here: https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/6.3/server-side-development/using-java-adapters/
MFPF 7.0 does support Java adapters; the adapter has a lib folder. You can use this folder to hold your libraries to use within the adapter logic:
-https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/7.0/server-side-development/java-adapter/
- also see section "adapter sandbox": http://www.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.dev.doc/devref/c_overview_of_ibm_java_adap.html?lang=en
Our product is using Worklight 6.3 (which contains Cordova 3.6.3). There is apparently a bug introduced in Cordova 3.6 that doesn't allow selenium tests to be run against it. Is there a supported way we can substitute the latest version of Cordova in Worklight 6.3?
Please see the post below for the problems we're facing:
https://github.com/selendroid/selendroid/issues/658
related link:
https://github.com/selendroid/selendroid/pull/788
There is no way for you, as a developer using MobileFirst Platform 6.3, to replace the bundled Cordova as it will be regenerated during each build in MFP Studio.
What we can do is patch the Cordova build that is used in MFP with the fix you've linked to. What you need to do is to open a support ticket (PMR), requesting this.
Link to this question in the PMR.
#tedL I'v had to deal with Cordova bugs specific to Windows in the past. See my answer in IBM Worklight - How do I patch Cordova? on how I was able to add the patched files in to a automated Worklight build. You can try the same and hope it helps.
I have a fresh install of Eclipse 4.3, Worklight Studio v6.1 Consumer Edition, Worklight Mobile Test Workbench, Android SDK and the ADT plug-in. I am using Windows 7. Using the Android SDK, I only installed the Android 19 API. In Eclipse Window -> Preferences -> Android, the SDK Location is correct and the list shows 3 targets - all using Android 19 ("Android 4.4.2", "Google APIs" and "Google APIs x86").
When I use the wizard to create an Android Worklight Environment, it insists on using the Android 18 API level. I know I can change the API level using the Properties of the created Android project but I should not have to. I have seen other questions where the wizard used Android 19 and they wanted to use a lower level. But the answers did not mention a way to permanently change that.
I also noticed that the created iml file had this line:
<orderEntry type="jdk" jdkName="Android 4.2.2" jdkType="Android SDK" />
Android 4.2.2 is associated with the Android 17 API which adds even more confusion.
I cannot find anywhere to specify which API level to use. Is there a place to do this? Or will I always have to change my created Android projects? It seems others are getting projects created with Android 19 so why am I seeing it use Android 18?
In Worklight 6.1.0.x, when adding the Android environment to an application, its AndroidManifest.xml will initially be created with android:targetSdkVersion="18".
18 is the default value generated by Worklight Studio until upped to 19 or otherwise in a future release.
You cannot change this behavior (only after it is generated, you can manually change it to 19).