Nokia Drops JavaME

What the major news outlets failed to highlight yesterday in Nokia’s news to consolidate on QT for both Symbian and MeeGo is that Nokia sells a large majority share of MIDP  JavaME devices deployed worldwide. And usually consolidation moves like this ripple through the Mobile OEMs.

True, not many other OEMs have something like the QT strategy in-house. But you have to wonder when the next market leader in deployed MIDP JavaME devices will consolidate and drop JavaME. I wonder how Oracle will spin this?

Advertisement

Joe Hewitt about as open as

Image via Wikipedia

Joe Hewitt, funny the complaints about open coming from a Facebook developer, the same firm troubled by privacy gaffles, not being open, etc.

Lets back track a bit. Other OSes claiming open in mobile devices. Symbian, at first Symbian source tree was not accessible and viewable by outsiders much like Android. JavaME, same deal.  You see folks, its normal in mobile operating systems and in fact in any operating system with multiple stakeholders to at some point in the incubation period for the master source tree to be not viewable to outsiders.

The claim of it does not have this or that so must not be open is a bit of FUD to distract us from discussing other issues such as the consumer should have a choice in OSes, mobile operator device/service plans, etc without shackles of any OEM or Mobile Operator and Apple’s policy of locking down the consumer is somewhat wrong and miss-guided.

 

 

Android Testing DSL Reprise

Image via Wikipedia

I did some hacking yesterday with Calculon in a attempt to see if it could be extended similar to robotium. Not possible, robotium is the best option..sorry MK(Calculon developer). Thus, we have a IDE plugin or build that runs all the tests at one time and completes a code coverage report along with a DSL syntax to reduce the complexity of writing unit tests.

It will not be as pretty as say Spock, but still it reduces test writing expertise to something manageable.

But Android emulation is unique in that we have to start up anew AVD to test a different device model. The obvious next step is to get some way to start and stop the AVDs in your emulator inventory and run install-app and tests each time and produce test reports for each device model.

Apache ANT is too brittle of DSL to be flexible enough to work as a work-flow testing scenario. This might be an ideal situation to use Gradle in as it uses Groovy’ DSL with the ability to run/execute ant tasks/targets, maven stuff, ivy, etc.

Dependency Injection vs Mock wise I do not see a need in testing to resort to DI if you have Android-Mock available. But maybe some developers prefer to use DI rather Android-Mock, it just seems that yuo are moving your focus away from  tests up the DI chain if you pursue that route.

Agile Android Development

Gee, be nice if testing was easier and with the influx of  new frameworks does not make it any easier. The major reason why the average android developer does not unit test from the beginning(TDD) is that in any Virtual Machine mobile environment you run into situations where certain objects are not accessible to test.

Robotium and Calculon attempt to reduce the complexity by overlaying DSL concepts to come up with a new syntax to testing. Than we have droid-sugar/roboelectric which brings different style mocking to the area.

My thinking is why not combine the android port of easymock(Android-Mock) with some DSL syntax and it allows me to re-enforce my android internals knowledge. Plus the problem with mocks, is that effective mocking is on device/emulator the way Android-Mock implemented and with mocking on JVM rather than Dalvik you are doing a lot of extra steps for less effective results.

So AndCalculon is a polite fork of Calculon to integrate Calculon with Android-Mock and see how far I can take it. I will publish more later this week with the bitbucket.org link.

Google gets it Wrong

Hello  rant on. There are times hen every developer both outside application developers and project contributors want to just strangle Google. This might be one of those times.

On Sept 21st a developer blog post was posted on the android blog about using proguard to obfuscate in oreder to use some LVL features. The proguard supplied files had noticeable errors such as not picking up 3rd party libs in the proguard task amnd a poorly deficient proguard config file.

The corrections to the proguard ant task file can be found in the add-proguard-release.xml file in my AndCooperANT project. You can also find a correct proguard config file were log calls are stripped out and stacktraces and lines kept in the form of the proguard_android_config.txt file(drop box download).

To this date almost 30 days and no correction form Google and no acknowledgement of the errors. Come ON Google we have to get better than THIS! Its bug 11413.

AndCooperANT 0.1.1.1 Release

There is now a download of the AndCooperANT Android Java Application build tool. Its still alpha with the most tested area being the build.xml script. Of course if you find errors report them in the issues section.

Some of the docs are still in flux at the moment let me know in an issue/bug report of the instructions are unclear.

Gingerbread vs HoneyComb

With one of the new Android releases coming up in October lets go over differences.  Android 2.3 is being nicknamed Gingerbread by press but as you know according to Google/OHA 2.3 is not Gingerbread as there is never a full transfer of all the changes in the private Gingerbread tree to any public release.

So what is in Android 2.3? Expanded cloud messaging and voice recognition. More video codec support along with WebM. Bluetooth voice commands.  A complete UI refresh that might prevent all the OEM adding UI skins which has been delaying new releases being sent out to device owners. Last but not least, a possible USB api update to include apis for applications to interface with new USB features in preparation of OEMs supplying full AB USB port modules.

Wait! Part of the cloud message update involves a promise that Google gave back in May, Music store by year end holidays. That is why if you had viewed the android kernel commits recently you saw some drm commits.

So what is Android 3.0? Same as above in that although the press has labeled is as Honeycomb, the private tree never gets a full release or folded in to a public release.  Its easier to just think of it as Android 3.0. As Google has talked to OEMs and noted the tablet trend it has come up that OEMs are preferring Android than Chrome for tablets.

Using Android for tablets presents some new challenges both in what constitutes an Android device as far as expected hardware inputs, outputs, ports, screen sizes, etc. Thus, android 3.0 is being developed to address these challenges.

But, there is more! Remember the Web APIs demoed in May(IO video)? That is part of what is in Android 3.0. And of course the improvements to support GoogleTV.

More Video Demos

I am putting up more Video demos:

As per my habit now, you will usually find sample code for that demo on my github account link at the bottom of this blog. I should have some more up very soon.