01 August 2009

ItemStateListener's behaviour of Java Runtime for S60

My recent investigation indicates that ItemStateListener's behaviour on TextField of Java Runtime for S60 3rd Edition FP2 has been changed.

On S60 3rd Edition FP1 devices, ItemStateListener.itemStateChanged will be called when the user has selected a phone number from his/her phonebook in order to insert it into a TextField. In contrast with that, my E75 does not call the method when I have selected a phone number from my phonebook. Although -- as far as I know -- Nokia has not announced this change, this behaviour has been also confirmed with emulators of S60 3rd Edition FP2 SDK and S60 5th Edition SDK.

I cannot understand why Nokia has changed the behaviour of phonebook interaction case only; altering directly the contents of a TextField still calls itemStateChanged method.

| | TrackBack (0)

19 December 2008

Making a phone call programmatically from Android - JPDialer

Recently I got a T-Mobile G1, Google Android mobile phone. For my study of Android platform, I started to port my MIDP applications to Android. The first target was Dialer, which was so small that it should be easily ported. By the way, as the name “Dialer” is used by Android’s standard telephony application, I named Android version of my application “JPDialer”.

In order to make a phone call to a particular phone number programmatically from an Android mobile phone, Context.startActivity() method is used with specifying an Intent.ACTION_DIAL or Intent.ACTION_CALL, and a phone number. If you would use the latter Intent, you need to add CALL_PHONE permission to your application’s manifest. The following code snippet can place a phone call:

Continue reading "Making a phone call programmatically from Android - JPDialer"

| | TrackBack (0)

18 December 2008

Profiling main screen - Expense Report (6)

The more I have used the Expense Report application and have added expenses, the longer Sony Ericsson W890i has taken to show the main screen. Although I suppose it, it is slower than expectation.  W890i takes 7 seconds to display 50 expense items while Nokia E51 takes 3 seconds. The user can feel like being kept waiting so long if the duration exceeds 5 seconds. Furthermore, because I have not optimised the implementation, the main screen will be instantiated every time the user goes back to it. It means that the user has to wait very long time for the main screen after any operation.

Which part really took so long time? I have measured profiling data so that I could find out the bottleneck in the main screen.

Continue reading "Profiling main screen - Expense Report (6)"

| | TrackBack (0)

15 December 2008

Soft key labels - Expense Report (5)

As a small change in Expense Report version 0.5.1, I have revised soft key labels so that even small screen handsets can display them without truncation.

In the market, there are still many mobile phones with small screens like 220x176 pixels, 2 inches diagonal. Six Latin letters or two Far-Eastern letters are typically suitable for soft key labels so that such small screen can properly display them. Again, this is just a typical case because Latin letters are usually shown with proportional fonts, which means that the width of letters differ from one to another.

In MIDP-2.x, command labels can have two forms: one is short form for soft key labels on the bottom of the screen, the other is long form for command menu screen. I also have added long labels so that MIDP-2.x devices can display more self-contained labels.

| | TrackBack (0)

11 December 2008

Reorganisation of internal state management - Expense Report (3)

After releasing Expense Report version 0.4.2, I decided to reorganise the internal state management. Because, the following two major functionalities remained to be added, which expected to be so complicated that implementation could get much confused:

  • Synchronisation between mobile phones.
  • Exporting data for PC software.

Both required asynchronous I/O, and did the users many steps to operate. I needed to prepare for mechanism that could afford adding such complicated features.

Previously, pressing command buttons by the user only triggered state transition. Therefore, all state transition occurred inside CommandListener.commandAction() method. Since asynchronous operations were going to be introduced, I decided to reorganise the internal state management. Finally, I got a huge switch-case block, which looked as if it was a window procedure in Windows programming. It must be later split into several pieces, or be replaced with table-driven state machine, or I have to rewrite it by using the State design pattern.

| | TrackBack (0)

02 December 2008

List.append() - Fragmentation in MIDP

They say that Java ME has been fragmented due to proprietary extensions by manufactures and network operators. In reality, not only proprietary extensions but also MIDP, which should be a baseline, has been fragmented. This article describes an example that I have experienced with List class in Expense Report project.

I defined DataBountList class that extends List, which is for displaying expense summary. While List has string labels and icons for each item, DataBoundList additionally has arbitrary objects bound to items. In the case of Expense Report, each item is bound to an object that represents each expense.

Continue reading "List.append() - Fragmentation in MIDP"

| | TrackBack (0)


Android | Dialer | Expense Report | JPDialer | M2ch Viewer | Mobile | Programming