dansup
Account switching is a tricky feature to implement properly because it involves a carefully orchestrated procedure that involves rotating cached auth data, invalidating the api query cache and then storing new auth data and applying the per-account settings.
There are a ton of things to watch out for, like expired auth tokens, and the refresh logic, deleted accounts, and 2FA.
Not to mention Push Notifications, its possible you'll get notifications from other accounts and we have to handle that
dansup
@joelving No worries, I appreciate the advice and I'm almost finished this feature!
We're using MMKV in our app for a cache, so for this, I'm adding a new accounts item that will contain each accounts relevant data (token, instance, etc) and will preserve that across logouts so users can select an account to log back in in that state
Peter Toft Jølving
@dansup aaaand, now I see that you've already built it. Sorry!
Peter Toft Jølving
@dansup that would also let you keep the stores hydrated for those users that aren't currently active.
And again, I may well be mansplaining like crazy here, and you probably know all this by heart. In that case, sorry!
Peter Toft Jølving
@dansup yeah, multi-tenancy can be a pain to retrofit. If you know ahead of time, that you want it, you can scope the data stores to individual users.
One way to deal with it (if you want suggestions, otherwise sorry!) is to use a global singleton for storing active user ID and a factory that returns indivual data stores for each user ID and use that when injecting the data stores and changing the active account. Would that be feasible in your situation?
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.