PIM: Accessing the Personal Information Manager - Java 2 Micro Edition Application Development - page 187

The to-do API supports a subset of the vToDo fields that are defined in the vCalendar RFC 2445
specification. Analogous to the addressbook and calendar API, the to-do API contains specializations
of the PIMElement and PIMList interfaces, namely the ToDo and ToDoList interfaces.
Field IDs supported in the ToDo interface are COMPLETED , DUE , NOTE , PRIORITY , SUMMARY , and
UID . The following code snippet illustrates the usage of the ToDo API:
TodoList myTodoList = PIM.openTodoList(PIM.READ_WRITE);
Todo myTodo = myTodoList.createTodo();
myTodo.set(Todo.SUMMARY, "Buy a book covering MIDP and PDAP");
myTodo.set(Todo.DUE, new Date());
myTodo.set(Todo.NOTE, "Perhaps Sams offers a good one."
+ "Take a look on their website first.");
myTodo.set(Todo.PRIORITY, 1);
myTodo.commut();
myTodoList.close();
Like the EventList , the ToDoList supports an elements() method that returns an enumeration
containing all ToDo elements ranging from a start date to an end date. Repeat patterns are not
supported for ToDo s.
Contact Sample Application
In order to become familiar with the PDAP PIM API, you will now build a simple PIM sample
application. Although the sample will focus on the address book part of the API, it will be designed in a
structured way that allows you to reuse many parts as building blocks for your own, more powerful
PIM applications.
For the PIM sample application, you will first design a simple dialog that allows you to edit a single
contact, including fields with subtypes. The second building block of the application is the main
window, showing the list of contacts stored in the default ContactList of the device.
An Edit Dialog for Contacts
For the regular contact fields, it is obvious how to present them to the user in a graphical user interface.
You just put them in two grid layouts contained in the right and center areas of a border layout; the left
grid shows the labels and the center one the input fields, as in many other examples. However, for the
fields supporting multityped values such as TEL or FAX , the task becomes a bit more complex.
One option to make all subtypes accessible in a convenient way is to create separate panels for each
subtype such as WORK , HOME , and so on using a CardLayout . A Choice element can then be used
to switch between the panels.
This approach is shown in Listing 7.1 . Figure 7.2 shows a screenshot of the contact dialog. The panels
are represented by the inner class FieldPane . FieldPane contains an integer variable type
representing the subtype of all contained fields. The method addField() adds a field with the given
label and ID. In order to be able to synchronize the user interface with a concrete Contact instance,
the FieldInfo helper class is used to store the link between the TextField in the user interface
and the ID and type of the corresponding field. All FieldInfo objects are stored in the vector
fieldList . When the dialog is filled from a contact in the edit method, all field info objects are