44: Tips for Building Android Apps
Published September 1, 2020Run time: 00:22:17
Building an Android app requires overcoming several idiosyncrasies. Tim and Rob share their tips for building Android apps so you can successfully navigate Google’s unique requirements. (If you’re looking for tips around building iOS apps, check out the previous episode.)
In this episode, you will learn:
- Why to start on your privacy policy before your app launches
- How Google’s developer fees differ from Apple
- Which Android devices are best for testing your app
- What Material Design is
- What fragmentation is and how it affects testing
- How many Android operating systems and devices you should support
- Why a crash reporting tool is even more important in an Android app than an iOS app
- Ways to distribute beta builds
- Why you probably don’t need to know what Gradle is as an app owner, but we’ll tell you anyway
- How the Google Play Store works for releasing and updating apps compared to Apple
- Why your app won’t look exactly the same on Android and iOS
This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.
Recorded August 13, 2020 | Edited by Jordan Daoust | Produced by Jenny Karkowski
Show Notes:
Previous episode: Tips for Building iOS apps
Episode Transcript:
Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non-technical look at all things technical. I'm Tim Bornholdt.
Rob Bentley 0:06
And I'm Rob Bentley. Let's get nerdy.
Tim Bornholdt 0:21
So last episode, we covered some tips just for building iOS apps. And on this episode, we are going to do the same thing but for Android. Right, Rob?
Rob Bentley 0:32
That's exactly right. And boy am I excited.
Tim Bornholdt 0:38
You're just jumping out of your chair. I can feel it.
Rob Bentley 0:40
Yes, I am.
Tim Bornholdt 0:43
So again, we kind of touched on this at the beginning of the last episode, but you know, we at the JMG, we focus on native app development, versus hybrid app development. And hybrid apps are where you can kind of write the code one time and then have it run everywhere. But we like to get down into the nitty gritty with each operating system, so you can have a experience that's tailored right for the user of an Android phone or an iOS phone. So a lot of these tips will still apply if you're doing a hybrid app. But just be aware that when we're talking, we're covering mostly native apps.
Rob Bentley 1:18
Right. So before you get started, there's going to be a few things that you're going to want to think about. First is you'll want to get in touch with a lawyer to get your privacy policy started. They're required for all apps to be on the Play Store. And not only should you have one because you legally have to have one, it's also just a goodwill thing to do to let users know what you're doing with their data and what your policies are on their privacy.
Tim Bornholdt 1:42
Yeah, and you won't probably be able to complete your privacy policy until you get closer to the end because things change. You might need to collect more data than you thought or less. And you might incorporate other third party services into your app that you didn't think you would need to before so at least make sure you have the ball rolling so that you don't get to the day that you want to actually ship your app to the store and then have to scramble and get a lawyer. I'm sure that they're not cheap to get last minute.
Rob Bentley 2:10
Right. They can work on their own time sometimes. So if you want to have it ready by the time you're ready to launch, you want to start thinking about it well before you're at that point.
Tim Bornholdt 2:19
Another thing you're gonna want to get on right away would be creating a Google Play Developer Account. We talked again last week about Apple, how it's $99 a year. With Android and with Google, it's only $25 one time and then that's it. You've got an app. And you can be a business; you can be an individual person, doesn't matter. But that's all it is. So it's a little easier to get access to the Google Play Store.
Rob Bentley 2:44
Right. And this is where your developer will go through and add screenshots for the Play Store and your content ratings. And just all the stuff you have to have before you'll be allowed to actually put an app on the app store so getting this done sooner rather than later is also a good idea just so all those set up things can be done before it's actually time to launch your app.
Tim Bornholdt 3:05
And it's good for you to also click around as a product owner to just be more familiar with the Google Play Developer Console. Because there's a lot of weird quirks and little things that you can do and a lot of settings you can tweak. So just having some time to play around with it and ask questions and get comfortable with it is going to help save you a lot of time in the long run, so you're not scrambling at the last second if you want to change something.
Rob Bentley 3:28
Right. So hardware that you'll want to have, if you're really going to try to get nerdy about it, the program that is used to develop Android apps is Android Studio. There is another one called Eclipse that was used a long time ago. It still works. But most Android developers use Android Studio as it's more modern and built by Google for the specific purpose of developing Android.
Tim Bornholdt 3:55
And it works both on Macs or PCs. If you're building just an Android app, then it really doesn't matter if you get a PC or a Mac. But if you're going to build iOS apps as well, if you're involved with that, then you might want to get a Mac because it again, it runs on both. And then that way, you'll also be able to run iOS builds. And if you get more comfortable with compiling code and things like that, it's just nice to have a Mac right out of the gate.
Rob Bentley 4:20
As far as devices to actually run your Android app, what you're going to want to do is get a few different devices. Android devices are generally cheaper than iOS devices, it does depend on which ones you get, but in general they are, so you can go out and get a few different phones. What you'll want to do is get a couple of older ones on eBay and a couple of newer ones. Try to get different screen sizes and different brands, because those can all make a difference with how the app performs and works.
Tim Bornholdt 4:51
And we'll get into the fragmentation issues with hardware a little bit later. But you know, good testing devices, we have found good luck with Google Pixels. Like, you gotta have some of those laying around. And also Samsung devices, you need to have some of those laying around.
But yeah, another tip that I use with Android, if I need to get a new Android device and I'm not too concerned about running the latest and greatest is just going and getting, I guess what you'd call a burner phone, like one of those prepaid phones. You can pick one up for 99 bucks, just take the sim out of it, and then you're good to go. And if you want to test with cell then you just can pop the sim in and pay as you go, though. That tends to work really well for the Android side of things.
Rob Bentley 5:35
Yep. And just like the App Store, there are guidelines for what you can actually put into the Play Store. It's generally a little bit looser than Apple, like Apple has a ton of things that they look for in review. The Play Store still has some but it's not quite as extensive as Apple so it's a little bit easier, but there are still things that you need to look out for that they won't allow in the Play Store.
Tim Bornholdt 6:02
It seems the things Google really cares about would be things that would relate to their core business of advertising. So making sure that your app doesn't like, you know, cheap any advertising systems or do false positives for clicking on ads or anything like that. That's kind of the stuff that they really are looking for, versus, like, Apple tends to be more editorial of like the content that's in your app, and making sure your app actually looks good. Because you can look through the Google Play Store. There's a lot of crap on there. And crap by like, it's just garbage stuff. It's kind of a pro and con of going for iOS or Android. That's just one of the advantages of being on Android is if you're gonna put out quality software, it's one less hurdle that you have to jump through is having to go through all the review process that you do with Apple.
And another thing too is, Google really has invested in automating their testing. It's not like you can just put anything on to the Play Store; they have a really good automated suite that will check your app for malware and different things like that. And Apple's kind of moved into that front as well. But that's just one thing that I've noticed over the years is Google's really good at their automated testing. So that's why they don't really have a whole lot of eyes on it, if that makes sense.
Rob Bentley 7:20
Yep. And if you listened to last week's episode, you'll remember we touched on the human interface guidelines for iOS. If you're really trying to knock it out of the park by building your Android app, you're going to want to take a look at Material Design and make sure that your development team or designer, whoever you're working with, when they're building out the design for your app, that (A), it's not only just an iOS design, but (B), that they're thinking about material design as well.
Tim Bornholdt 7:48
Yeah, material design is really, really fascinating. And there's a lot of theory behind it. Just like when you're doing the human interface guidelines. There's a lot of theory behind that. But within Material Design, it's really focused on making your app work right and look well on all kinds of different devices, like all the way down to a watch, all the way up to a TV. So take a look and it helps you kind of adapt your mindset as a product owner as to what people on Android are expecting and how they expect your app to work as opposed to iOS.
Rob Bentley 8:22
And as we touched on earlier, too, with wanting to buy a variety of devices. That's because of something called fragmentation. And fragmentation means that there's a ton of devices worldwide that can run Android and things might not work the same from device to device. And this could be either software or hardware. Actually, some Samsung phones will have different cameras than the Pixels and just the way their OS and software is built can sometimes cause changes. And there's a lot of things skilled or experienced Android developers are used to doing to make things, really, a one size fits all so that it works on as many devices as possible. But it is something to be aware of is that Android does take longer to test. And sometimes you do have to put things out in the wild to catch certain things just because of the fragmentation around it.
Tim Bornholdt 9:21
Yeah. And when we're talking fragmentation, like Rob said, it's hardware and software. When we were talking about iOS, we were saying you can really support the latest one, and maybe one back and you're going to get more than 90% of iOS users. But on Android, it's like, to get 90% of Android users, you need to go like five or six versions back to get all of them. And a lot of that is because the device manufacturers, you know, don't really have an incentive to let you upgrade to the latest version of Android. Their incentive is to get you to buy new hardware. So like the Pixels, that's why I recommend getting a pixel for one of your main testing devices because Google has an incentive to let you keep upgrading, and so Pixels tend to last longer in that regard. But a lot of device manufacturers, they might support one new version of Android but then after that, you're kind of SOL and just need to really buy a new device to get the new software on it. So that's one of the the main differences between developing for iOS and Android.
One other thing that we found interesting. We had a project a while back where we kept seeing that when you take a picture with the camera, that on one very specific phone, the image would be rotated 90 degrees from what you were expecting it to be. And it ended up, the way that the hardware manufacturer, like they get specs for putting it in the right way, but they mounted their sensor in the phone at like 90 degrees rotated. So there was like no way to know that unless you had tested it and caught it in the wild and on some of our devices, some of the apps that we have, you know, they have like 20 to 40,000 different types of devices working with them. So it's like Rob said, there's no way to test and catch all of them, just from our testing perspective. We can get a good idea of it working if we have a few different devices from a few different manufacturers. But sometimes you just have to, because of the fragmentation issues in Android, you kind of have to throw something out in the world, and make sure when you hear back from crash reports that you're monitoring those and fixing them as they come up.
Rob Bentley 11:31
Right. And when we talk about crash reports, we're mainly talking about Firebase. It was Crashlytics. And then it was Fabric. And now Firebase has acquired it. So that's the same thing. It's just now owned by Firebase. But that's a specific crash software that your developer will install. What this does is when there is a crash out in the wild, it helps the developer know what file and line number the crash happened on. Just so it makes it a lot easier to figure out where things went wrong that we didn't catch in the QA process.
Tim Bornholdt 12:05
Yeah. And if you listen to the last episode, we went into better detail about crash reporting software and the importance of it. But as important as it is for iOS, it's, I would say, way more important on Android, because there's just way more variety out there that it's helpful to have useful examples from working devices that then we can go in. And the cool thing with Android Studio is you can simulate devices from within there, and they have a very wide range. I would not guarantee all of those types of phones are in there. But they cover a pretty wide range of hardware configurations that they can emulate from software. So we can catch certain things from a simulator standpoint, but it's still, you know, the combination of real users using real phones. You can't beat that whenever with the simulator. So that's why we make sure that there's always some sort of crash detection software included inside an app.
Rob Bentley 13:04
We definitely make sure we try to catch everything before it goes out. And that's just not always realistic, sometimes, just because of the sheer number of devices and combinations of software and hardware put together. But when we put those out, there's a couple of different ways that we can distribute Android apps for you as a product owner to test. The preferred method is, Google Play actually has a beta program. So what happens is, you'll collect the Gmail addresses that you want to use, and then you'll receive a link to opt in. And then you'll just go to the Play Store like you would for any other app, and you're able to download the beta version of the app from there. The downside of this is you would have to opt out of it to get the actual live Play Store version to install. And then you'd have to like go back and forth.
Whereas the other method is you can host it somewhere like Dropbox and just install it from a link with the APK itself. This can be a little bit more difficult to do on newer devices because of security settings. I'd say as of Android 7, you could just click the link and install it. Now you have to click the link and save it to your device and make sure your settings are enabled to install apps from outside sources. And then you can just run it from your file system. But it takes a few steps to get that in that way.
Tim Bornholdt 14:37
And it is faster, I would say all around, to do it that way on Android, and that's one of the biggest benefits is, you don't have to distribute through the Play Store. There's a lot of different ways to distribute apps. It just seems that the Play Store is obviously the de facto way to do it. So it makes sense, kind of like TestFlight would be sort of the equivalent of the Google Play beta process. But sometimes it's like, if you just want to put out a quick thing to say, Hey, do you like it, you know, this color or this color? Just those little small things, it's nice to have APKs to distribute. So then you don't have to go through and upload a build and send out an email and do all that. There's a lot of bureaucracy in that. So that's where it's nice to sometimes just have the APK handy.
Rob Bentley 15:21
Yep. So sometimes you'll see either one, or both, depending on the use case for that. I know last week, too, we touched on dependency managers for iOS, which was Cocoapods. The Android version of that is called a Gradle. So what that means is, if a developer needs to use a library that has some trusted code that's been used for years, such as network connections or something very common like that, we'll often use a library to cut down on development time, and you manage those through something called a Gradle. So that would be, oftentimes if you download a framework from the Gradle, you won't have the ability to edit yourself. So if you happen to see a crash in a crash report, and you ask your developer and he's like, Well, it's from a framework in the Gradle. I can't edit it. I can try to update it. That's what that means.
Tim Bornholdt 16:14
Yeah, it's something you'll never probably touch on as a product owner yourself. But again, good to just know what that is. Yeah, because you don't want to, you know, I guess you don't want to sound like an idiot. But you also probably wouldn't be an idiot, if you're like, what's Gradle? Because that's like a weird word that you wouldn't know. Just like Cocoapods. Like, why would you know that? So don't be ashamed to ask questions. But that's just you have a rough idea. That's what that is.
Rob Bentley 16:42
And then the other one thing I will say that's a lot better about Android is their app review process. Sometimes on the very first version of the app you'll put out, you'll have to wait a little bit for it to go live while they review it. But then subsequent updates they just let you upload at will. So if you have bugs to fix, you can just upload another version. And then it goes live as soon as the Play Store can catch up to the update.
Tim Bornholdt 17:08
Yeah, like the whole process, like app review, all of it, it's so much nicer on Android. There are pros and cons to the app review process on iOS, for sure. And there's pros and cons on Android. But that's just one thing that when you hear developers complain about App Store reviews, they're complaining about iOS. I don't know really any Android developers that complain about the process of getting an app listed on the Play Store. It's like we said, there's so much crap on the Play Store. So that's like kind of the con to it is, you're kind of swimming in a sea of mediocrity of all the other apps. But it sure is easier to put a quality app onto the Play Store than it is to put a quality app on the App Store.
Rob Bentley 17:51
Right. If your software is actually high quality, and people use it, it'll come to the top of the search rankings and it'll shine through. So it's not like you're going to have to worry about that really.
Tim Bornholdt 18:02
Well, we didn't really have a whole lot of tips for Android. I mean, the big thing is obviously the fragmentation and the differences in the Play Store. But you know, Rob, do you have any other final thoughts about developing for Android? And anything that you'd share with the audience here?
Rob Bentley 18:20
Yeah, I mean, I guess this is kind of part of material design that we didn't really cover. But sometimes people will expect their iOS and their Android app to work exactly the same. And what we'll do is, we'll make them functionally the same. But sometimes we'll build the screens or user interface just a little bit different to really match what an Android user expects, because there are a couple of different paradigms. The two systems are becoming more and more alike as time goes on, but there's still some subtle differences to the two. So while some views may look a little bit different, you know, our aim is to still make them work the same.
Tim Bornholdt 19:00
Yeah, that's a great final thought. And especially if you are a person that has been on iOS since day one, and you get an app that's built for iOS and Android, you might get an Android device and then play with the app and wonder why they don't look exactly the same or function exactly the same. And that's kind of again, like we talked about at the beginning of the episode with hybrid designs and hybrid apps, you know, that's what makes a native app so much more advantageous is we can take advantage of specific things that Android users expect on Android and iOS users expect on iOS. We can take advantage of those as native developers, native platform developers.
And yeah, there's a lot of things with app development where if we're doing our job right, you don't notice it at all. And that's one of those things that you might notice it as a product owner because you're holding an iPhone in one hand and an Android device in the other hand, it But no other user is going to do that, right? Like an Android user is going to just expect it to work the way they want it to. And an iOS user is going to want the same thing. And it's just those little small nuance touches that really lead to a much higher quality experience overall.
Rob Bentley 20:13
Exactly. The two are really alike, but they're also a little bit different. So that's just what you'll expect. The goal is really to make an Android user feel like they're using an Android app.
Tim Bornholdt 20:23
Yep, exactly. Well, that about wraps it up for today's show. Show notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing hello@constantvariables.co. I'm @TimBornholdt on Twitter. Rob's @ScottMahonis, but he's never on there. And the show is @CV_podcast. Today's episode was produced by Jenny Karkowski and edited by the lysm Jordan Daoust.
One more thing I wanted to bring up before we signed off today. If you haven't heard, Twin Cities Startup Week is going virtual this year and will be a month long event throughout September, so startup month. We're hosting our first Twin City Startup Week panel discussion around how to scale from an MVP. While everyone talks about the importance of an MVP, there's not a lot of talk about preparing for the next step. We have some great panelists that will cover what you need to know on the tech side, the VC side, accelerator side, and the founder side. So head over to TwinCitiesStartupWeek.com to get a ticket and see the awesome schedule of events. And be sure to join myself, David Dalvey, Eric Martell and Kate Evinger on Thursday, September 10, 2020, at 1:30pm as we answer your questions live.
If you have one quick minute before you leave, we would really love it if you left us a review on the Apple Podcast app. It shouldn't take much time at all and it really does help new people find our show. So please head to constantvariables.co/review and we'll link you right there.
This episode was brought to you by The Jed Mahonis Group. If you are looking for a technical team who can help make sense of mobile software development, give us a shout at jmg.mn.