tazzix.com

Gone are the good days when PocketPC was the only smart phone platform worth developing for, or when developing an application in J2ME will cover a major share of the devices.

Now you have to cover as many platforms and take care of device fragmentation if your application or service has to give you good coverage across various markets and regions.

I had developed for WindowsMobile since the PocketPC 2002 days, for J2ME since its inception,  and Symbian S60 since the first device was released, but I never was doing mobile device development as a full time job or even hobby, I did however, develop applications and snippets that the usual mobile developers did not venture to.

My most work was on J2ME which I did take up on professional level apart from a few projects in S60, where I found out that I knew much more about mobile device development than I thought I would. I was able to port most of my J2ME stuff to BlackBerry with added features using native classes and APIs. Unintentionally I knew the S60 API inside out without developing many applications and even the versioning issues and workarounds when a specific API was not working as intended under particular circumstances.

Then the dreaded iPhone was launched, an expensive mega mobile device with features unheard of and NO J2ME. Well it was only Web / AJAX development for the first few months. The requirement of owning a Mac for iPhone development is too huge a commodity, not that S60 development could be done on a Mac (out of the box), but Android has nailed it with support for not only these two but my favourite platform, Linux.

As a user, I like the Nexus One, but some things I can only do on the Nokia N97, even if its the most inferior looking to some out of the above devices. The Fuze / TouchPro was my biggest disappointment and hence no other WM phone is going to land in my pocket any time soon.

Now lets go through each of them briefly (trying to be in chronological order, omitting revisions):

Windows Mobile (PocketPC):

Supported by Microsoft it is one of the oldest platforms around in relatively similar shape. Although the .NET framework has changed it a lot but the main goal remains the same as always, to keep development similar to desktop Windows development. I am not sure about other developers but I do not think that worked for me, I was not a Windows developer ever, and Visual C++ or VB where alien terms for me, and knowledge of all things Linux never helped, my applications remained to eVB (embedded VB) because of its visual interface designer. I have later done C# applications as well but the memory management and background running things annoyed me more than any segfault on Linux.

Pros: Windows API, .NET, Familiar languages and constructs, Microsoft Tools, great on device debugging, can run J2ME applications

Cons: Mostly for Windows developers, SDK / Tools only for Windows OS.

Symbian S60:

Symbian also has its roots to older PDAs but in my opinion has changed too much from that era, I have done a few professional projects and know my way around its usually difficult documentation. With Carbide C++ getting better and now free its a good platform outselling most in some regions. All devices run J2ME with multi-tasking, leaving C++ to be used at will and when certain aspects of the phone are to be used.

Pros: Getting OpenSource, Carbide C++ free, Some Linux development possible, Ajax / J2ME applications work

Cons: Variant of C++, Troublesome signing, not so easy to set on device debugging

J2ME (Java):

J2ME is as close to normal Java as it could be on mobile devices, this approach has its own drawbacks but got developers attracted easily and applications rolling. Although the fragmentation with respect to screen colors, dimensions, and keypads killed the enthusiasm as quickly as it began. Although color screen devices with or without touch and any kind of keypad, keyboard, or the lack of it could be handled in one single application and all my applications were based on this. Most of my mobile device work is on this platform ranging from general purpose APIs to stock market and streaming media applications.

Pros: Familiar language and constructs, Cross Platform development, major device share

Cons: device fragmentation, tricky on device debugging, RMS is evil.

BlackBerry:

RIM used J2ME as its starter and provided APIs for native additions, this approach worked well for BlackBerry devices and enough professional applications are out there as this platform targets such users. I liked the native APIs for trackball, special keys, and network integration, etc. I ported some of my J2ME work with native APIs others were just re-packaged to work on RIM devices.

Pros: Similar to J2ME, native APIs and Classes.

Cons: tricky packaging and deployment

iPhone:

The most hyped platform, restricted by Apple and available to the masses unlocked and jailbrocken by I would like to know who. The one iPhone I had corrupted and had to reflash, jailbreak, unlock to get it to work again makes me think that the whole process is not anything like discovering X-rays or the sorts, there is simply no logic behind the precisely timed steps and so on. I have flashed official and not so official operating systems and ROMs to nearly all devices I ever owned (number goes into dozens) so I understand how you can accidentally hit a bootloader and how you need inside info to know it.

Owning a Mac is another bottleneck for iPhone development, its just too expensive compared to similar specification machine of vendors for Windows or Linux. So being unsure if I would do anything commercial I used a Hackintosh, but do not promote it, once you feel you are going to earn from it, go buy a Mac.

The final nail in the coffin, pay US$99 to get on device debugging to work, my foot, ok go ahead and google a free way around, I am still not impressed, the device itself has not seen any changes. Good thing is developers do not need to worry about device fragmentation but iPhone was supposed to be all about innovation, which we have not see between 2G, 3G, and 3GS.

Pros: Hot Platform, First AppStore

Cons: Mac OS X only, built upon antiques, costly on-device debugging / deployment, too much hype.

Android:

Aah, the new kid on the block, but this is how a mobile device platform should be like in this day and age, needs a bit more work on the usage side and I have high hopes associated with FroYo / Android 2.2. Has the best support for development on all platforms (Mac / Win / Linux) on-device debugging was so painless that I could not believe myself if its really my application or if HelloWorld! was installed by Google itself

Java in its full glory with APIs having access to anything on the device and then a Native Development Kit (NDK) for those who want to dive deeper, fixed a bug in the OS, fix it yourself (well a bit more difficult than that, but you got what I mean). Flashing a different OS / ROM does not feel like doing anything risky or potentially harmful to the device. Great work google. The applications maybe low in numbers but with more users jumping on with a better user OS, this is bound to change. Market has potential to attract developers, for the passion and of course the money.

Pros: Familiar language and constructs, vast and well organized API, superb on device debugging, Cross Platform development, OpenSource, use og XML resources.

Cons: low market share of devices,

These are my opinions. Other developers can have their own. Feel free to comment to discuss, but please avoid flaming just because I do not like what is dear to you. You can write about it on YOUR blog, thanks

For all Wateen WiMAX users out there in Pakistan, this small desktop utility will keep you logged in without having to relogin or to find out that your connection was down while you were trying to do something and gave up on it. It is very simple and just uses the web interface to log in and check uploaded and downloaded bytes which are shown on the screen, the green / red square is a status check to see if the connection is up or not. You have to define preferences for username, password, always autologin, and refresh time in seconds. Tested on Windows XP, Ubuntu 7.10, MacOS Tiger.
I also have a J2ME version to be used on WIFI enabled cell phones / PDAs but currently no preference changes are implemented so can not make it available for download, if I get more than 10 comments here asking for it, I’ll take out some time to implement it.

Download the desktop version here:

Screenshot for eye candy (click on image for full version):

When I started exploring J2ME in 2004, I started by creating some APIs which made my life very easy, however, somebody new to J2ME will need a steep learning curve in the restricted environment and on top of that to learn to use third party APIs. Hence, I envisioned that there should be a RAD environment that would allow using built-in J2ME classes, JSRs conditionally, and my APIs without the person need to know anything about any of these things.

This project is precisely here to convert the vision into a practical software. And this post is to keep me working on it.

Planned features:

• An abstract data type to encapsulate a “Screen”:
  • A wait (splash) screen shown while other objects are created including any data gathering from connectivity options
  • Connectivity provided for:
    • SOAP WebServices (via JSR, kSOAP, and wSOAP)
    • Servlet providing data separated rows by “|?” and columns by “||”
    • Bluetooth, IR, USB via JSRs
    • Custom class implementing connectivity interface
    • RMS via RMS to Object mapping, may also be used to cache data that is cacheable
  • UI provided by LCD UI, thinlet (XUL), charts, or table API.
  • Action handlers to perform UI tasks, navigation of screens (may use Hecl mobile scripting for advanced features)
• Rules for screen navigation
• Internationalization

Overview:

Some time ago the thinlet project dropped support for J2ME, but during my search for a XUL API for J2ME, I could not find a more suitable one. Therefore, I first customized the old version for some of my requirements, later on some new features of the thinlet API for J2SE were back ported to this J2ME version. And now its in a state where I think CLDC can compete with CDC using thinlet and maybe more than that

Features:

• Developed on j2me-wtk and Nokia Series 60, testing on Nokia 3650
• MIDP 1.0, CLDC-1.0 Compliant, i.e. can be used on any kind of J2ME device
• All features supported by thinlet API for J2SE
• Full screen text editing for text boxes, with dictionary (T9) support
• Jump mode support (left arrow to activate controls by mnemonic number)
• Touch screen support

Status:

• In production, and being used in my other projects
• Also used by other developers, there used to be Yahoo! group

Screenshots:

Initial version, modified color scheme, and an IM application:

Overview:

This API provides Object Oriented Mappings over J2ME’s standard RMS
Features:

• Developed on j2me-wtk and Nokia Series 60, testing on Nokia 3650
• MIDP 1.0, CLDC-1.0 Compliant, i.e. can be used on any kind of J2ME device

• Support for all J2ME primitive data types and their class representations
• Support for Vector which contains any of the supported types / classes
• Support for pseudo-floating point (MIDP1.0 has no float)
• Support for any class implementing the persistence interface
• Filters, Searchers, and sorters can be applied at retrieval time

Status:

• In production and being used in my other projects
• May not give full performance on phones with slow processors
• May not be an optimal solution on phones having limit on RMS size or low memory

TODOs:

• Write a benchmark program and publish results

Overview:

Currently un-named, its goal is to provide a chart drawing package based on MIDP 1.0 specifications. Another goal is to make this package open-source, see help required below.
Status:

• Line charts are complete
• Pie charts are complete
• Bar and Bar with Line charts are working but require some minor changes
• Data can be given in categories and multiple lines and bars are drawn
• An area of the screen can be given for charting while application uses the rest of the screen
• With a sample application the obfuscated jar is 16 KBytes and takes 52 KBytes heap memory on the Nokia Series 60 emulator
• Axes drawing is partially working (lables and markers are missing)

TODOs:

• Customizations in drawing charts (Point circles, Axes stepping, lines in BarCharts, etc.).
• Chart titles, Axes titles, Data titles, Legend Charts for better explanation of charts.
• Finding a way to release the API in a way that source is hidden (till opensource efforts succeed).

Screen Shots:

Here you see a simple midlet on a Nokia 3650, with the charts occupying the whole j2me canvas area.

Screen shot of my latest j2me work to write a chart plotting API, you can see it in the Nokia series 60 emulator and the Default Color phone emulator from j2mewtk. Although it can contain a lots of bells and whistles, I plan to keep it simple to be viewable on all screen sizes, however, applications need to check for color, gray scale or monochrome device.

A lot more to come in this category, I am in the process of converting my website (Sep 2007) so come back soon.