 | |
Handheld devices like cell phones have limited memory, storage, and processing power. Furthermore, small screens and limited input facilities make entering information tedious. It is therefore important that applications optimize resource use and minimize input effort imposed on the user. One way is to download to the client only the information most relevant to the user, then present that information effectively, taking into account the user's preferences and history as well as the task at hand. Following this approach, which is known as personalization, minimizes the information to be displayed and input. Note that personalization-related data is persistent by nature, quite different from the transient data maintained in session states. A key goal is to ensure that the most relevant data is available immediately, on the device, while less relevant data remains available online. In addition, the most relevant data should be accessible first. Careful ordering of information reduces the number of user actions, such as key clicks. Stable Data for Personalization When building personalized applications you need to identify which data doesn't change from session to session. Examples that can be found in the Java Smart Ticket Sample Application include login screens and the user's postal code. The Smart Ticket demo is a fictional application that lets users browse personalized listings of movies, theaters, and showtimes, reserve seats and purchase tickets, and rate movies they've seen. It improves the user experience by employing personalization. For example, as Figure 1 shows, a user creating a new account can specify automatic login. If that option is selected, a full login won't be necessary every time the user just wants to check a movie's showtimes at a nearby cinema.
On account creation the application also memorizes the user's postal code, and thereafter uses the code to localize searches. The code never needs to be re-entered unless the user wants to search for showings in a different area, as illustrated in Figure 2
As you can see, personalization reduces input effort. The user doesn't have to log in for each use of the application, or re-enter a postal code for each search. Where Should the Data be Stored? When building personalized applications, you need to decide where persistent data should be stored, and whether it can be made available to multiple clients and applications. If you're careful to consider all relevant factors, these decisions are not always simple. Take the Smart Ticket demo as an example. The user can run it from either a cell phone or a desktop web browser, and the saved postal code must be available in both environments. If it's stored on the desktop machine the phone will have no access to it, and vice versa. Accordingly, the application stores it on the server. If you're considering storing personalization information on a server, you must consider the costs of downloading the information when needed. These may be financial, such as the charges for network use, or behavioral, such as latency in access. Will caching some of the data on the device reduce these costs or increase them? You need to take these factors into account when deciding where to store personalization information. If data is duplicated on the client and the server, you need to worry about synchronizing it, to make sure data on both sides is up to date. When synchronization - and other operations - involve the exchange of confidential data, the application developer must ensure that the information is protected in transit, for example by using a secure transmission protocol like HTTPS. Security Issues Personalization raises privacy and security issues. For example, it's clear that an automatic login feature can avoid tedious authentication procedures and improve the user's experience, but it poses a security problem, because it uses locally stored information, such as an ID and a password. Automatic login should be done only at the user's direction, and thus should be configurable. If any of the data your application stores locally is sensitive, you need to take special care to protect its integrity and confidentiality. Consider credit-card numbers, for example. Sending them to the server, even automatically, should be okay, but they should not appear on the screen unless the user enters a password to indicate that it is safe to do so. This extra step before display or entry of a credit card number provides important protection. If the phone is lost or stolen, an unauthorized user will find it difficult or impossible to retrieve the sensitive information. You must ensure data's integrity as well as its security. Features of the Record Management System (RMS) in the Mobile Information Device Profile (MIDP) can help. In MIDP 1.0, only the application that creates a record store has access to it. In MIDP 2.0, a record store can be shared, but only at the discretion of the MIDlet suite that creates it. This owning MIDlet suite can impose an authentication procedure, such as password entry, before granting access to its local persistent data. In such cases, to protect against inappropriate access the business environment may require that the automatic login feature be disabled. As a final note: Passwords alone don't always secure data adequately. An effort is under way within the Java Community Process to address this concern. The intent of Security and Trust Services API for J2ME (JSR 177) is to define additional security mechanisms that will meet the needs of a wide variety of applications and services such as access to corporate networks and digital rights management. For more information Java Smart Ticket Sample Application About the author Qusay H. Mahmoud provides Java consulting and training services. He has published dozens of articles on Java, and is the author of Distributed Programming with Java (Manning Publications, 1999) and Learning Wireless Java (O'Reilly, 2002). | ||||||||
| |
| ||||||||||||
Print-friendly Version
