On launch go to last account used, not just first in list

[gnprice]

In my initial implementation of #516, when you launch the app, we'll navigate to the inbox for the first account in your list of accounts. For most users, this will be their only account.

But for those of us who do have more than one account we're logged in as, the first one in the list might not be the one we most often want to use; it's just the first one the user logged in as after installing the app. So it'd be more convenient to instead go to the account most recently used, which is much more likely to be the one the user is interested in seeing now.

Doing this probably means adding a bit more data to our local database: probably a small new table, named perhaps like "navigation", always with just one row, and perhaps at first just one column which is an account ID. Then GlobalStore will have a corresponding field, and LiveGlobalStore.load will read the table at startup, just like the accounts table.

To update the data… perhaps supply a NavigatorObserver that looks for newly-pushed routes that are instances of AccountPageRouteMixin, so therefore carry an account ID, and when the NavigatorObserver sees such a route, the observer causes that account ID value to get written if it's different from the existing value.

We don't have a lot of examples yet of using the database, so this is an issue that will call for some experimenting with the API and finding the style we want to use. It's therefore not a suitable issue for a new contributor.

[Detective-Khalifah]

To update the data… perhaps supply a NavigatorObserver that looks for newly-pushed routes that are instances of AccountPageRouteMixin, so therefore carry an account ID, and when it sees one it causes the value to get written if it's new.

We don't have a lot of examples yet of using the database, so this is an issue that will call for some experimenting with the API and finding the style we want to use. It's therefore not a suitable issue for a new contributor.

This issue is definitely not suitable for a new contributor. I got lost at the different instances of it.
Would SharedPreference be a better option compared to (local) database operation in this case?

[gnprice]

I got lost at the different instances of it.

Good feedback, thanks. I just edited that paragraph to expand most of the "it"s into more explicit references.

But yeah, as I said above, there are other reasons this isn't a suitable issue for a new contributor.

[gnprice]

Would SharedPreference be a better option compared to (local) database operation in this case?

SharedPreferences is a traditional option in Android apps, because it's been in the Android SDK since the very beginning and so there's a very low barrier for an Android app to start using it. But it's no longer recommended even in the upstream Android docs — at https://developer.android.com/training/data-storage/shared-preferences there's a red warning box reading:

Caution: DataStore is a modern data storage solution that you should use instead of SharedPreferences. It builds on Kotlin coroutines and Flow, and overcomes many of the drawbacks of SharedPreferences.
Read the DataStore guide for more information.

And in any case it's an Android-specific platform feature, so it's not suitable for a cross-platform Flutter app. We already do have a SQLite database, so it won't be hard to use that; it's just that we'll have to pick what style we want to use to organize the internal API of how our application code talks to our storage layer in model/database.dart.