Replacing Shared Preferences with Room Database - but data not persisting

Question

I'm self taught so forgive me if I'm missing some basic knowledge. Based on some errors I'm receiving via the Google Play Console and subsequent reading, the understanding I have now is that shared preferences is no longer the best solution for saving data. So I'm trying to switch to Room Database as the suggested best alternative.

I updated my game and it seems to work just fine, the data saved OK when I returned from onStart. The game picked back up where I left off.

However, when I returned after the app was destroyed none of the data from the prior game appeared to have been saved, my game started back at zero. So, it appears I'm missing a step - the step where the data is actually written to the device's internal storage - and then the subsequent step to it being retrieved.

I don't expect for the exact code to be provided here, I just hope to be pointed in the correct direction as to what I need to read/research to achieve this.

Unfortunately my code is Java, so hopefully this is not a problem. The code is provided below:

@Entity(tableName = "DatabasePiles")
public class DatabasePiles {

    @PrimaryKey (autoGenerate = true)
    @ColumnInfo(name = "pile_id")
    public int pile_id;

    @ColumnInfo(name = "db_pile_number")
    public Integer db_pile_number;

    @ColumnInfo(name = "db_card_1")
    public Integer db_card_1;

    @ColumnInfo(name = "db_card_2")
    public Integer db_card_2;

    /// constructor, getters, setters, etc.
} 

My DAO:

@Dao
public interface DatabasePilesDAO {

     @Insert
    public void addDatabasePile(DatabasePiles databasePiles);

    @Query("select * from databasePiles")
    public List<DatabasePiles> getAllDatabasePiles();

    @Query("select * from databasepiles where pile_id ==:pile_id")
    public DatabasePiles getDataBasePile(int pile_id);
}

Database Java Class:

@Database(entities = {DatabasePiles.class}, version = 1)
public abstract class DatabaseForDatabasePiles extends RoomDatabase {

    public abstract  DatabasePilesDAO getDatabasePilesDAO();

}

In my code I have a method to SAVE the "pile" (an int[]) to Room, as such:

 RoomDatabase.Callback myCallBack = new RoomDatabase.Callback() {
                    @Override
                    public void onCreate(@NonNull SupportSQLiteDatabase db) {
                        super.onCreate(db);
                    }

                    @Override
                    public void onOpen(@NonNull SupportSQLiteDatabase db) {
                        super.onOpen(db);
                    }
                };


dbForDatabasePiles = Room.databaseBuilder(getApplicationContext(), DatabaseForDatabasePiles.class,"DBForDatabasePiles").addCallback(myCallBack).build();


int[] example = new int[]{1, 2, 3}
int pile_id = 1

DatabasePiles examplePile1 = new DatabasePiles(pile_id, example[0], example[1], example[2]}

dbForDatabasePiles.getDatabasePilesDAO().addDatabasePile(examplePile1);

This is how I retrieve the data:

DatabasePiles dbPile = dbForDatabasePiles.getDatabasePilesDAO().getDataBasePile(1);
// where (1) is the pile_id

Answer 1

However, when I returned after the app was destroyed

If by destroyed, you mean that the App was effectively uninstalled then you will lose all data as the database belongs to the App. That is the database will be stored at data/data/whatever_package_is/databases.

There will be 1 or 3 files, the file as per the database name passed as the 3rd parameter of the call to Room.databaseBuilder

There may a file that is the same name suffixed with -wal (the write-ahead log). There may be a file this is the same name suffixed with -shm (shared memory, a log for the wal file).

e.g. (as per a working demo of you code (modified/adapted to suit (brevity and convenience))):-

All files in the respective package (in the case of the demo a.a.so77089546javaroomnotsavingdata) belong to the App. If the App is uninstalled/lost/destroyed then the database along with the App go.

Of course with an/the emulator where you have access you can also delete the file(s) via Device Explorer (as was used to get the screen shot) which will result in the database being lost.

If you need to protect against this scenario then matters are more complicated as you would need to either access the database from elsewhere or have a process that can backup and restore the database from elsewhere (e.g. external storage (which isn't necessarily external)).