I am using android studio for developing my android app. SO i created a native API using the worklight 7.1.0 and copied all the jar files to the lib folder and wlclient.properties to the asset folder. So after that i have a set of adapter deployed in my company server, which i have to invoke from native code. So i changed all the values in the wlclient.properties as per the adapter required to call.
I added a listener for the connect and tried connect , it gave a Unexpected error.
I added a listener for invoking the adapter and tried connect, it gave a Application is not found in the server, couldnt register client
You only provided your explanation, and not any real example... so that's not helping to understand the real culprit here.
What I can say is:
So i changed all the values in the wlclient.properties as per the adapter required to call.
What you put in wlclient.properties is the server address for the client application to connect to. It does not relate to the adapter per-se. The adapter is invoked by the server once a request from the client came in.
The adapter then sends a request to what that is defined in the connectionPolicy element of its {adaptername}.xml file.
Various exceptions
Since you did not provide anything useful that can be debugged - I suggest that you will instead review the following tutorial and its sample application: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-1/foundation/server-side-development-category/invoking-adapter-procedures-native-android-applications/
The tutorial mentions the required steps to take in order to use the MobileFirst API in the Android app.
Related
The hybrid android app made from mobilefirst cli 7.1 is not getting the authorization token from the mobilefirst server in our UAT environment which has webseal junction, so the subsequent adapters calls are failing as 401 unauthorized is returned for these calls, what makes this interesting is that ios app which is made from the same client side hybrid code works well with the same UAT environment with webseal.
one more interesting fact is that same android app works fine when pointed to SIT environment where there is no webseal .
So i am trying to understand what triggers the client ( WLHybridRequestSender)to send out the" /authorization/v1/token " call , and is there a chance that the webseal is filtering any response to a preceding call "token" call thats is breaking the client side code? if so where and what should i look for to resolve this issue?
Any advise or help is much appreciated !
Thanks
This issue was already fixed, you can find more details about it, here.
You should update your cordova-plugin-mfp 7.1.0 plugin using mobilefirst cli:
mfp cordova plugin update
This updates the Cordova assets for each plug-in that is installed in the app.
Please notice that you must execute the command in Cordova project folder.
You can read more about mobilefirst cli in this tutorial.
(1). MobileFirst APP will crash or unstable (sometimes) when the following conditions occur :
We used WL.Client.connect API to trigger direct update at the same time when iOS native code is running (some native process we wrote) .
(2). We found that different version of timestamp will not trigger direct update. for example:
Our MobileFirst console version is 7.1.0.00-20151107-1647.We deployed wlapp(builded by 7.1.0.00-20151107-1647 Studio) to that console.
If the mobile client APP version is 7.1.0.00-20151114-1616 then the direct update won't trigger
Should we make sure that MobileFirst server and client version must be the same?
If so, How to deal with old MobileFirst version APP in Apple store or Google Play to connect new version of MobileFirst server and make sure the direct update , notify and remote disable still work.
If the Studio build that you're using contains fixes/changes to the underlying native component of MobileFirst, then Direct Update may not work. You can see this when building in Studio - you get a warning stating this.
In such cases you will need to up the environment version value in application-descriptor.xml and upload a new .ipa/.apk to the App Store/Google Play.
Hi I am trying to debug the worklight adapter and couldn't find any solution. firebug is also not showing the adapter and also i am not able to put an alert in the adapter to check. can someone say how can I debug the worklight adapter as I need to know where the error in adapter is
If you have implemented a JavaScript adpater (Worklight/MFP 6.x, 7.0) then you can debug JavaScript adapters as mentioned in the following answer: IBM Worklight 6.0 - How to enable/view WL.Logger.debug in adapters?
You cannot place alerts in an adapter because it uses server-side JavaScript and is outside of the application scope. In other words, alerts make no sense as they have no place to print to. See the above answer to learn how to print logs to the server.
If you have implemented a Java adapter (MFP 7.0 only) then you can debug it as described in the following tutorial: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-0/server-side-development/debugging-adapters/
Am new to IBM Worklight,Is there a way to fetch the call Log and contact,like in android using TelephonyManager to track call duration,call details.Can any one know,please guide me to do fetch these details.
Worklight itself does not have access to this information. However, Worklight uses Cordova, and using Cordova you could gain this access.
To accomplish the above, you will need to create a Cordova plug-in, from which you will be able to hook into the TelephonyManager and retrieve any information that it can provide you, including call duration and details.
Creating a Cordova plug-in cannot be explained shortly, so I will link you to the training module explaining exactly this: Adding native functionality to hybrid applications with Apache Cordova.
Also, in the following question I have code written that enables hooking to the TelephonyMananger to get a different type of information, so you should be able to modify it to get what you need: IBM Worklight - Unable to get network signal strength in Android
Worklight 6.2.0
Native Worklight App on Samsung Galaxy S4, Android 4.4.2
WLAnalytics.enable();
WLAnalytics.log("some text", new org.json.JSONOBject() );
WLAnalytics.send();
// and also go on to successfully call an adapter
Analytics Dasboard shows the app version and adapter activity. Log Search does not show any application log messages and the dropdown for selecting applications shows "All Applications" only, no sign of my app.
Have I missed some initialisation step? Any other ideas?
** edited to add **
It has been suggested that we should use the method:
WLAnalytics.log("some text");
In our 6.2.0.00 CLI environment there is no such Java method.
The answer is that there a further initialisation requirement that seems to be necessary when working with a pure Native application, these are typically build using the Worklight CLI tooling.
This is the initialisation, note the call to Logger.setContext()
WLAnalytics.enable();
Logger.setContext(this);
Then this works
WLAnalytics.log("My test message2", new org.json.JSONObject());
It's worth noting that the call to WLAnalytics.send() is not necessary in normal running as typically the analytic data is buffered and sent as a piggy-back on adapter calls. However while testing a call to send() does help.
Further, if running in an environment where the Analytics WAR is on a separate machine from the Worklight Server WAR there are additional latencies. Hence testing all of this needs care.
For now, I suggest that you just use the WLAnalytics.log(String) method. There are some clear inconsistencies that need to be dealt with whether it be through documentation or code fixes.
The WL.Logger APIs were originally created to send log data to a custom adapter, which is why they take a dictionary/object for extra metadata. The data sent to the custom adapter could be read as a valid JSON object to run operations on the adapter.
The WL.Analytics APIs mimicked the WL.Logger APIs for the same purpose: parsing the JSON on a worklight adapter. The Operational analytics server came as a convenience to intercept and display some of these logs, but not all of them are being captured as you have learned.
Your questions are all valid though, as none of this is described in the documentation. In future releases, we may make use of the extra JSON object passed into the API in the Operational analytics console, but for right now they only serve their original purpose of sending the analytics to a custom adapter.