application development for mobile devices

8/8/2019 Application Development for Mobile Devices

1/12

Application

Developmentfor Mobile

Devices

Course Work:

November, 2010

Dotun Kola-Olaleye


2/12

Application Development for Mobile Devices 2010

2

Table of Contents

Introduction .................................................................................................................................................. 3

Section 1 ........................................................................................................................................................ 4

Section 2 Bugs ............................................................................................................................................ 4

Section 3 Strengths .................................................................................................................................... 4

Section 4 Screenshots ................................................................................................................................ 5

Section 5 Program Evaluation .................................................................................................................. 12


3/12


3

Introduction

The coursework required the development of an application for mobile devices using Java 2 Micro

Edition (MIDlet). It involved the use of a limited Application Programming Interface (API) compared to

the Standard Edition (SE) Platform of the Java Programming Language. Thus, many easier-to-use

elements Java made it more challenging than normal. However, it proved to be an invaluable

experience as new tricks were learnt and old ones remembered.


4/12


4

Section 1

Feature Implementation

a) Screen 1 Fully Implementeda) Screen2 Fully Implementedb) List all details of trip Fully Implementedb) Search by name Fully Implementedb) Sort Partly Implementedb) Delete specific trips Fully Implementedb) Delete all trips Fully Implementedc) Details of expenses Fully Implementedc) Details of expenses associated with trip Partly Implemented. It does not display on

screen

c) Total Expenses Not Implementedd) Multimedia Fully Implemented

Table 1

Table 1 shows the features in the application that are implemented, those not implemented, and those

in between.

Section 2 Bugs

The sort functionality sorts trips according to the purpose of the trip instead of date Sometimes the some deleted trips show up in subsequent lists

Section 3 Strengths

In the first screen, the staffID receives only five digits and ensures that the value entered is acombination of alphabets and numerals like bf995, as stated in the coursework specification.

This way, the value entered can be restricted to only staff with valid staffID. This is done by

validating the input in the validateInput () method.

In addition, the logic to search and sort the records from the record store is separated from theMIDlet into the SearchHandler.java and SortHandler.java classes, respectively. This

conforms to the object-oriented model of programming which allows for re-usability. For

example, if the application is to be extended to accommodate more features in other MIDlets in

the same MIDlet suite, these java classes could be shared amongst the MIDlets.


5/12


5

Virtually every screen in the application has an Exit command, which allows the user to stopthe application at any stage during execution. This gives the user a greater degree of control. If

any reason arises for the user to stop the application while filling the details, he/she can simply

exit it, thereby erasing the information already entered.

The application provides helpful hints on several screens to assist the user through the processof filling in details and command selections.

Section 4 Screenshots

Figure 1

Figure 1 above shows the implementation of the Screen 1. The user enters the values as shown in the

figure on the left and selects the Next command under the Menu, which displays the alert as shownin the shot on the right. The user details are displayed for confirmation in the alert.


6/12


6

Figure 2

When the user selects Next Command from previous screen, the user is taken to Screen 2 whichaccepts the Trip Details as shown in Figure 2. The alert shown aggregates information from the first two

screens and displays it for confirmation by the user.


7/12


7

Figure 3

When the user selects Confirm in the previous alert, an INFO alert informs the user that the details

have been saved and offers options to either enter more trip details or proceed to the Options screen,as shown on the right of Figure 3.


8/12


8

Figure 4

The Options screen allows the user to either search for the details of a trip by typing the first few letters

of the detail or List the Trip Details saved so far as shown below in Figure 5


9/12


9

Figure 5


10/12


10

Figure 6

Figure 6 shows the screen to add expenses after the Add Expense command is selected from the Trip

Details screen. The user enters the details in the various fields as appropriate. When the OKcommand is selected, and there are no errors, the Saved alert informs the user that the information

entered has been stored


11/12


11

Figure 7

Figure 7 above shows the addition of an Image to the Trip Details form. The image depicts a manhugging a bag of cash!


12/12


12

Section 5 Program Evaluation

As an introduction into developing applications for mobile devices, the exercise was well rounded. Most

of the basics of J2ME necessary for a beginner were covered in the coursework. It was a challenging

experience largely because the MIDP has a limited API compared to the Java SE API. Some things had tobe implemented from scratch, re-inventing the wheel, so-to-speak. For example, while trying to validate

the user input from the Screen 1, particularly, the StaffID, it became clear that the Regular

Expressions technique that makes use of placeholders in Java SE were dropped in Java ME. So a

workaround was in order, as done in the validateInput () method. A combination of String arrays and

regionMatches () mostly got the job done. I learnt also the impossibility of calling one MIDlet from

another within a MIDlet suite. While they can share common resources within the same suite, they

cannot call each other or create instances of one another. In fact, MIDlets cannot be instantiated

programmatically, but is the responsibility of the MIDlet manager on individual devices.

The RecordComparator and RecordFilter were relatively easier to work with than most of the other newelements like RecordStore. The getSelectdFlag () was cumbersome to work with until I abandoned it

altogether.

If I gave myself more time, I could have implemented more Object Oriented models in the program

development. Rather than lumping most action codes into the commandAction() method, it would be

better to create Classes and methods that could be called and re-used several times and extended

further to other programs. More time would also have allowed for a more robust and fault-tolerant

program. For example, the alerts were given general messages to cover several error scenarios,

whereas I could have given specific messages to specific errors, which helps the user navigate more

easily.

In addition, the design was a linear. There are a limited number of screens that could be jumped to

from other screens. Such an implementation would be more flexible for the users interaction and a

more enjoyable experience.

Certainly, there would be more use of animations and visual cues if doing it again were an option. There

could be more engaging design elements to help ease the tedium of such record entries as this for busy

executives.

In conclusion, a lot was learnt but much more to be done.

application development for mobile devices

Documents