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...
----------------------------
|
