Application Development For Mobile Devices

Application
Development
for Mobile
Devices
Course Work:
November, 2010
‘Dotun Kola-Olaleye
Application Development for Mobile Devices 2010
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
2
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.
3
Section 1
Feature Implementation
a) Screen 1 • Fully Implemented
a) Screen2 • Fully Implemented
b) List all details of trip • Fully Implemented

b) Search by name • Fully Implemented
b) Sort • Partly Implemented
b) Delete specific trips • Fully Implemented
b) Delete all trips • Fully Implemented
c) Details of expenses • Fully Implemented

c) Details of expenses associated with trip • Partly Implemented. It does not display on
screen
c) Total Expenses • Not Implemented
d) 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 a
combination 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 the
MIDlet 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.
4
• Virtually every screen in the application has an “Exit” command, which allows the user to stop
the 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 process
of 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 shown
in the shot on the right. The user details are displayed for confirmation in the alert.
5
Figure 2
When the user selects “Next” Command from previous screen, the user is taken to “Screen 2” which
accepts 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.
6
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.
7
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
8
Figure 5
9
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 “OK”
command is selected, and there are no errors, the “Saved” alert informs the user that the information
entered has been stored
10
Figure 7
Figure 7 above shows the addition of an Image to the “Trip Details” form. The image depicts a man
hugging a bag of cash!
11
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 to
be 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 new
elements 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 user’s 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.
12

Application Development For Mobile Devices

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Development For Mobile Devices

Uploaded by

Copyright:

Available Formats

Application

b) List all details of trip • Fully Implemented

c) Details of expenses • Fully Implemented

d) Multimedia • Fully Implemented

Section 5 – Program Evaluation

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

You might also like