G'day everyone. Welcome back and welcome to section 13.
I'm going to start this section by showing you how to convert the app to AndroidX.
We've talked about the support libraries, and we've seen how useful they are,
but they've grown huge, and a bit confusing over the years.
Google are in the process of moving things like AppCompat into a new set of libraries, which they're calling AndroidX.
If you started this course recently, you'll have ticked the Android X Box when creating your new projects.
In that case, there's no conversion necessary and you can skip this video if you want.
It's useful to see the conversion though, because you may have to convert older projects.
If you're not using AndroidX already, you'll have noticed some of your classes are importing from v4 and v7 libraries.
One example is MainActivity. Have a look there
at the imports, and we've got imports of android.support.v4.app.Fragment
and android.support.v7.app.AppCompatActivity
That's confusing, especially as our minimum SDK is set to API 17, not 4 or 7.
It's not just confusing, it's also a bit unwieldy.
Google have to release new versions of very large libraries, even when they only want to update a single component.
So they're rationalising everything into the new Android X libraries.
They've also made it very easy to convert your apps, and you should get very few problems.
Most of the time, you'll have no problems at all.
Alright, I've got the TaskTimer app loaded in Android Studio.
Let's see how to switch the libraries to AndroidX.
In the module app build.gradle file,
at the bottom, we can see all the dependencies, on com.android.support libraries.
It's these dependencies, and the imports, that the conversion modifies.
Go to the Refactor menu, and choose the option Migrate to AndroidX.
It's a very good idea to have a backup of your project first.
Of course, you've already done that, but just in case you haven't,
the migration process will zip up your project files to create a backup for you.
If you want to backup, make sure the 'Backup project as zip file' box is ticked, before clicking the migrate button.
I'll leave it ticked, because there's something to watch out for if you use that option.
We have to specify a location for the backup zip file,
but be careful.
It doesn't do it on my Mac, but on Windows and Linux,
notice the default to putting the zip file into your project directory.
So be careful there, and make sure you save it somewhere else out of the way.
I'll put it in my documents folder.
Click OK after choosing a suitable location,
and Android Studio will convert the project to use the Android X libraries, instead of the old support libraries.
It shows you what's going to change in the refactoring preview at the bottom of the screen.
You might want to expand all the sections there to get a feel for what's going to change.
It's fairly straightforward, and I'm just going to click the Do refactor button.
It takes a while to update everything, and you may see a dialog asking if you want to update Gradle.
Android Studio seems to perform a check for updates, as part of the migration.
So you'll see that dialog if any new updates are available.
Click Update if you do see that.
Android Studio will then resync the Gradle files.
At the moment, some of the AndroidX libraries are still in beta.
You won't want to use them in a production app, but they should all be released versions quite soon.
I've got a load of suggestions about version numbers in my build.gradle dependencies,
because new versions of the libraries came out after this version of the migration tool.
It's always worth checking your build.gradle file after migrating, to fix up any version numbers, as necessary.
We've done this before, in an earlier video.
I'll change the version to match what Android Studio's suggesting.
It can be tricky to get the light bulb to appear, but clicking on the ticks in the right margin seems to work well.
Clicking on the word before the final colon in each line, also seems to be reliable.
You can also just type the new numbers in without using the light bulb.
Google have also changed the way the lifecycle version number is provided.
They no longer use that lifecycle underscore version variable, and it can be deleted.
Okay, sync now to use the new versions.
Our dependencies are now on the Android X libraries, rather than the old support libraries.
Switching back to MainActivity,
the imports no longer have that odd mix of v4 and v7.
They're all from one of the Android X dot something libraries.
If you get any unused import, you can safely delete them.
Make sure they really are unused, though.
I've noticed that the conversions sometimes results in fully qualified class names, instead of using imports.
For example, check the removeEditPane function, in MainActivity.
It's using Androidx.fragment.app.Fragment,
which is a bit unwieldy. I'll delete the package name.
And now the import's no longer unused.
Of course, if Android Studio removed the import, you'll now get an error.
Use Alt + Enter to add the import back in again, if that happens.
Now, I said you don't get many problems, but you may find errors with some of the functions you've overridden.
Google have been adding annotations to the Android framework code,
and some of the function signatures have changed slightly.
I'll spend a moment explaining all this, because it's very easy to deal with when you understand what's happening.
As I mentioned in an earlier section,
it was safe to delete the nullable type marker on the onSaveInstanceState function.
Let's have a look at that in MainActivity.
Ctrl-click on the super dot onSaveInstanceState function, in line 146.
That takes us to the Android source code.
Notice that there's no annotation on the outState bundle parameter.
As a result we don't have to change our code.
I haven't got an error in MainActivity.
As they introduced new versions of the AndroidX libraries, and other librariesin the Android framework, for that matter.
Google are annotating parameters that can't be null.
When you convert to AndroidX, you may find that later versions of the libraries are used, and you may get errors.
I can simulate that behavior by swapping to pre-release versions of the AndroidX libraries.
I'll paste in a new dependency section in the module build.gradle file, to replace the current versions.
Sync now,
and back in MainActivity,
we've got an error on the onSaveInstanceState function.
Control click on the super call again,
and we can see that this new version does annotate outState with @NonNull.
Back in MainActivity, the function signature no longer matches the function that it's overriding.
We have to delete the question mark from the parameter to fix the problem.
If you're not sure what the correct signature should be,
comment out your function, and get Android Studio to generate the stub for you again.
If Android Studio generated your function subs with the latest libraries,
outState won't have been marked as nullable and you won't get an error.
This only really applies when converting old projects.
Okay, that one was easy because I had MainActivity open.
I'm not going to open up every class file to check for errors.
Instead, use Build, Rebuild project
and check the build pane at the bottom of the screen to see if there are any more errors.
It takes a little while to rebuild and I've got another error.
The onAttach override in MainActivityFragment is incorrect.
You can double click the error in the build pane, to go straight to the problem code.
We can delete the question mark after context,
and then rebuild the project again.
The AndroidX libraries are more Kotlin friendly than the old support libraries.
In fact, Google aren't developing the old support libraries anymore.
Version 28.0.0 will be the last version of them.
So that's two good reasons for switching to AndroidX.
There may also be unused imports at the top of file.
Search the file for AndroidX,
to quickly find any fully qualified class names.
They don't cause a problem
It's just harder to read the code if they're fully qualified, rather than imported.
Unused imports are a good indication that the migration's done something like that,
but sometimes the import's missing.
Searching the file for AndroidX is a more reliable way to detect those fully qualified class names.
I've also got a suggestion that there's a redundant call to toString,
in the onAttach function.
I'll use a light bulb to fix that.
I'll also space the function out better.
There may be another fully qualified class name in onViewCreated,
and I'll fix the fully qualified classes in AddEditfFagment,
and our cursorRecyclerViewAdapter class.
It's worth going through all your class files, looking out for changes that you may need to make after the conversion.
Android Studio suggestions in the right margin are very useful,
and the presence of unused imports is also a good clue, that some of your class references will be fully qualified.
After these changes, the project builds successfully.
I'll run it in the emulator just to be sure
You should really test the app thoroughly, of course,
but you don't want to watch me doing that.
Make sure it works before moving on to the next video.
There's one change I'm going to make before finishing this video.
Back in the build.gradle file,
I change the library versions to use the alpha versions.
You shouldn't release an app with the alpha or beta libraries,
and I don't want to forget that I'm currently using them.
So I'll add a to do comment as a reminder to update things like androidx.appcompat.
when Google makes the release versions available.
Alright, that's our project converted to use AndroidX.
We'll make a start with dialogues in the next video.