I was using IBM worklight 5.6 earlier but just updated latest 6.0. Right now thinkin why I updated, earlier was good. Really lots of weird things happened in the worklight project.
App descriptor is changed, I wonder where i'm going to change the server IP ? And I also got to know that 6.0 is having some new Geo location toolkit. Where is that unable get it or did not find a way to get it. No proper doc available to me, I have done a lot google on it. If anyone is having any info regarding this ?
Build for remote server; right click the app, run as > build for remote server to change the connection hostname:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/topic/com.ibm.worklight.help.doc/devref/t_transporting_the_app.html?resultof=%22%72%65%6d%6f%74%65%22%20%22%72%65%6d%6f%74%22%20%22%73%65%72%76%65%72%22%20
Geolocation (location services):
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/topic/com.ibm.worklight.help.doc/devref/c_overview_location_services.html?resultof=%22%67%65%6f%6c%6f%63%61%74%69%6f%6e%22%20%22%67%65%6f%6c%6f%63%22%20
The rest of the docs:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp
Related
I am using Intraweb version 14.0.0 on C++Builder 10.2 Tokyo.
I have constructed a test application using TIWServerController and TIWApplication.
When I run the application it shows the controls on the web browser, but I am not being able to get access to the same application using another web browser window of the same kind.
How can I use IntraWeb to serve the same application to several users from different locations of the same local network ?
Thank you very much.
Jayme Jeffman
I have found the problem. The version of IntraWeb (14.00) which was added to C++Builder 10.2 Tokyo community edition does not work the same way as it does on the paid version which has the 14.2.10 attached to the paid edition of C++Builder.
I have asked to a collegue of mine who has the paid edition to build the same test application I have made and everything is now working fine. Including the port number that now is always the same set in the IWServerController instead of start each time with a new one.
(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.
I want to automate the disable access feature of my worklight application ( version :- 6.1.0.2 ) , I have created the below links referring info center links, Can any one please let me know, how can i get the value of gadgetAppID in the below mentioned urls. Also i have added the snap shot of the mysql DB.
Disable App post url below.
http://localhost:10080/AppName/console/api/applications/setAccessRule?gadgetAppId=""&action="disabled"&message="please try later”
Enable App post url below
http://localhost:10080/AppName/console/api/applications/setAccessRule?gadgetAppId=""&action="enabled"&message="please try later”
Thanks
djrekcer.
It is a bit complex in 6.1, see - http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.1.0/com.ibm.worklight.apiref.doc/admin/r_http_interface_of_the_prod_server.html (search for setAccessRule)
Starting with 6.2 there's a RESTful server API for that, see http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.2.0/com.ibm.worklight.apiref.doc/apiref/r_restapi_app_version_access_rule_put.html%23App-Version-Access-Rule--PUT-?lang=en
I am working on developing an application for BB10 using geolocation services. Initially the application was on worklight 6.0 and had following permission set in config.xml:
read_geolocation
After upgrading to worklight 6.1, while accessing geolocation services, I am getting following popup:
local:// wants to access your location. Allow?
This popup was not coming in earlier version.
Also, after migrating to latest ifix pack, I added the folloing permission as well:
access_location_services
Still the issue persist.
AAV,
This was found to be a defect in Cordova.
If you'd like to receive a fix, please open a PMR so a fix for Worklight 6.1 which you are using, could be supplied to you. Provide a link to this question.
Afternoon All,
Here is my context:
I am setting up an existing worklight project with App Envs for IPhone, Android, and Mobile Web.
When using the Worklight Console to preview the apps, I get context root errors from the iPhone app only. (I get the Error: The Server was unable to process the request from the appl...)
When I open the browsers JS console, I see the problem is that the app is requesting the wrong context root. It is accessing the /worklight/ context, which is not there.
The contextroot that does work is the following:
http://localhost:8080/apps/services/api/[APPNAME]/iphone/init
The Context root that the iphone is trying to hit:
http://localhost:8080/worklight/apps/services/api/[APPNAME]/iphone/init
Here is the weird part. The context root is fine for the Android, and Mobile Web environments. Only the iPhone environment is having context root issues.
All three environments are sharing the same application-descriptor.xml file and same server.
Below are some file outputs.
Files below:
/server/conf/worklight.properties
publicWorkLightHostname=localhost
publicWorkLightProtocol=http
publicWorkLightPort=8080
publicWorkLightContext=/worklight/
/apps/[APPNAME]/application-descriptor.xml
<worklightServerRootURL>http://localhost:8080</worklightServerRootURL>
So a couple of questions.
1) When setting the context roots, what is the relationship between the client and server. Do the context roots have to match between the two? Is one a master and the other simply slaves from that and does not need settings?
2) (Somewhat unrelated) While debugging this issue I have come across zero documentation about how to go about "un-deploying" the server in the Eclipse dev ide. (un-deploy the server is right from IBM's documentation) I need to know how to redeploy the server when I make changes to the server settings (worklight.properties). I have seen references to cracking open the war manually, to just stopping and starting the server in the IDE.
Any help is greatly appreciated.
If you are using a context root, it must exist in both worklight.properties and application-descriptor.xml. make sure both match, then re-build and deploy and see if the problem persists.
When using the development edition of Worklight, your server is based on Jetty which is run within Eclipse (it is bundled with the Worklight Studio plug-in you have installed in Eclipse). You do not need to "undeploy" anything. Simply make the changes to worklight.properties and application-descriptor.xml and re-build your application. The changes will make their way to both the server and client.
Do note, though, that using a context root is mainly for when using application servers such as Tomcat, Liberty or WAS.