The new method is a little bit janky, but a little bit of jank is better than 2n
heavy SQL count queries per folder before we even show the folder list.
On my 200 folder account, display of the folder list activity drops from 10+s to
< 1s
If you attempted to use SSL to connect to a server that speaks
STARTTLS, you should get an SSL protocol error. Instead, you
were likely to get an "Unrecognized Certificate" error that shows
you an unrelated certificate chain and asks you to accept it or
reject it. Neither action would work because the actual problem
had nothing to do with certificates. The unrelated certificate
chain that popped up had been statically stored when validating
a prior connection to a different server.
With this patch, certificate chains are no longer stored statically
when validating server connections.
Issue 5886 is an example of a user experiencing this problem.
Gmail style user pics, 2nd try
* sfuhrm/gmail-style-user-pics:
Changed the fallback char from 'K' to '?'. The riddler was here ;).
Using Android proposed colors as contact color palette now: http://developer.android.com/design/style/color.html
Fixed NPE found by blackbox87 ... thanks pal!
Added more finer characters as proposed by cketti
Caching also the calculated anonymous bitmap as proposed by maniac103. This removes a lot of code for special handling unknown contacts.
Bugfix for negative modulo result indexing the palette array
Changed hash based color calc to a hash indexed palette as discussed in the pull request.
GMail-app-style generated colorful one-letter contact pictures for pictureless contacts
Conflicts:
src/com/fsck/k9/activity/misc/ContactPictureLoader.java
src/com/fsck/k9/fragment/MessageListFragment.java
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.fsck.k9/com.fsck.k9.activity.UpgradeDatabases}: java.lang.NullPointerException
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2117)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2155)
at android.app.ActivityThread.access$700(ActivityThread.java:139)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1248)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5062)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:795)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:558)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
at android.app.Instrumentation.execStartActivity(Instrumentation.java:1409)
at android.app.Activity.startActivityForResult(Activity.java:3389)
at android.app.Activity.startActivityForResult(Activity.java:3350)
at android.app.Activity.startActivity(Activity.java:3562)
at android.app.Activity.startActivity(Activity.java:3528)
at com.fsck.k9.activity.UpgradeDatabases.launchOriginalActivity(UpgradeDatabases.java:183)
at com.fsck.k9.activity.UpgradeDatabases.onCreate(UpgradeDatabases.java:109)
at android.app.Activity.performCreate(Activity.java:5058)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1079)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2081)
... 11 more
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.fsck.k9/com.fsck.k9.activity.MessageList}: java.lang.NullPointerException
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1970)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1995)
at android.app.ActivityThread.access$600(ActivityThread.java:128)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1161)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4517)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:993)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:760)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
at com.fsck.k9.activity.MessageList.decodeExtras(MessageList.java:368)
at com.fsck.k9.activity.MessageList.onCreate(MessageList.java:216)
at android.app.Activity.performCreate(Activity.java:4470)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1053)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1934)
k
* 'Issue_4503_auto-fit_messages_option' of https://github.com/zjw/k-9:
Revert "Don't show a disabled preference if there is nothing a user can do to enable it."
Fix indentation
Correct preference version number.
Issue 4503: Auto-fit messages option
Don't show a disabled preference if there is nothing a user can do to enable it.
Previously the activity theme was used to display the auto-complete
suggestions. This lead to unreadable text when the activity theme was
different from the "composer theme".
This was disabled in faa666394c
because it isn't possible to extract the name of the android
contact in the 'ORDER BY...' clause when querying the database.
Instead it simply sorts by the email address.
This may cause the same contact to appear multiple times in
the list, if they have multiple email addresses assigned.
But in most cases this is good enough and surely better than
not having the option to sort by sender at all.
Desktop mail clients such as Thunderbird also simply use the
sender email information when sorting the column.
This also adds a SenderComparator for usage in the MergeCursor.
The server search itself does work. But the results are not displayed
to the user because only the message headers of found messages are
downloaded and the subsequent search in the local database won't return
those messages.
The MIME type for the supplied text was always text/html,
so there is no need to pass that as a parameter.
Furthermore, we are relying on it being text/html because
we are wrapping it with HTML code.
Likewise, change/simplify/rename AccessibleWebView.loadDataWithBaseURL().
Previously, <html>, <head>, & <body> tags were
attached to messages before they were stored locally.
But now that the <head> element also needs to include
a <meta> element (for proper MessageWebView display),
it seems unecesary to store all these tags with each
message.
Now the tags are no longer stored with the messages. Instead,
MessageWebView applies the tags before displaying the message.
This also eliminates the need to upgrade an older
message database where all the old messages would have
otherwise needed to be wrapped with the new tags.
This fixes the following scenario:
- Get a mail notification
- Click on notification -> message view appears
- Press home
- Get a new notification
- Click on notification -> last instead of new message is displayed
This way also the From: selection, To:, Cc, and Bcc: are themed correctly.
It looks more homogeneous and is consistent with the looks of the MessageView.
by default.
The message view theme isn't something the user is likely to change on a
regular basis, so we don't need to clutter the message view menu with
this setting. The menu item can still be enabled for those who want it.
Remove the fadeout to make things look a little less weird
Make the animations slide in from the edge. (See the aforementioned comment about jankyness)
TODO: don't remove the message view until _after_ the animation runs. Before HC, that requires rather a lot more code (writing a whole animationadapter) than it should.
TODO: get the messageview to stop jumping to hide the header area as it's displayed.
- Since the split-view change, MessageView is only a fragment, so we
can't call setTheme() anymore so easily.
Instead, use a ContextThemeWrapper and use that to inflate the
layout. This way the message header and attachment view
are styled correctly.
- The HTC WebView fix in SingleMessageView was returning the wrong
background color, when message view theme and global theme differ,
because it always used the global theme to retrieve it.
Fix: Specifically put the light/dark values in the themes.xml,
and get them using getContext().getTheme().resolveAttribute().
getContext() will use the ContextThemeWrapper from above, so
even if the global and message view themes differ, it aleays
returns the correct one.
The getThemeBackgroundColor() method added to the K9ActivityMagic
interface in 309eeb72ac is now not
needed anymore, and was removed.
