Support for email addresses #1656

ChrisMrX · 2021-01-27T14:41:56Z

Is your feature request related to a problem? Please describe.
To follow this request: Also show contacts without phone number #1570

Describe the solution you'd like
Currently, KISS only provides tooling for phone and messages.
KISS's support for email addresses would be great.

Describe alternatives you've considered, or that are already available within KISS
A time saver that allows you to open email app without going through contacts app.

Additional context
We can imagine the support of contacts with an email address like this:

Click on the icon to launch the email app.

But if contacts have multiple phone numbers and multiple emails displaying them separately takes up a lot of space.
I would prefer this (pop-up bubble):

Click on the icon to choose the phone number...

... or email address to use.

Would you be able to contribute code?
No, i don't have the skill

@Neamar

Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-authored-by: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-authored-by: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-authored-by: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-authored-by: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-authored-by: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-authored-by: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-authored-by: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-authored-by: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

@Neamar

This is a draft to enable multi im support Neamar#1660 and mail support Neamar#1656 and should be extended in future to allow replacing of default messaging of phone contacts as @Neamar thought of. This adds some basic functionality so any contact details can be shown as result in KISS. Regardless of whether that is from any messaging app, mail, phone or anywhere else. As default only phone contacts are show, so nothing will change in first place. Also it was a little bit trickier than expected because messaging apps use their own mime types and not the provided ones. So for custom mimetypes this is working pretty well, other ones (CommonDataKinds.SipAddress, CommonDataKinds.Im, CommonDataKinds.Website, ...) may be handled separated if requested. Following changes are done: - existing mime types are loaded from contacts (IM, Mail, Phone, ...) - extended **ContactPojo** to hold additional data by mime type - as this may lead to **ContactPojo** that has no phone but mime type only there were additional null checks added - added basic settings to select any mime type that should be shown as separated contact (phone only is default) - **ContactsProvider** was extended so result also considers mimetype - **LoadContactsPojos** was refactored, so basic data is fetched only once and then all **ContactsPojo** are created dependent on selected mime types (phone contacts are handled separately) - **ContactsResult** was changed, it now has the ability to show following contacts: -- contacts with phone only -> phone button + message button -- contacts with mime type data only -> message button only that calls mime type intent -- contacts with phone and mime type data -> phone button + mime type intent that calls mime type intent -- instead of phone number the detail text of contact is show (set by messaging apps) - added **MimeTypeUtils**, for basic handling of mime type related data -- methods for handling mime types -- methods for intent handling -- methods for fetching mime type related data from sync adapters, messaging apps, ... There's also lots of work left: - general code review needs to be done - especially for some classes that needs to be renamed/relocated - performance needs to be checked - maybe calculation of result needs to be changed - contacts should have separate messaging icons so it's clear which app will be called, maybe we use app icon or add badge similar to shortcuts. Maybe @TBog can help here, as i'm not sure how this can be handled. - settings should be refined - layout needs to be checked, some mail addresses and some telegram infos are a little too long on my screen. Bur for first version it's working pretty well, i already enabled telegram messages and mail on my daily driver and i have to say: I love it 😄 * remove common prefix from unique mime type labels Co-Authored-By: TBog <thetbog@gmail.com>

ChrisMrX added the enhancement New feature label Jan 27, 2021

marunjar mentioned this issue Feb 27, 2021

[RFC] Multi-IM support #1660

Open

5 tasks

marunjar mentioned this issue Mar 10, 2021

Multi-IM support, email support #1714

Draft

marunjar mentioned this issue Dec 8, 2022

Im draft marunjar/KISS#2

Merged

github-actions bot added the inactive This issue hasn't seen any activity recently. label Apr 13, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for email addresses #1656

Support for email addresses #1656

ChrisMrX commented Jan 27, 2021

Support for email addresses #1656

Support for email addresses #1656

Comments

ChrisMrX commented Jan 27, 2021