Commit Graph

8 Commits

Author SHA1 Message Date
Marc Blank f419287f22 DO NOT MERGE: Move emailcommon2 sources to emailcommon
Change-Id: I06df7e467cd2e0117df8b8db3ddc6ff9da13f1c7
2012-06-28 11:15:06 -07:00
Marc Blank dceb2884ea Reduce max in-memory size of IMAP text from 16MB to 2MB
* Even 2MB is probably high, but it's far better than 16MB

Bug: 5573863
Change-Id: I00d6d84ebc538d41dbf5683bd078a6bcd802e584
2011-11-14 16:53:48 -08:00
Marc Blank 31d9acbf06 Email split, part huit: Refactor constants, clean emailcommon
* There are three pieces to this CL (sorry):
  1) Move and/or rename some constants into emailcommon
  2) Move Utility to emailcommon, moving the few UI
     related utilities back into Email (FolderProperties
     and UiUtilities)
  3) Remove all references to resources from emailcommon
* The three pieces relate in that, between them, they allow
  the emailcommon static library to compile cleanly

Bug: 3442973

Change-Id: Ic5e3abaa2a1b36999e0b6653c6c2134ea1bd544f
2011-02-14 12:18:10 -08:00
Todd Kennedy 32311cce01 Implement IMAP prefix support
We support two different ways for an IMAP prefix to be specified:
  1. A text field on the IMAP configuration page. This is the most obvious to
     the end user. It is also an explicit, manual configuration.
  2. RFC2342 defines a NAMESPACE IMAP command to be able to query the prefix
     from the IMAP server. This is an automatic configuration without any
     user involvement (i.e. the UI will NOT change if a prefix is loaded in
     this way)

If the user goes to the trouble of specifying a prefix, we will always honour
it instead of the namespace returned by the IMAP server -- even if the user's
configuration is wrong.

bug 1592696

Change-Id: I6b94c7aaac538f6cd9dc4694b0f1634e8c956bc1
2011-02-11 14:17:48 -08:00
Marc Blank 2193962ca2 Email split, part quatre: Move along, nothing to see here
* No code was harmed, er, changed in the making of this CL
* All that's happened is that code that is needed by both Email and
  Exchange have been moved into emailcommon
* This required import changes to many files, which explains the
  length of the CL

Change-Id: I4e12455ba057a4a8054fdbd0b578c73afa411c8a
2011-02-10 16:28:37 -08:00
Todd Kennedy 8d8537cd2e Resolve build warnings; part 3
Fixes deprecation warnings

NOTE: This does not resolve hostauth deprecation; that will be fixed
in a separate CL.

Change-Id: I47115516da34effbf885615cb439c9d3e6f95b84
2011-02-03 12:43:12 -08:00
Makoto Onuki 977a7d206a Always destroy ImapResponses.
Unfortunately it's hard to write tests for this change, but at least
all tests pass with Idc7b88c4.

Change-Id: If0335a848dfcc23aecea22c21b2cce73dac7ff6f
2010-06-02 09:56:46 -07:00
Makoto Onuki 7e5ba0e1ea New IMAP parser to fix long-lasting problems.
- Almost completely re-wrote ImapResponseParser layer
- We no longer use simple ArrayList and String to represent
  imap response.  We have classes for that.  (Type safe!)
  These classes are also NPE-free.
  (which isn't necessarily a good thing, though)
- A lot of clean-ups and fixes in ImapStore.
- More tests for ImapStore.

Now ImapResponseParser moved to com.android.email.mail.store.imap.parser,
but inside, it's 99% new code.

This CL introduces many new classes, but most of them are small classes
to represent the IMAP response.

Problems that this CL fixes includes:
- Special characters in OK response
- Handling BYE response
- Case sensitivity
- ClassCast/ArrayIndexOutOfBound/NumberFormatException
- Handling NIL/literals at any position

Bug 2480227
Bug 2244049
Bug 2138981
Bug 1351896
Bug 2591435
Bug 2173061
Bug 2370627
Bug 2524881
Bug 2525902
Bug 2538076

Change-Id: I7116f57fba079b8a5ef8d5439a9b3d9a9af8e6ed
2010-05-28 15:59:09 -07:00