By default in the latest IBM Worklight 6.0 driver it seems the StaticAppProps object is set to:
WL.StaticAppProps = {
"APP_DISPLAY_NAME": "defaultTestApp",
"APP_SERVICES_URL": "\/apps\/services\/",
"APP_VERSION": "1.0",
"ENVIRONMENT": "android",
"LOGIN_DISPLAY_TYPE": "embedded",
"WORKLIGHT_PLATFORM_VERSION": "6.0.0",
"WORKLIGHT_ROOT_URL": "\/apps\/services\/api\/defaultTestApp\/android\/"
};'
There is another property named "APP_ID" and I was wondering a few things:
Why isn't that a default property added to the object? (in a previous version I thought this was by default)
Since the ID is set for the display name by default, is this name used somewhere directly out of box within the app?
Should I expect someone to set the APP_DISPLAY_NAME to something like "My Banking App" or should I always keep the APP_DISPLAY_NAME as the app id?
In general, is the best practice to keep the StaticAppProps object synced with the values used in application-descriptor.xml?
IMO there is no reason for you to touch (alter) those static properties...
The app id is used mostly internally at the moment when creating mobile environments and in other locations within
To change the external name of the app (what you see under the app icon in the device), you change the displayName property in application-descriptor.xml
By default the app name is the same as the id (the value you enter when creating a new Worklight application), but you can change it as described in 3 above.
Related
How can I programmatically add a new category to the navigation bar of the windows files explorer. I mean something like this (For Example)
It is namespace shell extension. NSE must be registered in Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\Namespace\NSE_CLSID. Also it must implement IPropertyStoreFactory and must return True when system requests value of PKEY_IsPinnedToNameSpaceTree property.
For a very special situation I want to store Dojo classes (i.e. the sources) that I load from remote in the localStorage to have access to them in offline situations (we are talking about a hybrid mobile app). I got everything running but dojo.eval won't let me create the class from a string like this
var data = 'define(["dojo/_base/kernel",...'; // class definition as string
dojo.eval(data);
Any idea how to accomplish this?
If you need to have your app run offline, store the resources (css, images, js) in the app manifest. The manifest file looks like the following.
{
"name": "My App",
"description": "My elevator pitch goes here",
"launch_path": "/",
"icons": {
"128": "/img/icon-128.png"
},
"developer": {
"name": "Your name or organization",
"url": "http://your-homepage-here.org"
},
"default_locale": "en"
}
Your app could require hundreds of modules so for performance and manageability of the manifest, you'll want to create a Dojo build which will reduce the number of js files to one or maybe a couple depending on how you create the build.
I finally managed what I was trying to accomplish. However, I found no way to use the localStorage and to load the classes from a string.
The trick is to load the Dojo class source file from remote using XHR, store it using the Cordova File APIs, getting an URL to the stored file and using this URL in the require().
Does what I want and gives me full control over the cached files.
I'm using Worklight Studio 6.0.0.20130917-1749 in 64 bit Eclipse Juno on OSX Lion.
I'm finding that if I put a call to WL.Client.invokeProcedure(), or even WL.Logger.debug() in a jQueryMobile (1.3.1) pagebeforeshow handler, it causes the design portion of the rich page editor to hang when I try to switch to that page.
$("#myPage").on("pagebeforeshow", function(){WL.Logger.debug("loading myPage...");});
If I double click on myPage in the Mobile Navigation view, the page doesn't display, and I am unable to switch to any other page in the app, or do anything with he design pane. The refresh button doesn't fix it (it just tries to load the same page and I am right back where I started) The only thing I can do is to close the html file and re-open it.
This seems to be caused by a missing definition for WL.StaticAppProperites in the code that is run in the RPE. If I look at the html source of the common resources for the app under chrome I see a definition:
<script>
// Define WL namespace.
var WL = WL ? WL : {};
/**
* WLClient configuration variables.
* Values are injected by the deployer that packs the gadget.
*/
WL.StaticAppProps = {
"APP_DISPLAY_NAME": "MyApp",
"APP_ID": "MyApp",
"APP_SERVICES_URL": "\/MyApp\/apps\/services\/",
"APP_VERSION": "1.0",
"ENVIRONMENT": "preview",
"LOGIN_DISPLAY_TYPE": "popup",
"LOGIN_POPUP_HEIGHT": 610,
"LOGIN_POPUP_WIDTH": 920,
"PREVIEW_ENVIRONMENT": "common",
"WORKLIGHT_PLATFORM_VERSION": "6.0.0",
"WORKLIGHT_ROOT_URL": "\/MyApp\/apps\/services\/api\/MyApp\/common\/"
};</script>
There are similar definitions in the generated HTML for the various environments. But looking in weinre, I see that there is no corresponding script injected into the html that is displayed in the RPE. The lack of a definition for WL.StaticAppProperties is causing the code in worklight.js to fail just before the definition of WL.Utils.
Is there any way for me to add WL.StaticAppProps = {} so that this would come before the code that gets injected to load worklight.js?
Is there any other workaround for this problem?
The editor is defining that WL.StaticAppProps property under-the-covers but it is in an additional injected .js file, not in an inline script block like in the running page. It's possible that the location of that script in the editor's markup is incorrect and we will investigate that.
However there's a larger issue here, which is that a page in the editor is not able to make calls to the Worklight server. Because the editor always needs to operate independently of whether a preview server has been published and started, it uses its own mechanism to load web resources into the Design pane. Therefore the origin server is not the Worklight development server and attempted calls to server-side logic will go unanswered. I believe this is more likely the reason for the hang scenarios you see.
A general recommendation is to use the editor to construct the page's UI markup and then start to wire in service calls after the UI is generally complete. At that point previewing the application should likely shift over to the Mobile Browser Simulator and/or native device testing. In order to continue to do incremental UI work in the editor you can also add some temporary conditional logic to avoid (or mock-up) server calls while doing design work, such as:
var designMode = true; // switch to false for real server preview
if(!designMode) {
// your service invocations here
}
I have created a busy indicator and defined the text of the busy indicator globally as below.
WL.ClientMessages.loading = "Please Wait...";
var busyInd = new WL.BusyIndicator('content');
When busyInd.show() is invoked, the loading icon can be shown successfully with "Please Wait...".
Since my mobile app supports multiple language, I have some functions (e.g. setEnglish(), setFrench()) which specify the translated message for different keys. The key WL.ClientMessages.loading has been added to the functions but the message does not change.
Can the text be changed after the busy indicator object is created?
Thanks.
Environment: Worklight 5.0.6
In 5.0.6 this is the behavior of BusyIndicator by design - it is created with some text and uses it throughout its lifetime.
So - a simple way to bypass the problem would be to create a new object after each setLaunguage().
How do you store and retrieve application preferences using the App SDK?
I see in some of the scripts they seem to use use:
rallyDataSource.preferences.getAppPreferences()
rallyDataSource.preferences.update()
rally.sdk.data.Preferences.parse()
Are these documented anywhere?
Thanks...
Those functions are for unsupported and undocumented in the AppSDK. We never were able to make the preference functionality simple enough for us to fully include in the AppSdk.
I would recommend saving the Preferences manually.
Here are some things to remember when dealing with preferences.
Preferences require a name and a scoping parameter.
The combination of the scoping and the name must be unique. This code will show you how to save a preference that is name spaced to your current workspace and namespace it by the apps current id. It will not work external to a Rally App tab unless you replace WORKSPACE_OID with a workspace's object id.
var value = { value : true };
rallyDataSource.create("preference",
{
Name: prefNameKey + rally.sdk.util.Context.getAppInfo().getAppId(),
Workspace: "/workspace/__WORKSPACE_OID__",
Value: dojo.toJson(value)
}, function() {
}, function() {
});