"Scale-independent Pixels - this is like the dp unit, but it is also
scaled by the user's font size preference. It is recommend you use this
unit when specifying font sizes, so they will be adjusted for both the
screen density and the user's preference." - Android Developer Docs
Make the mTopView a ToggleScrollView. The only consumer is currently the MessageView, which uses a ToggleScrollView anyway. This should make it easier to reuse the anti-scrolling features in ToggleScrollView for ListView later on.
Remove memory leak from referencing MessageView context from the
Intent that is created to go back to MessageList. MessageView is no
longer hardcoded to go back to MessageList, it instead uses an Intent
given at creation to get back to the originating Activity.
Try our best to restore the MessageList in its previous state when
"Manage BACK button" option is enabled:
Since MessageList lives in its own task, we look for the previous
active task and check whether its top activity matches it. If it does,
we just finish MessageView and Android will automatically restore the
previous task. If it doesn't, we launch the originating Intent (and
MessageList state will be lost).
If option is off, we get the regular Android behavior: got back to the
previous screen, whenever it's the MessageList or another application
if the user long-pressed HOME.
The consequence of this is the need for a new permission in order to
check the previous active task: android.permission.GET_TASKS
reloading
As part of automatic activity reloading following a configuration
change, Android invokes Activity#onPrepareDialog() even for dismissed
dialogs. Consequently, one can't make the assumption that this method
is only invoked by explicit calls to Activity#showDialog() from our
code.
The actual problem here was the mActiveMessages member being null
at such times.
Message operations should be more consistent now, regardless of how
the messages are selected (long click, checkbox+Menu, future group selection).
This is a backport of the modifications made on the issue258 branch,
without the threading specific features (no new feature introduced).
The previous approach (generating the view in the adapter) kills performance
because list views cannot be recycled anymore, as soon as the user scrolls to
the bottom of the list. The Android ListView widget already provides support
for list header/footers, so use them.
Standard Java serialization is slow on Android. Replacing it w/
parcelable makes it around 10x faster (on a N1, with ~ 500 messages
in the list).
To avoid further confusion and potential bugs MessageReference was
made no longer implement Serializable.
