We pass on Androidx or fascinating travel on a rake

The theme of the transition to Androidx is now in the air. There is already a short article in English from Daniel Lew , there is a report . But they all quite superficially consider the transition scenario described in the Google documentation .

I want to share my experience. In my project, Moxy and Cicerone are used, I find my experience interesting, because the official telegram channels of these libraries periodically raise the question of when they will be transferred to Androidx.

Just Migrate to AndroidX ...

In order to translate the project on Androidx, you need to perform a few simple steps:

1. Install compileSdkVersion 28 and targetSdkVersion 28 , update all the support libraries to the latest versions.

2. Add the following lines in the file gradle.properties :

android.useAndroidX=true
android.enableJetifier=true

3. If you are already using Android Studio 3.2, then use refactoring:


He will do more (or less) for you.

If you, for some reason, do not use Git, or another version control system, then at this stage you will have a chance to make a project archive:


Click the Migrate button, choose where to save the archive, and after a while, we get the result of checking the project before refactoring:


Here we see which dependencies in build.gradle and import directives are replaced. On the example of the MainActivity class, as can be seen in the screenshot above, one dependency will be replaced: android.support.v4.view.GravityCompat , but if we open this class, we will see that there are actually three more dependencies that need to be replaced:


I did not understand the reason for this selective behavior, but these dependencies will have to be corrected manually. Click "Do Refactor".


So, since the studio could not replace all the dependencies (maybe you could, then you can be congratulated), when you try to build a project, you will see a similar list of errors:


Having opened a class with errors, we will see something like this:


We delete outdated dependencies, and by the Alt + Enter hotkey we import classes from the androidx package


Thus we fix all the classes. If the error is not related to "import", do not pay attention to it, most likely it is due to the same problems in another class.

For example:


Here the errors are due to the fact that the TimelineView class also needs to fix the problems with the import. When all the errors are corrected, we build the project again, and perhaps we get a list of errors again, only in other classes, the process is iteratively continued.

For errors with classes that are generated (Dagger or DataBinding), at this stage do not pay attention. If there are no errors in your classes, and the studio swears only on the generated code, then you need to run the Clean Project and the Rebuild Project.


If this does not help, you can try to clear the studio cache:


You will have to clear the cache at least once in order for the classes that generate DataBinding or Room to be created correctly.

External libraries

In general, we set the android.enableJetifier = true flag just so that at the project build stage, the external library dependencies are replaced with the corresponding AndroidX dependencies automatically, but for some reason this doesn't happen to me.

In any case, before doing what is described below, make sure that you have this problem and that the latest versions of the libraries you use are not yet translated to AndroidX.

Moxy

The MainActivity in my project is inherited from MvpAppCompatActivity is a Moxy class, which, at the time of this writing, has not yet been translated to AndroidX. To solve this problem, I copied the class to my project, into a separate androidx package , and fixed the dependencies in it. The class name is best left unchanged, so it will be easier to update dependencies.

The same procedure must be done for the fragments, for the class MvpAppCompatFragment .

Please note that there is a generic in these classes, in the mMvpDelegate field , do not forget to correct the dependency in it, it is easy to miss, because it depends on the Moxy class, and not on the support library class.

Cicerone

To solve problems with Cicerone, I had to create a copy of the SupportAppScreen and SupportAppNavigator classes in my project . Please note that the SupportAppNavigator class depends on SupportAppScreen. Do not forget to correct this dependence on your copy.

findings

The transition to AndroidX, an exciting experience, and perhaps, if you do not have an urgent need, it is worth a little delay with it. After all, then, when most of the rake is removed from your path, it will be easier and faster to do this. But personally, I am pleased that I have gone this way, the bumps on my forehead will heal, and the useful experience will remain with me.