Currently export works. I've tried exporting a backup file, and taking a look at it using DB Browser for SQLite and it does show the data correctly. However, exporting has some implications:

1. Before exporting we must wait for any transaction ongoing to finish. This is done in AppDatabase.readAllData like this:

   if (instance != null) while (instance?.inTransaction() == true) { delay(1) }

2. Database must be closed before reading. In AppDatabase.readAllData this is called:

   instance?.close()

3. Since the database has been closed, no operations can be performed, so the easiest and safest approach is to restart the application. This is done with:

   val intent = Intent(this, CalendarListActivity::class.java).apply {
       addFlags(FLAG_ACTIVITY_NEW_TASK)
       putExtra(EXTRA_SHOW_EXPORT_SNACK, true)
       data = uri
   }
   startActivity(intent)
   finish()
   Runtime.getRuntime().exit(0)

   I've also added EXTRA_SHOW_EXPORT_SNACK which shows an Snackbar when the application is restarted telling the user that the backup has been completed, and also offering to share the file. The uri to share is obtained from Intent.getData.
   Setting AppDatabase.instance to null, is not enough, since all the observers have been disposed. A full reload is required.

Import is currently not working.

Edit: now import is working. The database file must be removed, otherwise RoomDatabase.createFromInputStream doesn't have any effects.

TODO:

• Test export functionality
• Test import functionality

@sunkup what do you think? Should we add the possibility of backups? Maybe only enabling the automatic ones? Otherwise this PR would be good, it's just a matter of updating the UI to Compose.

@sunkup what do you think? Should we add the possibility of backups? Maybe only enabling the automatic ones? Otherwise this PR would be good, it's just a matter of updating the UI to Compose.

Really nice feature to look at. Personally I don't have that many calendars - but I guess it might prove useful for a handful of people.

Does the code handle migrations already?

How do you think this would integrate once ICSx5 becomes part of DAVx5 ? Could that become an issue? Since DAVx5 will have complete app backups, would that not make this feature obsolete?

I think we should just take the automatic backup part, and get rid of manual backups as of right now. Simply store the subscriptions made so that if the device is formatted all of them can be added back again.

Maybe once we add backups to DAVx5, we can consider them here as well, or directly inside of DAVx5. It will be for sure a big task, and we don't want to have two different kinds of backups, so it's better to wait until we design a format for DAVx5, and then either implement that one here as well, or simply everything into DAVx5.

I think we should just take the automatic backup part, and get rid of manual backups as of right now. Simply store the subscriptions made so that if the device is formatted all of them can be added back again.

Sorry, I don't understand this.

In my head:

• "manual backups" = "Simply store the subscriptions made so that if the device is formatted all of them can be added back again." = this PR
• "automatic backups" = complete app backups like it's planned for DAVx5

Which automatic backup part do you want to get rid of? Do you want to merge this feature or not? 😅

What I mean by automatic backups are the ones made automatically by Android: https://developer.android.com/guide/topics/data/autobackup

Manual backups would be the user saying: okay, I want to create a backup of the database which I can then import manually.

I've been thinking about this for a while. Right now automatic backups are enabled, I thought they weren't. The database name is configured here:

and then the extraction rules are specified here:

and here

After much consideration, since the database of ICSx5 is quite simple, we can pretty much consider a backup creating a SQL file of the database, which uses SQLite. By how Room is designed, we can import this file later on. This is what I did originally in this PR, but a lot has to be modified in order to work with the new UI.

I believe the best approach would be to create a new PR copying and pasting most of what's here

Ah ok. How are migrations handled for automatic backups then?

And how do you think this would integrate once ICSx5 becomes part of DAVx5 ? Could that become an issue? Since DAVx5 will have complete app backups, would that not make this feature obsolete / hard to integrate with DAVx5?

Sorry for being so hesitant with this, but I'd like to avoid unnecessary work. :)

@devvv4ever Said they want to merge ICSx5 into DAVx5 this year already

I'll close this. We will implement it in DAVx5 at some point in the future.