After two years of blogging on this site, posting various tutorials and Android discussions I felt were relevant, I’m now looking to share that experience with others. Blogging has been an invaluable experience for me, as I learn just as much as I get to teach when I’m thoroughly researching and writing a post. There’s no reason for me to keep this opportunity to myself, though.

Third party libraries are a huge part of mobile app development. Popular tools like Retrofit, RxJava, Picasso, and many others prevent Android developers from reinventing the wheel everytime we need to do something over the network, asynchronously, or loading images.

However, developing and publishing these libraries can be intimidating to many people. I think this occurs for a number of reasons - worry about keeping up with maintenance, being outshined, or sometimes thinking no one would use your code. I have many thoughts on those ideas, but will save them for another blog post. In this one, we’ll just go over a step by step guide to creating and publishing a library to JCenter.

Controlling the brightness of your phone can be a hassle. Currently we’re stuck with the two step process - swipe down on the notification drawer, and then deal with the slider trying to get it just right. However, with the release of Android Oreo and a new fingerprint gesture API, a new solution was born. Enter DigiLux.

Espresso is a testing framework for Android that allows developers to write automated tests for their applications. The benefit of automated testing is that you can write a test plan, and simply hit run and have all of the important features in your app tested effortlessly, and arguably more consistent and thorough than manual testing. There is no doubt that it is a lot faster.

However, one of the lesser known development patterns for automated testing is the robot pattern, which makes writing tests much easier while providing a painless way to update tests whenever your app changes. Let’s take a deeper dive into what makes the robot pattern so powerful, and how to implement it in your next test suite.

Every Java programmer has faced the dreaded NullPointerException at some point in their life. Sometimes it’s your fault, sometimes it’s a pesky race condition. Regardless, it’s a head ache and generally leads to a ton of if (myVariable != null) { } conditions all over your code. However, the latest craze Kotlin can help with that too. Kotlin introduced null safety into its type system, with the potential of removing all NPEs.

This post is both going to review the official docs linked above, as well as provide some common tips and tricks to work with the nullability - something that is new in this language for many Java programmers.