Viewing DZone on the Android Browser

I really like my new job I started in January 2010 but the way to work takes a lot of time. I travel by train so I can use my G1 to surf the web and do stuff like that so the time isn't completly wasted.


One of the websites I really want to read is DZone.com. Unfortunately it doesn't look good on mobile browsers.


So I hacked a simple iframe to make it work (at least a little bit better) on my Android phone.


To access DZone from the mobile browser just open this link in your mobile browser:


http://www.mobile-j.de/dzone.html


It's not perfect but better than nothing. It might also work on other mobile browser but I haven't tested this.

AlarmManager vs Task Killer

For my current private coding@home project I was looking at how to schedule alarms on Android.

I quickly realized that the AlamManager was what I was looking for. I followed one of the many resources found on the net and started to implement a simple test application. One of those pages explaining how to deal with AlarmManager and WakeLocks is http://www.androidguys.com/2009/04/02/wake-up-with-the-alarm/.

Everything was fine and it instantly worked. BUT! I wanted to see if it will also work when my app is stopped (e.g. when Android runs out of memory it will stop apps that are still running in the background). To make it easy I took one of those task killer apps you can find in the Android market. I killed my app after the alarm was set and ..... the alarm never got off.

I was really disappointed and was looking for a solution. I also had a look or two at the built-in Alarm Clock app. I did everything like it was done there. And still it wasn't working.

Then I tried what happens to the Alarm Clock when I create an alarm and kill the app. And what happened? Exactly the same. I couldn't believe what I had seen.

After some googling I found that the real problem wasn't the alarm stuff but the task killer itself. ( see http://groups.google.com/group/android-developers/browse_thread/thread/3f87972d1f99ee81?pli=1 )

I really wasn't aware that using a task killer on Android is so aggressive. By definition it means killing also the alarms registered by the app (and everything else).

Now I know better and don't use that task killer app so much as I did before because now I can imagine how much can go wrong when using those kind of apps. (And now I know why there is no such app preinstalled on the device.)

J2ME Unit Testing

In the past I tried to get happy with unit testing of J2ME code.

I used JMUnit and J2MEUnit. JMUnit is a lot more straight forward while J2MEUnit is a high ceremony framework which requires a lot of boiler plate code just to be as much like JUnit as possible.

But in the end both suck. All J2ME testing frameworks will suck.

Why? Because unit testing should be easy and fun but compile, preverify, deploy to the emulator or the device, doing some manual steps just to see that something is broken isn't fun and it's also not easy.

There is a lot of stuff you have to try on the phone but that has nothing to do with unit testing but it's tinkering around implementation issues. You will have to do that anyway and I guess both frameworks are of little help here.

So what is the answer to J2ME unit testing?

In my opinion the best approach is to do unit testing on the PC inside the IDE. Using JUnit 4 and Java SE.

I'm currently giving this solution a try. I have a separate project with a dependency on the J2ME project.

For all those J2ME classes you need stubs. I haven't found usable code on the net so I write them myself. (I don't have a lot of them yet)

The good thing is you can really take control over everything with your own implementation of the J2ME classes. Your own bluetooth connection, file connection ... you name it. It's a lot of work but you can do almost anything. Once you have your mocks and stubs in place you will see how much better this approach is.

But the best about this is that the tests run fast, you can exhaust all the cool stuff from your IDE from good debugging support to integrated JUnit support, you can use mocking frameworks like Mockito, EasyMock etc., you can use a modern framework  (JUnit 4)  and you could even use coverage analysis integrated into your IDE (but I haven't tried it yet).

It should also be easy to integrate this into the build and run the tests on the CI server. (This is a nightmare with the "pure" J2ME solution.)

This idea is inspired by an experimental approach to unit testing on Android which is something I will try on one of my next Android projects.

Nokia S40 SDK on Linux

I completely switched to Linux some months ago and I'm quite happy with it.
Unfortunately there is still a lot of Windows only software. For the most stuff there is a free and open equivalent but when it comes to mobile (J2ME) SDKs / emulators the only way to go is usually the old(!) WTK (2.5.2).
I just wanted to share the information that some really nice guy at the Forum Nokia Discussion Board told us how to run the S40 SDK on Wine.
See: http://discussion.forum.nokia.com/forum/showthread.php?t=90868 (Scroll down to yanng34's post).
I successfully tested the solution on Ubuntu 9.10 with the Series 40 6th Edition SDK.

I really like Android's EditText

In the last couple of days I enjoyed doing a little bit coding for Android at home. With a J2ME background I was really amazed by the richness of the Android APIs. You have a lot of the Java Standard Edition APIs plus a lot of useful and well thought out APIs for UI and phone related stuff.

I quickly realized that a lot of functionality I thought I have to implement myself is already there. For example I really like the preferences API. On J2ME I had to implement everything myself. Starting from the preferences UI to the preference store.

Also surprising for me was how rich the widgets really are. Let's take the EditText widget. It not only looks really good when rendered on the screen it also has a lot of functionality you can easily use.

For my first application I have a form to enter geocoordinates. They are represented as text like "50:24,123".

After the basics worked I wanted to make the UI a little bit more user friendly by helping the user to enter only valid coordinates.

First I wanted to limit the usable characters to "0123456789:,.-". And it turned out to be quite simple:

NumberKeyListener keyListener = new NumberKeyListener() {

        public int getInputType() {
        return InputType.TYPE_CLASS_NUMBER;
        }

        @Override
        protected char[] getAcceptedChars() {
        return new char[] { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '.', ':', '-', ',' };
        }
    };

    lonEditText.setKeyListener(keyListener);

But this still doesn't prevent someone from entering something like "1:1:1:1" which is obviously not valid. So I introduced an input filter:

    InputFilter[] filters = new InputFilter[1];

    filters[0] = new InputFilter() {

        public CharSequence filter(CharSequence source, int start, int end, Spanned dest, int dstart, int dend) {
        if (end > start) {
            String destTxt = dest.toString();
            String resultingTxt = destTxt.substring(0, dstart) + source.subSequence(start, end) + destTxt.substring(dend);

            if (!resultingTxt.matches("[0123456789]*[\\:]?[0123456789]*[,.]?[0123456789]*")) {

            if (source instanceof Spanned) {
                SpannableString sp = new SpannableString("");
                return sp;
            } else {
                return "";
            }

            }
            
        }

        return null;
        }

    };

lonEditText.setFilters(filters);

(Please note that this is just an example and the code isn't production quality.)

That was easy and a lot better. Unfortunately you can still enter invalid coordinates like "999:99.123".

First I thought of getting all the magic into the regexp but first I don't like regexp-magic so much and second I wanted to see how I can give the user some feedback about the validity of the entered data.

I decided to implement a TextWatcher and validate the data in "afterTextChanged".

There I just tried to parse the coordinate and in case of an error I wanted to inform the user. My first approach was to use a Toast but it turned out that EditText already has everything I needed.

The code looked like this:

    if(coordinateValid){
        lonEditText.setError(null);
    } else {
        lonEditText.setError("Coordinate is invalid.");
    }

This is not the actual source but it shows what I wanted to show: Use setError to indicate a problem with the text contained in that EditText.

When the invalid field has focus the error is displayed. If it's not focused there is an icon showing that something is wrong with the content of this field.

That was easy and it's more than I had expected. Thanks Android!

Fragmentation is inevitable

Many J2ME developers are complaining about device fragmentation. And I agree that it's one of the hardest challenges when developing portable MIDlets.

Recently similar things are said about Android. (see http://androidandme.com/2009/11/news/what-does-android-fragmentation-look-like/ )

And even on the iPhone there are similar problems. And I think that those problems are inevitable when you don't want to stick to old and outdated technology.

But why does fragmentation occur? What are the reasons for it?

• Different software / hardware vendors. Even if the specs are very similar the details of an implementation can make the difference. This affects J2ME a lot. Luckily Android devices are more similar in terms of OS implementation but the hardware varies. The iPhone is the clear winner here. There's only one vendor. (Well this is in my opintion one of the few things that are good about having one vendor only.)
• Software evolution.  (i.e. new versions) Software normally gets better and better with each revision and usually users want to use the latest features. But not all users can or want to update their devices. So you have to deal with multiple versions.
• Hardware evolution. New devices have higher screen resolutions, more memory, more sensors etc.  If you want to make use of those new capabilities and don't want to break compatability with less powerful devices you have to write smart applications.

In the end device fragmentation is the consequence of device evolution. And we have to live with it because it won't go away.

Even controlled platforms like the iPhone are affected by this. Not as much as others but even iPhone developers have to deal with it. The next big change to that platform might be the introduction of new HD models with higher screen resolutions. We will see how those developers can deal with it. On other platforms people are already used to different screen sizes but I guess only few iPhone developers today think about screen size.

My guess on the fate of Symbian

According to the blog "The Really Mobile Project" Nokia is going to replace Symbian with Maemo on the high-end smartphones.

While Maemo looks quite cool I think this isn't the end of Symbian. Instead it might become the end for S40 since my guess is that Nokia will start to use Symbian for mid-range and - in the long term - for low-end phones. (Although I don't expect it to power ultra-low-cost phones like the 2330 anytime soon.)  Both market segments are not suitable for a heavy-weight like Maemo.

This makes a lot of sense since Nokia invested a lot of money into the platform and Symbian might be much more future-prove than the proprietary S40 platform.

Beside that Symbian (S60) is still one of the best platforms to run J2ME on.

Maemo: It will have to compete with Android and iPhone. I don't know if it will really gain momentum.

But only time will tell.