Worklight 6.2.0, Mobile Web Environment
The Worklight Info Center offers three formulations for logging an analytic message
WL.Analytics.log('my record');
WL.Analytics.log({data: [1,2,3]});
WL.Analytics.log({data: [1,2,3]}, 'MyData');
I am successfully using the first of these, but the other two produce no analytics and my fail() function is not fired.
I see in the online tutorials a further formulation
WL.Analytics.log({_activity: "myActivity" });
this too produces no output.
Question: Are there other formulations that do work?
All calls other than
WL.Analytics.log('my record')
were intended for Analytics features that were not implemented or did not make it into the Worklight 6.2 release. Clearly this is not reflected in the documentation. I will open a defect to either have the logs searchable or have this limitation reflected in the documentation.
If the following call:
WL.Analytics.log({_activity: "myActivity" });
does not result in activities being searchable in the 'Activites' page of the Analytics console, then this is a defect for Worklight 6.2.
I can confirm that all of the above issues are fixed for the next release of Worklight (whether its through code fixes or documentation). If you need some of these fixes backported to a previous release of Worklight, please open a PMR so that we can begin that process.
I would suggest passing in the stringify property as true.
var obj = {name : "bob", age : 100};
WL.Logger.config({stringify : true, pkg: 'myActivity'});
WL.Logger.debug(obj);
If you want a pretty format you could pass in the pretty property
WL.Logger.config({stringify : true, pretty : true, pkg: 'myActivity'});
WL.Logger.debug(obj);
Hope this helps.
Related
Simple question :
if I add documents with push:false to a collection linked to an adapter and then delete them, will they be marked dirty for deleting?
You can use the getAllDirty (Worklight Version == v6.2) or getPushRequired (Worklight Version < v6.2) APIs after the operations (add, remove) to see their state. If the change is not tracked (add w/o tracking the change, remove) you will not get a document back. In that case the intent is that instead of telling the backed "add this document, then remove it" the API just doesn't tell the server about the document. It's a bit more efficient than sending a change over the network that will just get removed.
Otherwise, if the change is tracked as it's the case for add(doc) you will get back something like this as one of the elements of the array returned:
{_id: 1,
json: {id: 1, ssn: '111-22-3333', name: 'Carlos'},
_operation: 'add',
_dirty: '1395774961,12902'}
Where _operation is the last operation performed. When using push (deprecated in Worklight v6.2) it will send that document to the adapter procedure noted in the _operation field (e.g. add => add procedure). The documentation here covers how to work with external data in Worklight v6.2. The API documentation is here and here. There are also examples of the various APIs here. Feature requests here.
wil u pls help out from globalisation of system messages using
WL.ClientMessages.loading = "Custom loading";
which is declared globally in common/js file.
I have gone to worklight docs but i couldnt understand hw to translate it to differnt languages
A device's native system messages can be modified during application start-up by globally assigning a custom value to WL.ClientMessages.messageName before the wlCommonInit() function.
WL.ClientMessages.wlSettings = 'Custom Worklight Settings';
function wlCommonInit(){
As referenced in this post, the loading system message can only be modified when an application does not connect to the Worklight server on start-up.
var wlInitOptions = {
connectOnStartup : false,
System messages are defined in .../wlclient/js/messages.js and can only be modified at start-up in the above fashion. Application specific messages located in common/js/messages.js can be modified at run-time using JavaScript. For examples and additional information please consult IBM's Getting Started Page
WL.ClientMessages.loading = Messages.wrklight;
Will cause an error because the application messages in common/js/messages.js have not been loaded when this statement executes. To translate system messages I recommend using the device language and locale to select a language from a set of conditional statements. Here is a brief example:
if(WL.App.getDeviceLanguage() == 'en' && WL.App.getDeviceLocale() == 'en-US') {
WL.ClientMessages.loading = 'Custom Loading Message';
}
I found Worklight JSONStore has no size limit by Worklight runtime.
Does WL JSONStore API return error/error code if you add to collection and hit the size limit of your mobile device?
Yes, you should get an error, but it will be a generic one like PERSISTENT_STORE_FAILURE (-1). I recommend testing this as part of your regular unit, funcional, etc. tests and QA process for your application. Report back if you see something unexpected.
Recently I answered a similar question "Can the JSON offline device store be size restricted?". I'll add my answer here because I believe it could be helpful.
While this functionality is not baked into the core API, it should be fairly straightforward to implement.
JSONStore has an enhance method you can use to add functions to the JSONStoreInstance prototype. There's an example inside that should help.
Cordova has a File API
Note: "size: The size of the file in bytes. (long)"
JSONStore stores its data here:
iOS: [app]/Documents/wljsonstore/jsonstore.sqlite
Android: /data/data/com.[app-name]/databases/wljsonstor/jsonstore.sqlite
I talked a bit about that file in these StackOverflow answers:
What are the recommended ways to debug Worklight applications?
JSONStore difference between 'number' and 'integer' in searchFields
Check the file size of jsonstore.sqlite using Cordova's File API before you add more data to your JSONStore collection.
Basically you would do something like this:
if(checkFileSize(collection.name+'.sqlite') < LIMIT){
collection.add(...);
}
Using enhance you can wrap that logic into its own method (e.g. collection.addWithSizeCheck(....)) that checks the file size and calls collection.add(...).
Note that the default username is jsonstore, hence jsonstore.sqlite. If you pass a username to init it will create a new .sqlite file with that username.
Does anybody know what if direct update updates everything that lives in the common directory structure. I used the same code base for multiple apps, the only change being certain settings within a js file that tells the application how to act. Is there a directory i can put that js file that would be safe from the direct update feature?
I cant seen to find any specific information on IBM's website.
I think you guys need to be careful which terms you are using in order to not confuse people who may be looking for similar help.
Environments are specific to the OS you are using. iOS, Blackberry, Android, and etc. environments.
Skins are based on the environment, and aren't generic to all platform. When you create a skin you must choose which environment you are running in.
So to correct some, direct updates will update all skin resources in targeted environments.
For example: You have an app with Android and iOS versions
When you create skins, you are creating essentially a responsive type of design to your parameters. For instance, if you have a 2.3 vs 4.2 Android OS, you can set a look and feel for both. However, these utilize a single web resource base. The APK would be the same for both versions of the app (by default) and have 2 available skins. On runtime utilizing IBM Worklight's 'Runtime Skinning' (hence the name) it goes through the parameter check for the OS and loads that skins overriding web code.
You could technically override all of the web code to be completely different for both skins, but that would be bulky and inefficient.
When you direct update you are updating all the resources of that particular environment (to include both skins), not the common folder/environment.
So an updated Android (both skins) would have updated web resources (if you deployed the android wlapp) and an iOS version would stay the same.
If you look at the Android project after build (native -> assets -> www -> default or skin) you can find the shared web resources generated by the common environment. However that is only put there every time you do a new build.
In the picture, I have an older version of the Android built for both skins on the left. On the right is a preview of the newer common resources after deploying only the common.wlapp. So you can see that they are separate.
Sorry if it was long winded, but I thought I would be thorough.
To answer the original question, have you thought of having all the parameters of the store loaded from user input or a setup? If you are trying to connect to 3 different store, create some form for settings control that will access different back ends or specific adapters. You could also create 3 different config.js that load depending on the parameters that you set so that you set. The other option is to set different versions of your apps specific to the store.
Example. Version 1.11, 1.12,1.13 can be 3 versions of the same app for store 1, 2, & 3. They can be modified and change and have 3 sets of web resources. When you need to update, jump up to version 1.21, 1.22,1.23. It seems a bit of a work around, but it may be your best bet at getting 3 versions of the same app to fall within the single application category. (keep 3 config.js types for modifying for the 3 stores).
To the best of my knowledge Direct Update will update every web resource of the skin you're using (html, css, js). However, I'm no expert with it.
If you're supporting only Android and iOS applications and need a way to store settings I recommend JSONStore. Otherwise look into Cordova Storage, Local Storage or IndexedDB.
Using a JSONStore collection called settings will allow you to store data on disk inside the app's directory. It will persist until you call one of the removal methods like destroy or until the application is uninstalled. There are also ways of linking collections to Worklight Adapters to pull/push data from/to a server. The links below will provide further details.
the only change being certain settings within a js
Create a collection for your settings:
var options = {};
options.onSuccess = function () {
//... what to do after init finished
};
options.onFailure = function () {
//... what to do if init fails
}
var settings = WL.JSONStore.initCollection('settings',
{background: 'string', itemsPerPage: 'number'}, options);
You can add new settings after initCollection onSuccess has been called:
settings.add({background: 'red', itemsPerPage: 20}, options);
You can find settings stored after initCollection onSuccess has been called:
settings.findAll({onSuccess: function (results) {
console.log(JSON.stringify(results));
}});
You can read more about JSONStore in the Getting Started Modules. See Modules: 7.9, 7.10, 7.11, 7.12. There is further information inside the API Documentation in IBM InfoCenter. The methods described above are: initCollection, add and findAll.
Since version 5.0.3 I think, direct update will not update all the webresources, only those of the skin you are using.
say you have skin def and skin skin2
you are on def
make change to def on the server -> you will get a direct update for
def only
make change to skin2 on server-> no direct update for you.
you are on skin2:
make change to skin2 on server -> direct update for skin2 only
make change to def javascript which also resides on skin2 ( and therefor end result is def+skin2 concatination), update only skin2
make change to def,just to a picture(also checking pic extension from application-descriptor: ") -> no direct update
Thats how direct update works.
Please also share some more details about what is the problem, I see you use a js file, where do you change it? what do you mean excatly, give a better (simplified) real life example, because it is unclear what you are trying.
I need a good example of using the LookbackAPI to get the data for a burn up chart. I see some limited questions and responses on the API but no examples on how I would use it to do so. I need to get the current scope on story points and story points completed.
Sorry for the scarcity of available examples. More and better examples will be coming as the LBAPI beta matures. I'd definitely recommend that you become familiar with the Lookback API (LBAPI) Documentation, as there are good examples there for formulating queries.
For a burnup, let's say you want to get the state Snapshots for an Iteration going from 15-Jan-2013 through 30-Jan-2013, and that the Iteration applies to a Project hierarchy that is four-deep. The following LBAPI query would obtain the PlanEstimate, ToDo, and Schedule State for Stories scheduled into that Iteration:
{
find:
{
_TypeHierarchy:"HierarchicalRequirement",
Children:null,
_ValidFrom:{
$gte:"2013-01-15TZ",
$lt:"2013-01-30TZ"
},
Iteration:{
$in:[
12345678910,
12345678911,
12345678912,
12345678913
]
}
},
fields:[
"PlanEstimate",
"ToDo",
"ScheduleState"
]
}
Where:
$in:[
12345678910,
12345678911,
12345678912,
12345678913
]
Are the ObjectID's of the Iteration called "Iteration 1". It's probably easiest to get these Object ID's from a standard WSAPI query on Iterations: (Name = "Iteration 1"). For Iterations copied into a four-deep project hierarchy, we would see the four Iteration OID's similar to the above.
For charting, the toughest part right now is an easy way to deal with the Time-Series data. The most robust way to query and process LBAPI data currently is by working directly against the REST endpoint and processing the returned JSON results in your own code.
With Javascript apps, for processing the data and turning it into a Chart, the preferred toolkit is AppSDK2, specifically the SnapshotStore.
For Javascript apps, the Lumenize javascript library is separate from LBAPI, but was developed by Rally's director of analytics and is bundled in the SDK. You can find some examples of using LBAPI and Lumenize to produce charting as part of some Rally-internal and Rally-customer Hackathon projects here:
https://github.com/RallyHackathon
Please be cautious with these examples for a couple of reasons:
Several aspects of the Lumenize namespace will be changing/renamed for clarity
There's a bug in the current version of Lumenize where its timeSeriesCalculator does not correctly account for stories deleted or reparented.
Hopefully there will be an updated version of AppSDK2 bundled and released soon to consolidate the Lumenize namespace and resolve the bug, so that there's better glue between AppSDK2 and LBAPI for Javascript App development.
Unfortunately, the .NET, Java and Python toolkits have not yet been updated to support the Lookback API. As a result, you'll have to do an HTTP POST to the Lookback API's REST endpoint directly, with a body similar to the one Mark W listed above and Content-Type 'application/json'.
I'd recommend using the Chrome extension 'XHR Poster' to experiment with what you're sending from a browser:
https://chrome.google.com/webstore/detail/xhr-poster/akdbimilobjkfhgamdhneckaifceicen