Android Architecture Components Assignment
Modify the step3_solution app at https://github.com/googlecodelabs/android- persistence/tree/master/app/src/main/java/com/example/android/persistence/codelab
so that, instead of an app about borrowed books, the app creates a database with reduced versions of the RecurringEvent and Event tables from the attached Draft Logical Database Design document, initializes these tables with some data, and retrieves and displays various subsets of the data in this new database. Specifically, a list containing the ID and type of each recurring event will be displayed when the app begins execution. When the button on the screen is clicked, a list of information for events associated with the first recurring event will be displayed. The information for each event will be the event number and the pointsEarned. When the button is clicked again, a list of information for the events associated with the second recurring event will be displayed, and so on.
Detailed Requirements
Rotation does not change the data displayed
For the tables in this assignment, the only fields needed are as follows. For the RecurringEvent table, you need an int id (primary key) and a String type. For the Event table, you need an eventNumber, a recurringEventId (together, a composite primary key), and a pointsEarned, all ints. recurringEventId is a foreign key referencing the id field in RecurringEvent.
Modify the example app’s db.utils.DatabaseInitializer class to perform the appropriate initialization of your database with at least two recurring events and at least two events per recurring event. You do not need to include Thread.sleep() calls between additions of data to your tables, as was done in the example app. I recommend that you number your recurring events consecutively beginning with 1; a hint below suggests why this might be helpful. However, except for this assumption, no part of your code outside of the initializer should make any assumptions about the data, such as the number of recurring events, number of events associated with the first recurring event, and so on. All of your code can assume that the database is valid, including that foreign key constraints are satisfied.
Use the Room architecture component to interact with the database. This means that you will need to write Entity classes to represent the two tables and DAO interfaces for inserting data into and retrieving data from the tables. The DAO method for retrieving event data should accept and use a parameter specifying the recurring event for which events are being requested. As noted above, there is a foreign key in one of the two tables. To ensure that this foreign key is recognized by Room, your code should use appropriate annotation in one of the Entity classes. You should modify the existing db.AppDatabase class to define your database as consisting of your two tables (Entity classes) and to define the methods that will be used to retrieve your two DAO objects. You must remove the line
.allowMainThreadQueries()
from the code in AppDatdabase that creates the database, since you should be using asynchronous database access. This implies that all of the values returned by your DAO interfaces must be LiveData objects.
Methods on the DAO objects must be called by a ViewModel class that you write (your class can be a modification of BooksBorrowedByUserViewModel, although you might want to rename the class). In the example app, the LiveData object is made available to the activity by storing the LiveData object in a public instance variable of the ViewModel. I recommend, but do not require, that instead your ViewModel object provide public methods that your activity can call to obtain each LiveData object. Note that unlike the example app, you will need two types of LiveData objects, one for a list of recurring events and one for a list of events. You should also use a variable in your ViewModel class to record the state of the display (showing recurring events, first list of events, second list of events, etc.). If you instead kept this variable in the activity, the variable’s value would be reinitialized on every rotation.
As in the example app, your activity should be notified that database data is available by creating Observer objects and registering each of these objects on the appropriate LiveData object. Unlike the example app, you will probably need at least two Observer objects, since there will be two types of LiveData objects provided by the ViewModel.
Hints/Suggestions
You’ll probably want to begin by downloading and running the example code. It can be downloaded from https://github.com/googlecodelabs/android-persistence. After unzipping, open the project in Android Studio and, after the build completes, navigate in the app to step3_solution. Right-click on BooksBorrowedByUserActivity and select
Run ‘BooksBorrowedByUserActivity’. If it does not start correctly, you might need to from the Android Studio menu choose Build | Clean and, when this finishes, Build | Rebuild Project.
There is a Google Developer Codelab that goes with this code which begins at https://codelabs.developers.google.com/codelabs/android- persistence/index.html?index=..%2F..index#0. You might find it helpful to work through, or at least read through, the first threefour steps of this lab.
I recommend deleting all of the “step*” folders from the project except for step3_solution (also keep the db folder). Otherwise, as you change the db files, you will see many errors in the other steps. (You might want to delete from AndroidManifest.xml the elements referencing the activities in these folders as well, but that’s a nicety.)
To specify a composite primary key, rather than using @PrimaryKey annotation, you add a primaryKeys specification to the @Entity annotation, for instance:
@Entity(primaryKeys = {“col_name_1”, “col_name_2”})
In the example app, a single call to retrieve data from the database is made in the ViewModel constructor and the result is stored in a public instance variable of the ViewModel. In your app, I recommend making all calls to retrieve data from public ViewModel methods that will be called by your activity as the data is needed and that will return their results (LiveData objects) to the activity. You will probably want two methods, one associated with each database entity.
One part of the example code that will change significantly is the method for handling buttonclicks(onRefreshBtClicked()inBooksBorrowedByUserActivity). Your version of this method will not recreate the database. Instead, it will need to update the variable representing what information is to be displayed (the display state) and then call the appropriate ViewModel method to begin the retrieval of the data appropriate for this state and register an Observer on the returned LiveData object. If you use state 0 to represent the state in which recurring events are displayed, 1 for the state in which the events associated with the first recurring event (recurring event with ID 1) are displayed, 2 for the state associated with events of recurring event ID 2, and so on, this approach (or something similar) is allowable and will probably simplify your code. Again, keep in mind that this state variable should be held in the ViewModel, not the activity.
In addition to your activity’s onRefreshBtClicked() method requesting data from the ViewModel (which will in turn request it from the appropriate DAO), your activity’s onCreate() method will similarly need to call the correct method, based on the state variable, to request the correct initial data to display. (Keep in mind that onCreate() is called if the phone is rotated, so it will not necessarily be correct for it to always request that the list of recurring events be displayed.) You’ll probably want to write a method that both onRefreshBtClicked() and onCreate() can call. This method will decide which ViewModel method to call and will register the observers.
There is no need to change the example app’s layout. However, you will probably want to make some changes in the res/values/strings.xml file so that the display isn’t about Mike’s books, the button says something more meaningful for our app than Refresh, etc.
Submission
As with an earlier Android assignment, zip the project folder (named android-persistence- master, although you can change the folder name if you like) and submit it to Blackboard.
Grading
0 points if your project does not build
(3 pts) Entity definitions, including primary and foreign key specifications
(5 pts) DAO definitions, including all necessary methods, correct SQL statements, and
return of LiveData objects for queries.
(2 pts) Database definition of entities and DAO access methods
(3 pts) Database initialization and creation as specified
(4 pts) ViewModel class, including display state variable and methods for initiating database queries and returning LiveData objects to the activity
(8 pts) Activity class, including proper use of display state variable, onCreate() method that always displays the correct information, click-handling method that correctly updates state variable and displays correct information, correct creation and use of Observer objects, appropriate formatting and display of information passed to Observers.