4 Commits

Author SHA1 Message Date
Moxie Marlinspike
375207f073 Switch MMS groups to use the group database infrastructure
Eliminate the concept of 'Recipients' (plural). There is now just
a 'Recipient', which contains an Address that is either an individual
or a group ID.

MMS groups now exist as part of the group database, just like push
groups.

// FREEBIE
2017-08-28 10:30:50 -07:00
Moxie Marlinspike
6da86e482d Support for dual-sim SMS/MMS functionality
Allow source selection for sending SMS/MMS, and display the
SIM that received SMS/MMS.

Fixes #555
Closes #5199
// FREEBIE
2016-02-09 16:53:15 -08:00
Moxie Marlinspike
40af2a81db Support for per-recipient muting, blocking, and ringtones.
Fixes #757
Fixes #354
Fixes #222
Closes #1815
Closes #3378

// FREEBIE
2015-06-11 11:09:02 -07:00
Moxie Marlinspike
83e260436b Major storage layer refactoring to set the stage for clean GCM.
1) We now try to hand out cursors at a minimum.  There has always been
   a fairly clean insertion layer that handles encrypting message bodies,
   but the process of decrypting message bodies has always been less than
   ideal.  Here we introduce a "Reader" interface that will decrypt message
   bodies when appropriate and return objects that encapsulate record state.

   No more MessageDisplayHelper.  The MmsSmsDatabase interface is also more
   sane.

2) We finally rid ourselves of the technical debt associated with TextSecure's
   initial usage of the default SMS DB.  In that world, we weren't able to use
   anything other than the default "Inbox, Outbox, Sent" types to describe a
   message, and had to overload the message content itself with a set of
   local "prefixes" to describe what it was (encrypted, asymetric encrypted,
   remote encrypted, a key exchange, procssed key exchange), and so on.

   This includes a major schema update that transforms the "type" field into
   a bitmask that describes everything that used to be encoded in a prefix,
   and prefixes have been completely eliminated from the system.

   No more Prefix.java

3) Refactoring of the MultipartMessageHandler code.  It's less of a mess, and
   hopefully more clear as to what's going on.

The next step is to remove what we can from SmsTransportDetails and genericize
that interface for a GCM equivalent.
2013-05-06 08:40:55 -07:00