Archive
Tea Leaves
Sometimes Apple appears to be so together. You get the feeling that that their events are impeccably stage managed, and every detail is thought through (despite occasional evidence to the contrary).
Apple is also a company of patterns. They tend to like yearly patterns. It made sense to expect that they would split their holiday offerings into two events, one in September and another in October. Instead, however, they decided to have one big bash this year, with focus on four(!) major product lines:
- Apple Watch
- iPad
- Apple TV
- iPhone
Notice any omissions?
As far as I can see, there are two reasons Apple chose to ignore the Mac during today’s press event.
The Optimistic Take
This event was all about new hardware. iPhone 6s. New Apple TV. iPad Pro. Even new colors of Apple Watch. However, with the exception of brief recap of watchOS 2, there was no mention of new hardware-agnostic software features. No review of iOS 9 (except for discussion of how great iPad multitasking is on that huge iPad Pro screen). Maybe Apple would have loved to talk about the Mac, but there was no new hardware ready. Intel doesn’t have the Skylake processors ready yet, so the Mac would simply not have fit in with this program. Soon enough it will be back in the spotlight.
The Pessimistic Take
Apple was focused on the future today. The Mac received about as much screen time as Windows PCs and Android phones. It is a platform that Apple supports out of obligation. Computing is now mobile (read “touch”) centric, and the Mac is no longer a first class citizen. Sure, some dinosaurs will insist on things like access to the file system and arbitrarily placed windows for the time being, but Apple is moving on.
So which of these positions is Apple telegraphing by virtually ignoring the Mac? My best guess is that there are camps on both sides inside the company. But we should be able to suss out what direction they’re going down soon enough. After all, Apple is a company of patterns.
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
Nothing Was Delivered 