Ability to re-order accounts

[micahmo]

Pull Request Description

The PR allows accounts and anonymous instances to be manually re-sorted in the account switcher modal. To accomplish this, a new index column has been added to the database table (where the initial value is based on the ID, so the initial order should be the same after upgrading). The account entries have been made sortable using SliverReorderableList. When the order is manually changed, all IDs are re-calculated, so there are no gaps. When a new account/instance is added, its index is the highest current index + 1.

Notes:

• Accounts are not sortable in the temporary account modal.
• Since accounts and anonymous instances are technically different lists under the hood, I have many the delineation more clear in the modal by adding separate headings. (This also addresses my concern where the meaning of the two "add" icons weren't clear before.) The sorting will apply separately to each list.
• I migrated anonymous instances to the database as part of these changes.

P.S. I haven't looked yet, but I'm assuming there will be some database conflicts with #1492. Not sure who should go first. :)

Review without whitespace.

Issue Being Fixed

Issue Number: #1488

Screenshots / Recordings

qemu-system-x86_64_XoWdVEcvKN.mp4

Checklist

• If a new package was added, did you ensure it uses an appropriate license and is actively maintained?
• Did you use localized strings (and added appropriate descriptions) where applicable?
• Did you add semanticLabels where applicable for accessibility?

[hjiangsu]

Thanks for doing this, and all the work with regards to database migrations for anonymous accounts! I just did a very quick code review of the changes, and I do want to bring up some potential changes regarding the architecture (if you agree with it of course!)

Do you have any thoughts on perhaps merging Accounts and Anonymous Instances together? For example, we could add a new column (isGuest) to the Accounts table to indicate that a given account is a "guest"/"anonymous" account rather than storing it as a separate table

My main thought surrounding this is that:

• From what I can see, Anonymous Instances and Accounts share the same columns (instance and index)
• Having a single table makes managing general "account" related information much easier (regardless of whether or not the account is authenticated or not) - this includes simplifying logic of switching between accounts amongst other things
• If we merge the Account and Anonymous Instance accounts together, we could extend the functionality of Favourites to guest accounts (and we can remove LocalSubscriptions since they would essentially work the same way)
• Depending on how we decide the behaviour of Add custom sorting per community/feed #1492, we could extend custom community/feed sort types to anonymous accounts as well (if we decide to go with separate sort types per account)
• This also opens up new features such as separate app settings per account (e.g., each account could have their own app settings, rather than just one global setting as we have now)

I do understand that this would require a lot of changes to the current PR, which is why I wanted to bring it up for discussion! I'm also bringing this up here because I think it'll be easier to change it now rather than later down the road if we do decide otherwise (since we'll have to deal with more complicated database migrations)

[hjiangsu]

Pinging @micahmo in case you didn't see my previous comment!

[micahmo]

Hey, sorry, I thought I already responded to this thread!

I totally agree that anonymous instances could be in the same table as accounts. We could even use the JWT being null as an indicator that it's anonymous (if we didn't want to add another column). But either way, as you said, this should open up a lot more possibilities. (Although, personally, I do like distinguishing the types of accounts in the profile switcher, even if they're stored the same way under the hood.)

What I was going to suggest was doing the database migration in a separate PR, and then once everything's in the same table, we can add the UI for re-ordering.

[hjiangsu]

Thanks for the response!

Although, personally, I do like distinguishing the types of accounts in the profile switcher, even if they're stored the same way under the hood

I agree with you here - I think separating them on the profile switcher makes things cleaner and more organized

What I was going to suggest was doing the database migration in a separate PR, and then once everything's in the same table, we can add the UI for re-ordering.

Sounds good!

[micahmo]

Would you be ok with reviewing and merging #1495 before I do any more database changes (as you have time, of course). The reason I ask is because, not only did I add another migration there, which would conflict here, but I also reversed the order of the downgrades. They should have been in descending version order all along, but it was just an oversight on my part. I only realized it when I tried to delete a column after the table had been dropped 😆 Anyway, having that one merged would create a good clean slate for the next round of changes.

[hjiangsu]

Done!

[micahmo]

Alright @hjiangsu this should be updated with the latest changes from #1500. It's pretty much just the UI changes now and a couple small db things I missed before. Should be ready any time! The behavior is exactly the same as the original demo.

[hjiangsu]

Just did a quick glance at it, but it looks good!