Looking into this feature right now. I was wondering what the use case is for this? For instance, do you just want to be able to reply to a comment with a different account? Or are you trying to see comments that might be blocked by your current instance?
Got it. I think the solution I’m going to implement is a temporary account switcher within a post. That way you can switch accounts for a single post without switching accounts entirely so you can perform some actions. Then as soon as you close the post, you are back to your original account.
That would be awesome! You’re doing a good job. This app is certainly the best. It’s very smooth and highly efficient. There is pretty much every feature I’ve wanted. Especially the multis. That’s all I really missed from Reddit.
Hmm after looking into it more unfortunately it seems that it would be too time consuming and it may even be impractical to switch accounts for a single screen at least without huge constraints.
Instead I will just add a way to switch accounts while you are viewing a post. Unfortunately, this will reset your scroll position in the community when you navigate back.
The app currently only maintains a cache for one user at a time. The issue with accounts that are tied to a single screen is that the cache is no longer trustworthy.
As an example, let’s say you have two accounts “a” and “b”. If you go from screen (1) as user “a” to screen (2) as user “b”, neither screen (1) nor screen (2) can trust the cache. The cache can contain some user “a” stuff and some user “b” stuff but there is no guarantees what is what so all API calls must be made fresh by screen (1) and screen (2). Screen (1) also can’t assume that the cache will always only contain user “a” stuff either because the user could have switched to user “b” at any point in their navigation.
Then you have fun edge cases where you can navigate to some post, change to user “b”, then open another post and change to user “c”. Now you are essentially 3 different users at the same time, just on different screens.
There are some solutions to this. The most obvious one is to create a completely different set of objects per user. Eg. user “a” will have it’s own cache, resources etc. But this gets complicated really quickly and also it may cause performance issues because it can multiply the number of user related objects in memory by the number of accounts you have.
Maybe in the far future if I’m bored enough I can look into this style of account management but for the time being it’s just really difficult to “containerize” each account like this.
That makes sense.
Looking into this feature right now. I was wondering what the use case is for this? For instance, do you just want to be able to reply to a comment with a different account? Or are you trying to see comments that might be blocked by your current instance?
Thanks for responding! I have a few different accounts, they mod different communities. That’s pretty much it. So yeah, comments, and mod actions.
Got it. I think the solution I’m going to implement is a temporary account switcher within a post. That way you can switch accounts for a single post without switching accounts entirely so you can perform some actions. Then as soon as you close the post, you are back to your original account.
That would be awesome! You’re doing a good job. This app is certainly the best. It’s very smooth and highly efficient. There is pretty much every feature I’ve wanted. Especially the multis. That’s all I really missed from Reddit.
Hmm after looking into it more unfortunately it seems that it would be too time consuming and it may even be impractical to switch accounts for a single screen at least without huge constraints.
Instead I will just add a way to switch accounts while you are viewing a post. Unfortunately, this will reset your scroll position in the community when you navigate back.
The app currently only maintains a cache for one user at a time. The issue with accounts that are tied to a single screen is that the cache is no longer trustworthy.
As an example, let’s say you have two accounts “a” and “b”. If you go from screen (1) as user “a” to screen (2) as user “b”, neither screen (1) nor screen (2) can trust the cache. The cache can contain some user “a” stuff and some user “b” stuff but there is no guarantees what is what so all API calls must be made fresh by screen (1) and screen (2). Screen (1) also can’t assume that the cache will always only contain user “a” stuff either because the user could have switched to user “b” at any point in their navigation.
Then you have fun edge cases where you can navigate to some post, change to user “b”, then open another post and change to user “c”. Now you are essentially 3 different users at the same time, just on different screens.
There are some solutions to this. The most obvious one is to create a completely different set of objects per user. Eg. user “a” will have it’s own cache, resources etc. But this gets complicated really quickly and also it may cause performance issues because it can multiply the number of user related objects in memory by the number of accounts you have.
Maybe in the far future if I’m bored enough I can look into this style of account management but for the time being it’s just really difficult to “containerize” each account like this.
That makes sense. Thanks for looking into it anyway.