[Logicmail-devel] Status report on v2.1 development

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

Since I don't have pretty pictures showing off features to accompany 
this report, I'll leave a blog post for another time.  However, since 
I'm about to get really busy at my real job, I figured I should update 
you all on where things stand.  We're actually pretty close, which is a 
good thing.  There may seem to be a lot of open tickets, but most of 
them are gravy (that I likely don't have time to work on).  Besides, the 
real goal of v2.1 is met by finishing everything described below.

If anyone has ideas or comments on anything I'm proposing below, please 
speak up.  I rarely get to discuss any of this with other developers, so 
I'm always open to ideas.

-- Server polling (#79) and always-in-the-background features (#329) --
These are almost done.  There is still plenty of testing that is 
necessary, and a few nit-picky use cases (e.g. account without saved 
username/password) to work through.
The only major piece of development that is really still needed is code 
to handle the "improved connection availability" use case.  This is the 
case where you are connected via the mobile network, and WiFi suddenly 
becomes available.  My current thought is that I'll test for this case 
whenever the connection state is about to leave idle, and reconnect 
accordingly.  What complicates this, however, is that WiFi may not 
actually be usable even if its available.  Since I don't want to kill a 
working connection to attempt to make a non-working connection, I'll 
need some slightly interesting logic here.  (I'm thinking of a 
"handover" process where I attempt to connect over WiFi, without logging 
in, before closing the non-WiFi connection, then "hand over" the new 
connection to be authenticated with.  I'll obviously need lots of extra 
thresholds/checks to make sure that LogicMail doesn't spasm or get stuck 
during these cases.)

-- Memory management for the object model (#212) --
I think I can make this one fairly simple, actually.  Folder-level data 
isn't much of a concern, since its not very big.  Its really only 
message content I'm worried about.  So I'm thinking that I'll simply 
flush message content out of the object model (its hopefully cached on 
the SDCard) whenever a mailbox screen is closed.  I might want to do a 
slightly more complicated implementation however, possibly with a 
background garbage collection process, so this flush isn't immediate.  
(If it was immediate, it could hurt performance or 
non-writable-filesystem device usability.)

-- Configuration improvements --
There may still be more configuration items I need to add for the new 
features, especially in regards to folder polling (e.g. when to update 
the counts, versus what to trigger notifications from, etc).  Also, the 
new user setup wizard needs to now include configuration of these new 
features.  I know Adam has an update to the wizard that improves general 
usability (when he contributes the patch).  Beyond that, I now need to 
also walk the user through the process of setting up polling/background 
operation.  (Its currently all disabled by default, and needs to be 
manually configured.)

-- Various UI touchups and nitpicks --
These are the (hopefully) easy low-priority items, some of which I 
really should do now, and some of which may get pushed to v2.2.  Some 
have tickets, some don't.

P.S. If anyone wants to meet me in person, I'm going to be at DevCon 
Americas 2011 in October giving a presentation on advanced BlackBerry 
unit testing with J2MEUnit and HammockMaker.

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