My kids got me hooked on Minecraft PE. I resisted, but acquiesced to play with them because it was something they were interested in, instead of me trying to get them interested in things I like. It didn't take long, though, when it seemed that my skill quickly outpaced their own. I came up with strategies for overcoming challenges that would set them back, but that isn't surprising when they are still in their early developmental stages. Nevertheless, I knew how to play Minecraft better than they did.

Occasionally I get lost in a labyrinthine cave while strip mining, but I usually find my way back with a full inventory of loot. Not so, on one occasion. I told as much to my six year old son. He told me I should just dig up to the surface. I was in a recently created world with little orientation of the world above my mine. I found less value in being lost above than down below. So I kept up my exploration of the cave, knowing that at some point I may end up dying with no way back to an inventory full of gold, diamonds, and other goodies.

Every couple of minutes he would remind me to just dig up and find my way home with a compass, which I did not have. At one point, after what seemed like a dozen times of telling me the same thing, I told him I didn't want hear his suggestion anymore.

"But dad," he calmly replied, "you can dig up and *make* a compass. You have the red stone and iron ore to make one."

I was speechless. He was absolutely correct.

I immediately began digging up to the surface. Upon reaching the top I made a crafting table and furnace, smelted my iron ore, and created a compass that guided me straight back home.

It's interesting how my own sense of superiority blinded me to a simple solution to a seemingly insurmountable problem. All I had to do was *listen*. The irony being that I incessantly complain to my own children that do not do the same.

Good ideas can come from anywhere. Even from those that know 'nothing'.

I was pretty excited when Apple announced its WatchKit SDK today.  There's a lot to learn, but even better than that, there's a lot of stuff that is easily translatable if you're an existing iOS developer.

Here are a few initial impressions:

Watch Logic & Communication
Because the logic for your app resides on the phone itself, latency really becomes an issue.  Pushing on controllers and associated data to the user requires Bluetooth communication that introduces a quite a bit of latency.  Instead of pushing just data to the watch and letting it decide how to store/cache/manipulate the data, the watch is continually pushing and pulling data to and from the phone just to put things on there that could otherwise instantly show.

This can be problematic from a user experience perspective, but if you have so many screens, maybe it isn't appropriate for your wrist.

The upshot to this model is that, from a development perspective, there really aren't any special skills needed to develop apps, outside of learning the specific frameworks for WatchKit.  There isn't a new language, there aren't any device-specific things that need to be done. Which leads me to the next curiosity:

Opaque APIs
There is no direct interaction with views or other UI objects with WatchKit.  Instead, there are opaque objects that represent these elements, but there's actually very little that can be done to manipulate them outside of changing the size, color, and opacity of them.  This really tells me that the internals of WatchKit are not just being closely held (in typical Apple fashion), but likely designed in a way to be dramatically changed under-the-hood as the platform matures.  I suspect that as the hardware improves and the underlying capabilities become more rich, so will the API support for more customizability.  At this point, Apple is setting itself up for change that minimizes impact to how we interact, software-wise, with the device.

Another way to look at it is that if Apple come up with other devices with limited interactivity, say, like a TV, a lot of the programming paradigms in WatchKit are transportable to other platforms.

WKInterfaceController is the UIViewController equivalent in WatchKit, except you're not directly manipulating its views.  One of the big problems I have with UIViewController is how poor separation of concerns has become over the years with that class really knowing too much and having too much control over the entire flow and state of the app.  I think that Apple is repeating this mistake in a much more serious way.  For example, there is a WKInterfaceTable class that operates similarly to UITableView, except that it does not have a delegate property for selection callbacks.  This callback is instead hard-bolted directly into WKInterfaceController.  If I wanted to create a more generic class for managing a table and all of its associated interactions, I'm kinda out of luck without some workarounds in the WKInterfaceController.

There are a couple of other examples where classes, IMO, need to be carved up a little bit.
I'm really happy that we can publicly talk about iOS 8 in its beta state.  That said, this post cannot contain screenshots because of some remaining limitations in the NDA.  Also, since this was written at the time of Beta 1, what I discuss here has a chance of completely changing.  It's well after midnight as of the original writing of this post, so sample code will follow at some point.  That said, now onto the post...

There's quite a dearth of documentation on widgets, a new feature on iOS 8.  This is a tutorial that will hopefully help you avoid some of the pain points I experienced so that you can get up and running.

First off, debugging extensions of any kind appears to be broken.  In some cases I setup a debug label to show stuff on my widget to help me troubleshoot.
There is a workaround below.

Creating a widget involves creating a brand new target.  You can go to your Xcode project file and add a new target.  A dialogue window will drop down and one of the target categories will be Application Extension.  Select that, then Today Extension.  Give it a product name and select the target that you want to embed it in.

Designing the Widget

When you create the new widget target, you'll get an Info.plist, a view controller subclass, and a storyboard.  To get running quickly, you can just customize the view controller in the storyboard, adding additional programmatic setup in the code files.  Creating a widget is very, very easy and leverages your existing Cocoa Touch skills.

Sharing Data

Naturally, you're going to want to surface content from your main application inside a widget.  But even though the widget will be embedded in your app, it is its own app and has its own sandbox.  The individual sandboxes cannot mix, but Apple has created a shared container that both applications can read from and write to.  This shared container is created by enabling App Groups. This is a feature that you can turn on in the Capabilities tab of your target properties.  When enabled, you can create a new App Group and it should start with group.  This capability must be enabled on both your application and widget targets and the group ID must match.

Once this is enabled on both apps, you'll need to both read from and write to the shared container.  In iOS 7, Apple added an API to NSFileManager called containerURLForSecurityApplicationGroupIdentifier:.  This will construct an NSURL instance that can be used to reference files inside the container.
NSURL *containerURL = [[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier:@""];

containerURL = [containerURL URLByAppendingPathComponent:@"data.plist"];

Launching The App

Another feature that may be very useful for your users is launching your app from the widget in the Notification Center.  There is a new set of APIs for doing just this that are specific to widgets.  There is a new class called NSExtensionContext that exposes a method openURL:completionHandler: that can be used to launch the custom URL in your app.  Just pass it a valid NSURL instance that your app responds to, and away it goes.
// Inside your widget view controller
NSExtensionContext *context = self.extensionContext;
[context openURL:deepDiveURL completionHandler:^(BOOL success) { // logic here }];


Debugging currently has some...limitations...that require you to attach to the process manually, if running on simulator.  Follow these steps (thanks to Daniel Kao):
  1. Build and Run your widget in simulator
  2. Go to Notification Center, include your widget in notification center, then press Done button
  3. Your widget should appear now
  4. Go back to Xcode, Debug, Attach to process by Process Identifier(PID) or Name, enter widget process ID or process name (should be the bundle identifier of your widget)

If you're doing this on device, you can just hit the run button, at which point you'll be asked to choose an app to run.  In this case, you'll want to choose 'Today', since that is the app the runs the extensions for the Today view in Notification Center.  I have found that debugging widgets on-device is very unstable, often crashing SpringBoard.  Pick you poison, I suppose.

'Wearables' as they are called is an interesting space right now.  Dominated with fitness bands that seem more fad than useful, saying that the state of the technology is in its infancy is being nice.  My biggest criticism of what's currently out there is lack of 3rd party developer support.  It could be argued that the iPhone (and by extension, Android) wouldn't be nearly as successful as it has been without other developers to build things that OEMs didn't originally think of or consider.

One of the stand-outs from this perspective is Pebble.  It has had 3rd party dev support practically since day one.  Its first release was quite rough, but v2.0 really unlocked some potential, allowing devs to persist data to the device, for example.  Even still, the path is far from well-tread and is beset with quite a few issues that are less than friendly to figure out.  Here's hoping that you can learn from my own mistakes.

Low Level Programming
C is a marvel.  The programming language can run practically everywhere and Dennis Ritchie definitely deserved receiving the National Medal of Technology because of his association with C, Unix, and other foundational technologies that we now take for granted.

But it is also a pain.  And the pain gets worse because you'll be writing a stripped down version of it that doesn't contain functions and libraries you may be accustomed to using.  The reason why: your Pebble app must fit in 24k of RAM. Yes, twenty four kilobytes of gold plated random access memory.

Get ready to get your hands dirty.  If nothing else, low-level programming makes you appreciate what higher-level languages and tools do for us. :)

There is no debugger.  I'm sorry.  This is a watch that connects with your phone via BlueTooth.

The Pebble 2.0 SDK comes with some higher-level logging capabilities, but require your phone to even see them.  I ended up using a 'debug label', a label added to the screen, for printing debug output.  It isn't incredibly useful when you're trying to debug memory issues, but it's better then trying to conduct a seance with your watch to tease out issues.

Build Your App In Stages
Because debugging is a pain, build your Pebble app in stages.  Have a plan for how you're going to build things, but don't try and do it all at once.  Start small and work big.  Commit or stash frequently so that if things go awry, you can roll changes back.  This is common sense when you're developing for a new platform, but sometimes we forget this important lesson.

Sample Apps and Documentation
The documentation that Pebble provides is...complete...but lacks clear examples on how to use all of the APIs.  Even though the SDK includes several sample applications, the coverage leaves a little to be desired.  This problem is compounded by the vast changes that were made between 1.x and 2.0 SDKs and all the search engines mostly giving back 1.x results.

Only when I had concluded making my first Pebble app did I stumble across this site that is very illustrative on how to build Pebble 2.0 apps.  I leveraged the excellent info here to add animations to my app.  It has really good basic examples and the author was even gracious to post all the code to GitHub.

Preparing for the Pebble App Store
Congratulations!  You got your Pebble app ready.  You got your iPhone code ready.  But you are actually far, far away from being ready.  Preparing for the Pebble Store is not something you do last.  You should start early in the development process.

Because the Pebble is an official Made For iPhone (MFi) accessory, there are a couple of hoops that you have to jump through that will add time to the review process. Take these steps, and the amount of time it takes to follow them, into consideration when planning your release.  If you do things right, you'll have done a bunch of this work ahead of time.  I did not and have had to learn the hard way:

  1. Create a Pebble App Store profile for your app.  This will create a Pebble Store ID for your Pebble app, which will be required in the next step:
  2. Fill out a white list request with Pebble.  Among other things, this form will ask you what the Pebble Store ID is for your Pebble app, as well as the bundle ID of your iPhone app.
  3. Go on vacation.  Seriously.  Pebble only submits their whitelist requests to Apple once a week (a Monday), so if you miss the cutoff, then you'll be stuck in the queue until the following submission.  Apple will take its sweet time as well, adding them a few days after Pebble submits the change.  Once Apple has whitelisted it, it could take 24-48 hours for the system to actually register in its systems for the reviewers.
  4. Once you have received word from Pebble that Apple has added your information to their Made For iPhone (MFi) program, you're now free to submit your iPhone app to the App Store for review.
I did all these steps at the very end of development.  With the back-and-forth with this process, it has taken more than three weeks (and still counting) to get my app through review.  YMMV, but DO NOT save this step for last.  You should be able to coordinate all of this such that everything is ready to go when your code is also ready to send off.

Wrap Up
Hopefully these things didn't dissuade you from thinking of building a Pebble app.  Pebble is just starting as a platform, but the promise is certainly there.  I really can't wait to see what happens with it and other wearables in the future.
I really buy into the premise: drive better, be fuel efficient. But this has loads of problems and ultimately makes my driving more stressful.

After nearly three months of using Automatic I got my first perfect score last week. But not for a lack of trying. The sensor dings me for accelerations that are not sudden (it's very unforgiving for standard transmissions), dings me for breaking that is not hard, and dings me for driving 69 mph (somehow the sensor thinks 69 > 70). I have a digital display telling me how fast I am, so either my car is lying to me or the device is dead wrong. Or how about when I set the cruise control to 68 and I get to 70 because I'm going downhill.  Yeah, that was totally my fault.

The fuel efficiency is wrong. Sometimes it eats trips. It's maddening.

They don't allow a data export, yet they blog about all this interesting information amassed from the user base. Allow me access to my data, please.

I'd really like to see huge improvements to their algorithms used to determine 'bad driving', data export, and even things to help me shift better (wouldn't that be cool and fuel efficient???).

Ultimately, I've decided to put this device away and *maybe* pull it back out when some HUGE improvements have been made--if I don't sell the sensor first.

UPDATE 3 MAR 2014:
Isn't social media awesome?

There is an alpha developer API for data.  Building some apps around it sound like fun, except I'd like to be able to access the link, as well.  I won't pretend that this will ever happen (and rightly so) but it's fun to wish.

As reported here, the dash speedometer may be a few MPH off from what appears through the ODB link.  My response:

@waynehartman Actually, speedometer dash display can be off by a couple MPH from actual speed. More here: ^AM

@automatic OK…since you know that it’s off, why not match the link with what the display shows?

@waynehartman We just take the data directly from the OBD port. But I can check in w/ the engineers about that. ^AM

@automatic Not likely available via OBD, but it would stand to reason with so much aggregate data you have an idea of which cars are off.