Keep your skills razor sharp by following these fantastic people and resources in the Android community
One of the best ways to learn Android programming is to surround yourself with people better than you — then watch and listen intently.
So here’s my attempt to help you find the best to learn from. Below is a list of some of my favorite people and resources in the Android community to help in your quest for excellence.
A big thanks to all these people and groups for making us all better Android programmers! 🤘
I’ve really enjoyed following these Android community members on Twitter.
These folks aren’t just knowledgeable teachers and key open-source contributors. They’re also positive-minded, hopeful, and friendly. Those qualities are just as important to me as being an expert in the area.
Chiu-Ki Chan — A devoted learner and teacher, Chiu-Ki does it all. She interviews folks, runs 360|AnDev, teaches on Caster, speaks, draws, writes, and probably does 100 other things I don’t know about. 😉
How to Write a Conference Proposal https://t.co/eDl5y1dmvQ
— Chiu-Ki Chan (@chiuki) September 7, 2016
Donn Felker — Not only an Android GDE, Donn’s got a great blog full of helpful posts. He’s also half of the Fragmented Podcast along with Kaushik Gopal (who’s pretty sharp in his own right). And if that weren’t enough, Donn’s also the head honcho at Caster.io, a fantastic site for video tutorials.
— Donn Felker (@donnfelker) September 9, 2016
— Jake Wharton (@JakeWharton) August 25, 2016
Kristin Marsicano — An instructor at Big Nerd Ranch, Kristin has a wonderful down-to-earth vibe and is clearly a great teacher. Her recent talk at 360|AnDev on the activity lifecycle is a great refresher for something you probably don’t think about enough.
— Kristin Marsicano (@kristinmars) September 2, 2016
— Ryan Harter (@rharter) July 29, 2016
The Practical Dev —OK, this isn’t technically Android specific. But it’s such an informative and entertaining commentary on programming, I had to include it. Sometimes reading general programming posts can be really enlightening (and hilarious).
— DEV Community 👩💻👨💻 (@ThePracticalDev) September 9, 2016
(Note: It’d be impossible to write about every single person who’s a great Android teacher, but you can find more on this extended Twitter list that I’ll keep adding to.)
- Fragmented — Produced by the aforementioned Donn and Kaushik, this is probably my favorite podcast. Two independent developers with their unique personalities and perspectives, with a focus on purely technical talk for Android.
- Android Developers Backstage — The most official Android podcast you can get your ears on. Straight from the people who…well, created Android.
- Material — Material isn’t a technical podcast, but is a lighter listen and a great way to get your Google news. Great for a Friday afternoon. Voices include Russell Ivanovic (from ShiftJelly, creators of Pocket Casts), Yasmine Evjen, and Andy Ihnatko.
- Caster.io — Another Donn Felker production, Caster has a over 100 lessons (and growing) of stuff you should know. If you ever watched a video from RailsCasts back in the day, it’s got a similar vibe.
- Realm.io — I’m admittedly a little confused by Realm. They have a cool database product, but on the side they also host fantastic talks — transcribed with video and slides that are synced up beautifully.
- Android Dialogs (YouTube) — A fun little video series where the aforementioned Chiu-Ki Chan and Huyen Tue Dao interview a bunch of folks in the Android community.
- Android Weekly — I’m late to the game on this one, but it’s one of my new favorites. So much good stuff specific to Android, packed into a weekly newsletter.
- Kotlin Weekly — Because Kotlin is awesome.
📚 General Reading
- Medium (AndroidDev and Android App Development) — Since anyone can tag anything, you sometimes have to dig for the good stuff. But I’ve run across a few really good posts (like this one about getting the most out of Crashlytics), so it’s worth an occasional peek.
To be totally honest, conferences are tough for me. No fault of the conferences — I’m just terrible at striking up conversations with new people! 😶
Of course they do have a ton of value — meeting new people and learning directly from the community is an irreplaceable experience.
Google IO is the only Android-specific conference I’ve been to, so I don’t have much to compare to. The sessions were top notch (logistical issues notwithstanding), and just about everyone you’d want to meet is there. The downside is that it’s so large, it can be hard to get into the sessions you want or meet up with new people you don’t already know.
There are two conferences I’ve never been to but have my eye on: the intimate 360|AnDev Conference (hopefully it’s back next year) and the more established Droid Con NYC (maybe next year I’ll remember to actually get a ticket).
Whether you’re just starting out or are a wily vet of the Android programming world, I hope this article was helpful to you! If so, please do hit the 💚 button below.
And if you have any Android favorites of your own, please share in the comments or on Twitter — I’d love to find even more great people and resources!
How to setup devices so that manual testing doesn’t crush your soul
A few days ago, I picked up one of my test devices to try out some new code. I couldn’t believe how frustrating it was.
I wasn’t logged into the right accounts. I didn’t have the right apps installed. By the time I finished testing, I couldn’t even remember how to reproduce the bug.
And like any Android programmer, my testing frustration was magnified because we support numerous OS versions/devices.
To save my sanity, I built a system for a unified, predictable setup on every device. Here’s how to do it.
1. Install the OS versions you support
Depending on what API levels you support, ideally you have a 1–1 device to API ratio. This isn’t always possible of course, but it’s helpful.
So first things first — take an inventory of your devices and which ones support which OS versions. Then examine what your customers use the most and optimize for those scenarios.
With that in mind, my lineup looks like this right now:
- Nexus 5 (5.1.1) — The Nexus 5 the most valuable device in my lineup. It’s supremely flexible and can run all the OS versions that most users have (4.4–6.x).
- Nexus 5 (6.0.1) — More than 50% of our customers are on 6.x. This is currently my baseline test device.
- Samsung Galaxy S6 (6.0.1)— Samsung devices make up a good chunk of our users, so it’s important to have at least one representative device. Their implementation of certain features (particularly WebView) can be different, so it’s important to test non-stock Android devices.
- Nexus 5x (7.0)— A newer device where I can test the very latest Android builds and features.
- Nexus 6P (7.0) — Not totally necessary, but it can be helpful to have one big screen device to see how things look in the real world, as compared to something closer to the 5″ size. Also gives me some flexibility to move down to 6.x as needed.
(I admittedly don’t have a 4.4 device, and rely on a Genymotion VM to test for that. I’ve debated knocking down my Nexus 6P down to 6.x, and flashing a Nexus 5 to 4.4).
2. Install and configure a common set of testing apps
You’ve probably got a common set of apps you rely on to test your app. This is the time to make sure they’re all installed, logged in, and preferences tweaked to your liking.
App choices will vary person to person, but here are a few that I rely on and recommend:
- 1Password — Keep all your passwords secure, and makes logging in to apps so much easier. Always the first app I install.
- AZ Screen Recorder — Great for screencasts or to create gifs to share with teammates.
- Chrome Beta — We do a lot of WebView work, so we want a heads up on how future versions of Chrome/WebView will behave.
- Dropbox — Automatically uploads screenshots so I can grab them from my computer quickly. I also use it to do some file-based testing.
- Flesky / Swiftkey / Google Keyboard — Writing on our homegrown rich text editor, Trix, is a big part of our app. So we test various keyboards frequently.
- Keep — Super handy to save quick notes, URLs and whatever else synced up across devices.
- Solid Explorer — The best file manager I’ve found. Moving things around in the file system can be very handy.
3. Login everywhere
It sounds painfully obvious, but with so many devices floating around, you might not actually be logged in everywhere you need to be. Inventory your standard places to login and do it.
Typically for me this means logging in to just a handful of places:
- 1Password for Teams
- Google — Personal
- Google — Work
It’s basic but there’s nothing more annoying than getting into your testing and realizing halfway through you’re not logged in to the right accounts.
4. Use Nova Launcher for a consistent experience
This was the real game changer for me. Using Nova Launcher, you can make every device look and work the same.
For me the biggest irritation was the launcher/app organization being different on every device. Everything was hard to find and it slowed me down.
Nova solves all of this.
You can setup your home screen, dock, and app drawer once, then share that across devices. When you pick up another device, your apps are in the exact same place as you expect. It’s predictable and fast— no hunting, no mental overhead.
Here’s how to do it.
- Pick your favorite device and install Nova Launcher. Buy and install Nova Launcher Prime (this unlocks a set of handy features).
- Set Nova as your home screen launcher, replacing whatever you’re currently using.
- Open Nova settings and play with all the settings. There’s too much to cover here, but take the time to make it work exactly how you want. Nova’s customizations can do anything your heart desires.
- When you’re happy with the setup, in settings go to “Backup & import settings”. Backup your current settings to Dropbox (or wherever).
- Pick up one of your other devices. Install Nova again.
- Go to “Backup & import settings” again, but this time do a restore. Pick the file from Dropbox (or wherever) that you saved in the previous step. Repeat for all devices.
- Voila — your devices now all look and work the same!
The long-term beauty of using Nova is that as your apps or preferences change, just upload a new backup and restore it on all your other devices. You’re all set again!
5. Tweak all your sytem settings
The last thing to do is go through all your system preferences and get them working the same on each device. For me that means:
- Making sure all my wifi networks are setup (home, office, favorite coffee shops)
- DND/total silence is activated. Test devices don’t need to notify me about anything.
- Developer options and USB debugging is enabled
- Screen stays awake when plugged in (developer options)
- Screen brightness is set to a level I like (with adaptive brightness off)
Optional: live with it
One thing I like to do is swap devices from time to time and “live” with our app for a day or two on that device.
Using the app on a real device under real scenarios gives valuable perspective. You can tell if everything looks, feels, and performs as you’d expect.
To make this process easier, a couple tips:
- Use a nano SIM from your cellular provider, and keep a SIM card adapter set handy. Even though all newer devices use nano SIM, you still might run into micro SIM slots (or if you’re really lucky, a standard SIM slot!)
- Install apps that you use outside of work. This helps ensure you don’t jump ship back to your daily driver, and you give the test device a real shot. But keep your personal apps in a separate tab in Nova’s app launcher. That way your testing apps are still front and center, but you can still get to the fun stuff and live with the device for a bit.
That’s it, I’m glad you made it this far! Following these steps should help reduce your manual testing frustrations, and hopefully keep you in the zone doing the more fun stuff (like programming everything that needs to be tested!)
If you liked this post, please do hit the 💚 button below. I’d really appreciate it!
A practical, step-by-step guide for building your own open source library.
In early 2015 I recognized a major hole in my professional work — I hadn’t made a single open source contribution. That’s pretty embarrassing to admit, considering I work with some major open source contributors on a daily basis.
Shortly after that depressing realization, I set a goal for myself: find a way to make at least a few small open source contributions within the next year.
As luck would have it, I knew that Turbolinks 5 would be released in early 2016. And one of the goals of the Turbolinks 5 project was to have adapter libraries for all three major platforms — web, iOS, and Android.
So having never done any open source work at all, what did I do? I volunteered to lead the charge and build a brand new Android open source library from scratch. 😳
Sure, I stumbled along the way, but in the end I somehow figured it out and we successfully launched Turbolinks Android in February 2016. 🎉
Why create a guide like this?
Creating an open source library has been such a rewarding, fulfilling experience — so much so that I want to encourage any open source newbies to give it a shot.
But hey, I get it — if you’ve never open sourced anything before, it can be a bit daunting. You don’t know how or where to start and you don’t have a map to tell you where to go.
And that’s exactly why I wrote this gigantic article —to hopefully give open source newbies some general direction on how to get started.
Keep in mind, this is based solely on my experience, and I’ve only done this once. Still, if you’re just getting started with building your own Android open source library, I hope it helps. Onward!
Step 1: Build a real app for yourself
First and foremost, build an app that does what you need it to do. Don’t worry about open sourcing anything at this point.
This is important — you don’t want to get bogged down with a bunch of questions about open sourcing that don’t matter yet. Hell, you don’t even have anything to open source yet!
Just keep building your app as you normally would. Your goal at first is to take care of yourself and make a great app, not worry about other people and their projects (at least, not yet).
And build only what you need — nothing more, nothing less. If you start worrying about open sourcing too early, you’ll start making premature design decisions in your code, like prioritizing “flexibility” over convenience and clarity. It’s not worth it— you’re just making complete guesses!
Step 2: Identify a problem your code is solving
Once you’ve got your app in a good place, it’s a perfect time to look at your code and determine what parts of it might be useful to others.
Scan your app and keep an eye out for…
- Code you’ve re-used from a previous project. If you’re borrowing code from something you worked on before, there’s a good chance it’s doing something useful and could be bundled up as a library. At the very least, it’ll save you the trouble of using it in your next project.
- Code that’s “your version” of another third party library. If you’ve written code that does roughly the same thing as another library, that’s actually a good indicator of a potential library. Even if your implementation is similar, how you approach the problem — your style — is what will come through. If existing libraries didn’t meet your needs, then there are probably hundreds of developers who are in the same boat.
- Code that solved a particularly difficult (or tedious) problem set. Think about how appreciative we all are for libraries like Retrofit, GSON, and Robolectric. If you’ve solved something painful but necessary, think of how much good you can do for the community!
- Code that is a unique solution to a common problem. As an example, Turbolinks Android falls into this category. It speeds up WebView performance by using a shared WebView, with Turbolinks doing all the work of requesting, rendering, and caching. That’s our unique take on solving a performance problem, but there are dozens of other ways to improve WebView performance too (caching, pre-fetching, mobile-specific views, etc.).
Step 3: Extract the relevant parts
Once you have an idea of what your library will do, it’s time to extract that code out into it’s own package and classes.
The goal here is simply to put together a rough outline of what the library components might be, and to see them all together. This also starts to put a soft delineation between your app’s code and what will eventually be your library.
You’ll need to hunt down all the relevant methods and slowly move them into new classes, most likely in a new package. Android Studio’s refactoring capabilities should make this pretty straightforward.
I’d recommend doing this in small pieces, slowly testing your app as you move things over a few things at a time.
Don’t get too hung up having it perfectly organized yet. Hell, you can even just throw them all in one giant class for now.
And definitely don’t worry about what the public interface is going to look like — method names and signatures don’t matter yet. Just do a “raw” extraction and get your app compiling and running.
Step 4: Refactor everything into a private interface
Get ready — this is going to be the lion’s share of the work!
Now that you’ve gone through the work of extracting the code into their own classes/package, it’s time to refactor everything. Update your method names, method signatures, dependencies, class structure. Refactor everything until you’re happy with how the library’s code looks on its own.
As you’re going along, keep this in mind: everything should click in your brain and feel natural.
Part of what’s great about building your own open source library is that it’s opinionated software. You want it to serve you and other likeminded people. So building the library in a way that fits your brain is the first step toward making a great public interface (the next step).
Beyond doing the pure plumbing of refactoring, you’ll want to gut check how your library’s interface feels in the context of your app.
If you’re on the right track, you’ll get good vibes about how the library integrates into your app’s code — readability, clarity, and the convenience it brings will all feel very natural. If it doesn’t, it’s time to go back and refactor some more.
This is also an excellent time to solicit as much feedback as you can from other programmers, regardless of their language preference. Some of the most valuable feedback I received was from Rails and iOS programmers. Iterate your code and create pull requests early and often.
Step 5: Stabilize a public interface
Now that you have an interface you’re comfortable with, it’s time to start thinking about other developers.
The good news is that you’ve done 80% of the hard work already with your private interface.
The bad news is that the remaining 20% is going about making things super stable, which means repetitive, check-everything-with-a-fine-toothed-comb work. The goal is to review every last detail of the library to make sure it’s solid.
This is the time to take a final pass through everything — naming, visibility modifiers, method signatures, every object passed in or out of your library, and whatever else you can think of.
Then test, test, and test some more.
All that said, I don’t want to make too fine a point of this. While you’ll do your best to make sure you’ve covered everything, the reality is that you’ll still miss stuff. Don’t fret — it’s software, things break. We’ll understand. 😉
Step 6: Document it
Since this is so late in the game, you might have thought you’d get away without having to do any documentation — nope, it’s a necessary step!
While I can’t say writing documentation is boatloads of fun, I did find it to be super valuable when building an open source library (I’m still generally anti-comments in private app code). Here’s what you’ll need to do.
Javadocs — You’ll want to comment every single class and method, public or private. Assume that nobody has any idea what you’re doing in the library code.
To be clear, I don’t mean you should comment every line of a method — your code should still do most of the talking. But writing a Javadoc comment for every class and method will 1) help people looking at the source and 2) let’s you to generate a nice Javadoc.
Once everything is commented, generate a Javadoc and give it a read. Look for holes and things you’ve missed. Have others read it. Does everything you wrote make sense to you and to others?
README — A good Github README does a few things:
- It describes what the library is and does at a high level
- It provides clear instructions for basic configuration and getting started
- It provides instructions for advanced techniques or configuration for those who are interested
I’ve found the best thing is to mimic READMEs from other libraries that you’ve found helpful. Here are a few recent ones that we’ve written that I think do a good job:
Step 7: Move the library code to its own project
Now that code complete and fully documented, you’re inching your way to publishing this to the world!
Before publishing you’ll want to move all the library classes to its own Android Studio project. This ensures the library is completely self-contained, eliminating any unexpected dependencies on your app. You basically want to see if it can compile and stand on its own two feet.
Once you’ve moved everything to a new project, you’ll need to setup a dependency to that project’s files. This is weirdly tricky in Android Studio, so here’s how to do that.
include ':turbolinks' // name of the module
project(':turbolinks').projectDir = new File(settingsDir, '../turbolinks-android/turbolinks') // location of the dir
In your app’s build.gradle file:
With those two configurations in place, the two projects are now file linked — any changes to the library files from either your app’s project or from your library’s project will update the same files.
Step 8: Publish it!
Finally, it’s time for all that hard work to pay off!
Relatively speaking this step is pretty easy, albeit a bit tedious. You’ll be publishing to jCenter, which is the default repository with Android’s Gradle plugin. You’re simply packaging up your library in a way that Android Studio understands, and in a place that Gradle already knows about.
My recommendation is to follow a combination of the three resources below. They are pretty much step by step and walk you through the entire process of publishing to jCenter.
- How to distribute your own Android library through jCenter and Maven Central from Android Studio
- Publishing Gradle Android library to jCenter repository
- Publish an aar file to jCenter with Gradle
Once you’ve done that, your library is published. Congratulations! 🎉
Step 9: Maintenance and community relations
Now that your library is public, there will be more eyes on your work — questions, issues, pull requests and discussions will crop up. This is a good thing!
I’m always thankful that people are interested in the project and want to be involved. But there will be times when you disagree with a discussion or you simply don’t have time to address everything. That’s OK!
Maintaining a library is no small task. There’s going to be some pressure from the community to keep things moving. We all want things to be better. But it’s also OK for you to say no or to defer work. There is literally always more to work on.
The most important thing is that you keep you continue enjoying working on the library. If that means addressing all the community requests, do it. If that means saying no, do it. If that means working only on the things you want, do it. Keeping your sanity and happiness working on this library will be what sustains it for the long run.
Summary & Acknowledgements
If you’ve made it this far, you’re well on your way to launching your own Android open source library. You’ll soon be helping a lot of people by making their lives easier and their work better. Great job! 👏🏆
Also, this process is the furthest thing from a one-person show. Literally none of what I talked about above — creating the actual library and having the opportunity to do so — would have been possible without the help and encouragement of everyone at Basecamp. Thank you all!
I’d like to thank a few specific folks for their unwavering support and contributions in helping launch and maintain Turbolinks Android: Jay Ohms, Jamie Dihiansan, Sam Stephenson, Jeffrey Hardy, and Zach Waugh. ✊
If you found this article helpful, please do hit the heart button below and let me know on Twitter. Thanks!
Our happiest customers are most likely our quietest customers
Like any app developer, the Android team at Basecamp cares about our app’s reviews. We look at them regularly because they can be a valuable source of feedback and a way for us to talk to our customers.
And like any app developer, we see our fair share of negative reviews. As a small team who takes feedback seriously, it’s a bummer when someone doesn’t like our app.
Of course not all negative reviews are thoughtfully written, and much has already been made of how broken ratings and reviews are. Still, it’s hard not to take some of it to heart and let it weigh you down.
But over time, I’ve learned one really important thing…
No matter how many negatives reviews we get, there are a lot of people who really like our app — they just don’t write many reviews. It’s important to remember those happy, quiet customers and not get too hung up on negative reviews.
Leaving reviews just isn’t a priority for many people
Here’s the thing — as much as you want them to, there’s really no strong incentive for someone to leave you a positive review.
For many people, your app is doing its job dutifully and everything is working great. It’s not changing their lives or revolutionizing their world, but it’s helping them get something done. They’re thankful it exists.
But for them writing a review is never going to be a priority. Even if they love your app and are raving to their friends and co-workers about it, giving you written, positive feedback is never going to compete against the hundred other things they’ve got going on in their lives.
You may have even experienced this yourself — do you have any apps installed that you like but have never left a positive review for? I certainly do.
Sure, there are ways to boost your ratings and reviews, and you should take whatever opportunities you can to help your app. But no matter what you do, there will always be a subset of users who are very quiet, but very happy.
Listen to your negative reviews, but keep your quiet, happy customers in mind too
While negative reviews aren’t always useful (particularly one-star reviews with the word “useless” written in it), some can be genuinely helpful.
What’s most important is that you listen to the reviews that have constructive criticism and feedback.
Respond if you can, and encourage them to email you directly with more details. Feedback and direct interactions with customers are valuable and show that you’re listening. Consider their ideas, prioritize, and start making your app better for those customers.
But at the same time it’s very, very important to know that there are a lot of people using your app that are perfectly happy with it.
You’ve already done a great job to get to where you are. Don’t lose sight of that.
Be sure to give everything five minutes so that the squeaky wheels don’t cloud your judgement. Continue to trust yourself and your team to make sound decisions based on considerate thought, not knee jerk reactions. And really think about all your customers, not just the vocal ones.
Believe me, the positive reviews and happy customers are out there. You just can’t hear them all.🤘