• Multi-region cloud presence
• Microsoft .Net stack
• 6 month migration – during which traffic increased by 30%
• 20% improvement in international response times (10% domestic)
• Reduced capital budget by 32%

You can read all about it here. We are planning to write a series on this blog detailing our cloud migration, so stay tuned.

Google does not permit the OAuth2 Access Tokens stored on your device to be sent to anyone besides a Google Service. From a security standpoint this is exactly what the user wants, otherwise a malicious app could hijack the users Google OAuth2 token. We want to avoid situations where the user entering Google credentials on a non-Google controlled environment.

So what is the appropriate workflow for a service which wishes to utilize Google purely as an authentication mechanism? Feedly looks something like this:

• User makes login request to Feedly
• Feedly responds with an authentication url – this is controlled and generated by Google
• User browses to authentication url
• User submits credentials
• Google validates credentials
  • If valid, Google notifies Feedly and redirects User to a new URL with a special short lived code generated by Feedly
  • If not valid, user can attempt authentication again
• Once validated, Feedly Local Client retrieves code from URL
• Feedly Local Client uses code against Service to obtain a refresh token and access token

At this point the user is validated against the Google OAuth2 credentials. The client app consuming the 3rd party service (feedly) can be reasonably certain the person logged in should have access to the login information. Because of this, the client app should be permitted to make API calls against the 3rd party service call utilizing the access token. Again, since the access token was generated based on a successful OAuth2 authentication against the user’s Google account, we can be reasonably confident that any requests made with the access token can be made on behalf of the previously authenticated OAuth2 account.

On a web/mobile web app the login process will look fairly seamless. Basically a series of quick redirects with some pauses in the workflow for user login input.

On a native Android application, an HTTP request running asynchronously in the background cannot be used from start to finish since at some point the user must enter credentials in the Google Authentication URL webpage. To do this we must embed a WebView within the application.

We recently went through the exercise of putting together a proof-of-concept Android application which leveraged the Feedly API. While doing so we noticed the Authentication piece is fairly boilerplate code and follows the workflow of many other OAuth2-exposed APIs.

If you wish to view our implementation or use it in your Android application as a Library project the code is accessible here:

https://github.com/infospace/android_oauth2_webview

As we want to provide a high level of device coverage, we used the compatibility library fragments. There is even a framework in place to create calls to the various Feedly API methods. See com.infospace.feedly.requests.RetrieveSubscriptionsRequests.java in the github repo for reference if you wish to look into creating more Feedly API requests.

Simply import the Android library project to integrate it with your existing Fragment-based Android project. When you wish to display the authentication portion, all you have to do is initialize some helper classes on activity start, and then push the fragment. Once the user authenticates the fragment automatically saves the refresh/access tokens for further use within the application.

If you have any questions please leave a comment!

Android and Google are trademarks of Google Inc.

There are three main things that, if you pay attention to, will help you build your app so that it scales and feels natural on a variety of screen sizes.

• Planning and understanding your application workflow and navigation.
• Creating layouts for your workflow that allow you to take full advantage of multiple screen sizes.
• Implement your application workflow using and taking advantage of the idioms built in to Android^TM.

This post isn’t going to go into any depth on the first two, but if you’re interested I’ve posted my presentation as well as a sample RSS Reader application which will help walk you through the concepts.

The Workflow

One of the most common workflows I see people asking for help with is the multi-pane workflow. A typical example of this workflow is when you start with a list, tap on a row in the list, and get additional content related to the row you initially clicked on.

On a phone we’d expect tapping on the row to navigate us to another screen with the additional data. On a tablet, where we have a lot more room for content, we have the expectation of being able to keep the context of our original list while also viewing the additional data about the row we selected.

The Layouts

For the purpose of this post we’re going to focus on two layouts.

_{default/phone: res/layout/main.xml}

1
2
3
4
5
6
7
8
9
10
11

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/fragment_container"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <!-- No Fragments defined -->

</LinearLayout>

_{tablets: res/layout-large/main.xml and/or res/layout-sw600dp/main.xml}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/fragment_container"
    android:orientation="horizontal"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <Fragment
        android:name="your.package.FirstFragment"
        android:id="@+id/first_fragment"
        android:layout_weight="1"
        android:layout_width="0dp"
        android:layout_height="match_parent" />
    <Fragment
        android:name="your.package.SecondFragment"
        android:id="@+id/second_fragment"
        android:layout_width="0dp"
        android:layout_height="match_parent" />
</LinearLayout>

The layouts are both for the same activity. Again, I won’t go into details about the layout other than to show you the XML and call attention to one important point.

Notice that the first layout doesn’t include any fragments while the second one does. The reason is that for the default/phone workflow we simply want to replace the current fragment on screen with a new one or a previous one as we navigate through the content.

Fragments that are declared in the XML layout file cannot be programmatically replaced using a FragmentTransaction. Only fragments added via a FragmentTransaction can be replaced. Instead you have to programmatically show/hide Fragments declared in a layout. We’ll handle this in the code below but I wanted to call attention to it as it helps provide some context for the code we’re about to dive into.

Handling The Activity Life-Cycle

_{Activity start-up}

The first thing we want to look at is what we do when the activity starts up.

1
2
3
4
5
6
7
8
9
10
11

@Override
public void onCreate(Bundle savedInstanceState)
{
  super.onCreate(savedInstanceState);
  setContentView(R.layout.main);

  if(savedInstanceState == null)
  {
      this.displayFragment(R.id.first_fragment);
  }
}

Notice that because we’ve used the built-in configuration qualifier idioms we only have to reference R.layout.main in the call to setContentView and Android^TM will chose the correct layout for us automatically.

We also want to make sure that we don’t go through all the work of setting up our fragment if we’re just resuming from the background. So we put in a quick check to see if we’re being passed any saved state.

_{Displaying a Fragment}

You may have noticed that there appears to be a lot of magic in the onCreate method because it just calls displayFragment. Let’s de-mystify that magic and show you what’s really going on when we call displayFragment.

The first thing displayFragment does is check to see if our fragment already exists in our layout. We’ll get to the inner workings of what getFragment is doing in just a minute, but it’s important to understand why we need to try to get a handle to the fragment if it exists.

Remember that our default/phone workflow did not define any fragments in the layout. Only our layout for larger screens defines the fragments in the layout. This is useful to us in code as having a non-null fragment is our queue that we need to update the fragments content and not push a new fragment onto the screen. In other words, it’s our primary technique to respond to our workflow without having to hard code each possible workflow scenario into our code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public void displayFragment(int id)
{
  Fragment fragment = this.getFragment(id);

  // the fragment is null if it's not already being displayed
  // or it's been declared in the currently displayed layout
  if(fragment == null)
  {
      fragment = this.createFragment(id);
      this.addFragmentToBackStack(fragment, id);
  }
  else
  {
      fragment.loadData();
  }
}

_{Checking to see if a fragment exists}

When defining a fragment in a layout you give the fragment an id using the android:id attribute and (optionally) a tag using the android:tag attribute on the <Fragment> element.

My preference is to only define the android:id and then when I push fragments using a transaction I use the R.id.YOUR_FRAGMENT_ID value as the tag (converted as a string). This allows us to simplify checking for the fragment as we’ve done in our getFragment method.

1
2
3
4
5
6
7
8
9
10
11

public void getFragment(int id)
{
  FragmentManager manager = getSupportFragmentManager();
  Fragment fragment = manager.findFragmentByTag(Integer.toString(id));

  if(fragment == null)
  {
      fragment = manager.findFragmentById(id);
  }
  return fragment;
}

_{Adding a fragment to the back stack}

In the case that getFragment returns null for the fragment we asked for; We need to create an instance of the fragment and then, using a fragment transaction, push the fragment to the screen by adding it to the back stack.

Adding a fragment to the back stack allows Android^TM to automatically undo the transaction when the user clicks the back button.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public void addFragmentToBackStack(Fragment fragment, int id)
{
  FragmentManager manager = getSupportFragmentManager();
  if(fragment != null && manager != null && !fragment.isInLayout())
  {
      FragmentTransaction transaction = manager.beginTransaction();
      // perform any custom fragment workflows here.
      // like hiding/showing fragments declared in the layout
      // using transaction.hide(...) or transaction.show(../)
      transaction.replace(R.id.fragment_container, fragment, Integer.toString(id));
      transaction.addToBackStack(null);
      transaction.commit();
  }
}

_{Popping the back stack}

Because we’ve added the transaction to the back stack we don’t have to do any additional work for the hard/soft back buttons to work correctly but in practice there is a little work we need to do.

In the case that your application is using an ActionBar you’re going to need to invalidate the options menu when popping items so that any options that have been added by the fragment that was displayed are removed.

We also need to update the home button if we’re using an ActionBar to ensure that the home button provides the correct visual feedback to the user.

I also like to track, in the method, whether or not we actually popped something and return that value. The reason is that I believe the user has an expectation that the app will close when mashing the back button, but not when mashing the home button in the action bar. So in the case of the back button we’re going to want to call finish on our activity if no back stack was popped, whereas for the home button we wouldn’t do anything.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

private boolean popBackStack()
{
  boolean wasBackStackPopped = false;
  FragmentManager manager = getSupportFragmentManager();
  if(manager != null)
  {
      if(this.shouldPopBackStack(manager))
      {
          manager.popBackStack();
          wasBackStackPopped = true;
      }
      this.invalidateOptionsMenu();
  }

  this.updateHomeButton();
  return wasBackStackPopped;
}

The shouldPopBackStack and updateHomeButton methods need to contain the custom logic, which is specific to your apps workflow, to decide if something in the back stack should be popped and what type of visual feedback to provide. In the case of a dual-pane app we wouldn’t want to pop the back stack or show the back arrow on the home button if the only two fragments that are displayed are the original two fragments defined in the layout file.

Wrapping it all up

Building for multiple screens doesn’t require much additional work once you understand the tools at your disposal. The only requirements are:

• Understanding the workflow and navigation of your app in order to identify opportunities for customized layouts.
• Creating the custom layouts, using configuration qualifiers, that handle the size specific workflow.
• Implement the pushing and popping of fragments using the techniques outlined above.

Android is a trademark of Google Inc.

You may already work in a polyglot environment and not even be aware of it.

Are you a web developer? Do you write server side code hosted by Apache, Nginx, or IIS? Do you work on mobile applications? Do you make any 3rd party API calls?

If you answered yes to any of those questions you’re most likely already working in a polyglot environment, at least from a language perspective. A typical web development environment, at a minimum, uses HTML, Javascript, and CSS. Calling an API? You’re most likely using XML or JSON as well. Maybe you’re using ASP.NET MVC or Ruby on Rails. All of those scenarios require a polyglot environment from a language perspective. Frameworks like ASP.NET and Rails provide mechanisms to blur the lines of the languages that are used and the frameworks that use them, but you’re polyglot nonetheless.

What can we learn from a polyglot environment?

So what does it matter if I’m aware that I’m working in a polyglot environment or not? You’ll start to ask more thorough questions to the problems you’re trying to solve as you gain more awareness of the environment you’re working in. Being polyglot-aware frees you of the bondage of limiting your solutions to only the constructs available in your language. You start asking yourself questions like:

• Is my problem best solved using a pattern based around a language/framework construct, for example a Linq expression, or is there a design pattern that better solves my problem that may not already be implemented in the framework I’m using.
• Is my IDE or programming environment causing me to make workflow decisions that I would not make given a different IDE or programming environment?
• How do other languages/platforms solve this problem? Are there best practices?

Polyglot environments allow us to learn from the growth of other platforms.

If you’ve paid attention to the evolution of .NET, Rails, Android, or iOS development over the last decade one thing you’ll notice is that each framework/platform has learned from other frameworks/platforms. ORM’s were introduced in the .NET Entity Framework as a direct result of their effectiveness in Rails. The understanding of the problems that ORM developers were trying to solve eventually lead to the NoSql boom that we’re in today.

Android Studio and Interface builder for iOS have evolved, in part (in my opinion), as a result of the tools provided by Visual Studio for building forms/web forms based applications. Android fragments were heavily influenced by the boom in the the tablet market, driven by iOS. The pattern was different but the problem was surfaced and addressed as a direct result of another platform/framework. The UI evolution in iOS around notifications seems to be heavily influenced by their Android counterpart.

Polyglot environments have helped to proliferate language constructs like closures, lambdas, and generics. Even if you haven’t been working in these different platforms/frameworks/languages a lot of the tools, patterns, and language constructs that you use everyday have been heavily influenced by people who do work in polyglot environments.

Polyglot environments allow us to think outside the box

In my experience, patterns tend to emerge quicker for the polyglot developer. I don’t have any hard evidence for why but my gut tells me that it’s because they’re exposed to the patterns more often in different languages/frameworks and so they’re more recognizable for what they really are (a pattern). Once you start recognizing patterns you can more easily differentiate the patterns from the language constructs that implement those patterns. When we’re aware of the underlying pattern being implemented we are better able to utilize the construct implementing that pattern. It allows us to understand the bounding box of the construct and not try to shoehorn a solution into a construct that wasn’t built to solve that problem.

As a polyglot developer you find yourself asking “Why am I solving the problem this way?” or “Is this really the best way to solve this problem?” more often. This leads to better solutions simply because you’re more involved in Why you’ve chosen a particular implementation. In my experience, polyglot developers are more likely to look for others who have solved the problem already than they are to just try to roll their own solution. Rolling your own solution to a commonly solved pattern often times causes us to miss some of the intricacies of the problem or introduce bugs that other frameworks have already squashed.

I’m convinced; how do I start?

Find a problem that you’re passionate about solving. Maybe you like reading RSS feeds, maybe you have a huge collection of books you’d like to categorize, or maybe you’re passionate about a problem with existing solutions that aren’t up to snuff. Once you have a problem you’re trying to solve pick a framework, language, and/or platform you’ve never worked in like ASP.NET, Rails, Android, iOS, or etc and start solving your problem. You’ll have a lot of fun because you’ll be solving a problem you’re passionate about and you’ll be well on your way to becoming a polyglot developer.

I have not found a suitable free solution for this type of thing for Java. The solutions I have found typically require Eclipse or IntelliJ as well, and I’ve been more productive sticking with Vim and Bash lately. That being said, I wanted a solution that could support both IDE users and Text Editor users, just like I’ve had in Ruby.

InfoSpace is happy to announce that we have released our Guard::Java project to the community, for free under an MIT-style license!

Guard::Java

Guard::Java is built on top of my favorite auto-testing framework for Ruby, called Guard, and provides automatic, background testing of your code as you are working, without you having to stop your workflow! It provides this capability through the following features:

• It watches your source and test files for changes
• When a file changes, it tries to find the unit test fixture/class related to that file that changed
• It runs just those tests, seeing if any basic unit tests for just that file have been violated or are now fixed
• It can (optionally) after a successful single-class run, run all tests as a regression pass to see if any other unexpected impacts result from the changes you are making

Guard also provides event and status notifications in various forms:

• Detailed output to the Console (e.g., in Eclipse or IntelliJ) or Shell
• Terminal / Shell title bar text
• Color coding of the session name when using TMUX

• Growl notifications (pop-up messages/toasts) with custom messages

How Does This Help Me?

I just work the way I normally would, and my system tells me if I broke someting or if everything is still OK, without me lifting an extra finger! While Guard::Java comes with sensible defaults for most common scenarios, it can also be configured for your specific situation.

What About Android Tests?

Yes, running Android tests are a pain since they are deployed to a device/emulator and fully run. In this case, we have adopted the following workflow:

• Guard::Java watches file changes and automatically compiles the code and/or tests on every save action to ensure nothing has broken
• It has a prompt in your Console/Shell that you can simply hit ENTER on and it will build, deploy, and run your tests using the standard ant tasks (or your own customized tasks) and report status all along the way.

The Guardfile that is generated when you run guard init already has code to automatically find your Android SDK folder and add it to the classpath as well!

I Use Eclipse/IntelliJ – Do I Need This?

It depends. If you have it configured to autotest specific code with each save, then you may not need or want this. The nice thing is that we have used this in Eclipse and IntelliJ (configuring as an External Tool, for example) using a Console tab in the IDE. We also have used this with folks using Text Editors (Sublime Text, ViM, and TextMate) with success.

It Doesn’t Do What I Need

We are happy to take suggestions and pull requests. Just open an issue—or better yet a Pull Request—from the repository at https://github.com/infospace/guard-java

How Do I Get Started

See the README on the project page on GitHub to get started!

Suggestions, feedback, and ideas are always welcome!

When writing user passwords to a datastore, never store them in plain text. If your datastore’s security is compromised, an attacker can easily steal user login credentials, unleashing a major PR incident on your watch. Don’t worry, it isn’t much effort to plan ahead and only incur a minor PR incident, none of which is your fault.

Is there a better way to store passwords than plain text?

Yes! Instead of storing the actual password text, store a hash of that password. Use a strong hashing algorithm like SHA256 or SHA512 to hash the password text and store the result of that. When a user needs to be authenticated, hash the submitted password and compare the two hashes. If they are the same, the password is correct. Unfortunately, hashing alone is not all that much more secure due to something called a rainbow table. Rainbow tables are very large sets of hashed passwords that can be used to convert hashes back to plain text passwords. These tables are readily available through BitTorrent.

Is there a better way to store passwords than using hashes?

Yes! Instead of storing the hash of the password, store a hash of a salted password. A salt is a random string (and unique to each password in your system) that you will append to the password before hashing it. And get this, you’ll store that salt in your datastore in plain text in the column right next to the hash!

What? Are you out of your mind?!

No! It turns out that even if the attacker has the salt and the hash, it doesn’t do them any good. Remember that storing plain hashes isn’t good because of precomputed rainbow tables. These tables are computed off of a large set of text passwords, not passwords with salts on them. The attacker would have to regenerate the tables using the salt from your database and since the salt is unique to each password, generating a different table for each password would take too much time to be a viable option. So using long unique salts is important. Something in the neighborhood of 128 chars should do it. The salts should be random and you should use a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) to generate them.

Why can’t I write my own hash algorithm?

So the attacker doesn’t know what it is and they can’t create a rainbow table for it, right? This is called security through obscurity and it is a very bad idea. Unless you’re a cryptographer and can prove that your algorithm is a secure cryptographic hash function, don’t go this route. Once the hashing function is reverse engineered, plain text passwords can be computed from the hashes. A rainbow table isn’t even required if the passwords fall out of the hashes if you shake them a little bit.

I forgot my password on site X and they sent it to me in an email. How does that work?

Well, they are storing your password in their system and it is vulnerable. Not to mention that they sent your password over the wire in an email that isn’t necessarily encrypted. Stop using that site and delete your account. Then email the site admin and have them read this blog. A coworker of mine ran into this very thing a couple weeks ago on a major home services provider site. This is still a real problem so spread the word and educate your fellow developers.

You can get the slides here and watch the presentation here (we talk about InfoSpace starting around the 25:00 mark).

Our journey began a little less than a year ago. We spent the first few months prototyping our architecture in AWS. During these months, we used this time to prove that our services could run in the cloud, evaluated cloud providers, and did some initial performance testing.

The real work started in earnest just after the start of 2013. In the past five months, we’ve organically developed a skilled team of engineers who are now well versed in all-things AWS: from VPCs, ELBs and ASGs to load-balanced DNS, Asgard and cloud security, we’ve built up a lot of skills and experience in a very short time.

Simultaneously with our move to AWS, we have had a project to consolidate our two datacenters down to one smaller presence. There’s a ton of logistical difficulties, contractural commitments and resource challenges we worked out – managing the timing and numerous dependencies was critical to the success of this project.

We’re going to cover several topics over the next few months about our plan to move out of the datacenters to the cloud, specific technologies and architecture choices we made, as well as how things are running as we gain more operational experience with it. Come back and visit our blog often as we chronicle our journey.

Upcoming topics

• Application architecture for multi-region deployments
• Global load-balancing using Route 53
• Fire and Forget: A performance testing approach
• Our Cloud-Ops approach
• Our resilient, redundant AWS architecture
• Lessons learned, landmines to avoid

Meanwhile, our Director of IT/Operations, Wayson, will start a series discussing our datacenter consolidation project.

We’re looking forward to sharing our experiences with you. And, if you’re looking for a great place to work with cloud technologies, InfoSpace is hiring!

Having been around the block in this industry, I have to say I was really surprised when I began working at InfoSpace. It really is unique!

Let me explain by giving you a peek inside at my experience over the last two months. If you’re someone who believes software engineering is as much engineering as it is art, then you’ll be right at home here. InfoSpace places a great deal of emphasis on the craftsmanship of writing code. So much so, they have several book clubs that read and then meet to discuss chapters from the book Clean Code, by Robert C. Martin. At the meetings, the groups get together to discuss what they’ve read. They debate the relevance of the points in the chapter, or share experiences about how what they read helped them improve their craft. Along these lines, InfoSpace provides a clearly stated definition of what is means to be ‘done’ with a given task. Included in that definition are incorporating unit tests for the code check-in and having a code review. Reviewers take time to offer suggestions of ways to make the code more elegant or more efficient. To put it another way, the focus is not just on getting it done, but getting it done right, even if that means it takes a little bit longer. Ultimately, everyone at InfoSpace improves as an engineer.

As part of that improvement process, they have bi-weekly ‘Lightning Talks’. Everyone gets together for some quick presentations on a bit of technology, engineering, or new idea that is trending in the software development industry. The talks let us share with one another something we just learned, or just think is cool. They’re a great way, and a fun way, for everyone to share their knowledge, expand their horizons, and speak geek with their coworkers.

The culture at InfoSpace is lighthearted. Folks here are social and friendly. Since I’ve joined, I’ve had several people introduce themselves to me and ask me how I’m doing. And many times during those conversations, they’ve mentioned how much InfoSpace encourages a work/life balance. While everyone enjoys working hard on their projects, InfoSpace recognizes their employees have lives outside the office. We all know it’s a competitive world, but pressuring employees to work nights and weekends only grinds them down. InfoSpace focuses on a healthy balance, acknowledging that folks need a chance to recharge their batteries. In addition to everything else they do, there are social gatherings, sometimes on Friday afternoons, to help keep things light. And InfoSpace has chosen to support a softball team this summer. It’s a testament to their commitment to work/life balance that I really have no idea how many hours I work each week. I think that says a lot.

All in all, joining InfoSpace is one of the best decisions I’ve made for my career, and my happiness, in a long time. When was the last time you couldn’t wait to get to work? For me now, it’s every morning.

These types of projects are the reason you got into computer science in the first place. Who comes up with the feature requirements? You do. Who defines the development process? You do. Who gets the glory when the project is the next big thing? You get the idea.

Engineer driven projects are becoming increasingly important to keep businesses relevant and evolving. They keep products fresh, technology fresher, and can help make a lot of money. You should be a leader in your company to push this movement forward. You should be an intrapreneur.

Where do I get ideas for projects?

The first criteria for picking a side project is that you are excited about it. No one is asking you to get this work done so if you’re not exciting about blazing the trail with your ideas and passion, the project isn’t going to go anywhere. You should feel a deep sense of ownership that its fate is in your hands. No one is going check up on it and see how it is going. Own it. Get it done. Next, start listening. Everybody’s got problems. Listen closely to the problems that are opportunities for improvement. “I wish I had a tool that…”, “Our API is clunky, I wish…”, “There gotta be a better way to do…”, there is no shortage of needs if you are listening for them. Keep a catalog of potential ideas and keep listening even when your bandwidth is maxed out and save them for later. Now that you have a list, you just need to pick one. Pick the one that you are both excited about and has the largest potential impact. Imagine the smiles on the faces of the people when they are pleasantly surprised that you secretly fixed their problem in your spare time.

What is Success?

It depends on what you’re trying to accomplish. Some projects are internal to your team and success is other team members approving your code branch to be merged in. Some are small independent tools that are developed end to end and given directly to the end user. If they use it and it is helpful, success!

My favorite type of project is the new product feature proof of concept. Success means proving that the concept of a large scale change works or it doesn’t. The end result needs to be testable and verifiable to be valuable. Product developers are always looking for fresh ideas that they can confidently invest in. If you prove your own ideas should be invested in, you’ll get the resources to do so. And you’ll likely be the visionary that will get to lead it to even more success.

The Best Part

The best part is that it’s all risk free. If you try something new and crazy and it flops, who cares. All you’re out is the spare time it took to build it. Now, don’t get me wrong, time is very valuable and I don’t recommend failing. Time working on a failing idea could be spent on a successful one, but if you do fail, learn something and move on to the next project.

The second best part is that you work for a company that (likely) has resources. You have access to people, software and hardware (you might need to get permission first) that can help you succeed. As long as you can fit it into your spare time and your ask isn’t too taxing.

Ok, But…

It sounds like I’m going to be doing a bunch of optional hard work. Why should I work so hard for a company that doesn’t care about me? Well, you shouldn’t. If you truly believe your company doesn’t care if you innovate or not and you don’t see other innovators being rewarded for their achievements, do yourself a favor and find a company that does. Many companies know the value of intrapreneur innovation and you should find one of those. Oh, and InfoSpace is hiring.

Continuous Integration also encourages us to check in early and check in often. Checking in early and often helps us decrease the surface area of our change, thus decreasing the amount of code that can introduce bugs in the system. Checking in early and check in often becomes even more effective when it’s coupled with unit/behavior tests. Having unit/behavior tests allow us to ensure consistency in functionality and behavior across changes. It gives us the confidence that our change, no matter how small, hasn’t changed the behavior of the system. It also allows us to ensure that previous bug fixes and features continue to work as designed. Most importantly, having tests allows you to identify areas of the code that can be cleaned up, refactored, or just don’t behave as expected.

So you may be asking yourself what all this has to do with automating builds for Android^TM applications. Strictly speaking automating Android application builds consists of:

• Having a machine setup with the latest version of your software (and optionally signing certificate for release builds)
• Triggering a build given some set of conditions
• Archiving the build somewhere.

Here’s where the introductory paragraphs become important. I would argue that having a reliable automated Android application build consists of the following in addition to the minimum requirements above:

• Having your source version controlled
• Having unit/behavior/integration tests that verify the functionality of your software
• Being able to trigger an Android application build from source control commits and have that build run the tests each time.

That’s exactly the system we’ve built here at InfoSpace to automate our Android application builds. Here’s a high level walk through of our automated build process.

The Tech

The Workflow

Our workflow varies per Android project depending on the build task (building and testing our libraries, building our release APK’s, or etc).

Our process

The Gotchas

The first gotcha is that the built-in Android application build test ant task ALWAYS returns a success exit code for its process regardless of whether or not the tests fail. This means that we can’t fail the build during the test portion of the build process if the project compiles but fails the tests.

The second gotcha is that you can’t run any of the ant tasks in the post build process. If we could do that then we’d have a way to work around the first gotcha by running the “Text Finder” plugin, which will fail the build, before running the ant task to build the release bits.

So what we’re stuck with right now is a scenario which isn’t ideal but is functional. If someone checks in code that compiles but doesn’t work functionally (i.e. the tests fail) it will still drop the release bits to our Dropbox archive. But we’ll get notified that the build failed and know not to use those release bits. Dropbox allows for file history so we can get the last known good build from Dropbox. But in the even that we can’t get it on Dropbox we take advantage of the ability to archive the build bits via the Jenkins project directly on the build server. If we needed to we could always go back and get the last known good build directly from Jenkins.

What’s next

We’re going to take a look at the new Android Studio and see if this can aid in overcoming the gotchas in our build process.