Programming Java 2 Micro Edition for Symbian OS 2004 (779882), страница 47
Текст из файла (страница 47)
Sony Ericsson providesan emulator skin for the P900 and UIQ devices that plugs into the WTK.This can be downloaded from http://developer.sonyericsson.com.The Symbian OS Toolkit can also be used when developing MIDlets.Although Symbian’s toolkit is not designed specifically for MIDlet development, the emulator environment provides a close match to the actualdevice on which the MIDlet will run. The Symbian OS Toolkit shouldbe downloaded from the manufacturer of the device that you wish toemulate.
Each version is slightly different so that it accurately representsthe capabilities of the individual devices.5.2.2 Requirements OverviewBefore discussing how MIDP 2.0 is used for the expense application, amore thorough overview of the application requirements must first beprovided. The high-level requirements for the application included thefollowing functions:• claimants must be able to create, edit, view and delete expenses,subject to the current expense state• budget holders must be able to approve or reject expenses and requestadditional information prior to approving or rejecting an expense• all expenses should be synchronized with a central server• expense information on the server should be able to be viewed ona website.The high-level requirements do a good job of describing what must beachieved, but provide very little information regarding the detailed solution.
Most of these requirements speak for themselves and do not requirefurther explanation. What will be discussed further is the workflow of an250MIDP 2.0 CASE STUDIESexpense claim from creation to approval or rejection, the application’suser roles and synchronization of client device with server.5.2.2.1 WorkflowThe state of an expense claim reflects its current location on the pathfrom creation by a claimant to approval or rejection by a budget holder.An expense claim can be in one of five states (see Figure 5.1).5.2.2.2 User RolesThe application has two user roles: claimant and budget holder. Theclaimant role provides the basic application functions, such as the creationand submission of expenses and the viewing of retained expenses thathave been approved or rejected by a budget holder.The budget holder role has a superset of the claimant’s functions,including the ability to review and either approve or reject a claimant’sexpenses.
Budget holders can use the application in claimant mode,which allows them to create and submit their personal expenses.Claimant createsClaimant deletesCreatedClaimant editsClaimant submitsBudget holder queriesQueriedSubmittedBudget holderrejectsClaimant re-submitsClaimant editsBudget holderapprovesApprovedFigure 5.1Expense claim state diagram.RejectedTHE EXPENSE APPLICATION2515.2.2.3 SynchronizationA synchronization process is used to exchange expense claim and userinformation between the wireless device and the server.
When an expenseclaim is updated or moves from one state to another, it will be sent tothe server when the next synchronization occurs. If the server has anyexpense claims that must be sent to the device these will also beexchanged, for example when a budget holder receives a claimant’sexpenses for approval.If the same expense claim is updated by two users who then synchronize, a conflict can occur. Under these circumstances it may bedifficult, or impossible, to determine which expense information is correct and should be retained. Resolving such conflicts is a non-trivialproblem that would normally become an administrative function of theapplication.For the expense application, each claim must be treated as an inviolable financial transaction.
Fortunately, it makes little sense for twousers to be able to update an expense claim at the same time. Everystate transition results in another user being responsible for the claim.Following a transition, the expense becomes read-only on the devicewhere the transition occurred. When the next synchronization occurs theexpense will be available for the user who is responsible for its continuedprogression towards approval or rejection.The server also provides a website that allows expense information tobe viewed.
The site does not allow expenses to be modified or created;doing so would again raise the issue of synchronization conflicts. Keepingthe business logic on the device also strengthens the demonstration ofthe technology. A production version of the application would deal withpotential conflicts and allow the website to fulfill a view and amendrole.5.2.3 The Expense MIDletThe expense application’s MIDlet class is implemented in midlet.view.ExpenseMidlet, which is derived from javax.microedition.midlet.MIDlet. Unlike most MIDlets, the ExpenseMidlet does not implement any part of the application view, deferring this to a class derivedfrom javax.microedition.lcdui.Form.
The separation helps whenimplementing the different user interfaces required for UIQ and Series 60devices. This is discussed further in Section 5.2.4.4.The MIDlet object is important not only for managing the run stateof the application, but also when using many MIDP APIs. The ability toretrieve the MIDlet’s instance from other parts of the application is useful.The expense application MIDlet permits this by keeping an instancereference in a static member that is available using a static getter()method.
The MIDlet’s constructor is explicitly called from the MIDP252MIDP 2.0 CASE STUDIESimplementation, which ensures there is only ever a single instance of theobject. The basic MIDlet code is as follows:public class ExpenseMIDlet extends MIDlet {public static ExpenseMIDlet getInstance() {return instance;}protected ExpenseMIDlet() {instance = this;}// instance of this MIDletprivate static ExpenseMIDlet instance = null;}A commonly-used object javax.microedition.lcdui.Displaycan only be obtained using an instance of a MIDlet. The Display objectis used to retrieve the attributes of a device’s screen and display newDisplayable objects, such as a Form or Canvas. There is a singleDisplay instance per MIDlet.The expense application uses MIDP forms extensively with customitems to make the user experience more agreeable.
When a form needs tobe displayed, the Display.setCurrent() method is used to replacethe currently displayed object. Some additional methods were added tothe expense MIDlet in order to simplify display handling, including amethod to display the application’s main form, when needed:public Display getDisplay() {return Display.getDisplay(this);}public void displayMainForm() {Display.getDisplay(this).setCurrent(mainForm);}public void display(Displayable disp) {Display.getDisplay(this).setCurrent(disp);}The following code shows an example of how to use the helpermethods to display a new form:SettingsForm form = new SettingsForm(settings);ExpenseMIDlet.getInstance().display(form);The main form of the expense application is derived from javax.microedition.lcdui.Form. The Form contains a number of itemsand commands that are all initialized in the class’s constructor.
ATHE EXPENSE APPLICATION253number of listener interfaces are also implemented to handle commandand item events. See the sample code for the details.The main Form implements the Singleton pattern. Therefore, it has aprivate constructor and holds a static instance reference with a gettermethod.
There will only ever be one instance of the main form and itexists for the duration of the MIDlet’s execution. Implementing the formas a Singleton enforces this and provides a simple method of getting areference to the main form as needed.5.2.4Custom Items5.2.4.1 OverviewWhen development began on the expense application it became apparentthat a form-based application was the best solution. Forms would make thedisplay and editing of expense claim and application settings reasonablytrivial. The only issue was how to create a main form with a list ofexpenses that allowed easy navigation between months. The work duringthe user interface prototyping suggested an interface that was just notpossible using the standard high-level LCDUI components.The solution was to use a new MIDP 2.0 feature called CustomItem.CustomItem allows the creation of new Items and gives the developercomplete control over the look and feel within the bounding rectangle.As always, with great power comes great responsibility.
In order to gainthis level of freedom the developer must perform all paint operations,event handling and calculation of the currently visible rectangle if theitem size exceeds the screen size.Figures 5.2, 5.3 and 5.4 show the user interface prototype for the mainform of the expense application, based loosely on the UIQ user interface,and its eventual implementation on the Nokia 6600, a Series 60 phone,and the Sony Ericsson P900, a UIQ device.Two custom items were created for the expense MIDlet: the selectoritem that can be used to select the month and a multi-column list thatshows the expenses for the month.The selector item can be seen near the top in Figures 5.3 and 5.4.
It hasa secondary mode that allows ordinal selection, e.g. 2 of 6, between aminimum and maximum value. Left and right arrows are drawn when it ispossible to change the selection in that direction. On a Series 60 device,the selection change occurs when the joystick is pushed left or right.The UIQ version of the selector allows additional buttons to be added,such as the Create button in Figure 5.4. The left and right arrows werealso re-engineered to be treated as buttons.
Each button has its ownhotspot region to simplify pen tap logic. When a pen tap occurs the eventhandler enumerates the buttons, searching for a hit.254MIDP 2.0 CASE STUDIESFigure 5.2User Interface Prototype.Figure 5.3 Series 60 Implementation on Nokia 6600.The Series 60 implementation of the selector item is implemented ina single class, midlet.uitools.SelectorItem. The UIQ version isimplemented using two classes and one interface (see Figure 5.5).The multi-column list can be seen in the lower half of the screen inFigures 5.3 and 5.4.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
