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

I started exploring on this front as well and have come up with some features and ideas that should be present in such a system.

• Easy to program scripts running on the device in a non-distructive manner
• Functions executed in linear / iterative fashion, including:
  • KeyPress – keycode
  • KeyDown – keycode
  • Delay – milliseconds
  • KeyUp – keycode
  • AllKeysUp – void
  • PointerDown – x, y
  • PointerUp – x, y
  • NOOP – void (no-operation) to force a step in the report
  • Grouping of above commands to form functions
  • Extended library to directly perform tasks available from the underlying platform:
    • OpenURL – url
    • TakePicture – void
    • etc.
• HTML based reports, viewable on the phone, via an embedded HTTP server, or sent to a computer:
  • Step function, parameters, screenshot before executing, and comments for documentation
  • Cell ID can be included for rough location estimates (once cell-id to GPS coordinates are established)
  • For phone with built-in GPS, show coordinates and link to Google Maps, or Yahoo! Maps, etc.
• Applications:
  • Mobile Software testing
  • QoS testing of a service provider, mimicking an average consumer (the script runs through commute and all)
  • Mobile Web site testing, screen shots are enough to show what is going wrong
• Platforms:
  • Python – to run on S60 v2, S60 v3
  • Symbian – to run on various versions of S60 and UIQ
  • .NET to run on PocketPC and Smarphone based devices

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

Anyways, I learned a lot during the research report and wanted to use this language more often. At the time I had a Nokia 3650 phone which could use a Palm (ThinkOutside) Infra-red keyboard using a special driver. Which was an ideal setup to just start forthing away anywhere at all, hence, I started looking for a Forth interpreter which could run on this phone, but could not find any. I had written some J2ME APIs (specially floating point emulation on MIDP1.0) so my next target was to find a Java based Forth interpreter implemented as a standalone class so that I can wrap it up into a J2ME Midlet of my own.

I stumbled across SFI Forth and achieved the goal, the official page also hosts a download link for my version. And for Spanish? readers. It has no file or RMS persistence support but I have not been using it on better phones now, even though I have plans to enhance it a little whenever I have some time.

In the picture below you can see the setup in action, click to see a larger version.

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:

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

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.

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