In the initial part of the series, we focused on the folder structure, logging device information and splash screen. In this part, we dive deeper into core Worklight features and focus on Offline Mode, State Manager and Navigation. Let us get right to the subject.
1. Offline Mode/ Processing:
Even though Mobiles are supposed to have 24*7 connectivity; reality is different. Given that every Application should implement Offline Mode. To enable Offline Mode, modify body tag of InitPage.html as follows:
Now, implement doConnectionFailure() method inside InitPage.js
Additionally, have a global busy indicator that could be used across pages to show processing cycles. This will ensure in uniformity across applications.
Applications can then show/hide busy indicator as follows:
2) State Manager:
Mobile Applications need to manage state on client side. This could be achieved through a State Manager that intercepts each View and stores relevant information globally. A code sample that illustrates the same is shown below:
The following snippet is present in InitPage.html to define the view name.
3) Navigation:
Navigation is key part of Mobile Applications. Implementing a versatile framework is essential for a quality application. Content fragments should be isolated so that they can be sourced from external systems if needed. It is also a best practice to keep UI in small pieces as opposed to a single large HTML serving up the entire application.
A sample snippet that implements recommended navigation framework in InitPage.html containing to 2 pages: demo1View.html and demo2View.html is shown below:
Now, demoView.html contains the following snippet to take the user back to InitPage.html. Note that mainView corresponds to view name in InitPage.html. For more details on views, refer to StateManager.
If the snippets are present in same page moveTo should be employed in both places. The above example is for navigating between fragments.
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.
Wednesday, September 26, 2012
Friday, September 21, 2012
IBM Worklight Series – Part 1: Best Practices
IBM Worklight provides an open, comprehensive and advanced mobile application platform for smartphones and tablets, helping organizations of all sizes to efficiently develop, connect, run and manage HTML5, hybrid and native applications.
Worklight Supports the following frameworks for developing HTML5 and Mobile Applications
Out of the above frameworks DOJO is widely used by IBM in their Portal and BPM suite of products and signifies IBM’s choice when it comes to RIA Frameworks.
In this 3 part series, we talk about Best Practices for developing Worklight based HTML5 and Mobile Applications in general. Note that some of them specific to DOJO Framework. However, parallels can be drawn and similar practices could be employed for Sencha and JQuery frameworks as well.
In the initial part, we focus on the folder structure, logging device information and splash screen.
1) Folder Structure:
Following is the recommended folder structure for Worklight Application (common folder)
Creating controllers and widgets folder under js folder helps in better organization of JavaScript assets as opposed to a single folder. Having a folder for html assets provides a clean structure and avoids them residing directly at root level.
When a Worklight built HTML5 Website or Mobile Application loads, InitPage.html or rather defined under application-descriptor.xml is invoked. A JavaScript file with same name InitPage.js contains necessary scripting information for the framework. Interactions between various components are shown below for better understanding. We will be discussing more on Web Framework in next couple of installments.
For the purposes of this discussion we call the as InitPage.html and main JavaScript file as InitPage.js. Normally, these are named as per Application created i.e. An Application with name ‘HelloWorldApp’ would have HelloWorldApp.html and HelloWorldApp.js as main HTML and JavaScript files.
2) Logging Device Information:
It is always a good practice to log device specific information for troubleshooting/ audits given the vast number of platforms and devices available today. This could be accomplished by calling the simple function below from a dojo listener in InitPage.js
3) Splash Screen/Text:
Mobile Applications have an initial splash screen that is displayed when an Application is launched. Following that, the initial page (in this case InitPage.html) is loaded. While the page is loaded, it might take a few seconds for framework libraries and CSS to load and user may experience a noticeable blip. To prevent this from happening, it is always a best practice to show some text/image when InitPage.html gets called for first loaded (call it as secondary splash screen/text). This is accomplished as follows:
Add the following snippet to InitPage.html
Add the following snippet to InitPage.js and call the function from dojo listener after page is loaded
In the second part of the series, we will be looking at some core features like Offline Mode, State Manager and Navigation.
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.
Worklight Supports the following frameworks for developing HTML5 and Mobile Applications
- DOJO
- Sencha Touch
- JQuery
Out of the above frameworks DOJO is widely used by IBM in their Portal and BPM suite of products and signifies IBM’s choice when it comes to RIA Frameworks.
In this 3 part series, we talk about Best Practices for developing Worklight based HTML5 and Mobile Applications in general. Note that some of them specific to DOJO Framework. However, parallels can be drawn and similar practices could be employed for Sencha and JQuery frameworks as well.
In the initial part, we focus on the folder structure, logging device information and splash screen.
1) Folder Structure:
Following is the recommended folder structure for Worklight Application (common folder)
Creating controllers and widgets folder under js folder helps in better organization of JavaScript assets as opposed to a single folder. Having a folder for html assets provides a clean structure and avoids them residing directly at root level.
When a Worklight built HTML5 Website or Mobile Application loads, InitPage.html or rather
In the second part of the series, we will be looking at some core features like Offline Mode, State Manager and Navigation.
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.
Subscribe to:
Posts (Atom)