MURAT YENER: Creating and managing local databases
is a core component of most mobile apps.
But whether you are using SQLite directly or true Room
persistence library, Android developers
have been asking for a better way to inspect
and debug their databases in running apps.
I'm Murat Yener, a developer advocate in Android DevRel.
And I'll be talking about the new Database Inspector.
Android Studio 4.1 comes with a new tool
called Database Inspector, which helps
you inspect, query, and modify databases in your running app.
With Database Inspector, modifying the data
in your database is not much harder
than editing a spreadsheet.
And if you are using Room and observing the query results,
the changes will be reflected instantly in your app.
In this video, I'll test some edge cases
on Sunflower app using the latest Database Inspector.
Sunflower is a gardening app that
illustrates Android development best practices with Android
Jetpack.
I encourage you to clone the repo
and follow along as you watch the video.
To add some plants to my garden, let's take
a look at the Plant List tab.
On the top right, there is a Filter button.
When I press this button, a shorter list of plants
is displayed.
Clearly this button filters the plants based on some criteria.
But I'm not super familiar with this project,
and I want to figure out how the filtering works by using
the Database Inspector.
To open the Database Inspector in Android Studio,
select View, Tool Windows, Database Inspector
from the Menu bar.
Now I need to run that on a device running API level 26
or higher and then select the app process from the dropdown
menu.
After I select the app process I want to inspect,
the database schemas appear in the panel below.
To see a sample of our database tables,
expand the database's sunflower-db schema.
Let's go back to the app and take a look
at the filtered plant list.
The list contains avocado, grape, orange, and tomato.
If I could sort the plant table by the plant name,
it wouldn't be hard to find avocado.
Let's see if the Database Inspector can do that.
First.
I double click on the Plants Table to display its data.
The data is displayed with that default page size of 50,
but you can reduce this number and page between a shorter
list of results instead.
Clicking on the Name column sorts plant table
on the name of the entries.
As expected, avocado is not far down the list,
and I find it in the second row of the table.
You've seen how to connect and display data sorting tables.
Let's see how the tool handles custom queries.
Looking at the data entry of avocado,
the grow zone number is most likely the property which
the app uses for filtering.
To verify that, let's run a query on the grow zone
number, which is 9 for avocado.
Actually, this query already exists in PlantDao,
and I can run the query directly from Room's query annotations.
Every query annotation has a similar icon
next to its line number.
When I click the icon for the query
of getPlantsWithGrowZoneNumber function
and select the correct database, a pop-up
appears asking me the value for Grow Zone Number.
I can enter a value of 9 and click
Run to see the query results.
Alternatively, I can type my own query
and run it inside the Tool window.
This gives me more freedom, as I am not
limited to the queries defined in DAO interfaces.
To run my own query, I collect the Plants database
from the newly opened tab on the right.
Next I type the query into the box next
to the database selection dropdown and click Run.
Here it is.
We have the exact same list of plants
as is shown when the filter is on.
The Database Inspector makes debugging your app a breeze
by allowing you to modify values in your app's databases
while it's running on a device.
First, let's say I want to test the app
UI for really long plant names.
Instead of changing the data [? source ?] and refreshing
the database with the new data, let's edit the values directly
on the database using the Database Inspector.
Make sure the Live Updates checkbox, which we will
see later, is not selected.
Double click on the Avocado.
And now that the cell is editable,
change the name from "avocado" to "Awesome California
Avocado," and press Enter.
If you are following along, you can type anything
your like, with the length you want to test in the app UI.
Now let's go back to the app.
Notice that without the us doing anything,
the app is displaying the updated data.
If your app uses Room and observes the query results
using LiveData or Flow, you do not
need to trigger a database query to refresh the data.
Otherwise, depending on how your app triggers a query,
you may need to relaunch the app or just
navigate to the related activity or fragment again.
In order to use the full potential of the Database
Inspector, this might be a good chance
to migrate your app to use LiveData or Flow.
Looking back at our app, it looks
like the [INAUDIBLE] is not designed to handle
such long plant names.
I'll fix this later.
But let's move on to the next test.
Each plant has a different watering interval,
and I want to see what happens when
the watering day is past due.
To do this, I need to add some plants to my garden.
But first I select the Live Updates checkbox
in the Database Inspector.
When Live Updates is checked, the Database Inspector
automatically displays any changes
your app makes to its database.
Let's go back to the My Garden tab
and add some plants, such as avocado and eggplant.
But first, go back to the Database Inspector
and double click on Garden Plantings to observe the table.
Notice how the data in Garden Plantings table
is updated automatically as I add new plants.
Both these plants have a water interval of three days.
I don't really want to wait three days to see what happens,
so I'll edit the database and change the last watering day.
Once again, I go back to the Database Inspector
and double click on Garden Plantings.
The last watering day is the last column of the table.
I'll change the values of both records to something
smaller to reflect sometime before today's date.
It looks like I went a little too far back in time.
But it should still work for my test.
The app UI seems fine displaying the due date.
For future development, maybe we can
suggest sending a warning to the user when watering day is past.
There are other features we didn't have time to talk about,
such as the ability to force databases
to stay open without closing while you are debugging.
The Database Inspector aims to help you to inspect and debug
your app's databases.
Go ahead and give the new Database Inspector a try.
Let us know what you think.
And if you come across any issues,
please don't forget the file bugs.
See you next time.