LunarLincolnLunarLincolnLunarLincolnLunarLincoln
  • Home
  • Process
  • Services
  • Work
  • Writing
  • About
  • Contact
  • Home
  • Process
  • Services
  • Work
  • Writing
  • About
  • Contact
Feb
29

Solving Hard Software Development Problems

  • Posted By : Travis Smith/
  • 0 comments /
  • Under : Coding

One luxury we as programmers often take for granted is the vast wealth of others’ experiences available for perusal at our fingertips.  Rarely do we encounter a software development problem so challenging that Google and StackOverflow cannot offer assistance. However, when working with cutting edge technology, these elusive obstacles arise more frequently and I’ve dealt with my fair share of them here at LunarLincoln.

While there is no steadfast problem-solving algorithm, most code artisans (I’m hoping this name sticks) will first consult the web.  More often than not, the hunt ends here.  An experienced developer will know the specific keywords that will help narrow the search for the solution to their problem.

giphy-2

But what if you encounter a problem that nobody knows how to solve?
Worse, what if nobody else has ever tried to do what you’re doing?

This is where we have to break out the big guns. Let’s use an example.

When I worked on Compass, I was tasked with figuring out how to stop it from draining the user’s battery so much.  At the time I hopped on the issue, Compass was tracking location data, motion data, HealthKit data, calendar events, photos, weather and more.  All the time.  Yikes.

compassiconintegrations1

Unsurprisingly, most phones didn’t react well to this kind of stress, and the largest complaint we got from testers was the drain it had on their phones.

Since everybody knows that premature optimization is the root of all evil, I had lots of avenues of attack.  The first matter of business was to figure out the biggest culprits.  Using Apple’s Instruments program, I was able to run the app and observe the battery usage levels as well as find out which parts of the app were consuming most of the CPU cycles.  As it turns out, recording a user’s location was creating huge spikes in battery consumption.  Knuckles cracked and fingers wiggling, I was ready to take a stab at it.

Adventure Time Deer

The first thing I did was dig into the current implementation to see how it worked.  The app was always tracking location, even in the background, with the highest quality accuracy.  And that’s great for results, but bad for battery.  Fortunately, I had a place to start looking for a solution.  Todd had a pull request ready which he said improved battery life but was ruining the accuracy of the location data.  His idea was to use geofencing.  He would wait until a user stopped moving, disable the GPS, and activate a geofence around the user.  When a user had moved a significant distance, the geofence would trigger, and the app would resume high accuracy tracking until the user stopped moving again.

I thought that was a brilliant solution, but as I researched all my options for tracking location, I learned it wasn’t going to work as we wanted.  Geofencing just didn’t offer enough precision.

giphy

The location logger app

The location logger app

The second solution was the phone’s motion coprocessor.

We were already tracking the user’s activity state, and I opted to hijack this information to determine when to activate and deactivate the GPS.  When a user is stationary, turn off the GPS.  Otherwise, crank it up.

Now I needed to create the algorithm to make this happen.  To iterate on the fine details of algorithm, I created a really small, ugly, but highly functional app that tracked my location and let me plug in my actual activity state (to make sure the motion coprocessor was accurate).  I would walk and drive around the neighborhood to test its accuracy while measuring its battery consumption. (Ben even went on runs to test the running measurement, and may or may not have eaten it on a piece of random construction material. Sorry Ben!)

The location accuracy visualizer app

The location accuracy visualizer app

When the tests were done, I would export the data and compare the location data to the route I actually took.  I created another tester app just to map the travel lines.  Using this, I could see whether my algorithm was precise enough to meet our needs.

In the end, I was able to create massive gains in battery performance without any noticeable hit to location accuracy.  Of course, the app still needs a lot of battery, but my models showed that multiple more hours of idle use could be seen, especially when stationary.

This form of rapid prototyping helped immensely in crafting a solution to this open-ended problem.

Surely this wasn’t the only way to solve this problem, nor is this guaranteed to be the best solution.  But one of my favorite ways to tackle a problem is to build myself some proper tools.

 

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” – (Probably not) Abraham Lincoln


Feb
04

From office noob to Android czar – Building a League of Legends App

  • Posted By : Travis Smith/
  • 0 comments /
  • Under : App Advice, Coding

[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.

chart-ww-smartphone-os-market-share

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.

giphy-2In 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.

giphy

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.

unnamedNow 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.

unnamed-1Along 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!).

200

(^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.

leageulegends

 

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.


Sep
11

LunarNoobs We

  • Posted By : Jennifer Bennett/
  • 0 comments /
  • Under : Business

We have a new employee! (We have TWO new employees (one of which is me – but we’ll get to that later)). So who is this guy helping us write all our code now?

May I present: Travis Smith!

Travis completely bewitched us by writing the best cover letter ever... (note to future applicants – I delete emails from those who cannot form proper sentences – LunarLincoln requires a modicum of grammar skills in addition to coding skills). It was as follows:

Hello Mr. President,

 

One score and two years ago my founding father brought forth on this continent a new programmer, conceived in happiness, and dedicated to the proposition that all developers are created equal.

 

Now we are engaged in a great job hunt, testing whether that programmer, or any programmer so conceived and so dedicated, can long endure.  We are met on a great medium of that hunt, the Internet.  We have come to dedicate an application with that medium, as an initial starting place that that programmer might work.  It is altogether fitting and proper that we should do this.

 

My name is Travis Smith and I’m looking for a software development job near Nashville.  Today I found LunarLincoln and was immediately drawn by its professional yet energetic and fun attitude.  While I am still a young, blossoming developer, I feel my eagerness to learn, my propensity to retain knowledge, my drive to succeed, and my clever wit would be a great asset to your team.  I don’t have the most experience with app development or procedural languages but you can bet I’d pick up the skills like a Roomba picks up dirt: quietly and routinely but at the end of the day you’ll be very satisfied with my work.  Attached is my resume for your viewing convenience.  If you need further convincing feel free to contact me any way you’d like.

 

The moon looks great by the way; I love what you’ve done with the place.

We loved it (plus he seemed to be a pretty good coder, which doesn’t hurt). After interviewing him (and many other applicants) we, of course, picked Travis.

So who is this kid?

Travis_LLHeadshotTravis is originally from Melbourne, Florida, and we’ve pulled him all the way up to Nashville – to similar hot, armpit weather minus the lovely beach. So far he seems to like it (or at least he claims to). He graduated from University of Florida, Gainesville cum laude with a degree in Computer Science and has past experience at VeriFone, Tyco International, and Tata Consultancy. In his free time he built and maintained a League of Legends leaderboard.

Currently Travis is absorbing all of WIley’s skills at light speed levels and we’re glad he’s joined the team.

Never leave us. Never.

tumblr_lsd9kegAk01qb1gqco1_500


Recent Posts
  • Copious Communication
  • Initial Questions for a New Mobile App Project
  • Gif TV: A LunarLincoln Product
  • Onboarding other peoples code
  • What’s in a name?
  • Don’t build it all. Picking a Platform.
  • Talk to your Users
  • Design for Fat Fingers
  • A new look
  • Hourglass for Jira
Archives
  • May 2021
  • September 2020
  • November 2019
  • October 2019
  • June 2019
  • April 2019
  • February 2019
  • January 2019
  • October 2018
  • August 2018
  • June 2018
  • April 2018
  • January 2018
  • October 2017
  • August 2017
  • June 2017
  • February 2017
  • January 2017
  • September 2016
  • July 2016
  • April 2016
  • March 2016
  • February 2016
  • October 2015
  • September 2015
  • July 2015
  • May 2015
  • February 2015
  • December 2014
  • November 2014
  • September 2014
  • May 2014
  • April 2014
  • January 2014
  • December 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • December 2010
Categories
  • Agency
  • App Advice
  • Branding
  • Business
  • Business
  • CaseCollage
  • Coding
  • Design
  • Design
  • NSVille
  • Uncategorized
  • Web Design
Copyright LunarLincoln 2023. All Rights Reserved