This commit addresses 2 issues:
1) Before, a general GestureDetector was registered on the highest level in K9Activity
This resulted in EVERY inherited activity to have a useless, unused gesture detector.
But more than that, in MessageList, a second GestureDetector was assigned to the ListView.
On every fling gesture, both detectors called the onSwipe() methods,
which technically did the following:
- The one directly assigned to the ListView would work corectly by mapping the
(local) event coordinates to the right entry in the ListView
- The global one worked on screen coordinates, so the onSwipe() method would
likely select the wrong ListView entry (system menu bar offset).
- For some reason this "worked" fine, and only the correct entry was selected,
despite two detectors used.
2) The gesture detection for the MessageView caused problems when the message
itself was scrollable, i.e. wide HTML mails. A fling gesture inside the WebView
would scroll the message, but also switch the message.
This commit fixes all those by doing the following:
- Don't register the GestureDetector in K9Activity, instead make the member variable
accessible by subclasses.
- In the subclasses that need a detector register it
- In K9Activity.dispatchTouchEvent() check for mGestureDetector being null
- For MessageList:
* Remove the duplicate gesture detector assigned to the ListView
* in the handleSwipe() methods: calclulate pixel offset of the ListView to make
it work using the global screen coordinates
- For MessageView: Limit sensitive area to the message header, to prevent interference
with the WebView scrolling
- Respect current behavior:
* Force-enable gestures for the MessageList
* Respect user setting in MessageView
- Make sure that after a successful swipe gesture, any pending action is cancelled, to
prevent unwanted things to happen (such as expanding the header after changing
the message, or a context menu popping up in the MessageList).
See http://code.google.com/p/android/issues/detail?id=8497
the new sort saves per account, and there is no active account for these folders.
so also, there is no saving of the sort for the unified inbox nor all messages.
otherwise obviously leads to crashes.
IMHO this was a logical location to move, and it resolved my issue when
account was not yet accessible due to not yet accepted key upon importing
old settings from a stored file
---
A new option to set default sort setting is added to account settings.
* commit '7a9ba4e0ad483cb275281e8b33d9e6d35d870151':
Create implicit sort remembering setting2(minor indentation error)
Create implicit sort remembering setting
Create default sort setting by preference
* 'master' of https://github.com/mnb20/k-9:
High DPI version of archive button icon
Fixed whitespace
Remove TODO
Replaced archive icon. Still a bit crap, but better than my previous attempt.
Added batch buttons for Archive and Move. Made batch buttons configurable.
"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.
UiThread:
Fixes a common error from the market:
android.view.ViewRoot$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRoot.checkThread(ViewRoot.java:2802)
at android.view.ViewRoot.invalidateChild(ViewRoot.java:607)
at android.view.ViewRoot.invalidateChildInParent(ViewRoot.java:633)
at android.view.ViewGroup.invalidateChild(ViewGroup.java:2505)
at android.view.View.invalidate(View.java:5139)
at android.view.View.setFlags(View.java:4502)
at android.view.View.setVisibility(View.java:3030)
at
com.fsck.k9.activity.MessageList.hideBatchButtons(MessageList.java:2883)
at
com.fsck.k9.activity.MessageList.toggleBatchButtons(MessageList.java:2906)
at com.fsck.k9.activity.MessageList.access$500(MessageList.java:77)
at
com.fsck.k9.activity.MessageList$MessageListAdapter.pruneDirtyMessages(MessageList.java:2302)
at com.fsck.k9.activity.MessageList$1.run(MessageList.java:811)
* mail-on-sd: (40 commits)
Added more comments to explain how the locking mecanism works for LocalStore
Fixed wrong method being called during experimental provider initialization (since provider isn't enabled, that didn't harm)
Add more comments about how the various StorageProviders work and how they're enabled
find src/com/fsck/ -name \*.java|xargs astyle --style=ansi --mode=java --indent-switches --indent=spaces=4 --convert-tabs
French localization for storage related settings
Remove unused SD card strings (replaced with storage indirection)
Merge mail-on-sd branch from trunk
Reset mail service on storage mount (even if no account uses the storage, to be improved)
find src/com/fsck/ -name \*.java|xargs astyle --style=ansi --mode=java --indent-switches --indent=spaces=4 --convert-tabs
Migraion -> Migration
move the Storage location preference into preferences rather than the wizard.
Made LocalStore log less verbose Added @Override compile checks
Added ACTION_SHUTDOWN broadcast receiver to properly initiate shutdown sequence (not yet implemented) and cancel any scheduled Intent
Be more consistent about which SQLiteDatabase variable is used (from instance variable to argument variable) to make code more refactoring-friendly (class is already big, code extraction should be easier if not referencing the instance variable).
Added transaction timing logging
Factorised storage lock/transaction handling code for regular operations.
Use DB transactions to batch modifications (makes code more robust / could improve performances)
Merge mail-on-sd branch from trunk
Update issue 888 Added DB close on unmount / DB open on mount
Update issue 888 Back to account list when underlying storage not available/unmounting in MessageView / MessageList
...
updates on a thread rather than on the main ui thread. it results
in the list blinking with old data, but that's still a better user
experience than "frozen"
This doesn't work on initial sync, since the comparisons fail and you're
left with duplicates in the displayed mailbox
This reverts commit fa1c88bec348d0132acc60a320626bf0ca1170ec.
the list, use a less painful equality check than iteration.
This works because messageInfoHolders compare to each other using the
same key as message they contain.
updates on the UI thread rather than the sync thread. This is a huge
performance boost (based on simple empirical testing) for initial syncs
as we now do more work as we add messages to message lists
into the messagelist is now much, much faster. Intentionally loading the
whole mailbox before we let the user interact with the list is
increasingly painful. A 250 message mailbox takes 2+ seconds to "unlock"
on a modern phone.
Consequently, this commit switches us _back_ to progressive loading of
mailboxes from the synchronous version.
Based on user feedback, we may or may not keep this for the production
release.
list, don't "bother" sorting the messagelist again before opening the
message, it adds a _bit_ of slowness when we don't need it and
we'll sort again when we get back to the message list.
