IBM Worklight – Part 3: Best Practices

So far, we have looked into folder structure, logging device information, splash screen, Offline Mode, State Manager and Navigation. In this final part, we will look into callbacks, source control and finally put together all our learnings and come up with an InitPage.js that implements all Best practices discussed so far.

1) Callbacks:
Callbacks form an essential part of JavaScript and it is always a good practice to keep callbacks clean and simple. There is not much material on the Web about DOJO callbacks other than dojo.deferred. Here is a simple callback function in DOJO that can be used as an example:

The following function will initiate a callback i.e. call getCurrentLocation – wait for it to execute and then call drawMap with obtained value rather than proceeding asynchronously.

2) Source Control:
worklightServerRootURL in application-descriptor.xml needs to have a process in place to customize Worklight URL for each environment ${local.IPAddress} is pretty generic and may not work when environment is clustered.

iPhone and Android folders have nativeResources folder which is a great place to have all icons for the app. When checking in the project into Source Control, it is a best practice to check-in common folder (source code) and just nativeResources folder in iPhone, android and other devices if any (windows, blackberry). It is always a good practice to have native code generated every time on developer workstations and through build scripts from common code. If assets under js folder are modified there is an option to check them in as well but if an App is running the same codebase, the folders in blue are the ones that must be checked into Source Control.

application tag has an id field which should match mainFile name in application-descriptor.xml i.e. if the id says ‘hello’ mainFile should be hello.html Altering the id field means changing the main file name as well. If they are not in sync, the App might have issues running on various platforms as native code is generated based on this assumption.

If dojo is employed, make sure the app.id in build-dojo.properties is the same as id in application tag 

Putting it All Together: After implementing the best practices we talked about in the 3 part series, an InitPage.js looks like the following:

The above snippet would be the skeletal structure of main JavaScript for a Worklight Starter application. However, the actual implementation would have more controllers, variables and utility methods. This structure makes the Application versatile and easy to adapt to changes.

Conclusion:

I hope you have enjoyed this 3-part blog series on Worklight best practices. If you have any questions or would like more information, please email solutions@prolifics.com. For more information about Prolifics, please visit www.prolifics.com.

If you would like to connect with me, please add me on LinkedIn and follow me on Twitter! I would love to hear your thoughts on this series and your experiences with IBM Worklight.

Laks Sundararajan is a Solution Architect with Prolifics and a key member of highly specialized team working on IBM WebSphere Portal, Content Management and Collaboration technologies. He has led the implementation of many global projects using IBM WebSphere Portal and has extensive background in design and development of enterprise portals. He specializes in providing Enterprise SOA solutions leveraging WebSphere Portal, Content Management, Tivoli and Mashup’s. He holds Masters in Information Technology from Carnegie Mellon University and a Graduate Degree in Engineering from BITS, Pilani.