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
