03-18-2018, 09:41 AM
My plan is to provide a new option in the settings to "switch library", and this will be a list of databases the user has set up. On Android, I can support having those databases be in any folder the application has access to. For simplicity's sake, if "Expose Database" is disabled, I will only ask the user for a name for each library and each database file will be stored in the same directory in the internal application data directory. If expose database is enabled, then I'll let the user select the location for each database file, but I'll default to the storage location. Switching the active library will just update a preference file which the application will read at startup to figure out which database file to load. If you do something like perform a library backup, it will only back up the currently selected database. In fact, every action in the application will only act upon the currently active database. This will keep the feature and complexity from getting out of hand and it won't require huge design changes. Have multiple open databases at once is something I have no desire to support.
On Windows 10, I have to keep every database file in the application data directory next to mobilesheets.db - there is no flexibility in this as the SQLite library fails if the database files are not in that folder. So the user will be able to create multiple libraries and name them, but they will not have control over where the database files are stored.
I'll be curious if this approach will satisfy the needs of those who have requested this type of feature in the past. I'm open to feedback of course, but the one thing that I won't even try to support is using multiple database files at once.
Mike
On Windows 10, I have to keep every database file in the application data directory next to mobilesheets.db - there is no flexibility in this as the SQLite library fails if the database files are not in that folder. So the user will be able to create multiple libraries and name them, but they will not have control over where the database files are stored.
I'll be curious if this approach will satisfy the needs of those who have requested this type of feature in the past. I'm open to feedback of course, but the one thing that I won't even try to support is using multiple database files at once.
Mike