[message_box type=”info”] This week we have a guest post from LunarLincoln developer Travis Smith. He spent 2015 working on a side project which he finally shipped (yay, shipping!) and we wanted him to give us a breakdown of his initial foray into indie development. Enjoy! [/message_box]

Sometimes it’s hard being the only Android user in a shop full of mobile developers.  You’d expect nearly equal representation as Android currently dominates global markets, but alas, mistakes do happen (yes, mistakes). However, a positive consequence of this misfortune is the compelling urge to prove Android is the superior operating system. And what better a way to do that than to become an expert Android developer.

Android’s Lollipop OS was released around the start of my development journey and alongside it the beautiful style guide known as Material Design. Coupled with the release of numerous support and design library features, I knew I wanted to create something awesome both as practice and for fun.

In addition to being the only Android user in the office, I’m also the biggest video game nerd. My favorite these days is League of Legends, arguably the most popular PC video game in the world. And luckily for me, Riot Games, released a beta version of their public API just a few years ago. Being no stranger to the Riot API (I rigged up an automated system to pull in millions of game records for statical purposes back in early 2014), I knew I wanted to push both my skills and the API to their limits. But where to start? There were already a handful of League of Legends apps in the Play Store and some had hundreds of thousands of downloads.

What was a problem in League of Legends that hadn’t yet been solved?

Friends. All of the existing apps I found made it easy to drown yourself in data and statistics about any player you wanted. However, none of them made it easy to see how your friends were doing, or whether they’re actively playing a game at the moment you’re using the app. Additionally, all of the existing apps were designed before the advent of Material Design.

I could see in my mind what I wanted:

• A name. I chose League Buddy. It’s simple, a little corny, not violating any copyrights, and unused. Works for me.
• The home screen should be a list, or maybe cards, of summoners.  I could show their names, their profile pictures, and when they last played a game (or if they were in game that moment!)
• A Floating Action Button at the bottom could present a popup of some sort that allows users to add new summoners to their list
• A single swipe to refresh could update the entire list at once and let me know immediately if my buddies were playing without me
• Tapping a summoner should do… well, something. I hadn’t figured out exactly what I wanted here yet. Maybe show some in-depth detail about the summoner?

Simple, right?

Time to learn some new tricks.

Around the time I started, Android released its ‘upgrade’ to ListView, the RecyclerView, and encouraged developers to stop using the ActionBar and instead use the new more generic Toolbar, which would prove very useful in implementing a core Material Design feature. I had my first screen laid out in my mind, but I still had a few questions.

• What are the best practices with Activities and Fragments?
• Does the Toolbar belong to the Activity or the Fragment?
• What about the Floating Action Button?
• What if I want to support multi-pane on landscape tablets? How should landscape look in general?

I spent so much time researching everything about best practices that I actually discouraged myself for a few weeks. Eventually I realized that the only way I was going to really learn what worked and what didn’t was by trying my best and fixing my mistakes.

Since I knew I only had one screen in mind, I decided to put multi-pane support on the back burner. However, I did prepare for the future and opted to implement my layout inside a Fragment (which was really just containing a RecyclerView) and put that Fragment in my Activity along with the Toolbar and Floating Action Button. Back then, I was using a library for the Floating Action Button since there wasn’t an official widget (yet). I created a small view that would slide up from the bottom when the button was pressed and that view allowed users to input a summoner’s name along with the region of the server they played on. For example, I play on the NA (North America) server, but there are about a dozen servers across the globe and I wanted my app to support them all.

Now I needed some way to persist data. On a previous project at work I had used Sugar ORM as a wrapper on a SQLite database. It worked well but I wanted to try something new. I came across a brand new tool called Realm which touted itself as being incredibly fast. Though still in beta and lacking some features (including null support and subclassing entities), I decided to give it a go.
All that was left was to set up the actual connection to Riot’s servers. Writing an API wrapper was easy, especially since most of my code from my previous Riot API project was up-to-date. I used Retrofit to talk to Riot’s server and Picasso to display profile pictures. After a few nights of work, I had accomplished my goal – an app that showed a list of summoners, with a button to add new people, and the ability to refresh the list. It was crude, not too pretty, and lacked lots of key features (like deleting summoners from the list), but it worked.

And then I stopped working on the project for a few months. Work picked up and summer meant vacations, so I halted progress.

But then, Android released some neat new tools that inspired me to resume development!

The first was an official Floating Action Button. The second was a new view called the CoordinatorLayout which allowed the Toolbar to hide as the list below it scrolled down. Last was a NavigationView class which made implementing a Material-themed navigation drawer incredibly simple.

Implementing the CoordinatorLayout proved to be very challenging. I had placed a view at the bottom of my fragment that indicated the last time the data had been refreshed, and this was throwing off the scrolling of the fragment. Despite aligning the view at the bottom and the RecyclingView above it, the scrolling did not work properly. Somebody else had filed a bug report about this exact issue and fortunately somebody had devised a workaround. However, now that the Toolbar slid out of view when scrolling my summoners list, I couldn’t imagine how multi-pane support would work at this point. My second screen was scheduled to be a scrolling list of cards containing tidbits of high-level information about a summoner, and having two scrolling views under one Toolbar would be very unwieldy for a user if that Toolbar was also sliding.

The next hurdle was the Floating Action Button. Now that Android had an official widget which directly related to the CoordinatorLayout (the button would hide on scrolling), I knew I had to replace it. However, I disliked my current implementation of adding a new summoner. A messaging app called GroupMe provided some much needed inspiration. When tapping their Floating Action Button, the button expanded outward until it filled a small rectangle. I loved it and had to have it. As it turns out, this animation is called a circular reveal animation (surprise!). Android had incorporated a utility class for performing this exact animation, but it was limited to devices running Lollipop or newer (which was a very paltry 10% around this time). Fortunately I found a library that provided the exact needed functionality to my app.

Along the way I encountered a new pattern I had never seen before: the event bus. While I’m still torn today over its fit as a best practice, I decided to integrate Otto into my app to help with loading and passing data. In hindsight, I regret this decision a bit, as it led to some poor coding practices and tangled dependencies. As practice, I also decided to upgrade all of my API calls to return RxJava Observables, as functional reactive programming is something I’m becoming more and more interested in.

Creating the summoner overview cards screen was fairly easy. The card styles were adapted from official examples and look very clean. I was able to use a StaggeredGridLayoutManager to allow different orientations and screen sizes to show different numbers of cards side-by-side. Because of switching to using RxJava Observables, loading all of the necessary data (since none of this data is persisted) was easy. I threw together a quick Settings screen which let users change their default region (which will be automatically selected when prompted to add a new summoner) as well as their preferred language (which all Riot data will be automatically translated to).

After a brief QA round across different devices and SDK versions, I had a working, ready app. With one problem.

Riot’s development API key is severely rate limited. To get a production level key, I’d need to get them to approve my app. And to do that, I had to follow their rules. The first rule is that no client-facing application can have the API key embedded in its code. This meant I needed a server to act as a middleman between my app and the Riot servers to append my API key and return the data. The second hurdle was that I needed a website to showcase my app and provide screenshots, FAQ, etc. I took my meager bit of Node.js and Express knowledge and pieced together a very small server application which would cache results for a few minutes and return the data to my app. I hosted this on DigitalOcean, struggled to get a free SSL certificate, and eventually got it working. I purchased the domain leaguebuddyapp.com and worked with Jennifer to set up a very simple one-page website (which is almost done, I swear!).

(^Jennifers reaction to this statement)

I was ready to publish.

Presenting, League Buddy! It’s small, it’s nowhere near finished, it’s got some kinks, but it’s mine. I’ve got tons of ideas for future expansions to the app. A wiki page with data on every champion and item in the game, a statistics section that lets you compare yourself to your friends (or even professional LoL players, if you dare!), and tons more cards on the summoner overview screen. Not to mention all the detailed pages for nearly every card! I’m going to be busy for a very long time.

Despite the incredibly long blog post, this doesn’t cover even half of the sometimes silly and often frustrating problems I encountered on this journey. But I feel it was completely worth it.

I’ve exposed myself to so many new communities, picked up so many new skills, successfully learned which patterns I like and which I don’t, and ultimately shown I’m capable of creating an entire application from scratch, including its server and web components. It was fun, challenging, and awesome. With 2016 under way and my routine back to normal, I’m hoping I can commit a little bit of time each week to cranking out some new features.

In the meantime, check out my app and let me know what you think! I’m open to all criticism and suggestions for improvement.

And I should offer thanks to the entire LunarLincoln team for putting up with my rambles and questions over the last year about this hobby project. Even though they’re not exactly Android fanboys and girls, they’re all brilliant and offered tons of great suggestions. I’m immensely thankful for their help and looking forward to using my new skills on upcoming Android projects.