28. Application Architecture
APPLICATION design is art as much as it is science. As with anything else, your skill at MIDP application design is a product of your knowledge, experience, and talent. The best way to improve is practice.
This chapter presents ideas to help you with your application design. There are no absolutes. What works well for one application might be a disaster for another. The purpose of this chapter is to help you get in the right frame of mind to design your own application effectively and imaginatively.
28.1. Use the Strengths of Java ME
Most applications these days span multiple platforms, so the trick is taking advantage of the best features of the platforms you’re using.
The Java ME platform is great for creating clients that are rich and pretty. Your Java ME client should be fun to use, sparkly, and highly responsive. Spend some time and money on this. If you are not a graphic designer, find a good one to make a user interface that people want to use.
Use threads to keep the interface responsive even when your application is thinking about something else. If you must show a wait screen while making network connections, consider a design that allows the user to continue working or playing.
28.2. Use the Strengths of the Internet
The other thing that makes Java ME clients so powerful is their ability to connect to the Internet and other networks. I’ll assume that the Internet is the ultimate destination, but you can build powerful applications based on SMS, MMS, or Bluetooth as well.
The strengths of the Internet are computing power and storage. Based on a request from a Java ME client, the server side of your application can search through massive databases and perform complicated analysis, sending a simple reply to your Java ME client.
In the near term, most mobile data networks are painfully slow. Faster networks are coming, but any application design for current mobile phones should keep network traffic to a minimum and put a lot of effort into effective background network access. Effective failure handling is also important, because there will always be problems with spotty reception.
Google Maps is a great example of a well-designed application. The Java ME client is attractive and highly responsive. The server side consults a large geographic database and creates compact map images on behalf of the client. The server can also combine the power of large databases to find businesses or specific addresses and flag them on the map. The map client remains responsive and useful while requests for more map images are sent to the server.
28.3. Don’t Cram the Desktop into a Java ME Application
This is really the same as use the strengths of Java ME. Don’t take a desktop application or a Web application and try to cram it into a Java ME client. It doesn’t make any sense, and you will end up with something that no one wants to use. It’s like trying to put a trailer hitch on a bicycle or adding a luggage rack to a kite.
The screen size is a big factor in this. Desktop and Web applications are designed to run on a screen that is much larger than a typical mobile device. Keep the screens of your Java ME applications as simple as possible. Users don’t want to be scrolling through lots of data.
The other big factor is input. Desktop computers and browser applications take advantage of a keyboard, which makes it easy to enter text. Mobile phones don’t have this kind of keyboard and, texting jocks notwithstanding, text entry on a phone keypad is painful and slow for most people. Your Java ME client should keep text entry to a minimum or eliminate it entirely.
28.4. Developing for Multiple Devices
Part of the point of MIDP was to finally deliver on the promise of Write Once, Run Anywhere. Unfortunately, reality has intruded on this idyllic vision. It is possible to write an application that will run on many different devices, but you’ll need to work at it. Testing is crucial.
You can choose from three basic approaches for making an application that runs on multiple types of devices:
Use code to adapt to different runtime conditions. In this scenario, you attempt to create a single set of source code that runs correctly on all devices.
Use a single set of source code, but create multiple application bundles with different attribute values for different types of devices. You might also use this approach to put different sizes of artwork (images) in application bundles destined for devices with varying screen sizes.
Use a preprocessor to embed device-specific or device class–specific code. When you build the application, you’ll use the preprocessor to create multiple application bundles for multiple types of devices.
For simple types of applications, especially those that use the prepackaged screens of LCDUI, you’ll have a shot at making a single application bundle that runs on all devices. Custom business clients and other boring applications fall into this category.
As soon as you start getting fancy, with artwork, custom screens, sounds, and other snazzy features, you’ll probably need to build multiple bundles using the second or third approach described above.
28.5. Stretchy Screens
Stretchy screens are one way you can insulate your application from the perils of running on multiple screen sizes. When I say stretchy, I mean a screen that can adapt to different screen sizes without requiring custom artwork.
The prepackaged screens of LCDUI are already stretchy: you can expect to use them without any changes in code from one device to another.
Custom Canvas or GameCanvas screens, however, require some more creative planning. One of the simplest things you can do is display an image centered on a Canvas. This is possible because, at runtime, you can find out the size of the screen as well as the size of the image. Assuming that your image size is not larger than your smallest expected screen size, you can display an image in the center of the screen on a variety of devices. For devices with especially large screens, however, you might need to use a larger image.
A more elaborate scheme would display a border around the entire screen, regardless of its size. In this case, you need to create separate border images for the corners, top, bottom, and sides. At runtime, based on the available screen size, you can place the corners and tile the top, bottom, and sides to create a border that just fills up the screen.
Although you and your artist will need to do a little more work to create this kind of stretchy screen, it is probably less work than either of you would have to do to create multiple versions of artwork to accommodate different screen sizes.
Another alternative to Canvas trickiness is to use Scalable Vector Graphics (SVG), which is stretchy right out of the box. The interactive nature of SVG means that an SVG document can be the entire user interface of your application. NetBeans Mobility even includes support for SVG in its visual designer tool. For more information, try these links:
http://www.netbeans.org/kb/55/svg-tutorial.html
http://blogs.sun.com/lukas/entry/tip_using_svg_menu_in
28.6. Make It Just Work
Making applications that just work is a huge and worthwhile challenge. You can build a powerful, flexible application, but without a great user interface it will not be successful. Consumers have very short attention spans, so if your Java ME application is not immediately useful or entertaining, users are likely to not try it again.
The usability of desktop applications is often measured by the number of clicks it takes to accomplish a task. Consider observing a similar measurement in your Java ME applications. How many button presses does it take to get something done? Are all those presses really necessary? What can be eliminated?
Think about the task your users accomplish with your application and simplify ruthlessly until you’re left with the bare essentials. Make it easy to do simple things, and make it possible to do harder things.
Think about the first thing users see when they run your application. Is it a security prompt? Find out if you can cryptographically sign your application to eliminate the security prompt. Does the first screen ask for an account name or number? Consider having users enter account information in a desktop Web browser or providing personalized MIDlet suites that embed account information as an application property. Is your first screen a network wait indicator? Show something more interesting or useful. Is the first screen a legal notice? Fire your lawyers.
Part of making applications that just work is consistency. Make sure that similar gestures always work the same way. If your application is based on screens, make sure that moving forward one screen or back one screen is always accomplished the same way. If your users navigate through your application using the arrow and select keys, don’t confuse them by throwing in soft button Commands.
28.7. Summary
This chapter presents some of the art and philosophy of Java ME application design. In many cases, a Java ME client connects to an Internet-based server. The Java ME client provides a rich and engaging user experience. The server has hefty computing muscle and can package complex data or analysis as simple results for the Java ME client. Repackaged desktop or Web browser applications will not work well with the small screen sizes and limited input capabilities of Java ME devices. Remember that consumers have a short attention span and will respond well to applications that just work.
Understand the problem you are solving and simplify ruthlessly until only the bare essentials remain. Then make it look pretty.