Re: [Logicmail-devel] J2ME vs BB-specific APIs

[Derek K. <dko...@lo...>]

On Tuesday 25 August 2009 7:03:20 pm WJCarpenter wrote:
> [[First of all, forgive me!  I had LogicMail 1.0.4 installed for quite a
> while and figured it was just another half-baked but promising IMAP
> client that would soon be abandoned like so many others.  Just today I
> installed the lasted 1.9 build, and woo-hoo!  This baby is starting to
> rock!  It's now pretty close to what I have been looking for ever since
> I got my BlackBerry.  Kudos.]]
I'll admit that I'm certainly taking forever to get to 2.0.  Its because the 
scope and complexity of 2.0 is orders of magnitude beyond 1.x.  (and I did at 
least fork 1.1, which is 1.0 with updated development infrastructure, more bug 
fixes, and some community patches)  The real reason is that 1.x was almost too 
simple.  Really the minimum app that got the job done.  To make a desktop 
analogy, going from LM 1.x -> 2.0 is like going from Pine to Thunderbird, at 
least under the covers.

> I haven't had the chance to browse through the LogicMail sources, but I
> am curious about the separation/modularity/abstraction of the BB
> proprietary APIs versus generic J2ME APIs.  My assumption is that
> BB-specific APIs are used to save work and/or to make a better user
> experience.  Are there fundamental features that would be extremely
> difficult or impossible to implement without the BB-specific APIs?
This is an interesting topic, actually.  When starting on a BlackBerry app, 
its easy to think that you only need the BB-specific APIs for the UI and some 
minor integration issues.  However, once you really get going (and far more so 
once you cave in to getting a code signing key), you find that the generic J2ME 
are almost absurdly limited.  (and RIM is more than happy to fill the gap with 
their own stuff)

Now on the bright side, whenever RIM adds a major new general-purpose API 
feature these days, they do try to find and implement a JSR for it.  So at 
least some of the new stuff does tend to use standard Java APIs.  (however, 
J2ME in general seems to be a crapshoot across devices for anything 
interesting, or so I've heard, due to lack of forced standards)

So the general answer is that the UI code is all RIM-specific, while the non-UI 
code is mostly generic Java.  But the more detailed answer is that there's a 
whole smattering of net.rim.* classes used in non-UI code.  These classes 
cover everything from array-handling utilities, to sortable vectors, to 
efficient hashtables for storing primative types, to MIME parsing utilities, to 
persistant object storage for application configuration (ok, this is the only 
one I used a J2ME approach for in 1.x due to code signing), to Base64 
decoding, and various other random tidbits.

If you're curious, recursively search the source tree for import statements 
referencing anything starting with "net.rim".

> The real question I am asking is .... would it be feasible to have
> non-BB LogicMail versions where some things have alternative or missing
> or dumbed down implementations without BB-specific APIs?  The mobile
> world in general needs a good IMAP client so much, and LogicMail is
> starting to look so good, that it seems a shame to limit it to BB only.
> Even though I use a BB Bold, I might be able to put some effort into a
> "pure J2ME" LogicMail if it looks tractable in the first place.

Is it possible? Sure.  Is it a ton of work?  Absolutely. :-)
First you'd have to write a whole new UI, or do even more overcomplicated 
refactoring of the existing UI to remove any RIM class references from the 
code.
Then you'd have to essentially abstract and reimplement a whole variety of 
utility classes.

Another option might involve doing this to just the core "engine" of the 
application (mail protocol handlers and asychronous event-driven data model), 
and breaking that out into a common code base that can be shared by different 
front-end applications that handle everything else.

The biggest issue here is that there really is no "standard" for mobile Java.  
From what I've seen, you have the following:

Android - More modern J2SE 1.5 derrived API, but very much a Google creation

BlackBerry - J2ME underpinnings, with additional JSR-based APIs, but very much 
a RIM creation with plenty of BB-specific useful functionality to fill the gaps.

Generic J2ME - Somewhat unstandardised and often ugly (unless using a 3rd 
party UI toolkit) and definitely primative API designed for dumb phones, though 
also offered on real smartphones as what feels like a second-class citizen to 
the native platform.
(Caveat: Its been a while since I seriously looked at regular J2ME)

-- 
---------------------------
Derek Konigsberg
dko...@lo...
---------------------------