This was/is a great tutorial. Will you be finishing the app? I would like to learn how to deal with adding items and does this take another table to get this done?
There is a follow-on article that adds items. The articles uses another table to demonstrate how to use relationships and along the way talks about migrations etc. when adding items. Now if you really wanted to get creative you could try to do that with a type field in the table and querying on things based on the type. IE: a category type for the categories and an item type for the items.
@Igleason. Thanks for such a nice tutorial. Wanted to confirm, like SqlCipher, how Room Persistence is encrypt/decrypt our records, or are they un-encrypted. Would you please share some article on storing SealedObjects in Room Persistence.
Roomdb by default is not doing anything to encrypt your data since it is using the default built in SQLLite data store. This means that anyone with device root access can access it. It looks like the SqlCipher team is working on some changes that might be able to support this in conjunction with a package called saferoom, but I havenโt personally looked at this so it may or may not be something that will help for your use case at this point.
I personally have not had a need in my own projects to use sealed object, but from looking at them it looks like it is encrypting the entire object. If your keys that you search on do not need to be encrypted and you just have select objects of data that need to be encrypted one idea might be to put the data that you want to encrypt in a sealed object, serialize it and then store it as a string or blob. With all of that being said depending on the use case you may find yourself fighting the tools to do this instead of using something that is designed for this.
If the saferoom package or something like that evolves that could change. If I was currently looking at doing a encrypted datastore and needed to have everything encrypted I would probably be evaluating other options as well such as Realmdb.
@Igleason, thanks for your response and analysis of SealedObject. I am already using non-SqlCipher DB to overcome security. I am taking into consideration this thing, because if someone stole any android mobile, and install something similar to jvisualvm (try on emulator) and stole the credentials of the user then it would be hell for that user. I am having 10 yrs experience in iOS apps, and as per my experience sql_prepare_stmt of sqlcipher takes 700 ms more time than non-sqlcipher statements. And if we are doing lot of background process, where each thread needs to open-close db connections on sqlcipher based DB, then performance of the application hits worst. Trying to find out best solution for mobile platform for DB Transaction or DB individual operation for both iOS and Android. Till now, only found SealedObject relevant for android with non-sqlcipher db and then will create custom iOS SealedNSObject class which will work similar to it with overwriting transformation from SealedObject to Serialized byte array.
Just wanted to know, if there is already any expertise solution available on it.
Thanks in advance.
If your doing a lot of those 700ms operations you might want to have a look at Realmdb to see if that gives you any performance gains, though it may be the encryption that is causing the performance hit. If you are doing a lot of opening and closing of the database connections you will probably be better off doing things in a service instead of opening and closing connections a lot, which is the same pattern that many end up with in IOS as well.
Iโd say do some coding spikes to see what works best for your project. When you find the best solution for you it would make a great blog post that Iโd love to read and share with others :]!
RoomDatabase is using context to initiliaze the db, but unfortunately it is crashing with background service (intent service/job service) based contexts. As when app is not in session (neither used for 5-10 mins, also removed from multi-task) then RoomDatabase is crashing.