Porting

Features

A central part of the functionality is opening Reddit links in the web browser of the device. While the recent Series 40 devices allow opening external URLs in the browser, there might be content that the Series 40 browser cannot open. The most notable exception to the feature set of the Android client is viewing video content. The category "/r/videos" was removed from the Series 40 port because of lack of support for viewing them in the device.

Application flow

The Android application architecture declares the general structure of an application: the application is essentially a collection of Activity objects, each of which are displayed on the platform upon request. They have a predetermined lifecycle and way of setting them up, launching them, etc.

In Series 40, what happens once the MIDlet is entered, is left up to the implementation of the "startApp()" method to decide. The Display class is used to control which view is shown, but the framework itself does not take part in the application flow. This means it is usually convenient to have a central view controller component for the central logic of switching between views.

Android has several mechanisms that the developer can use for dealing with asynchronous operations. In the Series 40 port, asynchronous operations were implemented using custom Listener classes that would be passed to the operations in their constructor.

Language & libraries

The JSON library used for parsing API responses was practically the same for both platforms. Although a different distribution, the API for the Java ME library is effectively the same for the Android one. The main difference is that the library is bundled in the Android SDK, whereas it had to be picked up separately for use in a JME project.

As opposed to the Android SDK, with a moderate collection of utilities and helper classes bundled in the distribution, the class library of Java ME is relatively thin. A number of helper classes are included in this application:

• HttpClient and HttpOperation classes for handling asynchronous HTTP requests

• TextWrapper for splitting text to be displayed in view items

• DatePrettyPrinter for printing human-readable dates, e.g. "3 days ago"

• TouchChecker for detecting availability of touch (should always be available for the targeted Series 40 touch devices)

• ImageLoader for loading images

• SessionManager for writing and reading stuff in the cache

UI design and views

How views are defined and drawn is one of the most significant differences between the Android and Series 40 platforms. In Android, views are usually defined declaratively in XML format by specifying layouts and UI components contained in them. In contrast, in Series 40 the view definition is done in the program code (although graphical editors are available for both platforms). Defining font sizes is more flexible in Android, and with flexible layouts options, the user does not have to calculate metrics for view components.

Because Android as a platform has a wide variety of different screen sizes and pixel densities, a typical application should have separate assets for low, medium, and high resolution displays. In this sense, the Series 40 devices are more homogeneous in that they commonly share a screen size of 240x320 or 240x400 pixels.

Series 40 full touch devices introduce landscape support but it was decided not to support it in this application.

Fixed top bar

The Android version used a fixed Link item (the topmost view component) in the Comments view. This would not have been possible without making the UI fully custom in Series 40. As a result, the Link item was made to scroll in the view just as the other items.

Performance

The original Android version didn't limit the number of Comments retrieved: instead, it always retrieved all the comments. Even if the data transfer would take some time, populating a list of some hundreds of comments and displaying them all in a ListView at once did not seem to be an issue. The situation is quite different on a Series 40 phone with less memory and processing power. Here it makes sense to only fetch a partition of the comments at a time, and load more when required.

Also, a View caching mechanism was put in place. The cache was implemented using WeakReferences, which are cleared up basically every time the application runs low on memory and the garbage collector is run. This means that the lifetime of a single view stored in the cache will not be long. Generally, a SoftReference would have been a better choice for a cache such as this as it wouldn't get garbage collected just as easily as a weak reference does, but in the 1.3 version of Java there are only WeakReferences available.

Potentially long-running tasks are executed in their own threads, and content is inserted in the Views by the UI thread by calling display.callSerially(Runnable r).

Unlike on Android, the thumbnail images in Link items are not scaled for performance and simplicity. They are almost always 70 pixels in width, which fits the JME version display nicely.

Reused components

The model classes were used almost as-is, with minor updates for date formatting and additional properties. Also the logic for parsing the JSON into Link and Comment objects was brought in largely unchanged, although it was later refactored and optimised a bit for the target environment. What had to be changed were mostly converting some generics into typecasts and updating some data types.

Consider the difference in the following two code blocks. Compare Android:

List<CommentThing> comments = new ArrayList<CommentThing>();
...
CommentThing comment = comments.get(0);

To Series 40:

Vector comments = new Vector();
...
CommentThing comment = (CommentThing) comments.elementAt(i);

To summarise, most of the parts related to the handling of data remained the same, but the parts related to UI management or application flow control were rewritten for the target platform.