we show images in avatars for the following items:
group chats, see dc_chat_get_profile_image() resp. DcChat.getProfileImage()
profile images of contacts if set in the system address book
these two sources are also used in the old telegram ui.
for the future, there will probably be a dc_contact_get_profile_image(), maybe we can just add and use a DcContact.getProfileImage() that always returns null for now.
Will tackle this one as soon as #79 is finished.
great :)
Delayed, will do #92 first.
great to push this forward.
@Boehrsi currently, for all groups _without_ an image set, a blue round icon with a group image is set.
i think, it is better to have the colored-fallback-icons-with-first-groupname-letter as before here as it makes groups in the lists easier distinguishable.
nb: the group icon (without circle then) could be added beside the title instread - as in the old telegram ui:

@r10s makes sense, will adjust that today while fiddling around with the avatars provided by the system.
cool.
i just added the function DcContact.getProfileImage() - currently it always returns the empty string for "no image", however, very soonish it will come to life.
would be great if this could be regarded already as well.
_With the latest changes probably some images / avatars will reset!_
As soon as DcContact.setProfileImage() / DcContact.getProfileImage() is working I would start adding the following:
@r10s could it be a good idea to add the "phone book contact photo id / uri" when calling dcContext.addAddressBook(...)? Doing this we would have a central place to get all the information of the system contacts directly from the core.
In general I changed some stuff so we just gather all images needed and copy them over to our directories. There we can load and control them without extra work. This is done for both, group images and also profile images. If we add later something like "server side image loading" we can easily fit this in.
great :)
some nitpicking:
wrt photoId/Uri: i think, currently, this is not needed. we can start storing them if we really need it :)
Added the color adjustments. Now starting with the loading of phone contact avatars.
Nearly done and already working in the "contact / new chat" activity. I'm currently struggling to apply the system contact images also for the conversation list + conversations + and so on.
so I postpone this until the setProfileImages / getProfileImages methods are ready, as they are meant to be used for this anyway
but these functions won't replace getting the images from the system address book.
in fact, they will _only_ return an image if set by the remote user. i this is not the case, the image from the system address book should be used. and, finally, if there is none, we fallback to the colored image as just now.
so, i think, it makes sense to show the image from the system contact address book already now if DcContact.getProfileImage() returns the empty string.
(for testing locally in your machine you could make DcContact.getProfileImage() return a path to an static image)
Makes sense and I'm already getting the images while loading the address book (and showing them in the contact screen) but we need some sort of mapping between the DcContacts and the system avatars. Therefor I asked for the URI / ID saving when adding the contacts to the core.
As an alternative I planned to use the setProfileImages / getProfileImages. Currently I created some sort of name + mail hashing for the load / show in the contacts screen (needed to fit everything into the signal image loading chain), but using that "loose relation" also for contacts I have a chat with makes not that much sense in my opinion. The name can change and if we have the chance to create a reliable relation we should take it.
I would suggest one of the following solutions:
Direct relation
Address book relation
I would vote for the Address book relation solution.
i would not like to have os-specific urls in the deltachat-core address book. this may cause problems eg. on porting address books between different systems, but also an import on the same one may result in a bad state.
As an alternative I planned to use the setProfileImages() / getProfileImages()
this won't work as deltachat-core will only allow to setup the contact image from SELF user. the contact images of other users are set by themselves - or they stay empty, and in this case android could fallback to the contact image from the address book - which allows to set contact images for other users.
however, i do not think that an additional index/ID is required for loading contact images from the address book; the email address is already unique. in the old telegram ui i did this as follows:
ContentResolver contentResolver = context.getContentResolver();
Uri uri = Uri.withAppendedPath(ContactsContract.CommonDataKinds.Email.CONTENT_LOOKUP_URI, Uri.encode(email))
Cursor pCur = contentResolver.query(uri, s_projectionAvatars, null, null, null);
if (pCur != null && pCur.getCount() > 0) {
while (pCur.moveToNext()) {
int contact_id = pCur.getInt(0);
int photo_id = pCur.getInt(1);
String addr = pCur.getString(2);
if (addr.equalsIgnoreCase(email) && contact_id > 0 && photo_id > 0) {
Bitmap tempBitmap2 = loadContactPhoto(s_cr, contact_id, photo_id);
// usw.
break;
}
}
}
pCur.close();
loading is done on a working thread and images loaded one time are cached in memory with the email-address as the hash.
the cache was clered every time the app goes to background - to save memory and to follow updates (for the later other solutions may be more elegant, however, in the typical cases, this is fine).
tor me, this was always fast enough and i also did not get complaints :)
the whole code is at https://github.com/deltachat/deltachat-android/blob/master/MessengerProj/src/main/java/com/b44t/messenger/ContactsController.java#L191
i would not like to have os-specific urls in the deltachat-core address book. this may cause problems eg. on porting address books between different systems, but also an import on the same one may result in a bad state.
Makes totally sense, I'm to "one client centric" sometimes...
I already looked into the old Telegram implementation and used an adjusted one for the loading of the images in the contact list. That was my point regarding "loose relation" as sometimes multiple persons share an email address (yep happens sometimes), so it's not really that unique (but combining that with the name and creating a hash, what I also did helps here).
The saving in memory shouldn't be needed for Signal as the Glide image library already caches images.
So I would just use the contact list loading logic also for chats now. This solution is similar to the one the old UI used and no additional core changes are required.
Sorry for the back and forth.
sorry for not being more clearer from the beginning on.
@r10s should work now as intended, also fixed a small problem with writing group avatar images. Also optimized the performance when loading system contact images in the "create new chat" view.
@Boehrsi great, as a first glance this looks very good to me :)