Michael Fazio, Engineering Manager (Android) at Albert and author of Kotlin and Android Development featuring Jetpack from the Pragmatic Programmers, speaks with SE Radio’s Gavin Henry about how the Android ecosystem looks today, and why it’s an excellent time to write native Android apps. They explore a wide range of topics about modern Android development, including when to go native, how to keep a lot of decisions in your back-end API, Kotlin co-routines, Jetpack and Jetpack Compose, the MVVM design pattern, and threads, as well as activities, fragments, Dagger, room, navigation, Flutter, and improvements in simulators. They also examine details such as IDEs, API selection, how to choose a list of support devices, Java vs Kotlin, handset manufacturers, XML layouts, and why Jetpack is a safe bet for all your future Android development.
Show Notes
- SE Radio 326: Dmitry Jemerov and Svetlana Isakova on the Kotlin Programming Language
- Episode 437: Tim Sneath on Architecture of Flutter
- Episode 428: Matt Lacey on Mobile App Usability
- Episode 427: Sven Schleier and Jeroen willemsen on Mobile Application Security
- Episode 300: Jonathan Stark on Mobile App Development
- Kotlin and Android Development featuring Jetpack
- Comparative study: Java vs Kotlin
- Effective Java by Joshua Bloch
- Android Jetpack Dev Resources
- Jetpack Compose UI App Development Toolkit
- Kotlin Programming Language
- Co-routines | Kotlin
- Kotlin Multiplatform
- Android Developer Guide: Activity
- Android Developer Guide: Fragments
- Dagger – IntelliJ IDEs Plugin | Marketplace
- GitHub – android/sunflower: A gardening app illustrating Android development best practices with migrating a View-based app to Jetpack Compose
- Twitter: @faziodev
- LinkedIn: @mfazio23/
- www.albert.com
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Gavin Henry 00:00:17 Welcome to Software Engineering Radio. I’m your host Gavin Henry. And today my guest is Michael Fazio. Michael is a software developer and tech speaker who fell in love with Android, starting with the original Samsung Galaxy S way back in 2010. He’s been the Android lead for multiple billion-dollar companies and is the author of Kotlin and Android Development featuring Jetpack from the pragmatic programmers. Michael, welcome to Software Engineering Radio. Is there anything I missed in the bio that you’d like to add?
Michael Fazio 00:00:48 Yeah, it sounds great. I’m also the engineering manager for the Android team with Albert, a financial startup in the US, and so we’re trying to help normal people, Americans. It’s complicated enough trying to just view the US and trying to make sure people have the advice and tools they need to get their financial space in place. So, I get to use Android and help normal Americans get in a better spot.
Gavin Henry 00:01:14 Cool, thank you. So, the goal for the show today is to understand where Android is right now. To discuss a brief, possibly pained history of Android mobile development and what it’s like now — you know, proper modern Android development. Also, I’d like to understand and the listeners to understand when to reach for native Android development versus some of the other frameworks that try to create apps for all different platforms. So, let’s get started. Android operating system, what is it today? Can you describe that for us?
Michael Fazio 00:01:48 So it’s at the point today where it’s the most used mobile platform around the world. I was trying to get updated numbers; it’s at least 3 billion devices at this point. That was from last year. Funny enough, it actually started as a digital camera operating system, and the team at Android Inc went, “this might get better reach being a phone OS.” And that turned out to be the case. And so yeah, it’s now on Phones everywhere, tablets; you can run Android apps on Chromebooks, on Windows, there’s Android TV, there’s Android Auto and Wear OS, which are effectively different display types for the, you know, your phone. So, you have your phone, it runs everything but then you display it in a different way in your car, dealing with things on your wrist, all of that.
Gavin Henry 00:02:40 And that’s native, isn’t it? That’s not–
Michael Fazio 00:02:43 Yeah.
Gavin Henry 00:02:45 So, there’s just a few shows that I want to mention to the listeners before we get onto the next section. So, we did a show, episode 326 on Kotlin. I did a show, episode 437 with Tim Sneath, who’s the head of Flutter. Matt Lacey, episode 428 on Mobile App Usability, which is a really good one if you haven’t heard that one, Michael. Show 427 on Mobile Application Security ’cause there’s a lot of surface area to think about when you’re doing these. And then lastly, episode 300, Jonathan Stark on Mobile App Development again. So obviously Android is everywhere — you know, 3 billion devices at least, and loads of different shapes and forms. Can you give us some examples briefly of problems you had experience in developing it since you got involved sort of 2010?
Michael Fazio 00:03:32 The number one thing I always call out is the fact that there are so many devices by so many different makers that you have a lot of choice with what you want to have in an Android device. You know, if you want bigger screen, smaller screen, more powerful cameras, whatever it might be. The issue from the dev side is that that level of fragmentation means you have to account for a whole bunch of different devices. And some devices will display things differently, some will run things differently. Some, like Samsung devices, are much more aggressive in how often they close out your app. And so, then you have to recreate it and make sure that when it’s recreated it comes back exactly as you expect. And so, trying to deal with all these different form factors, device makers, everything like, that can pose a lot of problems.
Michael Fazio 00:04:26 And it’s gotten better. Some of the Jetpack libraries that we’ll touch on a little bit later have helped that, but it’s still definitely a challenge to say, all right, I’ve got my Pixel phone, somebody else has a Galaxy phone. Does this look the same or not? How do I get them to match up? What can I do here? Past that, there’s always challenges with the lifecycle of, alright, the app is spinning up an activity, which we’ll talk about in a bit. It’s spinning up, what are the steps it goes through, what part do I need to jump into, how do I handle when a new activity is coming up and another one’s going away, jumping between them. All of that can be a challenge. And then just navigation between different views and trying to figure out, all right, here’s where I want to be, here’s where I need to go. What’s kind of a smooth way to do that? And so, there’s all these different pieces in there. Also, the fact that when you’re dealing with these applications, they’re on somebody else’s hardware; it’s a lot out of your control, and you just have to kind of hope it’s working well for them with, again, the different devices, different styles, different form factors, different network situations — all these other variables that you don’t necessarily have with like a traditional website on a PC.
Gavin Henry 00:05:35 Is this because, you know, you’ve got all these different devices and in different countries — is it a device issue, or is it the fact that you’re not dealing with the same range of Android versions? Or do you have to make a decision and say, you know what, we can only support a certain version of Android that’s up to five years old, for example. Can you kind of make a decision there and say, we presume that everyone has a back button, presume everyone has a screen of at least this size. I mean, how do you work around them, and how does it impact the user?
Michael Fazio 00:06:07 At some point you just have to, you have to have that cutoff and say, okay, we’ll support old versions of the OS. In comparison to iOS, it’s usually people upgrade very fast for their OS version. You know, you have a small set of devices and everything’s ready to go. An Android, like in our example, the current version API version I want to say is 33, and we support back to 21 — this is for the Albert app. And we do that to make sure that people that bought devices six, seven years ago, that may have been slightly out of date then can still use their app. But there’s a lot of challenges that does pose. And so, in combination with what I mentioned before about the different devices, yeah the different Android versions can be a challenge as well. Some things are backported, some things aren’t. So it’s just, there’s a much wider range of environments that you’re dealing with when you’re going ahead and you’re working with Android devices and this is not even talking about getting into tablets and all the other pieces I mentioned earlier. This is just talking about phones. There’s that huge range.
Gavin Henry 00:07:08 So this might impact a user by the fact that you won’t be able to do a certain feature on a certain Android version. And just explain what you mean by APIs versus Android 8 and 9 and 10. How does that work?
Michael Fazio 00:07:23 So it’s the same thing, it’s just a different way to refer to it. So, when we talk about an Android 8, 9, I think 13’s the current one, it’s code named ‘tiramisu’ because they always had their fun sweet dessert names for him. And so, the new ones 13 codename tiramisu, but it’s API level 33. There’s kind of these different names for the same thing. So, the users are looking at Android 13, the developers are going, all right, here’s the API level 33 because minor updates to Android versions use that API level, and the API level is what is really controlling what’s available just built into the OS. So, you say, all right, I’m targeting this, and then I have some other version that’s my minimum. The device needs to be running this, but I’m really hoping they’re running this better one because then I can get everything included over here and then have fallbacks for any situation where, oh this isn’t supported with a lower version of the OS.
Gavin Henry 00:08:23 Yeah, that makes sense. So, you can either weigh up how much effort do we need to put in to make it look or detect on these older things or just say we can’t do it and it won’t be available through the Play Store because of that version limitation.
Michael Fazio 00:08:37 Exactly. It’s like we just have to say, all right, here’s the experience we want, here’s the threshold. It needs to be. We can’t support every device, we can’t test every device. We’ve got tools to simulate that, but it’s not going to be perfect. And that’s just something that we have to accept and make sure that we are hitting the devices that our users are using the most.
Gavin Henry 00:09:00 And just before I move us onto to the next bit, we should also touch upon the fact that because Android is open source, you can’t really guarantee that you’re on API 33 because of vendor might do something to it to make it work on their proprietary hardware.
Michael Fazio 00:09:15 Yeah, they all have their own way to implement different things and their own tweaks and spins and here’s our version of the UI. It’s similar but it’s not quite the same and it can work a little weird. So, it’s like there’s the baseline and then there’s the parts added on by the different vendors. Exactly as you said.
Gavin Henry 00:09:32 I suppose it’s the freedom thing. You know, Samsung do one thing, HTC used to do one thing and you’ve got so many all the different vendors, whereas if you go Apple, it’s one way or no way, you know.
Michael Fazio 00:09:45 Yep, exactly. It’s like the beauty of Android is you have the freedom to get the device and the layout and everything you want. You can swap out the home launcher, you can do all these things, but it’s also the danger of it of ‘oh, things don’t work consistently on every device.’ It’s like, yeah because you have that freedom, it’s not quite as safe, it’s not quite as uniform as you’d expect from comparison to iOS.
Gavin Henry 00:10:08 Yeah, they might have taken a different kernel, as well. You know, you just never know. I think we touched upon all the different range of hardware that Android works on. So, my next question would be, as a developer, when do you choose to go native — as in proper Android like we’re talking about — or you go for a framework like React native or Flutter, or one of the other ones out there that’s still surviving because you want to make a mobile app that works on iOS, desktop, web and Android type things. Could you share any sort of best practices or anything you’ve experienced of what makes that decision clear cut?
Michael Fazio 00:10:46 Well it’s always funny because I’ve had people ask me that and I’ll be sitting here presenting about native Android development. They’re like, oh so don’t do cross-platform, Mike? No, no. The cross-platform tools now are really good and they make us make sense in a lot of cases. And the quick one I always give is, is your team big enough to support two completely separate apps, separate platforms, separate languages, separate integrations? Or are you in a spot where I need to have one code base because my team can’t handle it. We don’t have the resources, we don’t have the knowledge. I’ve also seen it before where, let’s say — I had a client like this years ago of, alright, everybody knows.NET, everybody can do C#, we need a mobile app, let’s use Xamarin because it’s C#. Our team already has the language part done.
Michael Fazio 00:11:42 Again, we’re not big enough to support two full teams for two full apps. Instead we can have a dev team and the mobile app is just another part of that. There’s extra challenges with the mobile app, but you at least have the ability to come in and look and go, I can read the code. That makes sense. It’s one of those where if you just want to get something small up and running, your cross-platform tools are going to be great. If your main concern is I want my app to be smooth, I don’t care if it’s basic, I don’t care what it does, I just want this thing to look smooth as possible. Flutter may be your best bet because that’s such a focus of that library. But, if you’re in a situation where you can support the multiple teams, you want the best possible experience out of your app, you want to be able to use multiple third-party libraries without issue, you’re going to want to go native then. That is the ideal state. Like, that’s the intended state for an app is the native approach.
Gavin Henry 00:12:32 When you say with the native app, is there more stability in the libraries that you choose versus — cause I’ve done a Flutter app and I’m just working on my next one and there’s so much movement on releases. I just, I was hoping you’d say in the Android world you get a bit more stability depending on what you’re using. You know, there’s potentially less choice of libraries because there’s, you’re going native so you don’t have all these different hooks. What would you say to that?
Michael Fazio 00:13:00 Yeah, absolutely. It’s so much easier to go and bring in something third party when you’re dealing with a native app. I know — again, going from my Xamarin experience: bring in this app, here’s all this extra work we have to do to get to work with Xamarin. Unless you get lucky and somebody else has done that for you and shared it. Otherwise, you’re doing that by hand. You go in on Android and you say, all right, here’s my library I’m going to use, here’s the version, put it in my Gradle file, sync. Hey, I’ve got a library, you’re done. That’s all you need to do with it. And it’s kind of nice thinking about, you’re talking about having the new versions and having to deal with that, whereas you get something like the Jetpack libraries, and not only are they out there and they’re easy to put into an app, but they’re all separately versioned. So, you don’t have to upgrade everything at once. Even if you want part of your, one of your Jetpack libraries to be newer, you can upgrade the single one and it doesn’t have to be the full suite. So, I’m jumping ahead, but it’s another spot where it gets to be easier to deal with, as opposed to what you have otherwise.
Gavin Henry 00:13:59 No, that’s perfect. Next section, we’re going to dig into the actual programming language, Kotlin, and why Android has adopted it and why it’s so popular. But just to close off this section about that Android operating system, in general, could we spend some time on you taking us through — in your experience, obviously — creating a traditional Android mobile app before Kotlin and Jetpack came around?
Michael Fazio 00:14:24 Yeah, and some of this stuff is absolutely still true. You come into an Android app, you have an activity: that is the main driver for an app. It’s your main view, it’s what starts up, it’s kind of a heavyweight component, but it has all these things it can do in there. And so, even now you set up an Android app, you need to have at least one activity that is your main piece, and then you can build up from there. But what would happen is before you’d be going ahead and you’d create an activity and it would have your view components; it would probably be accessing data somewhere in there. Maybe you can have a separation of concerns a little bit where you’d create some other classes to do that, and it can just somewhat tie into the activity. You want a new view, okay, now we’re going to go ahead and we’re going to jump this new activity.
Michael Fazio 00:15:17 And you’re running these intents back and forth, which again, still done when you’re going between activities, but before it was, that was your view component. That’s the only option you had. And so, you’re losing all your context, all your data from the activity and you have to spin it up in the new one. And then you’re sending parameters through when you’re starting up this new activity that’s there. You’re doing all of this tied to an XML file, which is where your layout lives. And most apps are still XML-based. But it would go ahead and it would say, okay, here’s my activity from a code perspective. Here’s my Java file with an activity, here’s my XML layout file for that activity, and I’m specifying the layouts — you know, I usually have like some kind of frame layout that’s my container. I’ve got a linear layout that’s some number of components in a row; got a, maybe I’ll have a list view where I can go ahead and I can bring multiple things in so it’s scrollable.
Michael Fazio 00:16:12 If you add too many, it might get really slow really fast. You’re also dealing with other resources within XML files. It might be string values because you can do translations. It might be dimension files, which are different sizes or values you’d use in layouts that are set. So, you’re doing all this; you’re doing it all in Eclipse back in the day. So, it was Eclipse with an Android plugin, doesn’t have its own IDE. You’re doing this in Java, you’re trying to make async calls somewhere else, but you have to use async tasks, which is an entire class. You’re overwriting methods and specifying “okay, before and after.” And you’re creating a brand-new class every time you’re going out to some third-party location, you’re directly accessing the SQL light database on the device. You’re getting a cursor back, you’re manually going through the cursor saying–all right, while the cursor has data, take it out, convert everything to what you want, make it an actual object you can use; send it out.
Michael Fazio 00:17:23 All of this, by the way, being done on an emulator that barely worked. That was one of those — I’m very realistic about this: the emulator was awful for years. And so usually, okay, if I can get a device and you develop on that, my life’s a lot easier. Not everybody would have that luxury. So, it was, I’ve worked on worse things but it wasn’t great. And when people would complain about oh, I have to do this and this and this, I’d go, yeah, that’s fair. It’s not the best developer experience. And so, there’s been a lot of changes that have been made to help the tooling, make movement around an app simpler, to make displaying data simpler, to make saving data simpler, accessing data simpler — all these ways that here’s what we had, we had to start there, but it’s definitely better than this Android development was back in 2014, for example.
Gavin Henry 00:18:15 Even when you got all that right, did you still have a potentially unstable app, or is that improved as well?
Michael Fazio 00:18:23 There’s always that chance with it. And again, talking about the fragmentation, we would go ahead and there were fewer devices but there were still multiple devices, and in a way it was a little bit more challenging because nowadays a lot of people are going to have Samsung devices; a good number are going to have the Google Pixel devices; and then there’s some people that have smaller offshoot devices. Whereas before it was a little bit more of an even playing ground where you had LG and Motorola, and I think Nokia had a little bit in there, and Samsung was still in there. You know, maybe Google was coming in a little bit later on. The fragmentation is still there, but it’s, the major devices are a smaller set than it was. And then you’re hoping everything worked and that your emulator showed a reasonable enough version of the app so that you can test and say, okay, here’s what I’m expecting people to see. But wasn’t even a guarantee.
Gavin Henry 00:19:18 And I noticed, there’s Android Studio now, which isn’t the Eclipse and Android plugin, which is actually really nice. I really like that using that. But you just remind me, touching on the emulators there, there aren’t that many emulators to choose from in Android studio. They’re sort of no older things. How does that impact using all the modern Jetpack things, but you’ve got potentially older devices you’re simulating on?
Michael Fazio 00:19:42 Well, and they’re more generic devices. They’re not here, let me do an emulator that’s a Samsung Galaxy S10 plus. Let me go ahead and have a — I mean they’ve got the Pixel 6 Pro, but it’s not a perfect example of how things will work. So, you’re doing that, but it’s not great. This is why there are tools like Firebase has their device set where you can say, I’m going to test this section of my app and I’m going to do it against these 10 devices, and it’s going to go run them against like the actual devices that are out there — as opposed to trying to use an emulator and going, I think this is how this is supposed to work except I have the real device and it’s not; you’re playing a bit of a guessing game. And so even now it’s like, it’s still a challenge with it. It was worse back then because they didn’t perform and they weren’t laid out nicely. But that is still definitely a sticking point when you’re trying to test things out properly and make sure it works well.
Gavin Henry 00:20:38 And Firebase is the Google SAS service, isn’t it?
Michael Fazio 00:20:42 Yes. And they’ve got all things like real time database crash analytics for tracking, again the device testing and 30 other tools I’m not even touching on here.
Gavin Henry 00:20:53 Excellent, thank you. Okay, let’s draw line the Android operating system and drill into the Kotlin programming language. What is Kotlin?
Michael Fazio 00:21:03 So Kotlin is just, it’s a multipurpose, strongly typed language. You can think of it as the next evolution of a Java. I always like describing it as: we took Java, we learned about it for years, we ran it through the book Effective Java by Josh Bloch, and we got Kotlin out of it. It can be used for all kinds of different places — I’m spoiling stuff ahead of time — and it’s a really, really nice language with functional parts. It’s object oriented and has a bunch of time savers as compared to what we were using in Java.
Gavin Henry 00:21:40 I’ll add that book to the show notes if it’s still something you recommend.
Michael Fazio 00:21:44 Yeah, absolutely.
Gavin Henry 00:21:45 So why was Kotlin created and by who?
Michael Fazio 00:21:48 It always makes me chuckle because it was created by JetBrains, which is the company that makes intelliJ or WebStorm PyCharm, Android studio, which is a skin of intelliJ focused on Android development, and they’re like, all right, we want to a JVM language and we want something with more modern features than we get from Java. Scala’s got them except Scala compilation times are really slow. So, what is a developer to do? They create their own language because that’s what we do. We create our own things. And so, they built out their own JVM language — this is back in 2010, they kicked it off; they finally told about it in 2011. Version 1 didn’t even come out until 2016. So, it’s not a brand new language, but it’s fairly new if you’re looking at something like a Java that’s been around for 30 years and even C#, which is still newer than Java but still been around for a while.
Gavin Henry 00:22:44 Yeah, it’s younger than GO as well, which you always think is quite new.
Michael Fazio 00:22:48 And so it’s the, this new language they put out. I would say it’s like, it’s probably a little bit too of hey, here’s this new awesome JVM language. It works great in intelliJ, why don’t you buy intelliJ and use it with it? Which again, I’ve got my own library or my own license for intelliJ and everything. It does work great.
Gavin Henry 00:23:07 And what are the main benefits for us still doing Android and Java, which I presume you can do?
Michael Fazio 00:23:13 Yep, you can choose. If you want to use Java, you want to use Kotlin, you want to use both. For a little bit of history, in 2017 Google went at Google iOS like, hey Kotlin, this JVM language that’s out here just went 1.0 last year. You can use this just like you use Java in Android apps. It is a first-class language for Android development. Then 2019 they go, you know what, why don’t you go with Kotlin first? We’re recommending Kotlin as the main language because it offers everything Java does, but it has more features on top of it and also allows the Android team to put things in that are Kotlin-specific, which will end up working better. And I think there was a little bit of incentive for Google to say, let’s get away from Java and Oracle and everything going over here. Let’s go with this other language with a partner that works with us with JetBrains.
Gavin Henry 00:24:08 So more of a political type thing potentially?
Michael Fazio 00:24:10 I think that was part of it too, but it is, again, it is to me a nicer language to be using. And there’s a whole bunch of reasons for it. So, the number one I always love calling out is, they shifted to a system where null safety is built in, meaning a nullable object — something that can be null: So in in Java you have a string and that string can be any kind of text or it can be null. So, it’s kind of two different objects because it’s an actual value and then it’s nothing. In Kotlin, you have a string which is some text value, or you can have a nullable string, which means I know this could be null at some point. And Kotlin at compile time makes you go ahead and handle those null scenarios. And so, instead of it being, okay, I’m raining along and oh shoot, I don’t have data here and I’m expecting to have data and your app blows up, Kotlin’s making you handle all of those scenarios.
Michael Fazio 00:25:15 I remember working on a C# app and this was a flag you could turn on. I’m like, this is great. You’re not sitting there getting bit by null pointer exceptions in different places when really we probably should have been handling this in the first place. That null safety is so nice for the stability of an app. Like, from a security perspective it’s better. Like it’s a huge part of it. But in addition, there’s a lot less boilerplate when you’re dealing with Kotlin. This is something that when people come from other languages and they’re looking at Java, they’re like, there’s a lot of stuff you have to write to really get to what you want between the getters and setters and going ahead and having multiple constructors and all these pieces when it’s, it’s not really necessary. It’s not what you’re going for. You instead, with Kotlin can really get to things quickly.
,
Michael Fazio 00:26:05 You get data classes, which are your kind of a your POJOs, so your plain old Java objects that you’d have. Normally it’d be: all right, I’m going to have user object with 20 fields on it. Each one of those fields may have a getter and setter or at least a getter. And then I’ve got five different constructors based on where I want that to be. Instead, you go ahead in Kotlin, you create a data class, you have all those fields in the one constructor. If some of them are optional, you can go ahead and define a default value, and maybe it’s making them null and making them nullable fields. Or you can go ahead and just assign, if you’ve got a string, you’re like, I don’t want this to be null; I default it to an empty string and I really only have to fill in five of the fields, let’s say. It’s all this flexibility to give you one constructor, the getters and setters are generated for you. You can make multiple constructors if you want. You have that flexibility, but you don’t need to do it out of the box.
Gavin Henry 00:27:05 Touching back on the null safety part. That makes Kotlin potentially more secure, doesn’t it?
Michael Fazio 00:27:12 Yep. Because if you’re running through scenarios where you’re going through security checks and all of a sudden you get a null pointer exception in the middle that you’re not expecting and oh, I’m trying to check this up, I blew up. Well I guess my checks are fine because I didn’t finish them. All of a sudden now people are let through. It gets rid of these unknown scenarios, these scenarios you’re not expecting that would be there otherwise.
Gavin Henry 00:27:39 And it sounds like you should just start off with Kotlin anyway because you won’t have to do all the painful things you used to do in Java. Or still do. And can you use Java frameworks with Kotlin? The big one I remember is Spring that does pretty much everything.
Michael Fazio 00:27:54 Yep. There’s probably some scenario where you can’t use Kotlin with a Java app, but basically every place you use Java, you can use Kotlin now. So, talking about Spring, not only is it now, as of Spring 5, you add Kotlin as a dependency and you can do whatever you need to, but if you go to start.spring.io, you go to the Spring initializer, one of the options there is like do you want your app in Java or do you want it in Kotlin? And I think they might actually offer Groovy as well, if I remember correctly. But it’s seen again as a first-class language for Spring development. Now, I will say if you are in a scenario where you want to use Kotlin completely and you want some of the API features you’d get from Spring boot, you can go ahead and use something like Ktor, which is a JetBrains library that they’ve created, framework I should say, it’s fully Kotlin.
Michael Fazio 00:28:43 You can do the server-side; you can actually have a client as well that you pull out of it that will use the same types that are in there. It’s got web socket support, it’s got co-routine support, which we haven’t even touched on yet, for asynchronous calls. Like, all these really nice Kotlin features are just built into Ktor, whereas Spring was originally built more for Java. It may be missing some of those, but even newer versions of Spring offer some nice flexibility with what you can do with Kotlin there that you couldn’t do before.
Gavin Henry 00:29:12 It would be good if we can scoop this up in the show notes for some recommended libraries, you know, rather than people trying to find these all out.
Michael Fazio 00:29:18 Yeah, absolutely.
Gavin Henry 00:29:19 It’s a bit of a silly question, but is does Kotlin just for Androids operating system or?
Michael Fazio 00:29:25 It’s not, and that’s not a silly question because that’s where it’s been pushed a lot. I remember one of the first times I did a Kotlin talk, I was at that conference in Wisconsin, Dell’s here in Wisconsin, large regional tech conference. And I’m like, all right, I’m going to be talking about Kotlin, it’s going to be a bunch of Android people in here and I’ll just make sure I’m tailoring that to them. And so, I get in there and I’m like, hey, before we start, what do people work on? Who are my Android people? And I’ve got, I don’t know how many people in the room, a quarter of the people raise their hand for Android. Who’s doing JVM server-side development, and two-thirds raise their hand. I’m like, oh, okay, I need to tweak this slightly as I go here. Like I’m going to, we’re going to change this on the fly slightly because all these people on the Java side were like, well I can use this, right?
Michael Fazio 00:30:10 Like, this seems like this works. Is this going to be better? And so yeah, you can use it on, again, anywhere you’re using Java, you can use Kotlin. It’s obviously this first-class language now on Android, but if you’re doing Spring apps like we talked about, you can do it there. There’s actually the ability now on the client side to use this. And this is saying Kotlin can be compiled down into JavaScript, ES5 JavaScript. You can go ahead and you can compile it down. There’s a create React app version that is using Kotlin that’s out there that I think JetBrains actually created as well. You can go ahead and use Kotlin native to build things for Mac OS, and it works actually on iOS if you’re taking advantage of something like Kotlin multi-platform, which is a whole separate discussion. In theory — I haven’t done this– but in theory with Forge, which is a mod library for Minecraft, you can build Minecraft mods using Kotlin. It should work everywhere that Java is. And so, we look a lot at the Android side of things, but it is certainly not exclusive to just being on Android.
Gavin Henry 00:31:19 I heard you mention co-routines and that’s something that always pops into my head when I read or see Kotlin. Is that something that you could do in Java, or what are they, and why is it a good thing?
Michael Fazio 00:31:31 So co-routines, the very simple version is they’re what you use for asynchronous development. They’re kind of like lightweight threads, but in the background they’re really able to run in any type of thread. And so, from a practical perspective, they’re what you use now — because I mentioned before about async tasks in Android applications and you’re overriding a whole class and doing all this to really get like three pieces of code to work. Here’s what I want to do before, during, and after, that’s it. With co-routines you can say, all right, I’m going to go and run a co-routine over in my Android app, here’s my co-routine scope, I’m going to run X, Y, and Z functions. They’re called suspending functions. This is similar to what people think of as like Async Await in a C# or JavaScript. You have an async function, which is called a suspend function or a suspending function in Kotlin, you can run whatever you want in that co-routine block.
Michael Fazio 00:32:34 You have multiple suspending functions or nonsuspending even. They can run sequentially in the block. And then you can react to it something at the end. And that is going to be run on a different thread asynchronously on its own, which leads to a lot of models with Android where I make a call over here, I run something asynchronously and then I have an event listener to let my view know when the processing is done. And with using some of the libraries that are out there, that gets much, much easier. So, it’s this really, really nice way to handle asynchronous development while not having to worry about so many of the pieces where moving around you’re like, you’re basically just calling stuff sequentially, but in the background it’s running off your UI thread out of the way, and it does exactly what you need with it.
Gavin Henry 00:33:25 Yeah, it sounds a bit similar to isolates in Dart that I chatted about on a different show. And in Erlang and Elixir you’ve got the threads that run not as native threads, but kind of like co-routines, I think. And I don’t think I’ve asked, but we’ve stated that Kotlin was developed by JetBrains. It’s open source, isn’t it? It’s a free programming language; it’s not a proprietary one. Yeah, I thought I’d just highlight that. Okay, so just to finish off this section on Kotlin, unless there’s anything exciting that you’ve not thought to say. You know, when someone says, why should I use Kotlin? You know, there’s something on the list that hasn’t come out?
Michael Fazio 00:34:06 I mean I could go on for a while about all the reasons that I enjoy working with it. From my perspective, the lack of boilerplate — from just simple things like not having the new keyword when you create a new instance of something to the ability to create a top-level function. So, it just, here’s a file with functions that I need, instead of having to create a class every time, or the fact that you have extension functions and extension values that are available; some of the quick little extras they have of all right, I’m creating a list, I can just do list of here’s my values and it creates a list for me. Instead of having to go, okay, new list this, all right, add these things to the list. Little parts like that. Or the built-in functions like LET where you take some object and then inside a block it creates a new instance of that same object.
Michael Fazio 00:34:59 So if it’s a mutable object, I can be changed. You do let on it, it creates a new copy of it and then you can use it in there. And now that object is immutable, or you do a null check on that object and then you get a non-null version of the same one inside your block. So, it can be used for just making things cleaner into read or to do a null check. There’s a ton of standard functions that are built in — you know, your map filter reduce, but one’s like chunked where here’s a list, I’m going to split this up into little pieces and it’s already built in zip with next where here’s a big list and I’m going to put them in together in pairs. When I was doing advent of code with Kotlin this last year, it was like, all right, I can use all these crazy functions I wouldn’t necessarily normally use to try to get my data in the right spot and it works out great. So, all the things we mentioned, we’ve got all of this, there’s all these other pieces. It just, to me, the summary with Kotlin is there’s a lot less extra code I have to put into my applications. It gets very, very readable very easily. I mean, it can get very not readable if you’re not careful. I mean, that’s pretty much any language, but it ends being very readable, very logical, and you just, there’s less in your way and more focused on what you actually want to get done with the code.
Gavin Henry 00:36:16 I presume this makes working with Android a lot more enjoyable than coding with Java.
Michael Fazio 00:36:21 I certainly think so. I mean I think it’s a lot easier to kind of get through, especially given that there have been some libraries where they’ve added extension functions to built-in pieces of that are in the Android framework. So, for example, the old Java way of doing a click listener would be item dot set on click listener, new click listener override function on click. Here’s my logic. And with Kotlin it’s set on click listener, add a block. So just parentheses or brackets around it; your code that wanted to be run, that’s it. Like you’re getting rid of all these other parts. And so, there’s all these nice benefits to it. It just, it’s easier to read, it’s easier to get somebody in there. You’re writing less code and it just, yeah, it makes everything nicer. And I try not to bash on Java, like that’s where I learned how to develop. But there’s a lot of benefits to going the Kotlin route.
Gavin Henry 00:37:14 Thanks, Michael. I’ll move us on to talking about, Android Jetpack now. Just to close off this Kotlin section, why can you still develop in Java for Android then, do you think?
Michael Fazio 00:37:26 I think it just, it’s for backwards compatibility mostly because you’ve got apps out there that are written in Java. They’re not ready to go ahead and convert over a million lines of Java code to Kotlin. What they can do is say, all right, new development’s going to be in Kotlin, parts of it’s going to be in Java, and we can kind of have both of them here. And I think there’s a little bit you talk about, you know, we were saying before about the multi-platform tools that are out there saying, all right, maybe I don’t want to try to learn Swift and Kotlin, but we know C#, let’s use Xamarin. You know, we know web development, let’s use React native. In kind of the same way, people know Java, maybe we just want to stick with Java. I remember there was a survey a couple years ago and they said, hey, teams that went and had a Java Android app switched to Kotlin and then switched back to Java.
Michael Fazio 00:38:16 What happened? And like, the only reason that people gave was, well we didn’t want to learn Kotlin. Okay, maybe you don’t have time. Maybe it’s not the incentive, whatever it may be. It still allows them to go ahead and get these apps out there. I mean, there’s so many apps out there that are Java-only, you can’t drop support. What they are doing though is some of the new features in particular Jetpack Compose is Kotlin-only. You can’t use it with Java anymore. Much to the chagrin of some of the, the Java developers. So, they’re not maybe getting the latest and greatest, but there’s still so much of a Java based out there for Android that you can’t dismiss that; you can’t get rid of it because it doesn’t make sense.
Gavin Henry 00:39:00 Yeah, I understand that. I mean people don’t like change unless they’re forced to. So, it makes sense. Okay, thank you for that. Maybe Kotlin should be a complete show by itself. It’s obviously a lot to talk about, but let’s move on to Android Jetpack. What is Jetpack, and why was it created?
Michael Fazio 00:39:18 So Jetpack is a large suite of mainly libraries, but there’s also kind of guidance. I don’t like using the term best practices, but basically the idea of here’s ways we recommend dealing with your Android application. And it’s all these pieces that are created to make Android development better, easier, help with fragmentation, help with older versions of Android, help get rid of some of those pain points that we talked about earlier in the show. And so, and it’s Google’s official recommendation of ways to handle things. This also includes, by the way, like a full guide to app architecture, which in fairness, you look at and you’re like, well yeah, this is how you develop an application. You have your distinct layers, they don’t know about each other, but it’s really good to call out within an Android context and within the scope of Jetpack to say, hey, here’s the libraries, here’s how you can use those to get this app architecture that we are recommending.
Gavin Henry 00:40:20 Is it easy to describe the architecture on a podcast episode or. . . ?
Michael Fazio 00:40:24 Quick version is it’s like you have your distinct UI layer, which will have your main UI components and then usually a view model to handle what’s going into your UI. So, you have that separation of your activity or fragment that is displaying what you want. The view model that tells the view what to display, an optional domain layer that’s you know, your complex business logic, any business logic we use. And then there’s the data layer that is, all right, here’s some of the other business logic, a little simpler trying to get app access. This will usually have a repository or multiple repositories in there, and then some kind of data source — whether it’s a local database running something like Room, which is one of the Jetpack libraries or calls out to your APIs. And again, I feel like it’s a fairly standard way to look at architecture of here’s my layers. UI is only focused on UI, your middle layer to really kind of navigate things around, your data layer to figure out where things are coming from and going, and making sure each of the pieces are stand-alone, not needing to know about the other ones at all.
Gavin Henry 00:41:37 That’s a bit more than your traditional MVC. And then you’ve got your model view-view model sort of JavaScript framework style like view. Is there an acronym for this at all?
Michael Fazio 00:41:50 I just, yeah, it’s an MVVM setup. MVVM, just like you described.
Gavin Henry 00:41:54 Yeah, MVVM, Cool. I got that right. That’s good. Okay, so just to summarize to make sure I understood that, Jetpack is a set of libraries to help you get around all the traditional problems faced with Android mobile development, as recommended by Google.
Michael Fazio 00:42:10 Yep. It’s all these tools to make development smoother and make things make a little bit more sense. I mean, we’re talking about there’s over a hundred libraries that are part of the general Jetpack umbrella. It’s also referred to sometimes as Android X because that’s the package name for it is, alright, Android X dot, whatever you’re dealing with.
Gavin Henry 00:42:33 I’ve seen that. Sounds familiar.
Michael Fazio 00:42:36 Yep. And so, you’ll see Android X out there,
Gavin Henry 00:42:38 The Jet.
Michael Fazio 00:42:39 Yeah, And so, there’s a bunch of pieces within Jetpack Android X that are either the libraries for this or they might be Kotlin extensions to make existing parts easier. I mentioned about the ClickListener, that’s part of Android X as well. There’s a whole bunch. Yeah, it’s all these different pieces you can put into your app to just make things smoother and easier to deal with.
Gavin Henry 00:43:00 And does Android Studio, is that the default to go for that makes this all easy? The Jetpack IDE?
Michael Fazio 00:43:08 Yeah. I mean anytime you’re doing native Android now you’re going to want to be in Android studio because they’ve got the tools in place that you want. They continue to upgrade it. They just had it recently where you can go and you can bring up access to your database and do network tracing, or look through the files on your device, or even just one recently it was, I have a physical device I’m testing on, I can do screen mirroring within Android studio. So, I have a physical device I can use and get all the benefits from that, but I can still see it on my screen and use my keyboard and all of that. And it’s all just built in Android studio. It’s very, very handy.
Gavin Henry 00:43:49 Yeah, I really like Android studio as well. It actually made me go out and get a Jetpack subscription for some of the other programming languages, as well. So, I didn’t want to shift back to nothing wrong with them, you know, I’ve used that for decades. But yeah, it was something nice about all the shortcuts and everything. Okay, so I got the summary of Jetpack, correct. So, set of libraries recommended by Google to make Android development easier, which is Kotlin. So, what is the infamous Jetpack Compose, and why is it so cool?
Michael Fazio 00:44:17 Well, the funny thing about Jetpack Compose is it’s part of this Jetpack library set, and it’s a way to go ahead and handle your UI within code. And so, now you remember there’s a little bit of confusion about, okay, Jetpack, well that means Compose, right? No, no. Jetpack is all these other pieces that are out there. Whereas Compose is just — not just, but — is the UI in your code, as opposed to using XML.
Gavin Henry 00:44:47 That’s what I thought as well.
Michael Fazio 00:44:49 Yeah. A couple things with just normal Jetpack that I want to mention. Because if somebody’s coming in going, okay, there’s a ton of libraries, like where do I start with this? Like, what do I use? There is an app called Sunflower that Android created — or the Google team created the Google created Android team — for highlighting Jetpack, including now Compose by the way, where it says, all right, here’s all these libraries, here’s how you can use them, here’s the benefits. We can give you the link for that. We can post with the show notes, but you can download it, you can start messing around with it. It’s updated constantly, it seems like it’s a nice. Fairly simple app highlighting all these things you get.
Gavin Henry 00:45:31 I’m quickly giggling it in the background. I can see it’s got 16 and a half thousand stars and yep, some commit two days ago. So, it’s very active.
Michael Fazio 00:45:40 Yeah, really, really handy to figure out, okay, what’s out here? What can I use?
Gavin Henry 00:45:46 Excellent. So, it doesn’t use XML.
Michael Fazio 00:45:47 Well Sunflower, unless they completely converted it over, still does because it’s, most apps are still running XML. That has gotten easier with Jetpack, as well. When you’re going ahead and you’re trying to grab components out of there. Jetpack offers both data binding and view binding, which are ways to easily access components within XML. All right, I’m going to use data binding, which is, I’m going to send some object or objects into my view. And then inside the view I can use a certain syntax to reference values that are in my objects that are here. And that could be a view model, that could just be a couple of classes, whatever it may be. Or I can use data binding and say, all right, here’s my binding, I’m going to reference this component and this component from my view and assign it values. So instead of having to like do a lookup based on ID for all your components in your UI, then start assigning values and everything, you can use one of these to get at it more easily. Now again, if you’re doing Compose, you’re already in your code, you don’t have to try to do some kind of extra library to buying stuff together. You can just say, all right, here’s my composable send in data and I’ve got everything I need right away. But for most apps that are still using XML, Jetpack makes it easier. And I think Sunflower should highlight all of that still. I can’t imagine they got rid of all of it at least.
Gavin Henry 00:47:12 Thanks. And so, what’s the strap line for Jetpack Compose? Because I’m thinking of the word declarative, but I can’t remember if that’s right or not.
Michael Fazio 00:47:20 Yep. I, it’s, yeah, it’s a declarative UI toolkit. The way I always describe it to people, I’m like, all right, imagine React. So, the JavaScript framework from Meta or Swift UI, it’s the Android version of that. Yeah, I remember.
Gavin Henry 00:47:35 Yeah I remember that as well. It’s the same.
Michael Fazio 00:47:37 Yep. Same idea. And I remember going through, because I’ve done React in the past, so that’s why it was the first thing I thought of. I was going through a tutorial and they got to one part where it was like, all right, we’re handling some of the state here. And I’m like, oh, this is React hooks. Like this is the exact same code in Kotlin that you would do in JavaScript for a hook. I get this. Okay, cool. I can do that this is easy enough. And so instead of, having your, here’s a full XML file and here’s your UI, again, you can reuse components within XML. You have to remember if it’s include or merge or whatever you may need; with Compose, you’re splitting everything up into small pieces. You’ve got your little composable and you’re saying, all right, here’s my composable made of multiple composables, made of more composables, all the way down as you want. And then you lay everything out that way.
Gavin Henry 00:48:32 Yeah, I think that’s similar to Flutter with widgets.
Michael Fazio 00:48:35 Yep. That makes sense.
Gavin Henry 00:48:37 And components in the JavaScript framework.
Michael Fazio 00:48:41 Absolutely. And you’re end up with this unidirectional data flow with the different composables, and so you’re, you’re sending state into — and composable for reference are functions — and so you can send in your parameters to that function. Again, looking very React like, saying, here’s the state I have, here’s all my objects, here’s everything there. And then sending events back up to the parent.
Gavin Henry 00:49:06 So the state floats to the top. Yeah, that’s similar to the rest of them. Yeah.
Michael Fazio 00:49:12 And so you can go ahead and you can have all these parts here. You’re sending data in, you’re doing events out. Again, the nice part is, they didn’t go ahead and come up with some crazy new paradigm. Like, it’s things we’ve seen before. It’s a general approach that works, that’s logical for people. It makes a lot of sense. So, it’s easier to get into than it could be otherwise.
Gavin Henry 00:49:34 So, would you recommend to start looking at Jetpack, Compose part of the Jetpack, set of libraries first and then work backwards, when you’re thinking about a traditional Android app versus the Jetpack way?
Michael Fazio 00:49:47 I think so. I know that’s Google’s recommendation, and they’re like, this is the way we’re going. We want to use Compose for everything. But to me, if you can say, all right, my logic’s in the code, my UI is in the code, everything’s within Kotlin. As opposed to, oh wait, but I’m in here but I’m jumping out to this layout XML and I’m also looking at this, you know, the string XML over here and the dimension XML over here. Like you know, you can still use some of those if you want, but if you can keep your layouts and UI together, it’s going to make things a lot easier. And if you’re new to Android and Kotlin, it’s a lot less that you have to deal with. And again, it’s just, it’s nice to use anyway. I almost feel like, in a way, it’s easier just to come in fresh and just go with Compose.
Michael Fazio 00:50:34 Because I know for me, like I was using it a little bit, I understand a declarative UI and I was still going, okay, so I develop it like this and this isn’t an XML file. I don’t do it the same way as I always have just because it’s Android. I need to think about this a little differently. So, with coming into it fresh and just doing the Compose part, you’re not kind of breaking bad habits that pop up when you’re dealing with Compose. Now again, tons of apps out there are still using XML. If you’re looking at this from a professional perspective, you need to be aware of how the XML works. But if you have the choice, Compose is the way to go both from a just realistic usability perspective and a Google recommendation perspective.
Gavin Henry 00:51:16 And what would you say to people that have tried to create an Android app before Jetpack versus what it’s like now? Just come on in and have a go?
Michael Fazio 00:51:25 Yeah, absolutely. It’s a much different environment. That was, I mean, that was part of the reason that I wanted to, I split the book like I did because I knew, okay, I love what I can do with Kotlin. I’ve done Android forever, but I’m like, I’m going to go ahead and kind of focus on Jetpack because it’s all these different ways that Android dev’s gotten easier. And for someone coming to new that maybe doesn’t have that experience of doing Android dev with Java and before all these libraries are here, they won’t know any difference. But it should be, okay, this makes sense. It’s a little weird that I’m over in XML, but all these pieces make sense. This isn’t too bad to deal with. And you know, if you’ve heard, okay, it’s scary. It’s way better now; if you haven’t heard that, it’s still a nice experience to go ahead and be in Android ecosystem with, even if you’re just looking at XML and Jetpack, way better with that. If you are using Compose, it’s even smoother in a lot of ways. It’s not perfect Compose is still, I believe it’s fully released now, but like it’s going to change. There’s things they’re going to tweak, but it’s so much nicer than it was in 2017, 2018 versus now.
Gavin Henry 00:52:37 So just to summarize that section, it’s a recommended way to develop a UI now.
Michael Fazio 00:52:43 Yes.
Gavin Henry 00:52:43 Go for Jetpack set of libraries first. More than likely, go for Jetpack Compose straight away. It’s made the ecosystem much nicer to work with than what it used to be — even five years ago. It makes things easier because you don’t have this complete separation of concerns with the look and feel it in the XML that you’ve got to tie back to data and IDs and tags and things and struggle that way. And as we all know, because we’re all developers, nothing’s perfect. What common mistakes should we be avoiding with Jetpack that you’ve come across that you can recommend?
Michael Fazio 00:53:20 I think there’s always going to be some. I think a lot of times it comes down to, understanding your application, understanding your use case. We have an example — I’m thinking about our current app — where our signup flow is dynamic, our backend controls it. And part of my brain’s always like, well we should use the navigation component that is part of Jetpack, because with that, instead of having to manually swap out fragments and do all this stuff, you create a navigation graph and you can jump between points. It’s a really nice tool. It works great.
Gavin Henry 00:53:53 The fragment is it something on your screen.
Michael Fazio 00:53:56 So fragment is — and this is something that I’ve slightly alluded to earlier, but not much — of you have your main activity and then a fragment is just a view component that you’re using there. You can have some logic and everything, but it’s a lighter weight view than you’d have for an activity. And so, one of the recommendations from Jetpack is create an activity and then use the navigation component to swap between fragments to get to all the areas you need. And so, it’s these view pieces that you’re using within your app to show whatever it is. It’s like, you know, really it gets a point of your activities, like your main app, which has a container, and then your views are all fragments. That’s the recommended approach now. It’s easier to deal with all of that’s there.
Gavin Henry 00:54:43 And going back to your navigation signup example.
Michael Fazio 00:54:46 Yep. And so, with that, we’re in a situation where, okay, we want to have it where we’re showing all these different fragments. We might be jumping to other parts of the application, different activities that are separate scopes for what we’re dealing with. Because in a lot of cases it, it ends up being nice to say, here is a flow within my app. That can be an activity because it’s its own kind of an isolated piece. And then I’ll use multiple fragments for the whole flow. With having that dynamic ordering that we might have, anything could be in any order really based on what we get back. With the navigation component, you normally would say, all right, I have all my destinations, so those might be fragments or activities. I want to go from this one to this one, which is an action, so that navigation move is an action there. And I’m going to define that within my nav graph.
Michael Fazio 00:55:33 If you have a consistent flow, it works beautifully. You can send parameters, you can get type-safe values out of it to say, all right, I’m going from A to B and I want these three parameters in the new one. I just say, hey, give you my arguments and I’ll use them in that view. It’ll be great. We can’t do that. With that signup flow, we’re like, all right, we’re going to just avoid using the navigation component because it doesn’t make sense for our use case. Even though it’s kind of like that startup flow, that onboarding flow, is exactly what we should be using in a navigation component for, our use case doesn’t make sense. So, I think with all tools, make sure you are trying to solve your problems and using the tools to do that rather than, here’s the tool I should use, let’s figure out where I can fit it in. So, making sure you understand what your app needs and where you need to go.
Gavin Henry 00:56:28 Thanks for that example. I’m presuming there’s some design patterns that are on the Jetpack tutorials and Google websites. What I’m trying to allude to is, is the decision of how to put things together made simple for you? Or do you have to decide, you know, we spoke about managing state between the different parts, Jetpack, Compose. Do you have to figure out, do I want that state management library from these 10? Or you know, are there some best practice design patterns we can just not spend any thought on say, right, let’s go for that. But given your example of the navigation component, then maybe some of them don’t fit and you, you still have to figure out your use case.
Michael Fazio 00:57:11 Well, I think that’s, that’s always the case when you’re developing an application. You have to use it, or look at how you’re going to use it, what makes sense for you. That being said, and I remember watching one of the videos and the team from Android were saying, we try to leave things nice and open for people for a while to say, all right, do what you want with this. We’ll give you the tools, we’ll let you go ahead and decide what’s best. And they said, you know what? It works better for us to be a little more opinionated. And I think that’s what kind of spurred the architecture layout that I suggested before. It’s what recommends, all right, we’ve got X, Y, and Z library. You know, you’re going ahead, you’re doing interactions with the database, just use room and be done with it.
Michael Fazio 00:57:56 Go in and that’s the, it’s an effectively an ORM over SQL light that’s built into a device. And so it’s a way to say, all right, instead of running queries or whatever, I need to, I can say, here’s a quick SQL statement, it’s on a function and I can go ahead and return something like live data or a flow from my database, which you can think of as: I’m going to create a tunnel and then when something happens, I’m going to send data down and then react to it later on in my application. But they’re like, just start with room. Like do that for any local database, and that’s what you want to use. We’re not going to go and say, well we could do it this way or this way. You can do it the old way. Here’s the way to approach it. If you’re going ahead and you’re dealing with fragments, you probably want to have a view model.
Michael Fazio 00:58:41 Here’s how you go ahead and you can use it. You know, you want dependency injection, there’s other libraries out there, but we’re recommending you use Hilt, which is based on a library called Dagger that Square came up with. There’s all these different tools and they’re like, here’s what you need to do. Here’s the library you can use. Go ahead and bring it in. If you really want to, do whatever. Like, you have to look at your own cases, but they’re going to say, here’s probably where you want to start. Do what makes most sense for your application. But this is really probably your starting point.
Gavin Henry 00:59:13 Jetpack sort of consolidates all that. Cause one of the time-consuming problems with most frameworks and ecosystems is right, that looks like the right thing to use, let’s go and check out the source control, see how active the project is, you know, see how many issues it’s got open. Hopefully Jetpack makes that all so much easier you can just say, right, if that does what it says on the 10, I can presume it’s going to be stable. I presume it’s going to be around for at least the next three to five years that I need to support our commercial app or apps.
Michael Fazio 00:59:44 Yep. And it’s, it’s all out there. And the thing that’s nice about the Jetpack libraries is they’re versioned independently. I think I had mentioned this earlier, but if you say, all right, I want to go ahead and I want to add in, let’s say I want to add room and I’m adding work manager for background scheduling, and I want the navigation components, and some of the Kotlin extensions for fragments and view models and all these pieces. I can bring those all in to my application. They can be on their own version. So, let’s say, all right, I get everything in here and then a new version of room comes out, but I’m not ready to grab it yet. I can leave it alone. Oh, I want an update for work manager. I’ll just update work manager and I’ll call it good. They’re all these separate pieces that are out there. And so, they are very clear of, okay, this is a stable release, this is a beta release, alpha release, whatever it might be. But they’re all out there, they’re all versioned independently, and they’re all available for what you need. What’s shifted, even from when I did the book of, here’s the pieces we’re focusing on with Jetpack, the old libraries are still out there, they still work, they still do what they need to; there just hasn’t been a need to expand on them.
Gavin Henry 01:00:56 Was there a problem with versioning things before Jetpack?
Michael Fazio 01:01:00 Well, what would happen is, a lot of times you would have the support libraries for Android and those were more tied to a particular version of the OS and like, okay, here’s where we’re backporting things, but it was like, here’s the whole support library. What if I just want the newer part of this section but not this one. Now it’s split up into smaller pieces, so you can get exactly what you want, but you don’t bring in like you don’t bring in Jetpack, you bring in all the pieces that make sense for your app. Because if you’re bringing all of Jetpack, all of a sudden your app’s way bigger because you have all these extra libraries and things that you don’t need. And so, you can have those pieces separately. You can version them separately. So, you upgrade when you’re available, and it puts you in as the developer more in control of what’s going into your app and what you’re using.
Gavin Henry 01:01:50 Yeah, and size is a concern for shipping across the network and things from play. That’ll get you into trouble. Okay. I’m going to start wrapping up the show. So, it sounds like Jetpack is a safe bet to choose for your next Android application. Do you agree?
Michael Fazio 01:02:06 Absolutely. Jetpack, it’s going to keep evolving, it’s going to keep changing, but the architecture they recommend, the tools they recommend make a lot of sense for even a new application right now
Gavin Henry 01:02:17 And Jetpack Compose is that something, is another safe bet?
Michael Fazio 01:02:21 Absolutely. The team is saying, this is where we’re going, this is what we’re going to have. This is the way we want you to write UI going forward. We’re done with the old XML style — like you can still use it, but the new effort that we’re putting in is focused on Compose. And so, this is where you’re going to want to go for native development for quite a while.
Gavin Henry 01:02:42 Excellent. Thank you, Michael. So, I’ve got one last question I’m going to sneak in before I properly wrap up. This is from one of our co-hosts. When an organization is also making an iOS app — which pretty much everyone has to do — is there anything they do differently to be able to share code or logic which may also affect how they build their backend? So potentially, maybe your backend’s an API, you know, and you’re calling into it from Android or Jetpack or iOS. Have you got an experience with that?
Michael Fazio 01:03:12 That’s part of what we’re doing right now with the current app. We’ve got an Android app, we’ve got an iOS app, we have a backend, we have a smaller web app. And one of the things we try to do is any logic — because we have feature parity between both platforms. A lot of places are going to be just like that — as much as we can, we try to put our logic in the backend, in our APIs. And so, a little bit how you’re developing your Android app where it’s like, here’s my view and here’s my view model. And I just know, all right, I ask for data, it gives me it back, I’m not worried about where it’s coming from, how it’s being dealt with, what the rules are, anything like that. I just say, here’s my state, here’s what I need. Send that to me.
Michael Fazio 01:03:56 We do something similar where we say, hey backend, here’s what I need. Here’s where I am right now. Or in a lot of cases, you already know where I am. Here’s who I am, you tell me what I need. And then, they send us the logic. And so instead of Android and iOS each having to try to deal with all these complex business rules based on what we know about a user, we let the backend take care of that. Now, if you want to go more direct and say, all right, we really just want to share logic that’s coming on, we want to share data coming from the backend, whatever it might be. Maybe you start looking at Kotlin multi-platform, which is a little different than your cross-platform libraries in that you can use Kotlin multi-platform to more or less build a separate library that works on Android and iOS, and you can fit it into both applications. And so now you’ve got one spot where maybe how you hit the backend is there, or how you grab language values from the backend is in there, and that can be shared as well.
Gavin Henry 01:05:00 What sort of things do you ask of your own backends if you’re allowed to say?
Michael Fazio 01:05:05 In particular, when we’re dealing with language, we allow the backend to determine how things are written for us, which has a couple benefits. One, it makes it easier for Android and iOS to just say, oh, you’ve got X, Y, and Z copy. You go ahead and send it to me and we’ll display the language that you gave us. We don’t have to worry about anything other than here’s a key for the language coming in and I’m going to display it. Also, if we’re in a situation where, and again, talking from a financial perspective, we have to be very careful about how we say things from a legal side. If something needs to be changed like immediately, it’s hard to go ahead and get a new app version out. It’s not hard, like it takes a day or so, but you can’t do something quickly. If that’s on the backend, we can update it faster.
Michael Fazio 01:05:57 Plus if we say, all right, we’re going to update this language and we’re going to have it for all these versions of the app; you change that in the backend, we don’t have to make app updates and people that already have the app will now see the new language, they’ll see the new logic. The apps are a lot more static than a backend can be because you’re not in control of it. It’s on someone’s device. You can kind of force them to upgrade, but like it’s not a guarantee that you can go ahead and say, hey, you need to have this version of the app because we want this thing. They’re like, well, I’m just not going to update right now because I don’t feel like it. Unless you want to lock them out of the app, you don’t have a lot of control. If you can instead have the backend control, all right, here’s a new feature, here’s new language, here’s again how that signup flow works. I can go ahead and I can turn pieces on and off of the signup flow without touching the app. It makes it a lot easier to test things out, make updates, and really get the experience that I want for users very quickly without needing them to do anything.
Gavin Henry 01:07:01 Yeah, so it’s part of your architecture design, your business logic, or business use case type thing.
Michael Fazio 01:07:07 Exactly.
Gavin Henry 01:07:08 So I think we’ve done a great job of covering why you should develop software natively for Android. Just to summarize that again was, you know, your teams, your expertise, devices you’re going onto et cetera and why you used Android Jetpack in the first place. But if there was one thing you’d like a software engineer to remember from our show, what would you like that to be, Michael?
Michael Fazio 01:07:31 I think it’s just Android development now is a really, really nice experience. Like, it’s not perfect. There’s quirks, there’s weirdness, but it’s gotten really, really good. Kotlin is great to work with and some of the headaches that people may have talked about in the past or may have, you know, the horror stories that were being told. A lot of those are gone and at the end of the day you get to sit here and have a mobile device and create really, really nice powerful apps for that device for people to use. And you can do it in a way where you know, you’re not always pulling your hair out because of let’s say, limitations within the framework. So, I’d say Android development now it’s in a really good spot. It’s really enjoyable. Kotlin enables a ton of that. Jetpacks made things better, composers made things even better from that and so it’s, it’s a really nice ecosystem now.
Gavin Henry 01:08:26 Thanks. I think that was more than one thing, but that’s good. Was there anything we missed that you think we should mention?
Michael Fazio 01:08:35 Again, probably one of those I could go on for another 45 minutes, but I think we definitely covered it. Yeah, so you’re getting into Android use Kotlin, use the Jetpack libraries, use Compose, and you’re going to be in a good spot going forward for quite a while.
Gavin Henry 01:08:49 Yeah, I’ll make sure we get the Sunflower app link in the show notes and some of the other stuff we’ve spoken about touch up after. So where can people find out more? We can follow you on Twitter, but you know, how should they get in touch if they want to drill you about anything?
Michael Fazio 01:09:03 So, I’m on Twitter as @faziodev and otherwise the book is available at pragprog.com, so you can go on there. Should be able to get a coupon code onto the show notes as well. I’m going to work with the team to make sure that’s available. And then otherwise just the developer.android.com has a ton of resources there. Go there, check out the documentation, check out Sunflower, go through the code labs. There are code labs for Compose and a bunch of the different Jetpack libraries. There’s ones on co-routines. All these different little hour-long mini classes that you can download and walk through and get your Kotlin skills, your Android skills improved just from walking through those. I think those are all great tools that are out there for people that want to learn more about Android.
Gavin Henry 01:09:57 Yeah, it’s really rich. I’ve looked at some of myself, but personally I would buy the book. Definitely buy the book .
Michael Fazio 01:10:03 I’m biased. But yeah, I think it’s great.
Gavin Henry 01:10:05 Michael, thank you for coming on the show. As always it’s been a real pleasure. This is Gavin Henry for Software Engineering Radio and thank you for listening.
[End of Audio]
