SMUG logo thumbnail
Stanford/Palo Alto Macintosh User Group Newsletter
January 23, 2013
In This Issue
December 10th Meeting
Quick Links
SMUG website SMUG Archive
Membership Info
Dear (Contact First Name),
Happy 2013 Everybody!

 Fresh from celebrating MLK Day, we're getting ready for the "Ultimate Event" - not sure what that means, or if hyperbole has truly gone too far here, but I'm looking forward to it anyway and hope to see at least a few of you there. We'll be  back in the Redwood Room on February 4th for a look back at what we came across and what we can look forward to in the year ahead from the Apple community. Plus the usual prizes and giveaways to unleash your not-so-inner Mac user!

One of the booths you can visit at MacWorld is our most recent presenter, Kevin McNeish (see Dave's report below), along with his latest tome, Book 3: Xcode 4.5. I say tome advisedly, it is 570 pages long. And, if you haven't got an Expo pass yet he has a few to give away - you can email him at
Meeting Notes  December 10th 2012 - iPhone App Development

The topic: Unleash the app developer within! Our speaker was Kevin McNeish. He spoke to us over the Internet using GoToMeeting.


Who is Kevin? President of Oak Leaf Enterprises. He does a lot of speaking in the US and abroad. Apple does not sent representatives, so it is up to guys like Kevin to spread the word.


Kevin started by showing us an Xcode screen. Xcode is Apple's development platform for Macintosh and iOS (iPhone and iPad). (It has been a while since I have played with Xcode). He had to blow up the font in Xcode for some of us with older eyes.


Kevin sells books about creating apps for the iPhone and iPad:

Apple keeps releasing new versions of Xcode, so Kevin has to keep releasing new books. He is close to releasing a third book: iOS App Development for Non-Programmers, Navigating Xcode 4.5. He put a book of his on our raffle: iOS App Development for Non-Programmers. (Note from Dave: I think it was the first book in the series: Diving in. The second book is Flying with Objective C.) The iPad version has images in color and embedded videos. It is also available on Kindle. (Note from Dave: That might be one of the rare times I'd buy the iBook/iPad version of the book rather than Kindle, since the iPad version has more cool stuff in it.)


Ken asked us: Who are you? We at SMUG are mostly non-programmers. For those interested in creating iPhone/iPad apps, he thinks of left-brain (logical) and right-brain (creative) people. He has been writing software for about 25 years. He started in hardware, then fell in love with software. As for the age to start developing software, nine is a bit young, twelve is great.


In this session, you get a taste of being an iOS app developer. Topics will include learning how to think, the three main parts of an app, Xcode, storyboarding, modeling real world objects, and an app demo.


When you visualizing the app you want to create, try to see what the end product will be. Visualize the three main parts of an app. And visualize how the code works (Kevin's second book in his Xcode series).


There are three parts of an app.


1: The user interface. Kevin showed an app that showed a city temperature, six day forecast, etc. As far as the user is concerned, the user interface IS the app; this is what the user sees and touches.


2: The core logic. In this case, the code to go out to the web and get the current temperature and forecast. Kevin feels that Objective C is not the best programming language, though it is getting better. (Note from Dave: I have to admit the look of Objective C scares me. I should be ashamed.)


3: Data. In this case, a list of commonly used cities, a default city, etc.


It is a good idea to keep a good separation between these three parts of an app. It is the key to app success. It helps you to conceptualize. And it allows your app to adapt to change.


Apple's tools make it possible! Kevin gave a demo of the app simulator by opening a recent project in the simulator. You get the simulator with Xcode: simulates your app running on an iPhone or iPad. It has lots of options (iPhone 5, iPhone 4, etc.)


Kevin brought up an app in the simulator. This app showed a list of apple chiefs over the years: a picture of each and a bit about him. Wow, it showed a LONG list of the products Steve Jobs created. The simulator can rotate: you want your app to look good in each orientation, portrait or landscape. The simulator also simulates shaking (like an etch-a-sketch app!). He showed printer options in the simulator. Showed a hardware menu: showed TV output in simulator. And he showed his current location in the simulator.


It is free to learn to develop apps. You need a Mac with a Intel processor (any Mac made after 2006).


Back to Xcode. You have a storyboard where you can look at different scenes in the app. Pixar does a storyboarding for their movies. (Note from Dave: and Hitchcock storyboarded his movies before he shot them.) Storyboarding is a great way to build an app. Storyboarding in Xcode is about 1.5 years old. You can look at your storyboard to see how your app works: the first scene comes in, then some detail, then you click on a control and go to that scene. The arrows between the scenes are called segways. Storyboards in Xcode are used for iOS apps as well as Mac apps.


If you know what you want your app to look like (note form Dave: and you should!), you can choose an appropriate template (tabs, game, page-based app, etc.).


A universal app runs on iPad and iPhone. For simplicity, Kevin picked iPhone. This iPhone project (like all projects) has some folders, but the project folders do NOT correspond to folders on your Mac hard drive. Kevin added a storyboard to the project: selected project, main storyboard. He had a lot of objects to choose from: view controller, table view controller, collection view, navigation controller, tab bar controller, page view controller, etc. He added a navigation controller for the very first scene that would show up in his app (you can see that in the storyboard). The tab bar lets you navigate between scenes.


He had some dental software: a client wanted to show at a trade show that they had something on the iPhone. In 45 minutes, Kevin had a prototype of what the client wanted to see. Kevin didn't need to write code for that. He added a table view for a grouped look, looks like a rounded rectangle. He took out two cells to leave one (he had three cells to start). He could drag and drop controls and images, and could change the font. He started putting in addresses for title and detail in deliveries: he just copied and pasted them to make a list. When someone clicks on a cell, he wants to go to scene for more detail. So Kevin added another table view to storyboard. How do you get to the next scene in storyboard? Drag over, select push, and Xcode creates a segway between scenes and a disclosure indicator (shows that something's going to happen) and a navigation bar with a back button. This, from just from click and drag. You can select a group to do multiple sections. He ran it in the simulator: go to the next scene, navigate back and forth between scenes.


In the storyboard, he had two scenes and information completed: delivery list and detail.


These cells are templates he created. They keep the style, color, font size he picked. This is prototyping for the app. This is not throwaway stuff; you keep this work for your app.


Kevin added a regular view controller. Users can launch a map with their location on it. He ran the app in the simulator, clicked on an address, and got a map view.


He put in a toolbar. He dragged the map view up, and added (dragged in) a tool bar object. He wanted a partial curl transition to match the button he created. In the view controller, he added what we are segwaying to.


He wrote zero code for what he did so far.


Kevin discussed visualizing the code with objects. He showed objects for a card game: a dealer, a deck, and a player. Think about the objects that you need to create in the app. Model real world objects. The dealer has behavior: open deck, shuffle deck, cut the deck, deal a card. The dealer has a name and a deck. The deck has a type (pinochle, poker) and cards. A card has a name, suit, and rank (the ace value, for example). A player had a name and a hand. A hand has cards, and takes a card, etc. A dealer has a lot of the behavior of a player: take a card, play a card. So you think about class and sub-class for dealer and player. A dealer is a specialized player. Kevin demoed the app in simulator. He picked a card. He clicked a segway (flip button) to see the card. There are 52 images for cards. A card has a name and image.


He showed the underlying code for create dealer, tap button, deal card to player, player shows last card. He showed more advanced programming debugging, as in breakpoints, where you step though and stop in your code.


In Q&A, Kevin said you can make an app, but you have to pay the Apple developer fee to get the app on a device. It is $99/year to join the developer program.


Dave Strom, SMUG Vice-President


P.S. If you're interested in learning more, Kevin has a class in April - you can get $300 off the class with promo code SMG300.

All in the Redwood Room at SLAC - February 4th, 2013.
Steve Bellamy
SMUG President