Enterprise Data Mobilization: Part 3

By  Armeen Mazda, CEO, Appeon — December 17, 2009

In Part 1 of this tutorial series we explored the first steps to take to mobilize enterprise data. In Part 2 we discussed application design considerations as you architect your system. In this installment, we'll explore the next steps in the implementation process, including client-side caching, coding business logic, and building the user interface.
Client-side Caching
As a business-of-line application, although you try to minimize making the application heavy with too much data or resource-intensive code, sometimes there is only so much you can work with when your customer or users demand certain functionality. For example, the screen at left contains nine drop-down lists. The data in each list can be filtered automatically against your selection in other eight lists. Making matters worse, some of the drop-down lists retrieve hundreds of rows of data.
This type of activity is very resource intensive on the BlackBerry. Each selection will trigger a data query to the mobile database and a change in any list will trigger a new query to the database for another round of filtering. This performance issue is exacerbated by the fact that this is a frequently used screen. The user opens this window numerous times within a short period, and thus it will become really unproductive for the user to have to constantly wait.
To address this issue, we built a local caching mechanism within the mobile application to improve the performance of this specific window. There are different ways to implement client-side caching. The way we chose was to define a static variable and package the heavy object/data in this variable. The first time the user opens this screen, the instance of this window containing 9 lists and related data will be stored into a static variable.So next time the user opens the same screen, the application will check whether the instance has already been created or not, and then use these instances or retrieve the data directly from the memory. Below is a code example to illustrate this concept.
//Define the static variable "monitorScreen
public static MonitorScreen monitorScreen;
. . .
//store the instance into "modifyScreen"
public static ModifyScreen getModifyScreen(Screen parentscreen, Connection conn, S_pkhe_call
if (modifyScreen==null)
modifyScreen=new ModifyScreen(parentScreen.conn.s_pkhe_call);
return modifyScreen
. . .
//Reuse the instance stored in the variable when reopening the window
if (HEScreens.modifyScreen==null) { //first creat
else {
. . .

The variable, which is the cache, is stored in the memory. Mobile devices such as BlackBerry have limited amounts of memory so you don't want to implement such caching for every screen, especially if the user will be running multiple mobile applications simultaneously. Only frequently used screens that have a serious performance issue would be good candidates for such client-side caching.
Once the user exits the application, the cache will be cleared from memory and will no longer consume system resources. 
Coding Business Logic Data
This is a big part of a transactional mobile application, but chances are you will need to have some logic coded as well. It may be some user interface logic, for example for validation or error handling, or it may be business logic, for example performing some calculation or mandating a process workflow. Java programming on the BlackBerry is quite powerful and you can code sophisticated logic.
But it is important to keep in mind that the performance of mobile devices is limited due to smaller hardware and limited battery life. The following are some best practices for Java development on the BlackBerry:
  • Use primitive types (such as int or boolean) instead of objects (String or Integer) whenever possible. This will minimize your memory footprint.
  • Set object references to null when you are finished using them. This will minimize your memory footprint.
  • Reuse objects as much as possible. This will minimize your memory footprint.
  • Use local variables since access to local variables is more efficient than access to class members.
  • Make classes final. When you create code libraries, mark classes as final if you know that developers will never extend them. The presence of the final keyword lets the compiler generate more efficient code.
  • Use int instead of long. In Java, a long is a 64-bit integer. Because BlackBerry devices use a 32-bit processor, operations run two to four times faster if you use an int instead of a long.
  • Avoid garbage collection. Avoid calling System.gc() to perform a garbage collection operation because it might take too much time on BlackBerry devices with limited available memory. Instead, let the BlackBerry JVM collect garbage for you!
  • Use static variables for Strings. When you define static fields (also called class fields) of type String, you can increase application speed by using static variables (not final) instead of constants (final). But beware, the opposite is true for primitive data types, such as int.
  • Avoid the String(String) constructor. It creates an unnecessary String object that is a copy of the string that you provided as a parameter.
  • Optimize division operations. Division operations can be slow on BlackBerry devices because the processor does not have a hardware divide instruction.
  • Perform casts using instanceof. Use instanceof to evaluate whether a cast succeeds instead of catching a ClassCastException. Using instanceof is faster than using a try/catch block. Use the try/catch block only when a cast failure is truly an "exceptional" circumstance.
Building the User Interface
Desktop applications developer may get used to tabs and fancy data grids, but none of these are available on the BlackBerry (out of the box). Through custom Java coding you can develop more sophisticated visual objects, but this is time-consuming and can affect the application performance (probably why RIM left these out in the first place). So, really, there needs to be a deep appreciation for the hardware and screen size of mobile devices.
In other words, you should not always think about "replicating" the same user interface but "redesigning" a new front-end to meet the usage of the mobile user. Here are some tips to consider in your user interface design, which are reflected in the example at right: 
  •  The user must scroll from field to field. So it is not good practice to clutter the screen with unnecessary fields. At the same time, you can only work with one screen at a given time (similar to HTML you go page-by-page), so putting too few fields on a screen will require the user to work with multiple screens to get a single task done.
  • Buttons, such as OK, Cancel, Save, etc. should be used thoughtfully. The user will have to scroll through every field to reach any buttons at the bottom of the screen. In some cases this is desired behavior if you wish to force the user to read each field/question.
  • But in general, it is good idea to make such functionality available in a pop-up menu.
  • Ensure the text size of field names and controls are adequate size. Mobile screens are small and most devices do not have the zooming capability as seen in the Apple iPhone.
  • Keyboards are small and some devices do not have a full QWERTY keyboard. So ideally your UI should not require the user to type a lot of data.
  • The user should be able to just click, scroll, click. You can achieve this by utilizing checkboxes, radio buttons, drop-down lists, etc. as much as possible.
  • BlackBerry devices have different types of models and screen sizes. So you should test the user interface on each model and the easiest way to do this is with the simulators provided in the BlackBerry JDE.
In Part 4 we'll explore the steps to take for user deployment and other best practices.


comments powered by Disqus

RATE THIS CONTENT (5 Being the Best)

Current rating: 0 (0 ratings)



Must See


Mobility Outlook 2015: People & Process Coming Together

The progression of mobility in the enterprise so far is akin to a child entering its early awkward teenage years, according to 451 Analyst Chris Marsh. How will this change in 2015? What trends need to go and what's coming? This exclusive report explores looks ahead and Marsh provides practical recommendations.