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
This was a holdover from Signal's origins as a pure SMS app.
It causes problems, depends on undefined device specific behavior,
and should no longer be necessary now that we have all the
information we need to E164 all numbers.
// FREEBIE
1. Switch from 300 to 500 colors.
2. Colorize incoming conversation bubbles.
3. Colorize recipeint preference activity toolbar.
4. Support inverted colors in avatars.
5. Make status bar icons tint according to secondary color.
// FREEBIE
Drawables are (strangely) mutable objects. We reuse a single
drawable for each recipient, but some avatar views (the
conversation list -- 40dp) are larger than others (the
conversation -- 30dp).
This results in a situation where TextDrawable doesn't render
itself appropriately, because the bounds are modified by a larger
view.
Giving the Drawable an intrinsic width and height resolves this
conflict.
// FREEBIE
If the contact doesn't have an image, render a color-coded
background and the first letter of the contact's name.
1) Don't display anything during recipient resolution.
2) Display a # icon in material gray for recipients with no name.
3) Display a material group icon in material gray for groups with
no avatar icon set.
Closes#3104
// FREEBIE
* unify single and multi contact selection activities
* follow android listview design recommendations more closely
* add contact photos to selection
* change indicator for push to be more obvious
* cache circle-cropped bitmaps
* dedupe numbers when contact has multiple of same phone number
// FREEBIE
1) In addition to the Recipient interface, there is now
RecipientDevice. A Recipient can have multiple corresponding
RecipientDevices. All addressing is done to a Recipient, but
crypto sessions and transport delivery are done to
RecipientDevice.
2) The Push transport handles the discovery and session setup
of additional Recipient devices.
3) Some internal rejiggering of Groups.
1) Switch back from AsyncTasks to an Executor and Futures.
2) Make the Executor operate LIFO.
3) Make the Executor thread a BACKGROUND_PRIORITY thread.
1) Refactor recipient class to support asynchronous loading operations.
2) Refactor recipient factory to simplify recipient access.
3) Consoliate everything into one recipient provider that is capable of
doing async lookups and intelligent caching.
This requires a few changes to Recipient in order to make sure we
have a Contact URI at click time. While we're at it, let's git rid
of the OldRecipientProvider, which was for pre-2.0 contact stuff
(no longer supported, woohoo!).
