Remove .jar files inherited from AndroidVNC: contentXML database ex/import

[bk138]

... and replace with contemporary functionality.

• [ ] com.antlersoft.android.contentxml.jar
• [x] com.antlersoft.android.db.jar

[bk138]

https://f-droid.org/forums/topic/limbo-android-qemu/ has info on contentxml.jar

[bk138]

As #117 will switch to Room, let's discuss here whether binary ex/import is a good idea or not @gujjwal00

[bk138]

I found https://github.com/android/architecture-components-samples/issues/340 that links to an answer from upstream which indicates binary export is possible, but it still seems it's not an expected use case.

[gujjwal00]

IMO, there are two things we need to consider:

1. Database versions(i.e. migrations): What if user imports older/newer dump then the version in app.

   • Not an issue until we change database version/schema
   • We can check the version before importing and then
     • Disallow old/new dump OR
     • Modify before import OR
     • Let our default migration code handle it.

2. Logging (Journal/WAL)

   • Need to decide between journal/wal
   • We could pack the log file with database in a zip file and export that.
   • We could truncate the log file:
     • -journal: There seems to be a truncate mode but I have not fully tested it.
     • -wal: There is a pragma to truncate the file but older devices(tested with API 21) ship with old SQLite library which does not support it.

As for whether it is a good idea, I would favor it beacause we we don't have source code for contentXML and no way to modify its behavior.

[bk138]

IMO, there are two things we need to consider:

1. Database versions(i.e. migrations): What if user imports older/newer dump then the version in app.
   
   * Not an issue until we change database version/schema
   * We can check the version before importing and then
     
     * Disallow old/new dump OR
     * Modify before import OR
     * Let our default migration code handle it.

These constraints more or less also apply when ex/importing XML as you pointed out in #117, right?

2. Logging (Journal/WAL)
   
   * Need to decide between `journal`/`wal`
   * We could pack the log file with database in a zip file and export that.
   * We could truncate the log file:
     
     * `-journal`: There seems to be a truncate mode but I have not fully tested it.
     * `-wal`: There is a  [pragma](https://www.sqlite.org/pragma.html#pragma_wal_checkpoint) to truncate the file but older devices(tested with API 21) ship with
       old SQLite library which does not support it.

That all seems pretty clunky TBH. I googled around a bit and people seem to play around with JournalMode.TRUNCATE and/or closing the DB. Strange there is no Right Way as it's a not soo uncommon thing to do IMO.

As for whether it is a good idea, I would favor it beacause we we don't have source code for contentXML and no way to modify its behavior.

Or look around for some alternative XML implementation. I'll have a look...

[gujjwal00]

Now that Kotlin support is added, we can use JSON Serialization .

[bk138]

Now that Kotlin support is added, we can use JSON Serialization .

That looks interesting indeed. We should keep the XML import for at least one minor version and can then remove this as well.

[gujjwal00]

Do you also want to switch to Parcelize? It will allow us to remove serialization code in ConnectionBean: https://github.com/bk138/multivnc/blob/a6327dd196e41c7c3aebfe144830642ae87397c5/android/app/src/main/java/com/coboltforge/dontmind/multivnc/ConnectionBean.java#L143-L221

[bk138]

Do you also want to switch to Parcelize? It will allow us to remove serialization code in ConnectionBean:

https://github.com/bk138/multivnc/blob/a6327dd196e41c7c3aebfe144830642ae87397c5/android/app/src/main/java/com/coboltforge/dontmind/multivnc/ConnectionBean.java#L143-L221

Yes, sounds like a good opportunity to remove boiler plate.

[gujjwal00]

Can we drop XML support now?

[bk138]

Can we drop XML support now?

Generally yes. But not exactly now. I'd like to give users a grace period of say 3 months.