So, after completing my Xamarin Certification I wanted to try out something new so I choose WatchKit.  This is still in the very early stages with actual Apple Watches not due out till sometime in April, so now was a good time to get started.

The Setup

The WatchKit Preview for Xamarin is ONLY available with Xamarin.iOS 8.7 (current release is 8.6) and Xcode 6.2 with 8.2 Beta 4.  For Xamarin Studio you will need to first download the 5.7 beta (I am using build 661 for this) and ensure that is using the 8.2 Beta 4 code.  I am listing the links below which is also to imply their install order.

• XCode and 8.2 Beta 4 – Download from iOS Developer Center (requires Apple account)
• Xamarin Studio Download – http://download.xamarin.com/watchkit/XamarinStudio-5.7.1.47.dmg (Mac only)
• Xamarin.iOS 8.7 – http://download.xamarin.com/watchkit/monotouch-8.7.0.132.pkg (Mac only)

Important: Once you attempt to install Xcode and Xamarin Studio the instructions will tell you to place the .app in your Applications folder.  I recommend not doing this, especially if you have a pre-existing development environment (I do).  My recommendation is to drag both to your Desktop and open them manually so you can ensure the correct environment comes up.

Important: Shortly after I had my environment setup Xamarin released update to Xamarin.iOS 8.6.  Allowing these updates on my other environment overwrote my beta Xamarin Install.  I easily fixed it by rerunning the 8.7 update; advice: keep the .pkg file handle.

The only other remain step is to point the Xamarin Studio installation at the 8.2 Beta 4 SDK path.  This is easy enough as you just point it at the Xcode 6.2 .app file (on the Desktop if you are like me).  This option can be found under the Preferences –> SDK Locations –> Apple option.  Screen shot below

Full Xamarin Article: http://developer.xamarin.com/guides/ios/watch/installation/

Getting Started

So, the first part of the setup is creating the projects and you will need three of them.  Coincidentally, this is also the point you will realize, yes or no, if your installation worked or is broken.

First create the iOS app using the Unified templates, I recommend a Single View app for simplicity.

Next we need to add a Watch Extension project

Finally, the Watch app project

Once you call the projects you will embark on what is perhaps the MOST critical and flakey step in this process: specifying the Bundle identifiers.

What Apple is going for with the current incarnation of Watch is the package the Watch App inside the actual App.  To do this, we need to add special suffixes to the bundle identifier for the Extension and the Watch App projects.

Assuming the bundle identifier is something like: com.farrellsoft.testapp for the iPhone app, this is what the bundle identifier’s will need to be for the Extension and WatchApp respectively:

• Extension: com.farrellsoft.testapp.watchkitextension
• Phone App: com.farrellsoft.testapp.watchkitapp

At present, you can only set these values by opening the project info.plist file.  Also, when setting the identifier for the Extension you will also need to indicate the identifier for the Watch App for the field WK App Bundle ID.  In the case of this sample, the value of that field would be com.farrellsoft.testapp.watchkitapp

Before you can run the app, you will need to set the Extension as the Startup Project.

Note: this is where making sure you are running the correct version of Xamarin Studio is critical.  If you dont not see the correct templates, as shown above, close XS and verify that you have the right version running.

Run and Pray

If you follow Xamarin’s instructions they make this all sound very easy, but honestly, for me, this part was very trying.  Some tips:

• Hardware –> External Display – there is a chance than when you start the simulator you wont see the Watch simulator.  If this occurs, you can open the Watch Kit simulator from Hardware –> External Display with the simulator selected as the active application
• Reset Content and Settings – I found that I had to reset my simulators content and settings frequently as I was debugging the application.  A sign that this needs to be done is usually manifested in the application taking forever to deploy to the debugger not connecting.
• Restart the simulator – the old shutdown and restart technique has not lost its value

I wont sugercoat, this whole process seems very flakey, but it does work.  But I cannot tell you how much time I spent wondering why my application would not show up in the simulator.  The biggest tip is, be VERY careful with those Bundle Identifiers and look at them first before you start diving deep.

The Interface

Before you can really start coding, you will need to link some files into the WatchApp to support the user interface.  For this post, we are just going to focus on the normal interface, not Glance or Notification (neither of which is supported without the command line right now).

Right client the WatchApp project and select Add Files.  From the presented dialog, navigate to the Extension project.  You will want to select the InterfaceController.cs and the IntefaceController.designer.cs

Important: When you are presented the dialog regarding HOW to bring the files into the project, be sure to select the Link option (screenshot).

Once this is done, you can double click the storyboard and start building your interface.  More details here: http://developer.xamarin.com/guides/ios/watch/getting-started/

Communicating with the Phone

After I got things working, I started to explore a couple scenarios around Watch to Phone communication.  Apple has said that, for now, the Watch will not support standalone apps and will require the phone to do most things.

Communicating with the phone involves overriding the HandleWatchKitExtensionRequest in the AppDelegate of your iOS app.  The main thing to focus on here is the method will be passed an NSDictionary from the Watch app (more on that in a second) and can then reply to the phone using the “reply” delegate which allows the method to send its own NSDictionary back to the Watch.  This appears to be the primary mechanism, in this version, for data access facilitation.  I should point out that, even if the app has NEVER been run on the phone, it can still call this method.  In fact, updating the UI is pretty easy (code sample):

To invoke this method from the Watch you need only call the OpenParentApplication method from the WKInterfaceController base class that your WatchKit interface View Controllers will inherit from (code sample)

Data Access Strategies

So with this model in mind, I began to explore possible ways to access data.  While it will definitely be a topic in a future blog entry, I can already provide some detail.

Basically, the WatchKit delegate method in AppDelegate is permitted to access the storage of the app itself, we think.  This being the case, it stands to reason that the Watch can make a data request through this delegate method and receive it back, as you see in the example above.

At West Monroe, our thoughts, right now, are to store data in either a flat file or Sqlite database and see if (and how) we can display this data to the user via the watch.  Certainly, we see the UI and usability challenges being presented, but we also see the value we could provide our clients.

Final Thoughts

Honestly, I am not a super huge fan of Wearables mainly because its bad enough to have to change the phone every two years, now we might have to buy new watches.  That said, when I was at Evolve last year, I saw some immense benefits, especially with schedule keeping.  It really is going to be interesting to see how we can use these limited interfaces and what value we can bring.  The Wearable is not a new idea, Google has been at it for years, but something different when Apple gets their hands on it.  Right now, still way too early to fully evaluate WatchKit but I do like the direction.