READ THIS FIRST

Update: 3-4-2016: If you're finding this blog and looking for information related to Azure Mobile Services, I'd strongly recommend checking out Azure Mobile Apps. Azure Mobile Apps is a new version (consider it a v2) of Azure's mobile backend support. All of the same features of Azure Mobile Services are there, with a lot of other very cool features to go along. You can read more about Azure Mobile Apps, and how to transition from Azure Mobile Services, here.

SplashScreen for LensRocket Update 2/20/2014: Due to a few issues, the app formally known as PikShare has been renamed LensRocket. Everything except some names remains the exact same as the originally released source code and application.

Today I’m happy to announce I’ve released the source code for LensRocket.  LensRocket is an Android app which allows users to share photos and videos with each other.  The sender can also select how long the recipients have to view the pictures and videos.  This probably sounds familiar because it’s how the very popular app SnapChat works.  LensRocket was built to demonstrate that Windows Azure, and more specifically Windows Azure Mobile Services, could be used to quickly get a mobile application off the ground and running.  More so, it shows that Mobile Services is fully capable of working as the backend for a serious mobile application and in this case, a social app.  You can easily set up this demo yourself by signing up for a free trial for Windows Azure here.

What does the app do

If you think about the core capabilities of an app like this, there really isn’t that much to it.  First, users need to be able to register for an account and then later they need to be able to log into that same account.  From there, users should be able to find other users and become “friends” with them.  Lastly, users should be able to record media, whether it’s pictures or video, and send them to those “friends”.  Now, if that was all an app like SnapChat allowed you to do, it would be hard to imagine it having become so popular.  The real reason SnapChat’s took off was that it makes the media ephemeral (a fancy way of saying it only lives for a short time).  Specifically, users have the ability to decide for how many seconds that image or video is available for their friends to see.  If you think about what that feature means, it makes sense how it’s made SnapChat so popular.  In today’s world of “once it’s on the internet, you can’t get it off”, having some degree of assurance that things will actually be deleted feels pretty good.  That being said, there certainly has been some controversy over whether or not SnapChat actually deletes the files in addition to other apps being made that attempt to grab the files off your device.

How does Azure help us

If I have a great app idea, I definitely want to get my app out there and fast.  Any delay means someone else can beat me to market and my app won’t become popular.  Thankfully Windows Azure has a number of features that make it super simple to get all of the backend features I need but don’t have to spend the time designing, developing, testing, and maintaining them.  For LensRocket we need to be able to authenticate users, store information for users, friend connections, and the files they want to share, actually store the files, as well as push notifications down to our users.  Now, like I said before, this really isn’t a huge amount of stuff.  However, if you think about the time it would take to design systems to handle all of these capabilities, then develop them, then test them, then load test them to make sure they can scale, and then maintain them as my app grows, that is a LOT of time.  Not to mention that is all stuff that will take away from building a really great client experience.  Thanks to the different pieces of Windows Azure, I get the ability to do all of that stuff with very little work on my side.

What parts of Azure does LensRocket use

First and foremost, LensRocket is using Windows Azure Mobile Services.  Mobile Services is what’s known as a Backend-as-a-Service (or BaaS).  The idea is that you spin it up and get access to a ton of features without having to do much work.  If you haven’t looked at Mobile Services before, I highly advise taking a look through some of the tutorials or videos to understand how it works.  For our Mobile Service we’re using both the built in data storage (using SQL Database) as well as the Custom APIs.  We’re also making heavy use of the scripting layer to put in custom logic as well as to handle our own user registration / authentication system (Mobile Services has built in authentication with Facebook, Google, Microsoft, and Twitter accounts but we’re rolling our own).  Mobile Services has us completely covered for all of the relational data we need to store.  For our file storage, we’re going to use Windows Azure Blob Storage.  Blob storage allows us to store both photos and videos extremely cheaply and gives us a way to secure those files so we can make sure only the appropriate people have access to them and only for the appropriate amount of time.  Lastly, we’ll use Windows Azure Notification Hubs to handle push notifications.  Mobile Services has the ability to handle push notifications built into it, however, using Notification Hubs means I can easily set up templates for my pushes (for when I have this app running on more than just Android), do tag based pushes (i.e. easily perform a push notification to all of a user’s devices), as well as many other things.  All of this without me having to build anything into my backend (i.e. keeping track of each user’s devices and what OS they are on and whether or not they want to get pushes, etc).  One thing that is phenomenal about both Mobile Services and Notification Hubs is that they have a free tier.  While storage does not have a free tier, storage is so cheap that I’d have to be storing several gigabytes of picture / video data before I’d even have to pay a dollar a month (Storage has two costs, the actual storage and transactions, however both are cheap).  What this all means is that I can easily develop my app against Windows Azure for nearly free and then, when my app is released and usage goes through the roof, I just need to drag a slider to scale up my Mobile Service and Notification Hub (Storage doesn’t need to be told you want to scale, you just put more data in when you want to). 

Tell me about the code

The source code which is available on GitHub under the Apache V2 license, includes both the Android client java source code as well as the Mobile Services scripts (which are javascript).  Once you’ve pulled the code down, you’ll find the Android code in source/client and the scripts in source/server.  The Readme file includes instructions for how to set up your Mobile Service, Notification Hub, and Storage account as well as where to put the different account names and keys in the client and server code.  I’m going to have several different blog posts talking about different pieces of the app (from both a client and server side) which will go into more detail about what’s going on in the source code but it should be pretty easy to dig around and understand what’s going on. 

WARNING!

This is where I’d like to spell out a few caveats and warnings about the code.  I put this application together quite quickly and therefore, it’s far from what I would consider a golden example of Android source code.  If I had more time, things would be better refactored and cleaned up, I’d move more things to background threads, and the camera code would be much better.  Specifically on the camera point, I ran into some serious issues while testing.  While I think a lot of the “Android Fragmentation” talk is overblown, working with the camera to do photos and videos is one solid example of where this is a serious issue.  I tested the application with a LG Nexus 4, a Samsung Galaxy Nexus, and a Samsung Galaxy S3 and the only area I ran into any real issues with one device working one way and the others working differently was with the camera (with a slight mention for the Action Bar / Status Bar).  I’ll probably detail it in a full post because it was quite complicated to work through but, suffice to say, I actually had to put code in the application specifically for the Galaxy S3 (pictures taken with the camera weren’t properly rotated and I had to do it manually with bitmaps) and the Galaxy Nexus.  Now I’m sure I could find more elegant and MUCH more efficient ways of handling the issues I ran into, but at the end of the day, this is not meant to be a shining example of how to build a perfect Android app, but how to build a really solid app that is based off of something insanely popular and  is using a scalable backend based in the cloud.  As time allows I’ll continue to refine and improve the code for this app.  if anyone would like to walk through it and provide feedback or suggestions, I’d happily hear them (or you can file issues in GitHub).

Can I use this code for my own app?

As the source code for this app is licensed under the Apache 2 license, you’re free to do anything allowed therein, except hold me liable for it.  I would highly recommend testing the client side code on more devices before launching anything in a public market though.  The same goes for the server side scripts.

What’s next?

I’m hoping to release a version of this to the Google Play Store so that you can test it out without having to set everything up yourself.  That should happen in early January and I’ll be sure to let people know (via this blog and Twitter) when it does.  I’d also like to go back and test the client side code on more devices as well as clean a few things up when time allows.  As I said above, there is a lot of code that touches the camera that I feel could be more efficient and I know there are a few things I could move over to background tasks.  Additionally, there are steps that could be taken to make the app run a little better for the user like prefetching the media files.  However, I think the next step for this will be to build an iOS version.  I had started the ground work some time back (at one point I was trying to build the iOS and Android versions at the same time but quickly abandoned that idea).  Now that I’ve tested my backend with the Android version, I can focus 100% on the client side while doing the iOS version.

Summary

LensRocket is a pretty powerful example of how Windows Azure can help you not worry about everything that goes into building a backend and instead focus on making a good client experience.  In time this should become a great cross-platform example as well.  For now, take a look at the Android and server side source code on GitHub.


Chris Risner


5 Comments

Chris

It's difficult to tell without knowing the specific error you're getting but my guess is that you missed the step in the "Client Application Changes" section where you need to pull down the ActionBar Pull to Refresh Library. For legal reasons, that library isn't included in the source of LensRocket so you need to pull it down yourself.

Chris

Those are script files for a Mobile Service. So, first create an Azure Mobile Service and follow the steps in the readme to create tables and custom APIs. Then clone your script repo locally using git. Copy the script files over, and then push them up to your Mobile Service (again using Git).

Leave a Comment