Welcome back. It's time to see if our changes have fixed that bug
when the locale has changed.
I'll repeat the same test as before,
which means I'll start by dragging English Australia
to the top of the languages.
Next, I'll run the app and go into reports.
We'll set the date to the 10th of June, like last time.
Notice that the week is starting on a Sunday,
and we'll get data from the 9th to the 15th of June.
Sorting by date will make it easier to check the results.
Okay. That is working as expected.
Now I'll switch the settings and change the language to English
United Kingdom.
When I switch back to the app,
the date format changes and we've now got records from the 10th
to the 16th of June,
that's just what we'd expect
because the week starts on a Monday in our new locale.
In the logcat,
we can see the database being re-queried
as the view model responsive locale changed.
Our broadcast receiver works and we fix the small bug.
Listen to all the feedback we get from students.
And in the last few sections, we've made the video shorter as a result,
but this one's a bit too short.
So I'm going to take a few minutes to show you something weird.
You'll have come across an indication of this in the BroadcastReceiver documentation,
but the documentation only talks about it when referring
to manifest receivers,
BroadcastReceivers that you receive in the app's manifest.
We're using a ContentReceiver but the same thing still applies.
If you register a BroadcastReceiver in the app's manifest,
your app will be launched when an action you're monitoring happens.
That can be useful.
A security app for example
could be launched when a user unlocks their phone.
The short video in the documentation
talks about the performance penalties,
and how too many receivers can really impact the performance
of the entire device.
Make sure you watch that video and read the documentation
if you're going to use BroadcastReceivers in your app.
ManifestReceivers are registered system-wide,
and they don't get unregistered unless you uninstall the app of course.
Okay. What will happen
if we fail to unregister our BroadcastReceiver?
We can test that by commenting out the line that unregisters it
in the uncleared function.
This short test will show how BroadcastReceivers work
and will also demonstrate why it's important to unregister observers and receivers.
Let's see what happens. I run the app and go to the reports.
We can see our DurationsViewModel being created in the logcat.
I'll filter on durations to make it easier to see though.
That lets us see the query being executed as well.
Okay. I'll use the up button to go back to main activity.
We get the ViewModels OnCleared function called
and our DurationsViewModel instance should now be destroyed.
What's going to happen if I switch to the settings
and change the language again?
Remember, we haven't unregistered our BroadcastReceiver.
Let's see, keep an eye on the logcat as we do this.
In the settings, I'll change back to English Australia.
In the logcat, we can see the BroadcastReceivers
OnReceive function being called.
Then the database is queried to get the reports data.
We're not showing the reports,
as you can see if I switch back to the app.
We're still on the main screen.
We've wasted battery life and resources retrieving data
that we've got no use for. It's worse than that
because our ViewModel didn't unregister its receiver,
it couldn't be destroyed by the system.
Our app had no further use for it,
but it's still registered as a receiver
and the instance remains in memory.
I'll go back into the reports.
And there's another instance of the DurationsViewModel class
being created and querying the database.
I'll clear the logcat
then switch to settings and change the language again.
Watch the logcat as I do this
because you may not expect what's about to happen.
The BroadcastReceiver's onReceive function
gets called twice.
Once for each instance of the receiver that's been registered.
Each time I go into reports
a new DurationsViewModel instance gets created
and registers another copy of the BroadcastReceiver.
We're starting to eat up ram with new DurationsViewModel instances.
We're also performing more and more queries on the database
to get back data that we have no use for.
That's what's meant by leaking memory.
And this is a really good way to do it.
If you want to give your users a really bad experience
and make their phones perform badly, then this is one way to do that.
Please don't.
Always unregister your BroadcastReceivers and observers
and clean up any other resources that you create.
Okay. I better uncomment that line
before finishing the video.
In the next few videos, we'll finish off this section
by using the settings in our reports. I'll see you then.