Enterprise Data Mobilization: Part 4

By  Armeen Mazda, CEO, Appeon — January 25, 2010

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 Part 3, we explored the next steps in the implementation process, including client-side caching, coding business logic, and building the user interface. In this final installment we'll discuss the remaining key steps to take for a successful impelementation and deployment.
Implementation: Coding Business Logic
Data 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.
Implementation: Building the User Interface
Desktop application developers 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:
  • 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.
Deploy to Users
Before you can deploy your application you must have it digitally signed. You can complete this signing process within the BlackBerry JDE by opening Build > Request signature. A key needs to be obtained from RIM so that you can use the BlackBerry Signing Authority Tool to sign your application. Digitally signing your application is important for two reasons.
First, it ensures the application has not been altered by a third-party with malicious code. Secondly, it will be compatible with the default BlackBerry settings ("Disallow Third Party Application Downloads IT policy rule").
This rule can be easily turned on/off in the Group IT Policy on BES by the system administrator. Once your application is ready for deployment, you will have either a .ALX or .JAD file plus one or more .COD or .JAR files. The .ALX and .JAD files are essentially index or descriptor files. They specify what .COD files are required to run the application. The .COD and .JAR files are compiled version of your application. The file type you use will be mandated by your deployment type. Generally speaking, there are 3 common ways to deploy your application to users in a corporate setting:
  1. Pushing the application from the BES down to the device.
  2. Using the BlackBerry Web browser.
  3. Using the BlackBerry desktop software.
In order to push the application from the BES down to the device, you will need to produce a .ALX plus one or more .COD files. Next you will need to add these files to the shared folder on BES. Then you will index the application using the application loader. Finally share the application folder. For more details, please refer to the BlackBerry documentation.
Another option is allow the user to point the Web browser of their BlackBerry to the .JAD file, and the application installs automatically. You will need to produce a .JAD plus one or more .COD or .JAR files. Next, you will copy these files to a folder on your Web server.
Lastly, for convenience sake, we suggest creating a simple HTML page with a hyperlink to the .JAD file. This way the user just bookmarks the Web page as single entry point for future upgrades. The final option we will cover is the BlackBerry Desktop Manager. The user will need to obtain a .ALX file plus one or more .COD files (as required by the application). Then connect the BlackBerry device to a PC via USB and start the BlackBerry Desktop Manager.
Using the Application Loader in the BlackBerry Desktop Manger, the user selects the .ALX file, which will automatically select the appropriate .COD files and install to the BlackBerry device. This is the least recommended approach as it is prone to user error and requires a PC to be available.
There are numerous paths and options while you look into enterprise data mobilization. This article just uses a real-life project in the hospitality industry to demonstrate one way to mobilize enterprise data with Sybase database tools on the RIM BlackBerry.
It may very well be that you can model your enterprise data mobilization as outlined in this article, or at minimum this will serve as a starting point for things you should consider. Not reinventing the wheel was key that contributed to our project coming in on-time and under budget.
We did not attempt to develop our own storage solution, data synchronization solution, or work with lesser known mobile technology and devices. By using the SQL Anywhere Suite (including UltraLiteJ) we could focus all of our energy on the mobile application development itself. By developing for the BlackBerry device with its JDE in Java, we ensured that we were not embarking on uncharted waters.
Most importantly, a plethora of developer resources are available, from other Java mobile and BlackBerry developers, such as this article you are reading now! Budget and timeline set aside, the bottom line was that we were successful. True success is measured by the user's acceptance of what we build as developers and the business problems we solve.
In this example, hotel management and maintenance staff had a fast and easy-to-use application, shown at right, that enabled them to effectively work off of the same data as standard online Web users (e.g. front desk staff). Moreover, the application could be operated anywhere on the property, such as elevators, basement, and outside.
However, such a deployment is not limited to the hospitality vertical -- any facilities management or other type of organization would benefit from mobilizing key enterprise data.
Armeen Mazda is CEO of Appeon.


comments powered by Disqus

RATE THIS CONTENT (5 Being the Best)

Current rating: 0 (0 ratings)



Must See


Tablets in the Enterprise

Justifying the addition of another device to the mobile stack became a challenge as the popularity of tablets grew, along with the adaptability and appropriateness for the field. Now, there is no question. Tablets are here to stay and they are enabling the business more than ever.