It’s worth noting that this solution will not work well for changing of table names. It is also the solution that the Android Developer Documentation states. When the user upgraded, the “cache” would disappear and they would have to download all the data again. We weren’t storing user data our database was just a cache of things from the network. Sure, when we started development this was obviously the easiest approach. These are the solutions that we went through: Solution 1: Delete the tables that have changed and recreate them I’ve been there and battled the fires in production. Upgrading databases in Android is difficult. When using your own SQLite database in Android, most people take for granted future releases of the application they are working on. Looking at the Android Developer documentation can also lead you down a rickety path. The post explains quite well the drawbacks of some of the solutions that I also went through, but their final solution can also leave you in trouble. After reading this blog post (and a few others) on how to use the onUpgrade() method for your Android SQLite Database, I thought I should share my experience about how to correctly upgrade your database. It will also be beneficial to highlight why the final solution listed in that blog post would also fail at some point for some scenarios.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |