Controllers, Directives, and Services. AngularJS 101

So you want to get into AngularJS. You’ve probably heard about it being a great framework or platform and that sounds like something you should be using. You might have seen a few great demos of data binding and wanted to incorporate that into your project. Then you take a look at the docs… you get lost. You read some things online and now your learning about dependency injection, model view controller, declarative programming…  maybe even lambda calculus. All you wanted to do was bind a variable into your page. Let me run you through the core concepts you should understand – you’ll be able to run with them and start developing with AngularJS right away.

So where do we start? Well we need some HTML. So let’s open up your favorite code editor and markup some HTML. I use Sublime Text. Here’s what you should type up.

<html>
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
    </head>
    <body>
    </body>
</html>

So what did we do here? Well for the most part its just some standard HTML markup. I also added a script tag that includes the angularjs file directly from a Google CDN. Why download it? If you save this file and load it in a browser, you won’t see anything, but you should be able to open up the developer console and type angular. This will return an object and you shouldn’t see any errors.

type-angular-no-errors

Ok great, we’ve setup AngularJS on our webpage and we’re ready to start writing some code! Let’s start with a controller.

Controllers

So what is a Controller? A Controller is an object that’s responsible for managing other objects. What that means is, the Controller doesn’t actually know the specifics about an object, like a Book for example. The Controller doesn’t know how many pages a Book has, who its author is or what its called, but it knows how to get a Book, how to ask it for its name or how to pass it to a View so it can be read. If you’re just getting started with AngularJS and Model-View-Controller architecture in general just remember that if your application has an object like a Book, chances are it will have a BooksController.

So for this simple application I want to ultimately display some weather for a specific city. So right away I know I am going to need to create a WeatherController to manage the Weather we request! Let’s do that now.

Go ahead and add another file to your application. Name this file app.js and update the markup in the html file you created earlier to include it:

<html>
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
        <script type="text/javascript" src="app.js"></script>
    </head>
    <body>
    </body>
</html>

Great! Before we make our Controller we are going to have to make a top level module for it to live in. AngularJS projects are built around modules, so we will make one next. Open app.js and add the following code:

angular.module('weatherApp', []);

Save and refresh your html page. Take a look at the developer console. You shouldn’t have any errors and you should be able to retrieve your angular app by typing the following:

get-angular-module

Did you see the subtle difference there in Syntax? When you create a module, you add the square brackets [ ] but when you retrieve one, you don’t. This can trip you up when you’re getting started with AngularJS. So be careful. What are the brackets for? For including other modules! For the Ruby developers, you can think of them as a require.

Ok, so now we are going to add our Controller (finally!). I’m going to just add it to app.js. In a production application you would likely use the return value from this module statement and have other files that had the code for your controllers, services, and directives, but I’m gonna keep it simple for now.

Here’s how you go ahead and add your first AngularJS Controller!

angular.module('weatherApp', [])
  .controller("weatherController", function() {
    console.log('weather controller created!');
  });

There’s another small thing to notice here – I took the semicolon off the first line and chained the controller declaration after the module declaration. I added a simple console.log statement to let us know that the controller has been loaded on the page. So let’s check that now.

Save and refresh your page. Nothing. That’s because we haven’t actually included that weatherApp module we created onto the page, to do that we need a directive!

Directives

Directives are simply custom html attributes that AngularJS knows what to do with. The browser will ignore them and Angular will use them. They are that simple. I know they are SO much more, but we are learning, and for the sake of getting started with Angular. That’s all you need to know for now. So let’s tell Angular to load our app. We do that by using a built-in directive named ng-app. Its common to put that on the HTML tag at the top of you page. Let’s do that now:

<html ng-app="weatherApp">
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
        <script type="text/javascript" src="app.js"></script>
    </head>
    <body>
    </body>
</html>

So again, if you save and refresh your page. Nothing. Ok, here’s the deal. We have told Angular about our app and Angular has in fact loaded it. If you don’t believe me go ahead and change the ng-app declaration from: ng-app=”weatherApp” to ng-app=”weatherApp1″. When you save and refresh the page you will see a horrible error message (get used to it – that’s one of the things that drives me nuts about Angular is the horrible error messages). Change the ng-app back and make sure you aren’t getting any errors. Now you believe me that the app was loaded, but where was that console statement? Well, we didn’t create the controller. Let’s go ahead and do that now. With another built-in directive named ng-controller!

Add ng-controller to the body tag:

<html ng-app="weatherApp">
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
        <script type="text/javascript" src="app.js"></script>
    </head>
    <body ng-controller="weatherController">
    </body>
</html>

Now if you save and refresh the page… you see the console message! Now that we have a controller there is a ton of cool stuff we can do. The first is to start using the scope and binding data to our html elements.

Data binding and scope

If you’ve done any jQuery before, you’ve probably written something like this:

$("p.description").text("Here is some text!");

This is simply finding a p tag with a class of description and binding the text Here is some text! inside it. It works, and its served us well. However, what can happen is this kind of code can be nested deep in a very large javascript application and the p tag, well it just has a class of description. We don’t know that this code is going to drive by and throw a value in it. It can be hard to trace back why some elements behave the way they do on a page. Imagine if this p tag didn’t even have a class of description. It was just a p tag! This is where declarative programming and data binding comes in.

In Angular we actually declare what we are binding to an element, it makes it much easier to understand what markup is going to be affected by our code and what the intention of the original developer was. So let’s go ahead and add a p tag to our webpage and write out a brief description of our app using Angular declarative programming:

<html ng-app="weatherApp">
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
        <script type="text/javascript" src="app.js"></script>
    </head>
    <body ng-controller="weatherController">
        <p ng-bind="description"></p>
    </body>
</html>

You know the drill. Save and refresh. Nothing. Don’t hate me. The reason is because Angular looked in the current scope of the directive (in this case the ng-controller named weatherController) and found nothing. So, you got nothing. Let’s go into our controller and add the description variable to the scope now:

angular.module('weatherApp', [])
  .controller("weatherController", function($scope) {
    $scope.description = "a simple weather app";
  });

There are two changes to notice here. First, we added a parameter to the constructor function of our controller named $scope. Second, we used that parameter as an object and added our description variable onto it. We gave it a simple value of: a simple weather app. What was that $scope parameter we passed to our constructor function? Well it was basically a service that gave us access to the current scope. What’s a scope? Well for right now, a scope is basically anything inside the element our directive is declared on. So, we declared our controller on the body tag. That means whatever we put inside the body tag is in the current scope when we are working inside our weatherController. Don’t believe me? Try this: add a div tag inside the body. Move the ng-controller declaration onto that div tag. Finally, move the p tag with our description outside the div, like this:

<html ng-app="weatherApp">
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
        <script type="text/javascript" src="app.js"></script>
    </head>
    <body>
        <p ng-bind="description"></p>
        <div ng-controller="weatherController"></div>
    </body>
</html>

Here we go again… save and refresh. Nothing. That’s because our p tag is outside the scope of the controller now. I hope that’s becoming more clear. Basically if you want to bind something to the page then it needs to be on the $scope object. The $scope object is relevant to everything inside the element that you declared the directive on. In case you are wondering if you can have nested scopes. Yes. You can. So now that we have used a couple built-in directives, lets create our own. A custom directive!

Custom Directives

Why would we want to build our own Directive? Well, suppose we have a lot more functionality inside our weatherController. Suppose it has a few Controllers and a Service or two. We might find it useful to re-use that weather on multiple pages. We don’t want to markup all the necessary elements every time on every page, so we use a directive. Adding a directive let’s us use templates so we can define the markup we need for weather once in its own file. Adding a directive also allows us to make changes to our code in one place and everywhere the directive is used is updated with the new functionality. Directives are really powerful and one of the best parts of Angular.

Adding a Directive to our app.js is very similar to adding a Controller. Here’s what app.js looks like now:

angular.module('weatherApp', [])
  .controller("weatherController", function($scope) {
    $scope.description = "a simple weather app";
  })
  .directive("weather", function() {
    return {
      restrict: "A",
      templateUrl: "weather.html"
    }
  });

This one is a little bit different than the controller in that it returns an object. That object has a bunch of parameters necessary for the directive to function. I’ve kept it simple and only added the bare minimum. First, I set the restrict property to “A”. This means the directive will function as an attribute of an element. This means I will put it on HTML elements just like ng-app or ng-controller. Second, I set templateUrl to a file named weather.html. This is the file that will hold the markup we used to have sitting in our body tag. Lets create that file next. Add the following code to weather.html:

<div ng-controller="weatherController">
 <p ng-bind="description"></p>
</div>

I’ve created a div tag here to declare the controller on. You could also have added the controller property to our directive and omitted this all together. Other than that, this file is pretty simple. Finally, let’s update our original HTML file to use our new directive:

<html ng-app="weatherApp">
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
        <script type="text/javascript" src="app.js"></script>
    </head>
    <body>
        <div weather></div>
    </body>
</html>

I love how simple that is! Basically anywhere I want to add my weather app, I just add that directive now.

Now before you run this, let me tell you what sucks. If you try to refresh this in Chrome you will get a huge ugly Cross Origin error in your console, like this:

cross-origin-error

Unfortunately, Chrome won’t let you reference local files. You can go ahead and work from Safari or you can run the following command inside your terminal window to open Chrome with this security disabled:

open -a Google\ Chrome --args --disable-web-security -–allow-file-access-from-files

Once you open you app again in Safari, or using the above command, you should see the same message as before, but now using your own custom directive! The last thing we need to do is add a Service.

Services

So we created a controller to manage our application and give us access to the scope. We placed all that functionality inside a Directive to allow us to re-use it and template out our markup. Where do we make a call to get our actual Weather? If you are thinking you would simply add a function to our controller and place the result on the scope… you’re not being very Angular! What I mean is that would work. You could simply call a web service right inside your controller and get your weather data, but Angular gives us Services to extract the functionality of getting our objects, calling web services etc. Its the preferred place to put that sort of logic.

Why else should you use a service? First, Reuse! You will likely create a service that is helpful to not only this controller, but to other controllers in your application. Or even a Directive (yes directives can be passed services). Second, maintenance. This controller example is trivial, but your actual projects will create very large controllers without cluttering them with service calls and the logic required to get and set objects.

So how do we add a Service? Well, again its very similar to the other pieces we’ve added to our application:

angular.module('weatherApp', [])
  .service("weatherService", function() {
    this.getWeather = function(cityName) {
      return "30";
    };
  })
  .controller("weatherController", function($scope, weatherService) {
    $scope.description = "a simple weather app";
    $scope.temp = weatherService.getWeather("Vancouver");
  })
  .directive("weather", function() {
    return {
      restrict: "A",
      templateUrl: "weather.html"
    }
  });

There’s a few items to take note of here. One, our service declares its function on this. Because of the way constructor functions work, you need to declare your functions on this if you want them to be accessible. If you didn’t declare it on this you wouldn’t be able to call it in the Controller. Second, we added our service to the list of parameters in our controllers’ constructor function. Finally, we created a scope variable named temp and placed the value returned from our Service call. Now I know I didn’t actually make a Service call. That’s the subject for another blog post, or a challenge for the reader.

The final piece is to update our template file with the new scope variable we created:

<div ng-controller="weatherController">
  <p ng-bind="description"></p>
  <p ng-bind="temp"></p>
</div>

If you save and refresh you will see your simple description and you’re hard-coded temperature. This was a simple and not very functional example, but the point was to help you understand the building blocks of an AngularJS application. With Controllers, Services and Directives and a basic understanding of scopes and declarative programming, you are should now be able to start to put together your first real AngularJS application!

Its time to take the IT person out of Enterprise Development

So I’m at my desk working on another “issue” with Internet Explorer. I quote it because its only an issue to someone who actually believes Internet Explorer 8 should actually be supported in 2014 and the person that drove that decision is an IT person.

I do enterprise software development. What is enterprise software development? Basically, its the anti-pattern to every single software development methodology out there. If there is an established, measured and proven way to develop a solution or solve a problem, enterprise software development does the opposite. An enterprise software project generally starts out like every other project – to solve a problem. Where people’s ability to get their work done is being impeded by a process or an application that makes it more difficult then it should be, but when the ‘enterprise’ attempts to solve it it does everything wrong. The first thing it does wrong is assemble the wrong people. Every single time. And it just goes downhill from there…

The wrong people are always chosen to “lead” the enterprise development project. This is the first place “the enterprise” goes off the rails. In the enterprise – we convene “project stakeholders”. Who are these people? Generally project managers, often who have been contracted and don’t work at the company or even in the domain of that organization, and hand picked company personnel that again are rarely an end user – usually middle managers or communications and hr personnel. These people will be responsible for ‘thinking up’ a solution. They will have little to no background in software development, but more importantly no experience in product design or delivery.

Who would this team be in the real world? Generally a product manager or designer, someone who will be responsible for making the tough calls on what the product does and doesn’t. A designer or user experience person. This person is going to be responsible for making calls on how the product is actually used, how it looks… because you know, they have experience and training in this area. In the enterprise, this is going to be one of the company personnel who couldn’t choose a nice looking font for their document – but they should have no problem designing a user interface! In the real world you’d have some developers as well. This is about the only parallel with enterprise development, because well… its development. However on the enterprise side, the development often has to be done through a remote desktop on poor hardware with restrictions, no source control and meetings. Lots of them! As many as can be scheduled!

There is another person on the enterprise development team that does more damage than anyone else. The IT person. That’s right! You will have an IT person, someone who is well versed in network connectivity, storage, and information security provide his “thought leadership” on the product. When you discuss a new feature the IT person will decide whether that’s a good idea. They object to the insecurity of the product, they won’t have any basis or merit behind their objections, they just won’t think its secure because it doesn’t have the Microsoft logo on it. They will object to the storage and bandwidth requirements for the product – again there will be absolutely no metrics to support this. They will just scare the shit out of the already inept enterprise team and then refuse to support the solution. It gets better. This is my favorite part. They will demand the new solution you are building work in Internet Explorer 8 (I’m being generous here it can be even farther back generally). Why? 99% of the time the answer is – because we have to support legacy applications. Again, what applications? They won’t have anything to support this. Is there 1? Is there 100? Who knows. The IT person is basically going to limit the innovation brought to the table in your project. They are going to waste time and money in meetings objecting to things that have a solution. Any idea what that is? Its an IT solution. That’s right. They are objecting because they don’t want to do the work. They could install another browser on the machines, they could have done that years ago, but they didn’t. So they are objecting to the effort now because as every year goes by they aren’t doing their job. They are getting used to it. You’re rocking the boat.

Try this as an enterprise software developer. Suggest a technology platform that’s 10 years old. See what happens. I’ll tell you what will happen, the IT person will object! That’s right – its too old. It will be hard to support, but it can’t be new either… because well, support. Right about now the project team is worrying about the entire solution. Its security, its resource demands and if you tried this trick – its technology stack is too old. The IT person has achieved their goal, the project will drag out allowing them to sit in on more meetings, and nothing will be done to the network. Phew.

When did the IT person get this kind of control of an organization? Why are they involved in the process at all? You know how an IT person should be involved? They should be told what to do. Here’s an idea, how about organizations solve their problems and involve the IT person only to get the resources they need. Not ask for them. Get. Them. On deployment, how about the IT person monitors the situation and uses their skills to increase access, ensure security and provide a great experience to the users. All of this is possible, its called the cloud. This is what I love most about the cloud. Want more memory? Done. Another machine? Done. Want to drop support for legacy browsers? No problem – because the only people using them are the poor souls trapped in the dark ages of a corporate IT environment. How do we know this? Well we have metrics.

We aren’t going to get the rockstar product designers or user experience gurus on our enterprise development projects anytime soon, but you know what we can do? Stop inviting IT to the meetings. When we are done we’ll tell you what we need or we’ll put it in the cloud.

Update on my app

So I was hoping to be done last week (before I got back to work) however, I wasn’t. Its started and I’m really far along though! Just starting and blogging about it was definitely a motivator, so I’m blogging about its progress again to keep myself on track.

TLDR: I learned to use a prototyping tool for iOS development. I’m hoping to have a working prototype next week.

What challenges did I run into building the app that quickly?

Surprisingly, at least to me, it was design! The reason I say that is because as a long time web developer I am used to prototyping web application ideas by simply throwing a backend together and then pages that basically have the functionality I need, but no real layout. Since its a web app. I usually have content and links. Making updates to it to eventually bring the design and user experience in – isn’t very difficult.

However, this way of working fell apart very quickly with iOS.

I couldn’t just throw data on the page and create a link to the next page. I had to consider how the data was being presented. I also had to consider how the transition from one page to another occurred. With a webpage, its a link. That’s it. With iOS, I could be in a navigation controller like Mail, I could bring up a modal window, or I could even animate and flip the screen like a Weather app. These decisions had to be made up front otherwise it was going to be harder and harder to change later – harder = time = expensive.

So I stepped back and started laying out the application in a prototyping tool. I started using Storyboards right in iOS. They were ok, but the process wasn’t creative enough. It wasn’t free flowing and building and running seemed time consuming.

I eventually settled on AppCooker.

Mockup-iPhone-Screens-View1AppCooker worked really well for me. Its an iPad app that lets you build out an entire iOS application and run through it. I can create clickable zones, choose transitions and I can try navigational constructs cheaply and throw them away if they don’t work. The best part is I can send the tappable prototype to someone. All they have to do is download AppTaster from the app store and try it out.

Once I had a working tappable prototype it made it much easier to build it out in Xcode. This was a big lesson learned for me for iOS development. I’ve used prototyping before on web development projects, but I haven’t always had to start there. I feel like its a mandatory starting point for iOS.

When am I going to show this thing off?

Soon! As soon as I have a working prototype I will make a video and walk through it – posting that here for you to see.

 

How to install and use RVM

RVM is a critical part of your Ruby on Rails development stack. Why? Because it allows you to work in multiple Ruby environments. As soon as you build out more than one project you could find yourself having to deal with one project at a certain version of Ruby and another project at a different version. Without a tool like RVM. This can be a huge headache. Fortunately, installing RVM is pretty easy.

So let’s start on a bare OS X system. You’ll notice you have Ruby installed already by running the following command in the OS X Terminal App (all the commands in this post should be run in Terminal):

ruby -v

Outputs:

ruby 2.0.0p481 (2014-05-08 revision 45883) [universal.x86_64-darwin14]

At the time of this post, the Ruby on my OS X 10.10 Yosemite was 2.0.0 patch level 481.

What you should be comfortable determining is whether or not you are seeing the OS X version of Ruby or the RVM version (the one you want).

So lets see the path to the ruby executable:

which ruby

Outputs:

/usr/bin/ruby

The output /usr/bin/ruby tells you that you are referencing the built in OS X ruby. Let’s fix that.

Here’s how you install RVM:

\curl -L https://get.rvm.io | bash -s stable --ruby

This could take some time to finish. When it does, run the previous command again to check your ruby executable path. It should read:

/Users/your-username/.rvm/rubies/ruby-2.1.3/bin/ruby

See that .rvm in the path? That means RVM is installed and being properly referenced!

The –ruby flag in the previous command installed the latest version of ruby. You can see that it has changed by checking for the version again:

ruby 2.1.3p242 (2014-09-19 revision 47630) [x86_64-darwin14.0]

Again, based on when you read this post and run these commands, your versions may be different.

Here are some default commands to get you started with RVM:

rvm list

This will show you the ruby executables (also called rubies) installed on your machine.

rvm list known

This will show you the rubies you can install

rvm install [insert ruby version number]

This will install a specific version of ruby to your machine

rvm install 2.0.0

rvm use [insert ruby version number] –default

This will make sure that a specific version of ruby is used every time you open a terminal window

rvm use 2.0.0 --default

rvm gemset list

This will list all the gemsets for your current ruby version

rvm gemset create [insert gemset name]

This will create a gemset in your current ruby version

rvm gemset create my-gemset

rvm use [insert ruby version number @ gemset name] –default

This will make sure a specific version of ruby is loaded every time AND at a specific gemset

rvm use 2.0.0@my-gemset

Now. What do you need to do in order to get started with Rails? Well, to be honest, there is some discussion as to whether or not gemsets are even required with Bundler. Obviously they are more important if you are developing a Ruby project without Bundler. So, for me, I find setting a ruby version is all I need.

Using RVM you have the ability to manage different ruby versions, what gems are included with each one and you’re not cluttering up the built in ruby with all your various project gems.

How to install and use PostgreSQL

If you’re a Rails developer and you’re not using Postgres for your database, its likely because you have already invested time and energy installing and configuring MySQL on your Mac. You also probably got use to great tools like Sequel Pro for managing those databases also.

However, it seems the community has really moved towards Postgres. Why? Well I can’t say for everyone, but for me there were two big reasons:

1. Heroku

Learning Rails can be daunting enough, but also learning how to do a production deployment of a Rails application can take it over the edge. To be honest, there really isn’t much of a reason to learn how to do a good production deployment of Rails unless you are personally responsible for taking client or company projects end to end – and even then, why wouldn’t you use Heroku, save yourself the liability of being responsible for managing a production Rails deployment. In my opinion, get really good at Rails. I’m not saying those server management skills aren’t important – I’m saying there are very important and just as specialized as learning Rails itself. So let someone who’s neck deep in operations take care of your app. End rant.

2. PostGIS

This doesn’t get talked about enough, but mobile introduced a huge new skill gap in developers. Those who know how to work with locations and those who don’t. What do I mean? Almost every mobile application has some location based feature. Well if you know mobile development then you are thinking: “That’s easy! iOS gives me the location of a user. done”. True, so does a web browser, that’s not the hard part. The hard part is asking whether that location is near another one… oh ya… you forgot about that part. Now there are a ton of ways to approach this, but PostGIS makes this a much easier task. Also, you think doing a production Rails deployment is hard… deploy a GIS product or server. No thanks.

So how do we install Postgres on OS X? Well there are a couple ways. Here’s the easy way. The way I do it.

Install the Postgres app

Go to http://postgresapp.com and click Download. Then drag that app to your Applications folder and fire it up. Done!

Its almost too simple.

So how do we use this with Rails? Well you will need the pg gem. When you try to install the gem you will likely get an error that it can’t find pg_config. That’s because its packaged in that cool app we just downloaded, so all you have to do is tell the gem where it is. Here’s how you do that:

gem install pg -- --with-pg-config=/Applications/Postgres.app/Contents/Versions/9.3/bin/pg_config

Note: You may have to change the version number, but at the time of this post it was 9.3

Now you just fire up a rails project using:

rails new myapp --database=postgresql

Using a PostgreSQL Client on the Mac

That’s it! Now you could click that Open psql button and start managing your databases from the command line, and there is nothing wrong with that, but you might want a nice tool with an easy to use graphical interface. Unfortunately Sequel Pro… is MySQL only. So the best option I found is PGCommander. Its actually great, but its also $40. If you find something as good and cheaper let me know. I use PGCommander.

Enabling PostGIS for PostgreSQL

Remember the other thing I talked about? How cool PostGIS is. Well another great thing about that Postgres app is that its easily enabled if you are build some cool location based Rails web services!

To enable PostGIS, connect to your database and enter the command:

CREATE EXTENSION postgis;

So that’s it! Now you have a PostgreSQL database on OS X ready for development. You can easily start using PostGIS services if you need and you can manage the databases using PGCommander!

Storyboards.

So I’m looking at laying out my interface using storyboards. I could manually build out each screen, but I’m not sure what would be the point. If you haven’t done much iOS before, basically every single screen is a view controller. So using storyboards is just a matter of throwing view controllers down.

As with all iOS endeavours, what I find is wiring the screens together isn’t the big issue – it’s always passing data back and forth or how that data persists. I think I’ll start with a simple singleton object. Something I attach to the app delegate. I know this might not be a long term solution, but in the short term it will get me to a functioning prototype.

Thinking about a prototype… I’m wondering how soon I could actually throw something on the App Store. Do this really agile… Chuck an app up, get people playing around with it and then iterate on it. I’ve read 2-3 days or as much as 8 days to get an app reviewed. Anyone have any recent experience with this?

Navigation is king.

So in coming up with the screens for my app. I immediately ran into how is the user going to navigate this application?

Tab Bar? Nav Bar? Pages? Facebook style? (Don’t know what to call that one).

I started by laying out the very bare essential screens I needed. I didn’t even consider navigation. Then I started drawing lines to and from the screens. The navigation options started to jump out.

I’m not building any kind of utility application, so using Pages or flipping back and forth between a couple view controllers won’t work. I’ve got to assume 90% of apps come to this conclusion pretty early… unless they are making a flashlight or a task list. So really you end up at navigation controller or tab bar controller… or a combination of both. You could always go ahead and come up with something really dramatic like Path, but that would take me way past MVP. I told myself no custom navigation elements. I’ll never get this done in a short period of time.

I’m gonna do a bit of paper prototyping tonight. See if one of the patterns really jumps out at me. I’m going to use the UI Stencils iPhone Sketch Pad and their app to test the prototype. I ordered these a while ago and so its time to put them to good use.

After that I’ll probably take a break until tomorrow morning. Then the code starts. I’ll be posting about the issues I run into or any a-ha moments I have with things like location, searching, and camera (yes that was a bit of a hint).

I’m also going to throw together the rails backend tomorrow morning. Should be easy, not going to do much except design the url routes and models. I’ll just hard code some JSON responses for now. I think that exercise will help me determine what objects I might be dealing with in iOS early on.

I should have something ridiculously rough tomorrow… that’s the goal anyway.

Minimum Viable Product. Complete.

So going through the various resources… took me to the same place.

Make a list.

Come up with an MVP. If you’re not familiar, basically a list of app features the app must have to be the product you dreamed up. However, this shouldn’t prevent you from writing EVERYTHING down. You never know… it might just become a big deal and you’ll get to do all the cool things you want to do.

So, what was interesting about making the list was that I looked at it from two angles. What features did the app need to have – and what features would be easy… ish to develop. Having some understanding of iOS and backend of development is pretty crucial here. Otherwise you’ll just go ahead and plan out a 3D first person shooter…. (I’m not making one of those… I swear).

I’m moving on to design – going to skim some of the books again. Making the list also gave me some idea of how the app might look work. Side note: does anyone else think that iOS 7 made it easier to come up with a design? Skeuomorphism seemed like a higher bar in terms of coming up with the assets to make your designs look like ‘real world’ things.

Anyway. Lessons learned. Make a list, scratch off the items that are totally necessary or will require huge technical investments or post major technical hurdles.

My two cents.

Time for a beer.

Where to start…

Ok, so I need to figure out what idea to work on.

I forgot to mention a couple other resources I picked up: The App Design Handbook and Design+Code I’m skimming them now… no time to read them cover to cover… but I need some guidance on narrowing my focus and picking the right direction.

One of the standouts is the concept of making a video for your app (mentioned in the App Design Handbook). This is interesting… basically the idea is that I should be able to come up with a video for my app. I don’t have to make it – just have to be able to plan it out. If I can – I have a well developed concept…

So that’s what I’m doing now.

I’m building an iOS app. Right now.

That’s right. I’m building an app right now.

I’ve found myself here with the precious commodity of time after doing the obligatory family visits over the holidays. I’ve always had a couple ideas, but never had the time. So here I am.

Getting started is always the hardest part… luckily I’ve been preparing for this moment for far too long… sort of an analysis paralysis kind of thing. I’ve been through a bunch of iOS online programs so I’m not completely green, stuff like iOS App Development with Swift Essential Training by lynda.com. I’ve also read a few books on the subject, Beginning iPhone Development by Apress is a good place to start if you’re just getting started – in fact I’m going to keep this at my side as I get going here – to reference the basics in case I get stuck. I’ve also purchased The Complete iOS 8 Course with Swift by Bitfountain. I’m going to reference this as well if I need to.

For the backend? I’m a rails (is it Rails?) developer. So I’ll use that. I’m gonna stub it out with hard-coded values to start… not really worrying about most of the backend until the end. I’ll push the app to Heroku so I can test it easily during development.

So what am I building? Well I have a couple ideas. I’m going to continue blogging my process and the problems I am hoping to solve, so maybe you’ll be able to figure it out… but for now… its a surprise.

Let’s get started!