mail into the "Sent" folder, thus eliminating the need to perform a 2nd
upload into the server's Sent folder. IMAP and POP3 do not support
this (although IMAP could when it recognizes Gmail IMAP servers.)
BUG=1807499
Automated import of CL 148230
message structures before fetching the message body. Code for IMAP &
POP3 is unaffected, but remote stores can override
requireStructurePrefetch() in order to trigger the new behavior.
BUG=1807499
Automated import of CL 148204
combine it with the same code that handles folder persistent data (in
the database). The schema is really simple; Rows with a folder id of
-1 are store data. This also adds the ability to use keys to store
multiple values, instead of a single string per account. Added/updated
unit tests.
3rd party stores will need slight code changes because the persistent
callbacks now accept keys.
BUG=1807499
Automated import of CL 148145
being strict enough about decoupling the MessageListener from
updates to the various lists that should only happen in the UI
thread.
BUG=1812798
Automated import of CL 148096
access mMessageContentView.
This is a brute-force solution, and I have also left TODO notes
mentioning that it might make more sense (long term) to use the
existing handler message mechanism.
BUG=1812798
Automated import of CL 148095
Folder.getVisibleLimit(), which used local copies of the data from the
DB. If there were two Folder objects associated with a single actual
folder, updating one wouldn't be reflected in the others.
BUG=1812798
Automated import of CL 148027
(e.g. EAS) can limit itself to n (usually 1) accounts per device.
The UI for this is really simple - don't show the EAS button when the
limit is reached. More work would be required in
AccountSetupAccountType.java in order to do a more sophisticated UI
(e.g. show the button but pop a toast if the limit is reached.)
BUG=1740626
Automated import of CL 148019
to the set that are stored in their own columns (and thus can
be quickly selected from). Add code to migrate old style
flags into new flags. Add tests.
BUG=1786939
Automated import of CL 148002
MessagingController to accept and track a Context, instead of the
unnecessary Application object, which makes this fix more testable.
BUG=1790798
Automated import of CL 147868
or other changes during a delete operation, we need to explicitly
open the remote trash folder and give it the callbacks.
BUG=1807499
Automated import of CL 147866
calls for each account. This allows the folder list to be
updated before it is synced, which is necessary for some
stores.
BUG=1807499
Automated import of CL 147839
synchronizer code.
2. Refactor (and spell-fix) the core folder synchronizer. Extract
the innards that are IMAP/POP specific, leaving common wrapper
code in a simpler shell.
3. For each account & folder to sync, check the store and call
the specialized sync'er (if provided) or the generic one.
BUG=1807499
Automated import of CL 147730
due to API change, but still has a smaller footprint. Also fixes the
bug in the original, which is that we actually needed to udpate the
local trash folder, not the remote one.
BUG=1807499
Automated import of CL 147714
*** Reason for rollback ***
We figured out a simpler solution affecting fewer files - we
don't actually need the new remotestore API.
*** Original change description ***
Some stores require changing the UID of a message when it is
copied to a new folder (I'm looking at you, EAS). Add a callback
to Folder.copyMessages() which allows the store to report back
such changes. Then, add a new api to record the new values:
Folder.updateMessages().
For now, the two APIs are linked by a common callsite in
MessagingController, so the existing stores can use a minimal
implementation - if they don't call the callback, nobody will
call the update.
BUG=1807499
Automated import of CL 147708
copied to a new folder (I'm looking at you, EAS). Add a callback
to Folder.copyMessages() which allows the store to report back
such changes. Then, add a new api to record the new values:
Folder.updateMessages().
For now, the two APIs are linked by a common callsite in
MessagingController, so the existing stores can use a minimal
implementation - if they don't call the callback, nobody will
call the update.
BUG=1807499
Automated import of CL 147620
deeper database-style operations with them. This enables two
new LocalStore APIs to be provided: A new version of
GetMessages() that can retrieve only flagged (or un-flagged)
messages, and a new method to set flags for an entire set of
messages, in a single SQL transaction.
BUG=1786939
Automated import of CL 147401
*** Reason for rollback ***
Despite the markings in the CL, this was inadvertently merged.
This CL restores donut & downstream branches to the desired state.
*** Original change description ***
am: CL 146359 D* N*T M***E - we'll keep the fix for donut+
Automated g4 rollback of changelist 146273.
*** Reason for rollback ***
Inadvertently approved for cupcake, past deadline.
*** Original change description ***
Fixed "show pictures" button isnot displayed for HTML messages.
Original author: stadler
Merged from: //branches/cupcake/...
BUG=1766880
Automated import of CL 146366
Automated g4 rollback of changelist 146273.
*** Reason for rollback ***
Inadvertently approved for cupcake, past deadline.
*** Original change description ***
Fixed "show pictures" button isnot displayed for HTML messages.
Original author: stadler
Merged from: //branches/cupcake/...
Automated import of CL 146361
of the role-specific folders such as Drafts, Sent, or Trash.
This allows us to properly target these folders even on
systems where they have different names. I capture the
tagged names into the existing columns in the account data,
where they are used elsewhere in the code (no changes
necessary).
Use default implementations on POP3 and IMAP for now -
no change from original behavior. The new code is
primarily to support EAS (for now).
BUG=1790798
Automated import of CL 146360
The default values are 25 (default) and 25 (increment). This is fine
for Stores that control downloads by # of messages, but won't work for
stores that use other measurements - e.g. EAS windows the download in #
of days. So for this change:
1. Allow the StoreInfo to provide non-default values
2. Remove the hardcoded references to the default values
3. Use StoreInfo values everywhere
4. Set the values to 1,1 in EAS store info
BUG=1789913
Automated import of CL 146331
syncing. This provides a key-value store, per folder, that
can be used by network Stores to record persistent data such
as sync status, server keys, etc.
Note that, by definition, this only applies to remote folders
(e.g. IMAP, POP3). You'll see everywhere that LocalFolder is
passed null, and this is correct - LocalFolder *is* persistent
storage and does not need external help.
Note to reviewers: The core changes are Folder.java,
LocalStore.java, and LocalStoreUnitTests.java, so please give
them the bulk of your reviewer attention. The other files
are just following along with minor API changes. Of those,
the one worth close examination is MessagingController.java,
which is the only place in the system where remote Folders
are bonded with Local Folders and thus where this new API
comes into play.
Note to jham: Can you please take a look at
LocalStore.LocalFolder.setPersistentString() and recommend
better SQL foo than my primitive test-then-update-or-insert
logic, which is not transactional or threadsafe.
BUG=1786939
Automated import of CL 146134
The current design for Store classes (e.g. IMAP) did not provide for
any persistent storage. This is the beginning of a mechanism to
provide that. It's quite simplisitic - each Store can read/write one
persistent string - but that's enough for the first simple use case
(saving some sync data for EAS).
The core changes here - suggest reviewing first - are in Account.java,
Store.java, and AccountUnitTests.java. Everything else is just
following the API change that was necessary.
Note that, by definition, this only applies to remote stores (e.g.
IMAP, POP3). You'll see everywhere that LocalStore is passed null, and
this is correct - LocalStore *is* persistent storage and does not need
access (so far, at least).
BUG=1786939
Automated import of CL 146061
The logic for this is quite simplistic, for now: When the store
reports that it has new messages, it triggers a service refresh,
just as if a pull-mode interval had expired and it is time to
check the server.
Note, unfortunately at this time there are no tests, because there
are not currently any good test seams in MailService.java.
BUG=1776149
Automated import of CL 145227
1. Generalize the code for the various spinners that control
account check frequency.
2. Provide an API for looking up store attributes (and refactor
existing instatiateStore logic to use it).
3. Cleanup the old code that was used to setup frequency spinners.
4. Hardwire Exchange accounts to default into push mode.
Notes to tester:
1. For each account type (POP, IMAP, EAS) we need to check that
auto & manual creation "do the right thing" for frequencies.
POP & IMAP should offer "none" or time intervals, while EAS
should offer "push", "none", or time intervals.
2. EAS accounts should default to "push", all others to "15 min"
3. Make sure that you can edit existing account settings and see
the right choices (only EAS should be offered push).
4. I couldn't write an automated test for the mail checker service,
please confirm that POP & IMAP accounts are checked at the right
intervals (or never, if set for "none".)
BUG=1776149
Automated import of CL 144953
the shipping client will include the necessary generic pieces for
configuring an Exchange client (e.g. account setup) but will not
include actual Exchange client code (e.g. transport / protocol).
Also added a "sample code" implementation of Exchange for use
as a starting point for implementors. (Note, this will not ship
in Donut, it's a placeholder for working on the "framework"
aspects.)
BUG=1740621,1740626
Automated import of CL 144525
errors, inconsistencies in passing Application/Activity/Context, and
some error handling cleanups. These are all changes that would have
probably been made before the original submits, but I didn't want
to fix them in the integration step.
BUG=1740621
Automated import of CL 144520
If you absolutely must add a string after string freeze, and that
same string has already been translated for another application
in a similar context, you can copy the translation by specifying
it by numeric message ID.
Fix the incorrect IDs I had told people for a couple of strings,
add the script that will make a flat-file version of translations
so you can find out the IDs yourself, and reimport the translations
for the couple of applications that wanted to copy translations.
Original author: enf
Merged from: //branches/cupcake/...
Automated import of CL 143164
