Archive
Xcode’s Next Top Model
The idea seemed simple enough. An app to keep track of your budget on vacation. You’d launch the app and then… what? Okay, I can figure that out later.
First a bit of triage. iOS apps are generally designed around a Model-View-Controller pattern. The idea is pretty simple. Your app has to do three basic things. First, it has to have some data, stored in a predictable format (the model). It has to show you things on the screen (the view). Finally it should be able to manipulate the model and view (the controller), making sure that the right data is displayed, and that as the user manipulates the objects on screen, that’s being translated correctly back to the data.
For my needs, the model seem like the easiest bits to address, so I’m going to start there.
Well, it’s a a budget app, so there’s going to be a budget object. That can be fairly simple to start with. It’ll have a name, a start date, an end date, a total, and some line items. What do those line items look like? Well, since the user can customize them, I don’t want to get too clever. So an array of budget items it is. In Swift, your budget template will look something like this:
internal var budgetItems: [VacationBudget.NWDBudgetItem]
internal var name: String
internal var startDate: NSDate?
internal var endDate: NSDate?
internal var tripLength: Int? { get } // We can figure this out since we know the start date and end date
Wait, what is an NWDBudgetItem? Well, that’s a good question. Well, it’s gotta have a name, which can be a String, and it’s gotta have a value, which can be an Int. No, that won’t work. In America, at least, we still have fractions of a dollar to worry about (you might know them as those those little metal discs that seem to end up strewn about your home). We’ll want a better way to represent a value. My plan is to use a struct that knows how many cents it has, but can give you the amount in dollars, cents, whatever floats your boat.
What you get might look like:
public typealias Cent = Int
public typealias Dollar = Int
struct NWDValue {
internal var dollars: NWDValue.Dollar { get set }
internal var cents: NWDValue.Cent { get set }
internal var totalCents: NWDValue.Cent { get }
/// returns “\(self.dollars).\(self.cents)”
internal var stringValue: String { get }
mutating internal func setTotalCents(cents: Cent)
}
You, dear reader, may be a professional programmer and you may be looking at this and listing off the many ways in which this is a bad idea, and I’ll end up back at the drawing board before this whole thing is over. That may be the case, but hey, at least it will give me some blog fodder as I try to fix the mess I am getting myself into.
This is… well, it’s a good start. But the bigger challenge is going to be figuring out exactly how the user will interact with this thing. Next time: You Gotta Start Somewhere
Ground Floor
Estimating how long it will take to program something is famously difficult. So while I’ve been plunking away at my project for the last few months, I could see that I was still quite a ways away from anything I would be proud to release. And it’s not that I’m slow—well, I am slow, but that’s not the only reason—it’s that this project is very ambitious for a guy who’s doing this all in his spare time and teaching himself what he’s doing from scratch while he’s at it.
At this point I was starting to get a bit demoralized. I didn’t want to spend another year at this with nothing to show. Was there something quick I could whip up in the mean time? Basically a dry run to get something into the store. If I was going to make any mistakes, let’s do it on something that would only take a month or two, rather than 10 times that.
So I needed a new idea. I had a few criteria.
- Everything is self contained. Web service? Apple Watch app? One thing at a time please.
- Simple UI. Nothing’s coming from a web server, and no one wants to plug a ton of info into their phone.
- Useful. Frankly having a few dollars coming in would be a nice motivation to keep this going. It needs to be something I can charge at least $0.99 for.
- Not a game. I am not an artist, so interaction should be text based. That and I’m not really a gamer, so I don’t know what makes a good game.
So I talked it out with my girlfriend over some pizza. Erin suggested a budgeting app. That was useful, but it could easily violate number 1 and 2. Peoples budgeting systems get crazy complicated, and of course everyone’s going to want it to sync to… something. What about a lightweight budgeting app? After a week or so you’d realize this was completely inadequate. But what if you only needed it for a week or so?
Most people have some sort of budgeting system, from using elaborate spreadsheets to just roughly keeping it in their heads. But when you’re on vacation that all breaks down. Your routine goes out the window. You could use some way of making sure you’ve not blown all your cash by day two.
This was what I was looking for. An idea! One that seem feasible! Something to write about on my blog! Stay tuned.
Without A Map
Editors note: This will be nerdy
I haven’t written about iOS development in several months. I haven’t given up, I just hadn’t had much to say. I was still soaking it in.
I was reading two separate books, while occasionally going down rabbit holes to understand a topic a little better, and even watching some videos (specifically the much touted CS 193P). I even whipped up a few rough test apps just to prove to myself that I could get something running, even if it didn’t do much.
Then a little while ago I received an email from Apple saying it was time to renew my yearly developers membership. So I had been working on this for a year without much to show for it. So I decided I wanted to start something. Even if it’s terrible, even if I end up trashing it and starting from scratch later, this seems like a good time to take a first concrete steps.
That was my first impulsive decision. The second was, upon firing up Xcode, choosing Swift as the language for my new project.
Even though most of what I had learned so far had been Objective-C, which I have really enjoyed writing, I thought back to my initial feelings after WWDC last year. Swift was my chance to get in on the ground floor of something.
What made me confident enough to do this the fact that I now had a basic understanding of Objective-C. This is important because Cocoa makes a lot more sense if understand that it was created hand in hand with Objective C. You can still use the Cocoa APIs from Swift, but it still feels like there’s a layer of translation happening. You end up with some weird syntax and excessive casting that only makes sense when you understand that these APIs were designed for an entirely different language.
That said, what have I got to lose, at this point? This is the future, right? And WWDC made clear that Apple was still full speed ahead on Swift.
So I jumped in and started playing around. It had been a while since I read Apple’s The Swift Language, so there was a period of adjustment in getting used to the syntax. Swift is a very programmer-y language. It was built buy compiler guys, so “fast” was as important as “easy” or “intuitive”.
But after playing around for the last couple of months, I’m feeling comfortable with it. The pace of change has slowed down, and I’m finding myself able to work for longer and longer stretches without having to look up something basic. And Playgrounds have been really helpful. Sometimes you just can’t remember if arrays are passed by value or reference, but it’s easy enough to test in 10 lines of code on a Playground.
There have been stumbling blocks. I watched Apple’s session on Protocol Oriented Programming, and got so excited I went into my project and made all my model layers structs that conformed to a specific protocol. That did not work out so well, but that story is for another blog post (and if you want a more informed opinion, go back and read Brent Simmons’s Swift Diary). But in general when I sit down I make head way.
So I’m still working. In fact, I’ve got a couple ideas now. It’s all starting to feel manageable. Which, if experience tells me anything, means I’m only a couple of weeks from once again realizing I have no idea what I’m doing.
An Index In Your Head
It’s been a month since I said that this blog would have a new direction and I haven’t posted anything meaningful on the subject. Let that not reflect on the subject matter, since there has been plenty that I meant to write about. I just… got side tracked.
So what have I been doing? Well, summer is never the most productive time of the year, but I have found some time to sit myself down and try to figure this thing out.
My main study guide has been Aaron Hillegass and Mikey Ward’s Objective-C Programming (2nd Edition). I found this to be a good place to start due to what it is not. It is not a book on how to make iPhone apps. The arcane incantations that get Xcode to work are only touched on briefly. Mostly this book aims lower. Start at the language. How does Objective-C work? What is Object Oriented Programming, and how does Apple want you to use it? What is going on in memory while your code is doing its thing? How the fuck do blocks work?
It remains to be seen whether this detour was worth it. There’s still plenty I don’t quite grok, but I’m betting that once I’m done with the text books and sample code, just having read these books and having a rough index in my head will be helpful.
Nothing Was Delivered 