The fast worldwide proliferation of small devices like cell phones and PDAs presents an opportunity for application developers to deliver useful products to a new and growing market. In order to be successful in the small device market, however, developers must follow an efficient design process.
The design process for MIDP (Mobile Information Device Profile) applications, small Java programs for portable devices like cell phones, largely resembles designing software for any platform. With MIDP, however, you'll manage a few points in the design process a bit differently.
In this article, I'll examine the entire process of developing software for mobile devices. First, by exploring how to brainstorm the idea along with some tips on market research. Next up is the requirement analysis and technical designing phase, followed by the actual system implementation. Finally, before you deem your application ready, you'll thoroughly test it.
In the beginning there is always the idea. During the brainstorming phase, you'll come up with many different ideas -- some good, some not so good. Keep in mind that ideas, when first considered, lack maturity, so you must process them before they can be properly evaluated. Always take your time when thinking these plans through.
Sometimes it's worthwhile to hire a consultant who can evaluate your business ideas and give you opinions about the market for your application. An outsider can more easily see the whole picture of you, your company, and its products, so they might spot a great product for your portfolio.
But what if you don't yet have an idea? Pick up one of the numerous books about discovering business concepts to learn how to brainstorm and evaluate them. Such books all seem to have one common recommendation -- always carry a pen and notebook with you. As you go about your day, write down every small idea that comes up. Go through your notebook every once in a while, pick the best ones, and think about them more thoroughly. The ideas are out there, you just have to find them.
OK, let's assume you've envisioned a great service. You'll next do a little market research. Are you the first in the market? How many competitors already exist? Are they large corporations? Are their products or services exactly like yours, or could you differentiate yours from theirs a bit?
Also find service providers, operators, and retail stores who would be willing to sell your application to end customers. If you're selling software for PDAs, you can sell from your Web site, but that's not usually possible for cell phone-based applications because you'd have to first get customers to your Web site and then have a way to charge them.
After you've verified the market demand for your application, and you don't see too many competitors, it's time to move to development.
There are pros and cons about each of the various software development processes. The examples below use a simplified version of the Rational Unified Process® (RUP), which is largely based on iteration. RUP incorporates features from numerous other processes, making it relatively easy to adopt. Figure 1 shows RUP's fundamentals. The arcs of the circle all have names in RUP (Inception, Elaboration, Construction, and Transition), but in this article I'll use RUP just as a backbone of the process and avoid focusing on the details.
Figure 1. The iterative software development process
Once the project (developing a system) has been selected to start, the iterative process begins by gathering some or all of the project requirements, which you'll then prioritize. The highest priority requirements are designed and implemented on the first iteration. The design team releases a working version of the software at the end of every iteration. The next most important requirements are designed and implemented in the second iteration, again followed with a working version release. The cycle continues until the software is ready.
You gather the most important requirements during the first iteration. Requirements can usually be divided into functional and non-functional groups. The functional requirements can be documented as use cases, which you describe by drawing a use case diagram and writing a use case description. This should be done for every use case. The use case description explains what happens, the pre- and post-conditions, and so on. The functional requirements in mobile applications are similar to the requirements in other applications.
Figure 2 shows the use cases for a scheduler application. The stick figure on the left, called an actor, represents the roles of the end user. A mobile application can have either one role or several roles. (On the server side, in contrast, the system frequently has different kinds of users.) The ellipses on the right are the actual use cases. The text inside each use case states its name and describes generally what happens in the use case. In a way, you can think of use cases as user-initiated actions in the application.
Figure 2. A use case diagram of a scheduler application (a small part of the whole diagram)
Moving on, you can also call the non-functional requirements quality requirements. Quality requirements can be related, such as the system's allowable down time, the speed of executing important functions, or the ease of further development. In mobile applications, such requirements could relate to the application's speed and ease of use. These requirements can prove hard to measure, but you should always present them to ensure that you're focusing on what's important and can actually test that the requirements are met.
After you've gathered your requirements, go ahead and prioritize them, starting with the most important or critical requirements. By prioritizing in this way, you get the most difficult requirements completed and working first.
As your last phase before the actual design of the application, you create the architecture for the entire application. The architecture should show the application's structure and its most important design decisions. With mobile applications, the main question is whether the application will be a stand-alone application (running in the cell phone with no server-side parts) or be a networked application (with one or more servers). If your application is networked, you must further ask whether it needs to store any information on the client side. One advantage of mobile phone-based applications is that they can store information and not have to continually connect to the server.
At its best, the architecture acts as a guide showing the designers and programmers how to do their jobs. With the architecture in place, you're aiming for standard guidelines and design principles for the application's various parts -- even for large software projects. Application development projects have no room for soloing designers.
After you determine the application's most important requirements and create the architecture, you can start the detailed design. This includes creating or finishing class diagrams and designing classes in more detail.
Make a sequence diagram of each use case to clarify what classes and actions (methods) you really need. One good way to find methods in classes is to find the most important classes, then do the sequence diagrams. As you go through the use cases, determine which classes must be involved in the function.
The sequence in Figure 3 shows how classes would implement the use case in a stand-alone application. The AppointmentControl class acts as the control class, which has a method for adding new appointments. First the method checks to see if all chosen users are valid (in the system), returns a vector of valid users, and adds the appointment to all of those users.
Figure 3. A sequence diagram of Add a new appointment use case
Figure 4 shows another version of the same use case, one designed for a mobile application that stores the information on a server. The application in the mobile phone presents the UI for the user and connects to the server to add the appointment. The server checks the users, then saves the appointment. Of course, this example design lacks the detail needed for real life.
Figure 4. A sequence diagram for a mobile scheduler application
With MIDP, the connection between the client and the server would be an HTTP connection because that's the only supported connection protocol according to the specification. You would have to plan the interface you'd use; that is, the parameters you would pass to the server.
In some situations, the Universal Modeling Language's (UML) state diagram or activity diagram can help more than a sequence diagram. That's fine -- use whatever is necessary to express your thoughts.
If you're developing for MIDP, be aware that a completely object-oriented design will not represent the best solution. Each created object requires some memory. Because the device's available memory is very limited, your application should be economic when creating objects. A good solution -- design classes slightly larger than usual and add more functionality into fewer classes. That way, the application's size and amount of created objects will remain smaller.
People often forget to write test cases and manuals while they're in the design phase. It is important to think and write down how you will test all the features and requirements you have in your application. Quality requirements can be especially tricky to test.
Now comes the hard part: the actual job of coding, in which you take your existing designs and implement the system. With good designing skills, you shouldn't need to change the designs while implementing the system. Sometimes, however, it is necessary to change a part of the design in order to implement the system's requirements. In such cases, don't forget to update your designs too; otherwise, you'll have an outdated design and software with no documentation.
Along those lines, you should also write the manuals while you're implementing the application so that your manuals will be correct and easy to follow. Remember, also, to perform unit testing and write down the test results. To help, find software to manage the whole testing process. That way, you can actually design and execute the test cases instead of just clicking the application and thinking that it seems to work. While developing mobile applications, it is crucial to test your application in the real device frequently.
Also, pay careful attention to the installation. With cell phones and PDAs, users will not be computer experts, so they expect the software to install easily and work immediately. With MIDlets (MIDP applications), however, you cannot easily affect the installation because MIDP has OTA (Over-The-Air) delivery, leaving the installation details to the service provider selling the application.
When you've got your software ready and documented, and you've created the necessary product information (brochures, photos, and so on), you're finally ready to release the application.
If you haven't already contacted the possible partners you listed in the market research phase, do so now. Send them information, (in PDF format, for example), offer test versions of the software, and be patient and persistent in convincing them. If you have existing clients (end-users or distributors), they are, of course, easier to approach.
In this article you have looked into the development of mobile applications, with a special focus on MIDP applications. The software development process can resemble that of server software, though flavored with some additional thoughts and considerations. As always, good organization, along with careful design and documentation, will help you create a superior product.
- Learn even more about MIDlet development in the author's book, "Professional Mobile Java with J2ME".
- For beginners, Mikko Kontio also wrote on architectures in pervasive computing, in "Wireless application development for a changing world (developerWorks, July 2003).
- Check out Kyle Gabhart's useful article, "Persistent data management, Part 1" (developerWorks, April 2003).
- To learn more about MIDP's Generic Connection Framework, John Muchow's article on "Network support in J2ME/MIDP" (developerWorks, January 2004) could prove helpful .
Mikko Kontio works as a technology manager for the leading-edge Finnish software company, Enfo Solutions. He holds a master's degree in computer science and is the author and co-author of several books, the latest being Professional Mobile Java with J2ME, published by IT Press. You can contact Mikko at mikko.kontio@enfo.fi.
