Android, Java, and Differences Between the Two.

I’ve recently started learning Android development. I’ve enjoyed working on small devices since my first job out of college in 1989 developing an app for a portable bar code scanner. I haven’t been able to do much development like this since other than for my own interests on an off, but in the current environment it seems foolish to not try and learn more about mobile development.

So a few months ago I picked up an interesting little Android 2.2 tablet – the MP4Nation MIDnite (a “badge engineered” Witstech A81E) primarily to experiment with. It’s a little buggy (and I need to update the firmware on mine) but it’s still a pretty capable device for the price. I then set out to start doing some development.

I won’t get into all the details of how to get started in Android development. There are plenty of other web sites and books covering that topic. Mostly I find the Android development process to be relatively painless. It has a powerful API and being able to develop in a familiar environment (Java & Eclipse) on any common desktop platform is a real plus.

My only real complaint so far however is the huge disparity between the standard J2SE and the Android API. I’m sure there may be good reasons, but it seems like they really reinvented the wheel in some areas where they could have created new implementations of existing interfaces.

I’ve really faced this in a project I’ve been trying to get started on. I want an app that allows some simple image compositing on the Android device which then can be sent to a server process for rendering and printing on demand. Nothing too complex – just an overall shape, a background color or gradient, optional background image like clipart or a photo, and some overlay text. If successful, I’d like to have a web and iPhone front end in the future as well. The images need to be scalable as well.

My first thought was to use SVG. I’m not terribly familiar with it, but it seems like it would suit my purposes. But getting SVG into Android is proving to be difficult. There are a couple of projects here and here on CodeProject using a port of libsvg on Android. However so far I haven’t had any luck getting it to work. I believe the problem is that the port seems to require Android 2.2, but to reach a wider audience I would like to target 1.5 as a minimum. I also looked into using the pure Java Batik, but the lack of the Java Graphics2D object on Android makes that impossible, at least without some major refactoring of Batik.

That brings me to my main complaint – why doesn’t Android use Graphics2D (and more of the AWT) as a base for their graphics? They could still have their own extensions on top of that. The Android Canvas class could likely be implemented as a subclass of Graphics2D, much like Graphics2D itself is a subclass of Graphics. This would allow the reuse of more existing code (like Batik) and more consistency when similar operations must be performed on both the client and server side.

So at this point I’m probably going to be implementing my own very simplified rendering engine(s). The good news is that Android DOES have all the primitives I need built in. In some ways it’s superior to what’s in J2SE (text on a path, anyone?) But there are libraries available for Java that fill those holes as well. It’s just that it’s going to mean creating a common format between the two and insuring that the renderings are the same. Annoying since there are other problems I would rather be tackling with this project instead. I feel like I’m reinventing the wheel.

This entry was posted in General and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

If you are human, count objects:
Enable this image please
I see:
- +
- +
- +
Ironclad CAPTCHA (Security Stronghold)