Developers enjoy expanding freedom to treat mobile devices as industry-standard platforms. Developers should be careful, though, not to judge mobile application tools by merely the same criteria that theyre used to applying in familiar enterprise settings. Mobile devices inhabit environments filled with novel challenges and serve users with rapidly rising expectations.
Obfuscating tools issues
Its important, but not sufficient, for a mobile-oriented tool set to live up to desktop-developer expectations for ease of visual construction of the user interface, clarity of code profiling and debugging, and transparency of access to various data sources. Mobile applications are actually more challenging in these respects because of the growing diversity of form factors that a mobile device may present, the burdens of relatively limited bandwidth and memory, and the need to support both connected and unconnected modes.
Diverse user interface layouts and behaviors are a growing problem for developers targeting Windows Pocket PC-based devices, which used to have a single screen size and orientation but now come in varying screen resolutions with square or 4-3 aspect ratios—and with some of the latter screens switchable between either vertical or horizontal displays. Developers need tools that generate correspondingly flexible code and accurately emulate the resulting application appearance and behavior—as seen in the UI design tool of Microsoft Corp.s Visual Studio 2005 .
The last thing that developers need is for the pendulum to swing back toward writing more code—long a notable drawback of the Java platform compared with the more fully automated development of basic applications on Windows. This threat is forestalled by the Visual Mobile Designer tool in the NetBeans Mobility Pack, which automatically generates considerable back-side code from polished and approachable graphical presentations with conventions familiar to any mainstream application developer .
Mobile device applications must also offer less obvious facilities for developers to streamline and protect their work. Code obfuscation, often a mere parlor trick for developers showing off their prowess in cryptic languages, can offer actual benefits to the mobile application. Java class files, for example, become smaller when obfuscated: Their original identifier names are replaced by cryptic tokens, and other information needed for dynamic programming techniques can be removed from the closed set of classes in a MIDlet suite (a package of Java modules written to the Mobile Information Device Profile specification).
Developers must realize that obfuscation is not a simple yes-or-no decision; it is a process (like file or image compression) that can be carried out at different levels of aggressiveness with proportional side effects. Testing procedures must include post-obfuscation reviews to ensure that all required behaviors remain intact.
Obscured code also becomes less vulnerable to decompilation, protecting a developers intellectual property. Theres a measure of irony, therefore, in the use of the free (under General Public License) obfuscator ProGuard (proguard. sourceforge.net) in the NetBeans Mobility Pack. The open-source NetBeans, in turn, is the foundation of Sun Microsystems Inc.s Java Studio Enterprise 8, which, as of this month, is available as a free download from Sun.
Both Windows and Java developers thus enjoy a high and still-rising level of mobile development support in full-featured, cost-effective tool sets.
Dont forget the users
Mobile users may encounter massive performance penalties or service provider surcharges if a mobile application using wireless connections is extravagant in its use of airtime. Mobile application development tools and project models should compartmentalize the act of connection, so a developer can offer appropriate warnings and choices to the user.
There must also be appropriate exposure of the security measures that a user has available, and this is as much a human-factors decision as a technology choice: Some users may be easily overwhelmed by too much detail, while others may want to have fine-grained control of service use. The Windows Smartphone platform makes these trade-offs clear with its distinction between privileged, unprivileged and untrusted levels—each offering a different balance of safety versus integration among applications and telephony.
Developers should not select tools only for their productivity in enabling desired application functions; they should also consider the paths that competing tools provide toward a convenient, secure and cost-effective mobile application experience.
Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.
