WatchKit Day 2

Did I mention that WatchKit was limited?

So far so good, Xcode’s Beta is crashing on an acceptable rate, Swift is starting to make more sense (yes, I’m also starting with that) and I had the opportunity to say my first “no, you can’t do that on the watch”.

I spent a considerable amount of time setting up the project. I’m now using a framework to share code between App and Watch Extension. All in Swift. ?

The rest of the day was spent dealing with tables.

Using WKInterfaceTable and configuring Row Controllers led me to wonder if those controllers were being reused. It makes sense to reuse cells in such a limited device. Probably they are being reused. Does that mean Row Controllers should implement the prepareForReuse: method? No. You won’t find cells on WatchKit, only Row Controllers.

Row Controllers are a concept introduced by Apple. Not a class, not a protocol, a documented concept. When you call rowControllerAtIndex: you get an AnyObject! back.

You can add row controllers to your table on the Watch App’s storyboard file. Those must have a name and a class (NSObject by default).

You can then set/insert row types in code, upon initialization for example. And Row Controllers will be instantiated for you as soon as you call
setRowTypes:.

I found that those were not being reused. You have a row controller for each row. I assume cells are being reused in the device, but row controllers (that configure a cell) are not, those live in the extension and probably map to reusable cells on the watch. That’s why row controllers need a name.

This concept of Row Controllers is somewhat usual on iOS. When you need to keep some state about your UITableView cells, that doesn’t belong in the model, it’s a good idea to keep another collection of controllers that keep that state.

Tomorrow I think I'l have a look at the testing options. Basic behaviour testing should be quite straightforward but we’ll see.