Use case:
Users often have more than one email account: from work, for personal use, etc. They need to be able to setup two or more account/profiles in their Delta Chat app.
Expected behavior
Two or more email accounts can be used simultaneusly with Delta Chat so users can chat with different accounts at the same time.
Actual behavior
Users are unable to use more than one email account in they Delta Chat app, so they are unhappy and need to use another MUA to check in an uncomfortable way they messages.
testbird: thanks, that is just what I am talking about. But it is a closed issue, to me this is a really useful feature, and several friends with I have shared the app, are complaining about they need this feature.
The issue is closed so discussion can go on here. Three of the more interesting comments which should maybe be discussed here are:
IMO the main issue about multi-account is the UI design and implementation of it. If someone can provide UI mocks on how it should work (setup, account selection etc.) please post .
What are the alternative modes that people do have in mind, in which new accounts may be used? (an account preference)
separated account?
* tabs to switch chat lists and used account
alias inclusion account?
* all chats included in the default chat list (āunified/shared inbox?ā)
* when creating a new chat the (default) account is preselected in the list of accounts to choose
Same, tabbed or not, for āunnapproved emailsā (contact request)?
Iāll provide my personal ideas based on my needs, maybe that can provide some orientation. In general, the XMPP client Conversations is a good example of a multi-account UI.
I imagine the account management view as in Conversations: You can add accounts to the list and activate or deactivate them separately via switch on each entry.
The chat list would then display the chats for the selected accounts in a single list because for receiving I donāt care much about to which account a message has been sent. So the same goes for contact requests.
For replies, the proper account would be automatically selected and for new chats I would select it myself.
Contacts would be independent of the account, I could always see all of them.
It s possible to build dc with different application ids or suffixes (see build.gradle).
With this approach its possible to install more than one instance of dc simultanously.
For example just now you can install f-droid version and github version in parallel with different accounts.
If we would provide in general a special build version for 2nd account usage (with different app icon to distinguish versions) then we would have a quick solution until a real solution will come.
Iām using this approach for testing at one phone
After using the multi-account feature in the Desktop Client for a while now, I have some suggestions on how to handle this UX-wise.
A problem for me is that I have to switch accounts frequently, because the other accounts are not crawling for messages in the background. The effect is that I rarely switch accounts at all. If there was a sidebar showing a logo per account with a small notification number or so how many messages there are, that would help a lot already.
To save energy & network usage on Android, this could be combined with this feature proposal where someone proposed a disable button for accounts.
Wire does it quite well, they could be an inspiration here.
@adbenitez@ana Iād say the Solution flag is not yet appropriate because the PR (nor any other) doesnāt implement concurrent/parallel use of multiple accounts (i.e. one can be logged only to one account at a time).
Thus you wonāt get notifications from other than the currently selected account which kind of defeats the purpose of real-time chat.
Hi, @dumblob, welcome to the forum!!
actually this is just what I was expecting for now, sure, having a way to manages account like in Conversations, where you can enable/disable several accounts at the same time would be great, but my initial request was just to use several account with one DC apk just like DC Desktop does, not to use them concurrently, hence I marked the feature proposal as solved.
Best regards,
adb