Introduction to AndroidX | The Xamarin Show
Articles Blog

Introduction to AndroidX | The Xamarin Show

August 18, 2019


>>On this week Xamarin Show, I have my good friend, John Dick, on all the way from Canada, to tell us about AndroidX. [MUSIC]>>Welcome back everyone
to The Xamarin Show. I’m your host, James Matzo Magno. I have one of my favorite Canadian
friends in the entire world, John Dick. How’s it going, buddy?>>Hey.>>This is your first time on
The Xamarin Show, isn’t it?>>Yes. I’m kind of surprised
I haven’t been here sooner, but it’s nice to be here.>>Yeah. We had you
on, you blog all the time, everything about Android, we had you on the.NET
Community stand up recently, to show off a lot of
cool upcoming features. So I figured I’d have you
on to talk about AndroidX, what the heck is it, what does it mean for
Xamarin developers? But first, maybe, can you talk
a little bit about yourself?>>Yeah. So I’ve been in the Xamarin Community for
quite a few years now, since the Mano touch
days and earlier, and then I finally took
the leap and joined Xamarin a few years back before the whole Microsoft
transition and everything. But yeah, I’ve been
coding on mobile apps since that first iPhone came out, it really captured my attention and I just loved doing it ever since.>>Now you’re the lead of our
Components Team, is that correct?>>Yes. So Engineering Lead. Well, we maintain a number
of different things. A lot of it seems to be lately like the whole Google ecosystem is just so large on Android outside
of the core Android, but they also have a lot of
iOS APIs that we maintain, and then there’s some other just
various frameworks and SDKs like Facebook and everything
from like SDWebImage, and all these other
little bits and pieces that people want to use, and we let our users use these native frameworks
in their Xamarin apps, and we help them with that.>>Don’t forget Xamarin Essentials, everybody’s favorite
cross-platform as well.>>Xamarin Essentials as
well, yeah, absolutely. So that was a big team
effort and obviously, you helped out a lot with that
too and then continue to. Yeah, we did a lot of
different need kind of smalls, sometimes big things, and it’s
a lot of fun on our team for sure.>>Absolutely. You’re probably using, a pure Xamarin developer, you’re using John Software, his Team’s software, anywhere
between all those support libraries, the Facebook, all those things, essentials, right,
including every template. I mean, every single
Android developer, when they do “File-New”
they get this plethora, this cornucopia, if you will, of, it may be starting as a plethora right now but maybe it’s moving to a cornucopia of Android
Support Libraries, what is going on in the
Android Support Library world, and what’s coming up?>>Yes. So Google has historically moved more and more things to
the Android Support Libraries, as mostly it’s a way to
combat fragmentation. So you’ll always hear
this term fragmentation, and what does that mean in
the Android world, right? So everyone kind of thing, Oh, you’re stuck with
this version of Android, and nothing new can come to it, and that’s just how it is always
going to be for a certain device. Well, Google has made
these Support Libraries, is what they initially called them, and the aim of them, really, was to bring new features
to older API levels, to older versions of Android. This really allowed developers
to use all these new cool APIs, a lot of new widgets. We saw the Material Design controls
come to the Support Libraries, and this really enabled all
of the developers to bring all these features and make a
consistent experience in their apps, no matter what the API level was that the Android
user was running.>>Yeah. It’s kind of
like my favorite and yet least favorite part about
Android because there’s so many versions and
things that keep track of, but it is really nice that
I don’t have to wait for a brand new version of Android
to drop to get new features. So I think that is one
of the unique parts of the Android Ecosystem. But from my understanding, Google IO and even
before the last year, there’s all these kind of terminologies of like
Jetpacks and AndroidX, and Support Libraries are going away, but they’re not really going away. What is this shenanigans?>>Yes. So because they’ve moved more and more things into Support Libraries, I mean, for one, we’ve seen this kind of creeping of more and
more and more libraries, and Google’s really
done this to try and keep them in small
pieces as possible, so you can pick and
choose what you want. Now, these became such a big
part of Android development. It’s almost impossible to create an Android app these days
without Support Libraries, especially if you’re pulling
in third-party dependencies. All of those other library authors
had to use support libraries themselves because most of the people consuming their
libraries needed them in their app. So we’ve seen this world where now Support Libraries aren’t
really like this additional thing. You have to make an app
with Support Libraries. You almost have no choice. Because of that, Google
seem to feel that the name ‘Support’ wasn’t really telling of what
these things were. They’re now like almost a core
part of Android but of course, they don’t want to include
all of these APIs in the core Android itself
because then they can’t ship them as rapidly. Since they’re all in
their own libraries, they can keep improving on them, iterating, releasing outside
of the Android itself. So we don’t have to
wait every year for a new Android API level to
come out for new features. So they’ve moved into this world, now they’re calling
this Android Jetpacks. Android Jetpacks is just a term, a marketing term if you will, for these AndroidX Libraries, and AndroidX is the successor
of Android Support. So it’s largely a rename, but they’ve definitely shifted
some APIs to different libraries around and kind of made new divisions
in the libraries themselves. Now we’re in this world where
these Jetpacks are a mix of Google becoming
more opinionated and how they think that you
should architect your app, but also just kind of elevating the name of these things
to be what they really are, because they’re really
important to every developer.>>It’s sort of like they’re the Xamarin Essentials
for Android in a way.>>Yeah, exactly. Like you must use it.>>Now, they have a website
for it to, right? Let me go and grab your screen up
here and then grab over to it. Yeah. So this is
the full website where people can go and learn
all about it, right?>>Yeah. So Android Jetpacks, and you can definitely see all of the different items that
are available in Jetpacks. When you start looking at
the Jetpack components here, this is really where they
start breaking things down into the separate APIs. So we’ve got this new CameraX API, this is a new AndroidX library. We didn’t have this in Support. We have still our good
old friend, AppCompat. There’s stuff for
notifications, for media. There’s newer Emoji libraries
that were in Support, but they’re still kind of something
that not everyone knew about, and of course, we’ve got Fragment. This Fragment is one
of the main reasons that developers needed to go support
libraries in the first place. So yeah, here’s all the
different bits and pieces, and you can see the APIs behind them and then how
to use each one of them.>>Got you. A lot of
these are looking familiar but not all of them, so I’m going to have to go and
actually check these out myself. So what does this mean for
Xamarin developers then? Do we have AndroidX or
what does it look like?>>It’s been a large effort between
a couple of different teams, my Components Team that I’m on. We’ve spent a lot of time on this. Matthew, from my team, has spent countless hours
of trying to make this experience really
pleasant for our developers. We think we have a good solution. We’re on track to deliver a really nice way for our Xamarin developers to
consume these libraries. So the first part of it starts with the bindings to the
libraries themselves. So we actually have to take these native libraries and figure
out how do we expose those to our C-sharp run-time and how do our developers consume
these Java APIs from C-sharp. So that’s the binding part of it. We’ve been working on those
for quite a while now. We’ve pretty much completed them. There’s a few little polishing bits here and there that
we’re still looking at. But for the most part,
the bindings are done. Now the harder part is more
the migration step of, how do you actually get
your app to use these new APIs? Now, Google did an interesting thing
here with their own world, with their own Java developers
and they’ve made a tool that helps their developers migrate
over to these new APIs. So if you’re a Java developer
and you had an app, you might use some of the
Android support APIs. Now if you want to
migrate to AndroidX, Google has this onetime
migration wizard that you can run that will take
all of your Java code, all of your resource like
your XML layout files. All of your ProGuard rules, all of your Android manifest files, and it will migrate
those things over for you to use the new sets of code. So that’s part of the process, is updating your own code to do this. The other part of it is, what happens if you have
third party references that haven’t migrated
themselves yet, right?>>Yeah.>>Not a lot of libraries have
already made that jump yet because they still
probably have a lot of developers that they
don’t want to alienate. They don’t want to say, “Hey,
we’re going to break you now, you’ve got to move with us or else.” Google recognized that
this would be a problem, so they also accounted
for this and they have another part of their
migration process that actually migrates the Java bytecode of all of the third party assemblies
that your app consumes. So if I’m using the
Facebook SDK, for instance, it’ll go and actually after
those dependencies get downloaded, they’ll actually migrate
the Java bytecode for you as part of that. So this is how the Java world works, and we have a few more
challenges on top of that. Because obviously, we’re creating bindings and we’re
doing different things. We have to do that same part
that Google’s doing, converting the Java bits themselves over and all the
bytecode that’s in there. But we also have to convert our own C-sharp bindings
to these third-party APIs. So for instance, we ship
a Facebook SDK binding. That’s something that we
maintain and support. So if you pull that in as
a dependency in your app, we also have to make
those C-sharp binding types converted over for you to be
the proper AndroidX types. So we’re writing these build tasks that will happen in MSBuild as part of your application, and this is going to do
all the work for you, and do all those
migration steps for you, both in the C-sharp and
the.NET managed layer, but also the underlying
native Java bytecode layer.>>Cool, awesome. Do you
want to walk us through it? I know you have at least nice
little demo pulled up on the way?>>Yeah. I’ve got this hello
jetpacks demo, we’re calling it. It’s just a simple solution. Basically, a File-New-Project. But I want to show you first, let’s try running it on just the normal mode
how it would appear using Android support
libraries. Nothing special. This is something that you’ve
probably seen a million times, but it’s good to look at some of
the base underlying parts of it. So for instance, we’ve
got this main activity here that’s our entry point
for our Xamarin.Forms app. As soon as I can launch
this thing here, we’ll start building it,
we’ll launch it on a device, and we’ll take a look and see that. We’ve got this main activity which inherits from
FormsAppCompatActivity. When we actually step through the debugger process and we
take a break here at this call, we can start to inspect
the item at run-time. So I’ve got my trusty visor
app open here. There’s not a whole lot to see. I’m using preview versions of tools. We’ve got an app launched here. Now that we’re stepping through this, we’ll pause on this line here and
we’ll take a look at this local. You can see it, it’s
a FormsAppCompatActivity. But if we take a look
at one layer lower, we can actually see that it’s an Android.Support.v7.App
AppCompatActivity. So that’s expected. That’s
what we want to see. So Xamarin.Forms itself is
depending on Android Support, and we haven’t done anything to
change Xamarin.Forms itself over. But now, if we go in and we
can add some NuGet packages, for instance, we can add
the AndroidX migration package. Let me just scroll
down through the list.>>These are like
all of the AndroidX, there’s even more packages
than ever now, right?>>Yeah, exactly. So we
can add this package in. Now we are going to be offering a migration wizard in the future too, so that you can take
your project and say, “Hey, I want to go all in on AndroidX. Migrate me over, do
the right things, help me out.” But for now, if we’re just
doing like a one-off thing, we can add that migration
package and it’s going to come in and tell
us as we’re building, which other AndroidX
packages we need to install? So for instance, we don’t have the Xamarin AndroidX
AppCompat NuGet package and that’s the one
that’s needed if we’re referencing the Android support
V7 AppCompat one. So we could go and add all
those packages individually. I’m going to do a little bit
of cheating here and just do this manually, quickly. Let’s go make a new item
group here and we’ll paste in just a big list of all the packages that
I know I already need.>>Yes. As you’re going through
basically, you would say, “Okay. Well, it says I need
these five packages, go install this package, install this package, install
this package, basically, right?>>Yeah. So you can see here I’ve
added the AndroidX AppCompat, I’ve added the browser CardView
media, blah, blah, blah. I’ve already got
the migration package in there, but I’ve added it back as well as I’m overriding this project file. Then there’s this other
kind of weird one, which is Google diverged
from their naming and the material design stuff is its own separate new
package now as well. So this is like material design 2.0.>>Google divert from namings,
I’ve never seen that. Now this is interesting
because those packages are living side-by-side
your existing packages. Not like you deleted the old packages
and brought in new packages, and that’s because
Xamarin.Forms is using the old packages and
not the AndroidX packages. It’s like that you’re
talking about as why they have that little swizzling,
if you will, in a way.>>Yes. So what are
tasks are doing here, and now you’ll notice
that this is interesting, because we didn’t actually
have to change any of our code to make this run. Now I don’t have any Android support
code referenced here. But if we did, I wouldn’t have had to change it. So this is something
that we’ve gone a little bit farther and
we’ve tried to make that experience really delightful
for our developers to say, “Hey, I don’t want to start
doing this AndroidX thing. But maybe, I don’t want to migrate
all of my code immediately. That maybe seems like a lot of
work that I’m not prepared for.” It’s kind of weird
because you can reference both the old APIs and
the new ones at the same time, and we’ll actually do that code
replacement for you at build time. So if you had a reference to an app, V7 AppCompatActivity here, that would all compile
as is without changing. But at run-time, you would actually see that it’s now
an AndroidX AppCompatActivity.>>Got you. Now in this output, maybe moving fast for a few people. I see like some AndroidX
things inside of here. Like that, obviously, it’ll take a little bit longer because
they had to restore all the NuGet packages and do all this crazy stuff that
you’re talking about, right?>>Yeah. So that did
all the special bits and pieces. Now when we come back to
our locals view here, if we inspect this, still got FormsAppCompatActivity,
that didn’t change. But now, we’ve got
this AndroidX AppCompatActivity. So at run-time, this has
actually been changed for us, and at build time it’s been changed
for us in just AndroidX type. The key thing to note
here is, like I said, Xamarin.Forms, we didn’t get a different version of
Xamarin.Forms here. Xamarin.Forms are still built against Android support
libraries and just like any other third-party dependency you would have consumed that was
built against Android support. We didn’t have to go get
a new version of that. We didn’t have to ask
those developers to update for us. All we had to do is
come in here and add our migration package and
add our AndroidX packages, and now, we’re good to go. So we’re doing all of
those underlying conversion for you at build time.>>Very cool. That’s awesome. I like that I don’t
have to do anything. It tells me what I need to do. A little bit nice, easy way of being like,
“Hey, I want to upgrade. I don’t want to change everything.” Also, there’s a huge ecosystem of developers out there and packages
that you’re probably using, and I don’t want to have to ask every single developer out there
to update their package, right?>>Yeah, exactly.>>Cool. Awesome, John, this is amazing. It blows my mind. If people didn’t get it today, it’s in 16.Visual
Studio 2019 something?>>Preview three. We’ve got
some packages available. Yeah, you’ll have to be
in 16.3 of Visual Studio and you should be good
to use it from there.>>Awesome. Well, thank you, John, so much for coming on and showing us all the awesome AndroidX stuff. Also more importantly,
just talking about what it is and how I use accessing. There’s still a lot
of confusion on it and it makes a lot
more sense to me now.>>Thanks for having me.>>Awesome. Well, thanks everyone for tuning to this week’s Xamarin Show. Of course, I’ll put all the links
to the show notes down there and how you can get
your hands on AndroidX today. Thanks for tuning and this
has been, The Xamarin Show. [MUSIC]>>Hey, James here.
Just wanted to check in and thank you for
watching this video. Now do all the things that you
know you want to do, such as like, subscribe, and ding
that notification bell, become part of
the notification squad. While you’re here, check out all these awesome videos
that I’ve already recorded. Click on that thing, click
it, watch it, do it.

Only registered users can comment.

  1. But why should we update? It's easy to understand what AndroidX is in this video and how to do the update. But why should we bother updating? Just for the sake of having the newest?

  2. How the hell did you get that build + startup speed? I am running a surface book pro i7 and building+debugging is dog slow.

Leave a Reply

Your email address will not be published. Required fields are marked *