Android Build Variants

One of the cool things about developing an application for the first time is learning something new at every step of the process.  Sometimes the learning is easy-peasy, and at other times you check the mirror every few minutes to see if you’ve sprouted any grey hairs.  But no matter the difficulty, getting through that obstacle is one of the best feelings a developer can experience.

Looking back, one of the most annoying obstacles I encountered was the creation of build variants for the application.  In order to explain build variants, it might help to understand why we need them in the first place.  Most applications today make network calls to servers to perform operations behind the scenes. In order to do that, an application needs a server that handles specific requests to store, retrieve, or change data.  So, when you pull up an application as a user, you’re probably doing some communication with a server somewhere! However, while you use the app, developers are out there working on that application to make it better.  They might be building a new feature into version 1.1 while you’re still on version 1.0.  In order to work with version 1.1, the server needs to be updated! Well, what if the developers changed the server you’re using to help them test their version? Chaos! That’s where a development server and a production server come in.  One is used by the development team and can be changed and messed with as much as they want, and one is always used for the application end-users, the people who need consistent functionality.

Still with me? Great. Now let’s think about the front-end, the application itself. You’re a developer, and you need to be able to use both aforementioned servers.  You need to be able to tell your phone to communicate with the development server to test new features but also quickly be able to tell it to talk with the production server to replicate bugs that are currently out there in the real-world.  How do you give the application this flexibility? You guessed it, build variants.

The phone and servers communicate using an Application Programming Interface (API).  For instance, an API might specify a method called /get_countries. The phone visits the API and specifies that method, and the server returns all the countries that are in its database.  Easy, right?  Usually this method is appended to a URL, like so: https://appproductionserver.com/get_countries. That might be the production URL, while the development URL is https://appdevelopmentserver.com/get_countries.  So, when I build my application to test, I need to make sure all calls go to the URL with development in it, and the production version calls must go to the URL without development! If there are just a few calls made in the entire application, it might be easy enough to make the change manually in the code. But most applications will have dozens and dozens of calls to different methods being made in different classes, and it’s just not efficient to do a manual change. So, how can I change ALL the calls in my codebase with the click of a button? Let’s find out!

In an Android project, the normal file path to the codebase is app/src/main/java/my/package/name. Inside your main package sit all of your classes.  Well, we can create different build variants using a few simple steps:

  1. In app/src, create two folders that will sit alongside the main folder–for example, prod and stage.
  2. Inside those two folders, create a file structure that replicates the one in the main folder. So if main contains java/my/package/name, then your prod and stage folder should contain java/my/package/name.
  3. Inside the last folder (in this case the “name” folder), create the class that needs to change based on the variant.  For example, maybe you have a URL.java class, which specifies ALL of the URLs for the application. In the stage version of the class, all of the URLs are to the test server, and in the prod version all the URLs hit the prod server.

Great, now we have the correct file setup. Next we need to tell Android Studio how to find them.

In our build.gradle file, we need to specify the product flavors:

productFlavors {
    prod {
        applicationId "my.application.prod"
        minSdkVersion 16
        targetSdkVersion 23
        versionCode 14
        versionName '0.3.6'
    }
    stage {
        applicationId "my.application.stage"
        minSdkVersion 16
        targetSdkVersion 23
        versionCode 15
        versionName '0.3.7'
    }
}

Once we do this, we can easily go to “Build” in the toolbar, and choose “Select Build Variant”. You’ll see four options there: prodDebug, prodRelease, stageDebug, and stageRelease.  You’ll mainly toggle between the debug options, and only use prodRelease when you’re ready to build and release a new production version! Don’t be worried if your compiler freaks out and throws a ton of errors when you switch variants, just do a project clean and they should resolve!

Hopefully this article has helped you to understand the need for build variants and how to implement them.  You can also use them to specify different names for the application like “MyApp – Dev” for development and “MyApp” for production.  I’ll leave you to figure out how to do that (Hint: You’ll want to replicate a strings.xml file like we did for our URL.java file)! That way, you can install both versions on your phone at the same time and tell which one is which!

Was this helpful? Have any other tips for build variants? Please let us know in the comments below!

Happy coding!

Sincerely,
Brandon from The Bunch

Merry Christmas

This week’s post is a little shorter than usual; for the first time since our launch, all LunchBunch developers will be in the same physical location, which means a lot of traveling and some time off for the holidays. We won’t be releasing any LunchBunch updates during this time, but while we’re together, we’ll be brainstorming new ideas and figuring out our plans for 2016. It’s been fun to work on LunchBunch under colored lights while listening to Christmas music, and we’re excited that Christmas is almost here!

We hope that you and your family have a joyful Christmas season–Merry Christmas from all of us at LunchBunch!

Sincerely,
Ryan from The Bunch

The State of the Union LunchBunch

We hope this blog has been interesting to follow and helpful for understanding LunchBunch–who we are and how to get the most out of your app experience.  We have been hard at work since our initial launch adding new features, fixing bugs, and enhancing the look-and-feel of LunchBunch.

My optimistic estimate of downloads during our first month was 50-100.  However, within 24 hours of our launch, we had surpassed 100 downloads, and a few weeks after that, there were over 250 LunchBunchers.  That’s pretty exciting, especially because we haven’t started our big marketing efforts yet–but marketing is next on our agenda, so stay tuned for details in a future post.

We are on Facebook, Twitter, and LinkedIn, so be sure to

!

Weekly blog posts and app information will be available on all of the social media links above, and we also have a mailing list which you can subscribe to in the sidebar on the left (or above if you’re on mobile). (P.S. you can sign up now ↖ if you haven’t already 😉)

Some of the features in our next few updates:

  • Search your contacts for friends who already have LunchBunch to make it easier to add buddies
  • Timed broadcast will automatically stop your broadcasting after a certain interval so that buddies know when you no longer are hungry
  • Restaurant integration will allow you to receive coupons, event notifications, and suggestions for local places to eat. (If your restaurant is interested in partnering with LunchBunch, please let us know).

So that’s a little bit about how things are going at LunchBunch. Again, we’ll be posting updates on Facebook, Twitter, and LinkedIn, and our mailing list. In the meantime, if you have any questions or comments, please let us know in the comments below!

Sincerely,
Ryan from The Bunch

Mobile Push Notifications

Push notifications have been around for only five and a half years, but today, it’s hard to imagine smartphones without them.  Push notifications seem simple–just alerts you get when an app has new information for you, right?  Ostensibly, yes.  But they’re so much cooler than that, and there’s a lot going on behind the scenes.

I work on the backend for LunchBunch, so most push notifications originate from the servers on my end of the application.  Information that needs to be sent to individual devices is delivered using a combination of Amazon, Apple, and Google servers before being displayed to the user.  The alert message that the user sees is usually only a small part of the payload; bundled with the alert can be all kinds of preconfigured options, like the sound to play when the notification arrives, what to do when the notification is opened, whether the app badge (the red circle on the app icon that lets you know when there’s unread content) should be incremented, and all kinds of other platform-specific actions or custom data.

Custom data can be very useful to include in a push notification.  It’s not visible to the user, but it provides information to the application that makes responding to the notification faster and more accurate.  For example, when you get a notification from LunchBunch that says someone has accepted your buddy request, that push notification also includes invisible information about the user like their username and real name.  Now when you open the app, that buddy will appear in your buddies list without having to refresh or sync with the server over the internet.  Pretty cool, huh?

In fact, sometimes all we care about is getting the data to the device, and there’s no need to bother the user with a visible alert.  In these scenarios, we can send a silent push notification. This isn’t just an alert that comes through without sound–the user actually won’t ever see the notification.  This allows the application to be updated in the background so that all of your information is up to date when you open the app next–just like in the buddy-request example above.  There are many times when this is useful, but the most straightforward example may be buddy removal. Let’s say you want to remove a buddy permanently from all of your bunches. It would be a little awkward to alert that user with a message that says you’re no longer friends. Instead, a silent push notification is sent that the other user’s device will receive and act upon (removing you from all of their bunches) without the user being notified.

We’ll be posting some technical articles for developers interested in integrating push notifications into their iOS/Android apps, and if there are any topics you are particularly interested in, please let us know in the comments below!

Sincerely,
Ryan from The Bunch