0

I think the question itself is actually a fairly sensitive topic. I'll explain why I'm asking this question, assuming all the circumstances I'm going to tell you.

[fictional story]

I built a Notepad app using an internal database (SQLiteDatabase or Room) and deployed it to the Google Play Store. A lot of users are getting downloads, but there is a problem. We realized that an error occurred during the feedback we received from users, and this was an error we could not find during the development process. I've been getting these error reports from a lot of users, and I've been trying to solve the problem with Notepad version 2. However, version 2 did not solve the error for users whose data was already stored in the internal database in the wrong format. So I try to access their data by only accessing the internal database of my app of users. And we try to modify the data so that there are no errors and store it inside each user's phone.

This is the story of the hypothetical situation that I assumed so far. Let me ask you a question.

  1. Can I access and modify the internal database of my app?
  2. If it is an action that should not be done, the reason is too natural and you do not need to explain it. So, how do apps with these problems solve them? If you simply delete the app and then install it again, users will not like it because the existing information will be lost.
  3. However, if you can access the internal database, how do you access it?

If the answer in question 1 is no, you do not need to answer in question 3. Since it is a question that involves the user's personal information, I ask this question before the initial development of the app.

H.JiMan
  • 269
  • 1
  • 2
  • 10

2 Answers2

1

Some answers.

Question 1 - your App can access the internal database and can modify it.

Question 2 - A lot can be done with a crash analysing tools like Android crashlytics but if it is a pure data corruption bug that does not cause a crash, then there is also the possibility to add the functionality to your App to export the sqlite DB file to a public location on the phone and then get the user to send it to you via email. You should put various prominent warnings that by sending you the DB file via email that they might be sending you sensitive and or personal data (otherwise you might not be able to publish the new version on the App Store)

Question 3 - See answer 2 and 1, add functionality to your App to export the data file to a public location on the phone and get the user to email it to you.

Andrew
  • 8,198
  • 2
  • 15
  • 35
0

1 and 2 Yes that's what Migrations are designed for.

3 A Migration is called when an increased version number is detected. That is the version number coded in the App is greater then the version number stored in the database header.

The Migration is passed the database as a SupportSQLiteDatabase which allows changes to be made (with some restrictions). This could be updating the actual data and or changing the schema to match the schema expected by Room which equates to match any changes to the Entities.

Earlier today an answer was given for a situation where the database was previously using SQLite and wanted it converted to room. However the schema had to be amended to suit room which is quite specific about column types. As data existed the database needed to be altered whilst preserving the data (the change was a change to the schema rather than the actual data, but otherwise it is an example that demonstrates the principle/procedure) so you may find the following of use :-

MikeT
  • 51,415
  • 16
  • 49
  • 68