DISCLAIMER: If you consider yourself a beginner, intermediate, expert or a ninja in the Android realm, this secret sauce still applies to you.

TL;DR: Build Something.

No really! I am not kidding here. Hear me out on this.

The secret to becoming better at Android development, with all the new shiny stuff being released every year and making you go through the fear of missing out and what not is just to build out something that’s functional, even before reading a blog post or documentation.

It is really very easy to say you read up the documentation and you have gone through a blog post that explains the intricate concepts/a new library introduced by either Google or some 3rd party developer/company. I am not saying it’s not required or a waste of time because it’s very important to understand the concepts and then proceed with the using the new and shiny library or a new concept you just came to know about. You SHOULD always understand the underlying concepts to keep yourself from misusing the API/framework/architecture approach.

But here is where I would like to pause and mention a different approach which has worked for me always and with people I have introduced this concept to. The concept isn’t anything new. It’s a simple extra step of approaching a new library/architecture in Android realm, which is to…

..build a simple, isolated and bare bone example android app to see a working example of what your are trying to learn.

That’s all. I call this Example Driven Development(EDD) approach🤓.

The reason this works out very well is that these simplified examples Android apps are devoid of any complexity you would have in your own apps. If you are like me who likes to see things working before jumping into implementing it in the complex app I am working on, this approach will be very interesting to you (unless of-course you are already aware of it and use it, in that case, jump to the bottom of this story 😅 )

These simplified examples android apps also provide you opportunities to experiment with concept/library you are trying to implement as well as spot possible bugs or issues far before you would have done otherwise if you would have implemented it directly inside your complex Android app.

Some people might argue that it is a time taking process and eventually a waste of time and energy because at the end of the day the example app is thrown out of the window and the concept/library has to be implemented into the android app you are working on.

I strongly disagree to that point, with my own personal reasons to justify that (based on my experience). This might not be true for everyone, but I have found it to work for the majority of people I have suggested this approach. I believe such simplified example android apps are like

• Unit Tests, simple and focused to understand the functionality and working of the concept/library.
• Comments in code, they are there for you to comeback to, understand how the concept/library works and plays along with on the platform at the most basic level.

It wouldn’t make sense for me to advocate an approach if I can’t show how I use it for myself, correct?

So I happen to be following this approach for sometime now and it so happens some people in the community reached out to me to share the same with them. And thus Android Example came to exist as it is today…

…I created this repo last year where I started putting in all the example apps I had built while working on a feature/library/concept as I was doing android development at work or while just learning something new for myself. Turns out it has grown quite big now with 100+ android examples (including sample apps from android libraries I have built myself)

Do check it out, to get a taste of what I have been blabbering about up until now. Just jump in and build up one of the apps demonstrating concept/library implementation that you always wanted to understand and get your hands dirty hacking on the code!

Better still, contribute back to the repo with more (missing) simplified android examples or improving the ones that exist in the Github repo. Contributions of any size are always welcome.

If you still think that this approach is flawed, I am more than happy to hear about anything else that has worked for you.

If you have suggestions or maybe would like me to add something to the content here, please let me know.

P.S: I did a write up sometime back about how I manage dependencies for such a huge number of example apps. If you are interested in that you can find that here

This post was originally shared on my blog Crushing C.O.D.E, here and is also published on medium.

Checkout my Github or simply follow me on Twitter 😁

Until next post keep crushing code 🤓