0

I am new into Android development and I am making a Flash Card like application.

I am writing the Card object into a file using ObjectOutputStream and reading it using ObjectInputStream.

I was thinking what will happen when the application is trying to write a Card into a file by updating it in the temporary physical memory and the user closes the application when the writing process is taking place.

The file will be in an inconsistent state and will lead to unexpected logical errors in the application.

ObjectInputStream ois = new ObjectInputStream(openFileInput(FILE_NAME));
Card c = (Card) ois.readObject();
c.foo = foo + 1;
ois.close();

ObjectOutputStream oos = new ObjectOutputStream(openFileOutput(FILE_NAME, MODE_PRIVATE));
// At this point the file will be truncated as the file is opened in write mode
// User closes the application here at this point
// Card has been updated but not stored into the file
oos.writeObject(c);
oos.close();

Can we make this group of code atomic so that even if the user closes the application in between, all the changes will be roll backed?

Or can we disallow the user to stop the application at this point?

By closing the application, I mean killing the app but I would like to know what happens in other cases too like pressing the back button, pressing the home button, etc.

Aditya
  • 315
  • 1
  • 9
  • What do you mean by closing, is it exiting by back button or pausing with home button press or killing the app through task manager ? – Sudarshan Vidhate Oct 14 '19 at 17:06
  • I meant killing the app, but I woule like to know about other scenarios too. I have edited my question accordingly. – Aditya Oct 15 '19 at 04:08

1 Answers1

0

Disk I/O is done on a background thread so as not to freeze UI. Now there are 3 scenarios :

  1. App goes to background(user press home button), your background thread (BT) will keep running.
  2. App is recreated(user rotates device), here also your background thread will keep running. But because your activity instance that spawned BT is no longer alive, so you cannot update any view state.
  3. App is killed, in this case your background thread will also be killed, so yes your file will be in an inconsistent state. What you can do to counter this is use Service (if your I/O is really long). You can read more about this here. Use Service for background task.

However if your task is not long(takes only 1-2 seconds), then you will be fine with BT.

These are your options to keep task ongoing if your app is pushed to background or killed.

But you can also structure your data to cover such unwanted scenarios.

For eg you can return a boolean after writing your card to file and save that boolean to shared preferences.

If you have multiple cards to write to a single file, then while opening the file use Mode Append, and assign a unique key to your cards and can save successfully written card key's to shared preferences. So by reading key's from shared preferences you can get to know which cards have been written successfully.

Rishabh Dhawan
  • 519
  • 1
  • 3
  • 11
  • Thanks for your answer. Currently the content to be written is small but after long usage the number of cards will increase and thus the I/O time. As I am learning Android development, I would use Service to learn it practically. I would also keep in mind the other scenarios that you mentioned. – Aditya Oct 15 '19 at 04:18
  • If you know before hand that 'to save data' will increase, then shared preferences is not right tool for the job. They are used when data set is small. For not small data set use a DB, and also read about Room(I have not used it till now, but heard that it provides abstraction layer over SQLite) – Rishabh Dhawan Oct 15 '19 at 04:32