The Nexus 4 was already a fantastic deal at $300 off-contract but now Google has lowered the price by another $100 presumably to clear inventory ahead of the Nexus 5. I bought mine at $300 and love it. At $200 it’s an unbelievable deal and I highly recommend snagging one, especially if you intend to do Android development.
Finally, we will set up our Ruby environment for our server code. We will use Ruby 2.0 and Rails 4 to develop the server-side component of our application. You could download and install Ruby directly but there are a few tools out there now that will handle that for you, allowing you to install and utilize multiple versions/flavors of Ruby on your machine. The two most popular are rbenv and rvm. Both have their strengths and weaknesses, but in general I prefer rbenv because it doesn’t get its hooks into your terminal quite as deeply as RVM. That sort of thing counts when in a production environment.
To install rbenv, open your terminal and run the following command
git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
This will check out the rbenv project into the .rbenv directory in your user’s home folder. Next, edit the ~/.bash_profile file so it matches the following:
ANDROID_HOME=~/android_sdk RBENV_HOME=~/.rbenv PATH=$RBENV_HOME/bin:$PATH PATH=$PATH:$ANDROID_HOME/platform-tools PATH=$PATH:$ANDROID_HOME/tools export ANDROID_HOME RBENV_HOME PATH eval "$(rbenv init -)"
The placement of the rbenv binary directory in the $PATH is important. It has to come first so the binary shims it creates are the first thing your shell references when you type ruby commands.
The last line in the profile is also important. It adds support for shims and autocompletion in your shell. You can run the command by hand to see the output if you are curious.
Next, we will install the ruby-build rbenv plugin to simplify the process of installing new Ruby versions. You can run the following command to check out the latest code and place it in the plugins directory of rbenv:
git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
Once this has completed you can use the
rbenv install command in your shell to install the latest version of Ruby 2.0 (p247 at the time of this writing):
rbenv install 2.0.0-p247
You will see some output about downloading various packages and then downloading and installing Ruby itself. Go take a coffee break or something as this can take a fair amount of time to download and compile. Once it’s done you should see something like this:
Once it is done installing we will make Ruby 2.0 our default ruby by running the following
rbenv global command:
rbenv global 2.0.0-p247
Next, we will install the
bundler gem. You should close and reopen the terminal to make sure you are using the correct version of ruby. I set the global version to 2.0 but it still insisted on using the 1.8.7 version installed with OSX until I restarted the terminal.
gem install bundler --no-ri --no-rdoc
We specify the –no-ri and –no-rdoc options because that just downloads documentation which is already available online. I personally feel those options should be the default, but the people who maintain the
gem program feel differently.
Now we will do the same thing to install the latest version of Ruby on Rails
gem install rails --no-ri --no-rdoc
With all of this complete, we will do one last thing to ensure we have rbenv shims for the executables that came with the gems we just installed:
That’s it! We are now ready to start developing!
…But not so fast. In our next installment we’ll start laying down some basic requirements for what we want to accomplish, as well as doing some investigation of our “competitors”.
First we will download and install the Android SDK. This is what contains all of the tools needed to develop Android applications. Go to the SDK page and click the “Download the SDK” button
Scroll down, accept the license agreement and click “Download the SDK ADT Bundle for Mac”
Once the SDK has finished downloading, unzip it. You will see two folders: ‘eclipse’ and ‘sdk’. If you intend to use IntelliJ as I am, you can ignore the Eclipse folder. If you’re used to Eclipse or just like it better, I won’t judge. Drag the Eclipse folder somewhere and put the binary somewhere on your tray.
Either way, move the ‘sdk’ folder into your home directory and rename it to something like ‘android_sdk’.
Then add the following into your ~/.bash_profile:
ANDROID_HOME=~/android_sdk PATH=$PATH:$ANDROID_HOME/platform-tools PATH=$PATH:$ANDROID_HOME/tools export ANDROID_HOME PATH
This will add all of the binaries in both tools and platform-tools into your $PATH variable.
If you prefer to use Eclipse, skip this section.
IntelliJ is really easy to download and install. Head on over to JetBrains’ website for IntelliJ and download the Community Edition. If you feel so inclined you can purchase the Ultimate Edition, but the Community Edition does just fine as well.
Once you have downloaded the DMG file, open it and drag the IntelliJ icon into the Applications folder. Wait for the copy to finish, then you can umount the DMG file and delete it.
Now go ahead and click the launchpaid icon on your dock (or do the sweet 4 finger gesture on your trackpad) and launch IntelliJ (or Eclipse from wherever you may have put that).
Ha! When I originally wrote this up I had us installing JDK 7 as the first step, then installing the Android SDK and IntelliJ. However even though I had Java 7 installed and on my path both Android and IntellJ were demanding Java 6, so instead of fighting it we’re just going to go with the flow. So once you attempt to open IntelliJ you should see the dialog below
Go ahead and click “Install”. OSX will begin downloading Java 6 for you.
Once the download is complete the software will be installed and you will see a dialog similar to the one below
Now we can complete the installation and setup of IntelliJ. You should be presented with a dialog notifying you that IntelliJ was an application downloaded from the Internet. Just click through. You will then be presented with a dialog asking if you would like to import settings from a previous installation. Select “I do not have a previous version” and click “OK”.
iOS Development Setup
The first tool to install is XCode, because XCode and the XCode command line tools are required for other tools to be installed later. Open up the App Store either via the icon or via Spotlight (Cmd + Space). Once the App Store is open, in the upper right search for “Xcode”.
Click on the first result and click the “Free” button. It should then change to “Install App”. Click it and go watch Netflix or something. It’s a 1.6 gig download.
Once XCode is installed, go ahead and open it up. Accept the license and then install the Device Support package you will be prompted to install
Once the Device Support package is installed click on the “XCode” menu in the upper left and select “Preferences”
You will be presented with a dialog. Click the “Downloads” icon towards the upper middle of the dialog and then install the command line tools as well as the simulators. Go watch more Netflix because it’s another 1.7ish gigs to download.
Once you have downloaded and installed the command line tools, open a terminal window and type “git –version”. If you see something similiar to the screen below your command line tools are properly installed.
Next we will install Homebrew, a package manager in the same spirit as apt-get, yum, etc. While we don’t need it right this second it is invaluable to have installed so we might as well get it done now. The install instructions are further down the page and call for you to use curl to pipe a file you download into the Ruby interpreter that comes with the XCode command line tools. A lot of people will warn you against piping a script right into an interpreter in your shell, but those same people will usually download a DMG or PKG file and blindly install it without batting an eye. At least with this method you can inspect what the script(s) are doing before you run them by downloading and reviewing before you run them.
Once you have installed Homebrew you should be able to type “brew” in your terminal and see output explaining the different options for the command.
Alright! Our iOS development environment is installed and now we are able to install our other tools.
Because this guide is supposed to be for a full stack application, I am going to make a few assumptions. The first assumption is that you will want to put your app in the Apple App Store, and that you will want to not go through the pain of attempting to develop an iOS app on a platform other than OSX (Windows, Linux, etc). I talk about purchasing hardware in this post.
With all that in mind and assuming you bought yourself a Mac, lets go ahead and get our development environment set up.
So back at the beginning of this year I started this blog with grand plans to write a long series of tutorial posts on how to do a full stack project: server, iOS and Android coding along with setting up beta testing, trying my hand at design-related topics, how to manage the app and the infrastructure after you go live, etc. The only problem was I never really had a solid app idea in my head when I started writing posts. As the time went on I got a little discouraged because I didn’t want to rehash some been-there, done-that programming trope like a to-do list or a Twitter client, so I decided to put it on the shelf for a bit and focus on my job. In the intervening months I have transitioned from a mobile developer to a devops engineer at work, which has added a new wrinkle to my repetoire of…wrinkles? Skills, I guess. So I will also be adding in how to provision and manage the infrastructure of your app as well.
Interestingly my brother-in-law is a huge trivia buff and in facts runs his own trivia nights at bars in NYC. He’s developed a huge range of content (questions) and his own visual style and everything. We discussed taking his library of questions and IP and translating them to a mobile game. I hadn’t really ever found time to get started but then it occurred to me that it would be the perfect app to detail creating on this blog, since when you get down to it a good trivia game is just asking you questions, and all of the “secret sauce” is in the content itself. The actual app itself is just a delivery mechanism for questions and answers and as such can be developed out in the open as far as I’m concerned.
So to that end, I present to you my intent to write the Fly Biosphere trivia game for iOS and Android (and maybe Windows Phone if I’m feeling super adventurous). I’ll kick it off with a post about setting up my dev environment in the next week and then we’ll really get into the meat of planning an app like this and then executing on it. Here’s to hopefully getting it done before Christmas!
So it’s been well over a month since my last post so I wanted to post a brief apology. I spent most of the month of February putting in a lot of late nights and a few weekends at work and just didn’t have the mental energy to do any writing. However I will start writing new posts each week moving forward. I’ll do a post on setting up our development environment, as well as one on learning resources before finally diving into design and implementation of our full-stack application.
Before we endeavor on this journey I feel it’s important to note what kind of hardware investment you will have to make if you want to take native mobile app development seriously. I am assuming that if you are reading this series on multi-platform mobile app development, you’re going to want to do iOS development. While you can do Ruby on Rails and Android development happily on Linux and (maybe less happily) on Windows, you can’t reasonably do native iOS development without OSX, and that means investing in some Apple hardware.
As of this writing (January 30th, 2013), you can obtain a Mac Mini with the following specs for $699:
- 2.5 Ghz dual-core Ivy Bridge Core I5
- 8 gigs of RAM
- 500 gig spinning HDD
Note that the Mac Mini does not come with a monitor, so you will need to purchase one of your own. Apple will try to sell you a 27” Thunderbolt display for $1,000, but that’s utterly ridiculous. Go to Newegg and see what you can find there if you don’t already have something laying around. You will most likely need to get your hands on a Mini DisplayPort-to-DVI adapter assuming your monitor of choice has DVI. There are also adapters for HDMI and VGA, if that’s your particular method of display output.
If you have a little more to spend, you can think about an iMac but having spent the past few years using a laptop (Early 2011 15” Macbook Pro) as my primary computer for work, I can’t imagine being chained to a desk anymore. To that end, I recommend getting yourself a 13” Macbook Air if you have the scratch for that sort of thing. As of this writing, you can obtain said Macbook Air with the following specs for $1699:
- 2Ghz dual-core Ivy Bridge Core I7
- 8 gigs of RAM
- 256 gig SSD
On paper these specs are worse than the Mac Mini I detailed above but having seen people with Macbook Airs at work, they are fantastic machines and the SSD will give you a huge speed improvement over a spinning drive. You can still hook up an external monitor and a bluetooth mouse to it if you like, and get the freedom to work anywhere you please (within reason). If you can afford it, this is the route I suggest.
While it is true that both mobile platforms offer simulator/emulator functionality to develop with and test on, there is no substitute for testing your app on an actual mobile device. Let me say that again: there is no substitute for testing your app on an actual mobile device. iPhone simulators are feasible to use but Android emulators (note the different words there, simulator and emulator?) are intolerably slow and should only be used for running unit tests as well as odd OS versions or display sizes you don’t want to purchase actual hardware for.
As I write this the most popular devices are the Samsung Galaxy S3 and the iPhone 5. Both of these will cost you about $600 without a 2 year contract so it’s not going to be a cheap investment. You can mitigate this slightly by purchasing a Nexus 4 which comes unlocked for HSPA+ for $300 and an unlocked iPhone 4 for $450. This will shave $450 off the cost of your device investment. T-Mobile has some nice month-to-month plans with 5 gigs of data, unlimited texting and 100 minutes of voice for around $30 a month as of this writing, so you don’t have to be locked into a contract for your test devices if you so choose.
You may be wondering about tablets but I would caution to you wait. I intend to write the initial version of the app only for phones to keep the complexity down. If you’re truly set on writing a tablet-specific app, you could get yourself a Nexus 7 (I have one and love it) for $200 and an iPad Mini for $320 instead of the phones I listed above.
View these costs as an investment in your learning and your ability to make money later on with your well-written, well-tested apps. It’s also a good excuse to buy sweet new gadgets.
One of the main goals I had when I started this blog was to scratch one of my own itches. As a professional mobile developer I regularly go out onto the Internet looking for information related to my day-to-day development. The thing I’ve noticed is that each place I go specializes in one aspect of app development. There’s places to go for Rails, for Android, for iOS, for design, etc. The problem is that enterprising indie app developers have to master all of these things at once. I’m sure somewhere out there are resources that cover writing apps for both major mobile platforms that include a server back end but I think this would be a good opportunity to write the information that I find I need as I go about writing my own apps this coming year in the format I need it.
To that end I am going to write a series of posts covering every aspect of app development and maintenance a multi-platform app developer will need to spend time thinking about, with the ultimate goal of compiling the knowledge into a book, either digital or dead tree (or both) before the end of the year. Here are some of the topics we’re going to cover…
This will involve identifying an opportunity (real or imagined), doing some mind-mapping and coming up with a basic list of initial requirements.
Once we have an idea and a basic set of requirements, we can start laying out some basic designs to start working from.
Wireframing is the fun part, but spending time thinking about how the back end will go together will pay dividends later on. This includes preliminary designs of how your server-side API will be laid out and consumed.
I lied, the fun part is actually making your vision come to life. This will involve Android, iOS and (presumably, unless I change my mind) Rails coding in large doses. I will purposely write the code in a manner that will lead to refactoring so we can see how that affects your development and how to learn from past mistakes in future endeavors. No one ever gets it completely right the first time.
Making it all look pretty
Once we get some functionality in place, we’ll probably realize that while functional, the app will almost undoubtedly look like a steaming pile of interface only an engineer could love. We will devote time to cleaning up both the mobile and web portions of this. We’ll dive into CSS, platform-specific design patterns (the visual kind), as well as creating graphical assets for multiple screen resolutions.
No developer worth his or her salt writes anything meaningful without having some sort of automated tests to make sure the important parts are protected from idiotic mistakes made at 3:00 AM (and those will happen). I don’t care if you write tests before or after, just as long as they’re there and covering your ass when it counts. We’ll also touch on continuous integration to really amp up the usefulness of our tests.
In order to gain insights into our customers and how our products are being used, we’ll discuss how analytics factor into our planning and development, as well as post-development support and tweaking.
App store submission and pricing
While a lot of people do this sort of thing just for the enjoyment of programming and the thrill of knowing people are using your app, most of us have bills we need to pay. To that end we will focus on payment processing, app store submission and pricing schemes. I might even throw in a little research on marketing if I’m feeling saucy.
Other unforeseen complexities
Other things will come up for sure. I’m going to try and make this as complete and end-to-end as possible. I will attempt to reign in the scope creep but it’s important to me that this end up being a one-stop resource for anyone looking to create a mobile app and control all aspects of the design and development
This will be a learning experience for me as well so this will all be written from the perspective of someone who is an intermediate at Android development, an advanced novice at Rails and a beginner at iOS development. Also, I’m terrible at graphic design, like most engineers I know, so I’ll be in the same boat as a lot of you.
I’ll try to get a few guest posts, and I’ll definitely be submitting my work to subject matter experts to make sure I’m not completely off base. Also, a colleague of mine complained that a lot of these kind of resources are too basic so I will definitely attempt to tackle some advanced stuff once the basics are in place.
I have some ideas for apps specifically for this blog but I’m curious if anyone has any suggestions for what they’d like to see created. Know that at the end all of the code will be open source so if it’s your Next Big Thing™, you may want to hold onto that for yourself. Hell, use these posts as a way to write your own Next Big Thing™ when it’s all said and done.
The act of making some new year’s resolutions and then promptly ignoring them is a time-honored tradition of mine. Each year I tell myself I’ll get some income going on the side, I’ll teach myself a new language or two (spoken and programming both), I’ll write some code for open source projects, etc. It always ends up being lots of plans and then it all devolves into playing endless video games. While I don’t think I’ll ever completely stop playing video games since that’s my outlet to release stress, I’ve already got a good start by getting this blog up and running and forcing myself to post to it. To that end, these are my goals for the year:
- Write a series of blog posts about creating a multi-platform mobile app including server component.
- Turn that series of blog posts into a well-formatted, well-written ebook.
- Attempt to set up some sort of passive income and reach a goal of $300 a month (cover a car payment)
- Work with my brother-in-law to create a multi-platform trivia game
- Contribute to some open source projects
It will be interesting to revisit this post on January 20th, 2014 and see what I was able to accomplish.