First, Do No Harm

First, Do No Harm

So the phrase first do no harm is often associated with the hippocratic oath. This is an oath taken by doctors that contains various ethical standards that they should abide by. The purpose, to ensure that they provide high quality care to their patients.

As software developers, we have the power to connect people with the information they need the most. They use our applications in order to do their jobs, handle their finances and stay in touch with friends and family, however, unlike doctors, we weren’t required to take some sort of oath or pledge, when we become software developers. But I still feel that we can learn a lot from the principles behind that phrase, “first, do no harm”.

Learning to Become a Great Android Developer

We’re going to look at various things that we can do to put in the effort to be great Android developers. And it’s gonna be three different areas we’re gonna cover and the first is related to how we approach study.

Newsletters

The first topic is related to newsletters, I’m a big fan of newsletters. These are three of my favorite ones, Kotlin Weekly, Android Weekly and Android DevDigest. I get them in my inbox and I can take my time going through them. I like the fact that the articles and newsletters are vetted, so I know that someone has already taken the time to make sure it has valuable content and I can maximize my efforts when it comes to learning new things.

Podcasts

Next we’ll take a look at Podcasts. These are the ones that I listen to the most consistently. Fragmented Android Developer Backstage The Blerg Android Intelligence Test Talks

Podcasts let you hear from real world developers. They’re out there tackling the same challenges that you’re trying to tackle. Android Developers Backstage interviews the engineers who are working on the frameworks and the software that we use to power Android. We get to hear from them the ‘why’ behind how they decided to design or implement something.

Online Courses

This moves me to the third item and that’s online courses. They allow you to go at your own pace. The next thing is that they tend to cover all aspects of Android development so you can learn about layout files all the way to publishing your app in the Google Play store. Depending on the company or the courses author, you can learn different techniques for tackling the same exact problems.

These are four course which I highly recommend to those who wanna level up their skills as Android developers. So the important thing about learning and study is having that humility to know there’s always more that you can learn.

The last one I wanted to mention is Caster.IO. This website is run by real world developers out there tackling the challenges. In full disclosure, as one of the instructors, I get to see all of the effort that goes into every single video and I’ve also learned a lot from my fellow instructors.

Conferences

The best way to reach new levels as developers, is by attending conferences. There are a lot of people who are already really passionate about Android and what Android has to offer. You also get the opportunity to hear from the experts right from the stage. And even later, you can politely stalk them and ask them your personal questions related to the challenges that you’re dealing with in your particular application. You also get to grow your network.

Conferences allow you to learn new techniques. Maybe you’ve always done something using X and then you go to a conference and they say here’s Y. Wow, now you’re in love, you have this new favorite way of solving problems all because you took the time to attend a conference so just truly invaluable.

Open Source

And this brings me to my final two in this section and that’s Open Source. Open Source is great because you get these countless examples of ways to deal with things inside of your Android applications. If you have the schedule, you can try to contribute to Open Source which allows you to learn by doing which is always very nice.

And you can see design patterns in action. One thing I like to do when I include an open source library in my application is I go check out the source code, I wanna see what I can learn from these other developers. Maybe they’re using the builder pattern in order to configure something. Maybe they have a unique way of structuring their files that I can learn from and adopt in my own application.

Another thing about open source, star things, like a lot. I also tend to follow other developers who I respect in the Android community. So I’ll see which things they’re starring or maybe new projects that they’ve started working on.

Prevention

This brings us to our second section and that is prevention.

Static Code Analysis

Static code analysis works in basically two ways when it comes to Java, either on your source code or on your compiled by code. Regardless of which option, they share some basic traits and they pretty much develop a model of your code and then try to help point out issues to you. These are the four that I use the most often, Checkstyle, FindBugs, Lint and PMD.

Everyone is using Android Lint right now for their static analysis needs. But there was also a pretty large percentage of people who rely on Checkstyle and FindBugs as well to diagnose issues in their applications.

Findbugs

FindBugs develops this model of your code and tries to help point out common issues to us and it will then give us this HTML report. Here’s the medium issues, things that you probably should fix. Here’s the high issues, please fix these. And then you can dig into each one of the issues. Another tool, Java Classes is like having this objective third party looking over your shoulder as you code your application.

The first one is that you can catch issues before they impact production, so typically, if you have a continuous integration environment running, you can execute that against every single pull request. So there isn’t just that one person that knows all the things on the whole team, everyone can share that knowledge. What’s nice about GitHub, the code reviews have improved recently where you can pick multiple people to review them to help streamline that feedback.

Leak Canary

This brings us to Leak Canary. Let’s focus on some of the preventative aspects of it. It helps you to catch memory leaks in your application. The set up is very minimal, you basically add some things to your bill.gradle file, little changes to your application class and you’ve got Leak Canary.

If you have Leak Canary installed, it’ll see that code and give you a notification, ‘look there’s a leak in this activity’, then it will help you track down. And so by having Leak Canary installed, we can help prevent these issues before they actually impact our users.

Architecture

Now the next thing we’ll talk about is architecture. The way we actually design our code can help prevent issues reaching our users as well. For example, a god class, it has so many different dependencies, it’s more difficult to catch bugs in something like this as well as add new features without worrying about possibly injecting some issues. Instead, we wanna opt for more modular design with fewer dependencies spread throughout them.

MVP coupled with Dagger

In order to achieve wonderful architecture, I use the combination of MVP or model view presenter coupled with Dagger. It helps keep things modular and also more maintainable. If you’re curious about learning more on how to architect your application, there’s a talk coming up Clean Architecture where Joe Birch promises to go into even more detail about the different patterns available to you and how you can take advantage of it in your Android applications.

Automated Testing

The next thing we wanna talk about is automated testing. Unit tests are typically fast and cheap, whereas the UI tests tend to be slower and a little more expensive to write. So that means that as developers, we would want to have more and more unit tests over the latter. For this I like to use Junit coupled with Mockito.

Junit and Mockito

They make sure I have code coverage and have enough very solid test foundation. Also I connect up my continuous integration environment. I’m run Jenkins in order to execute those tests every time someone submits a pull request.

API Testing

And the final thing is API testing. As developers we often have to integrate with some type of backend service and when issues happen, it tends to be this finger pointing game. We had to find a solution, enter Postman.

Postman

So Postman is a tool that lets you execute rest requests and has a very nice gui associated with it but you can also add testing to it so I just wanted to spend a few minutes scratching the surface of what Postman has to offer.

In order to send your API testing, you just send a request, get a response, run the test, it’s really like one, two, three when it comes to Postman which is pretty cool. All we have to do to execute API requests with Postman.

I have an array of some Post objects. If you wanna know more, you can use this website JSON Place Holder to give you just like fake JSON data. When I want to write a test, I want to make sure every time I execute that request that it was successful.

This is all I have to do, make sure the status code is 200. So in the Postman GUI, I get a response code and I can just check it, I’m done. Now every single time I run that request, if it ever fails then Postman will notify me. So just like that you could add this one test on every single endpoint in your API that you want and then you will know whether or not the API is passing.

Okay but let’s step it up a notch, let’s say I wanna make sure that I actually get an array. I can create this JavaScript variable, set a type on it and say it should be an array or null. I’m fine with either one, parse the response body as JSON and then Postman gives me this TV4 Validator. I don’t have to know what TV4 is all about. I just know I called the validate method. And it would report back to me if for any reason, the API didn’t send me an array or null, super useful.

Let’s say I wanna now make sure that the actual model object is all in the correct format. I can put a properties on every single one. So if you look here, we have the user ID and ID integers, title and body are strings so just imagine your whole entire API response, you can specify the exact fields that you wanna get back here in the JavaScript. And then when you run your test, if anything is different from what you expected, then Postman will tell us this isn’t valid, here’s the path, this is what you told me it should be, this is what is was, so extremely, extremely useful.

What’s more, you can have the ability to set up monitors for all of your Postman tasks. So let’s say you have like 10 different API endpoints. You wrote five different tests for every single one. You can create a monitor to automatically run all those tasks. It runs all the tests and will report back to me any errors. What’s cool about the monitors is you can choose your own schedule so you could run all tests once a week or run them every single day. And any time the monitor’s executed, you’ll get a daily report from Postman so you’ll automatically know what the issues are.

Run Tests Against Staging

I like to run all my tests against staging. So that I can try to catch them before they push something out to production so I run all my tests against our staging API, if there’s any issues, I can see that’s a float. Supposed to be an integer, who changed it, what’s going on, it’ll break the app so just a useful tool.

And once and for all, that whole finger pointing war has finally been fought and won by means of Postman which is pretty cool. So we’ve looked at all these different techniques for preventing bugs in our application and as I mentioned we were only able to scratch the surface so I really encourage you to just take some time out and see which one of these things you can incorporate in your applications to help prevent more and more bugs from sneaking in and affecting your end users.

Diagnosis

Our final section is gonna be about diagnosis. Because you as a developer are the most intimately familiar with the code, you know the scary sections that always have the secret bugs so you really are the best tool to try to fix issues in your application. And you would take advantage of various tools to help diagnose issues.

• We have the DeBugger.
• Travel Prophecy.
• And Logcat.
• Crashlytics.
• Rafawna.

Debugging

Now the key thing that we use to debug issues in our applications is Android Studio, our IDE of choice so we’ll definitely be talking about some of the things included in Android Studio that can help us to track down bugs and squash them. We’ll gonna first look at things we can do in our own code, we’re gonna look at things outside of Android Studio, move inside and then things we can do in our emulator or on a device.

So let’s start with our own code, the simplest thing you can do is just write some logs. I like to use Timber. It lets me choose which logs make it into release builds or not and it’s a simple way to track things down.

Pidcat

Someone else also mentioned Pidcat, Logcat, here’s an example. Pidcat is just the cousin of Logcat, I’ll say. You can see the line number of certain issues, get to the root cause and fix it. These are typically some of the easiest bugs to find just because we put some logs in our code. I’ll send events to my typical analytics tracker but then I also, if I have Fabric or Crashlytics around, I’ll go ahead and send an event to them as well.

Crashlytics

Then I can go into Crashlytics. I basically have some little bread crumbs to see what they were doing when they logged in, it failed and it crashed, okay. I log in and fail and see if I crash. And so at least this way, just by logging those events, it can help speed up the level with which we can track the issues, debug them, fix them.

Staged Rollouts on Google Play

Now let’s move on to outside of Android Studio. We briefly looked at Crashlytics just a little bit. But I wanna spend a little more time talking about what it can do for you. Crashlytics has the stability report between the different versions of my application so one thing I to do is use Stage Rollouts on Google Play. I’ll just roll it out to a small percentage of the users and then I monitor this stability report to make sure that my new release didn’t cause any regressions or that there isn’t a new bug there.

So if there’s something new, I can quickly fix it before it impacts the whole population. All because I’m here checking this available to me in Crashlytics, another nice thing is that it can break down the different Android versions as well as the devices that your users are on. So if you have a huge percentage of your users running the Samsung something, unfortunately, you need to fix that Samsung something. You may want to focus your efforts on that in comparison to your favorite Pixel. So this is just a nice way to see, actually, all my users are not on Pixel. Maybe I need to get the Samsung and fix it.

Classy Shark

The next thing I wanna talk about is Classy Shark. Classy Shark is for trying to fix issues that aren’t in my code. Sometimes I’ll add a third party dependency and it’s causing a crash or causing some weird issue. I can use Classy Shark in order to track it down. It also recently added this APK Dashboard which allows me to go in and see if there’s any duplicate dependencies, some third party brought in, some weird native libraries being included. It’s just that one stop shop for figuring out what’s happening with all of my third party dependencies.

Battery Historian

And the next tool I wanna talk about is Battery Historian. For example, it could detect that the GPS was active for 26 minutes, very useful information. Battery Historian gives you tons of usage data. It also gives you the list of apps based on CPU usage so this is my phone. If you wanna know even more about batteries, there’s another talk on being a good Battery Citizen by Eric that promises to share even more techniques on debugging issues and finding out what’s going on with your app and your device’s battery.

MITMproxy

The next tool I’m gonna talk about is Mitmproxy. Also Charles Proxy is very similar. It stands for ‘man in the middle’. And this is just a way to sniff HTTP HTTPS traffic on your device. It gets extremely more complicated when we get to the S part of HTTP but fortunately for us as developers, that’s all happening behind the scenes. We just add some certificates and then we can use Mitmproxy on our device.

I can look at the response that segment sent back just a perfect way to debug traffic. This has helped me to detect duplicate image requests that were being made from my app. Also there was another scenario where there were many more requests happening than I had anticipated and our app has to work in network constrained areas, so I was able to figure all of that out just by running Mitmproxy.

Systrace

And the final two I wanna talk about is Systrace. The UI isn’t the best but you can quickly spot issues. There’s also an alert pane, just click on Alerts, it’ll give you a list of everything that’s wrong and then you can go into detail and figure out what’s happening and possibly there’s a video to tell you how to fix it.

Debugging with Android Studio and APK Analyzer

Now let’s move inside of Android Studio. We can use APK Analyzer to really dig in and find out more about what’s going on. Also coming to you in Android Studio 2.4 is the Android Profiler which gives us this very nice information about CPU Network and memory. You’ll see all the information in one place. There’s also information now about CPU. We also have GPU Overdraw which helps you spot if you’re drawing multiple pixels on top of each other. If you enable that option on your emulator device, you’ll get this cool green, red, blue looking screen.

So we looked at over a dozen tools today, all in an effort to help us prevent issues in our apps or diagnose them. And before I leave you, I wanted to share a few words with those from the Android community.

Conclusion

So it was awesome, I had a lot of fun putting that mash up together, probably not as much fun as they had recording it, however, what’s really nice is that sometimes it can feel a little overwhelming, all the things that we need to do in order to be experts or so advanced in this industry but I’d like you just remember these things. First of all, it takes study, so you have to put in some effort, you have to learn. Second, you have to have some preventative techniques available to prevent those bugs from getting in your apps. Third, skillful handling of diagnostic tools in order to debug issues when they arrive. But whatever thing you choose to tackle next, first, do no harm.