Test Driving the Microsoft Band SDK

TL;DR: The Band SDK is currently very much a preview and you should wait if you want to do anything serious with it. You’re very limited in functionality.

Pairing

I use my Band on a day-to-day basis with my Nexus 5. I had never paired it to a Windows Phone. I had to factory reset my Band to get it to sync with my Lumia 635. I’m hopeful this is not a common issue when switching between platforms. I had no problem getting the band to pair back to my Nexus 5 when I was done. If it is an issue, then cross-platform development would be significantly easier if you had a separate Band for each platform. That may be true anyways to avoid constant re-pairing when testing multiple platforms at once.

SDK

I was using the 1.3.10219-preview build from NuGet. Currently, you can

  • Read sensor data in real-time
  • Create tiles and send notifications to them
  • Change themes
  • Change the main tile background image

I was mainly interested in sensor data. My goal was to create a simple app that would post your steps for the day to Slack (I have a lot of Slack code from a Windows Phone Slack client I started and didn’t finish). Ideally, the user would be able to tap a tile on the Band and a message would be sent to Slack. Unfortunately, the SDK does not support anything like that. You can send notifications to a tile, but you can’t trigger code on the phone from a tile. My backup plan was to have a timer background task that read step data from the Band, but that didn’t work either. Apparently, the SDK does not work in background tasks right now . I settled for the user having to tap a button in the app.

PCL Support

While I was working on Windows Phone, a co-worker was playing with the SDK on Android using Xamarin. We were disappointed to see that the NuGet package does not support Profile259, which would include iOS and Android. It only supports net45+win+wpa81. Long-term, I hope to see the interfaces separated into a separate assembly so that they can be referenced by the PCL. Otherwise, I would need to wrap almost the entire SDK myself to use it with MVVM. Or hope that Xamarin does it for them with their component.

Pitfalls

  • Bluetooth is flaky. You will get IO errors. Be ready for them.
  • I was also surprised that the pedometer sensor gives the total number of steps the device has seen overall, not just for the current day. Since you can’t run in a timer background task right now, there is no reliable way to get just your steps for the day.
  • Be careful managing the lifetime of your IBandClient objects. When it gets disposed, all of your open connections to the Band will be closed. This is perfectly reasonable, but I wasn’t thinking about it at first. If you’re wondering why your ReadingChanged event never fires, this is probably why.

Mapping View Model Dependencies with MvvmCross and AutoMapper

AutoMapper is one of those amazing tools that I wish I was better with. It’s incredibly flexible, but I often throw in the towel and map things myself when it starts getting complicated. A recent pain point has been view models in a MvvmCross project.

MvvmCross is a nice C# implementation of the MVVM pattern. I use it on a daily basis to write mobile apps. It’s very common to use it with AutoMapper to map from Model -> View Model. However, my view models often have constructor dependencies, which AutoMapper can’t handle with the default configuration.

Solution (On GitHub)

MvvmCross is able to supply these dependencies. We just need to make sure everything is registered and tell AutoMapper how to get them. My demo is a simple app that displays different types of tiles.

public class TileViewModel : MvxViewModel
{
private readonly ITileService _tileService;
public TileViewModel(ITileService tileService)
{
_tileService = tileService;
}
private string _color;
public string Color
{
get { return _color; }
set { _color = value; RaisePropertyChanged(() => Color); }
}
public IMvxCommand UpdateState
{
get
{
return new MvxCommand(async () =>
{
await _tileService.UpdateStateAsync(this);
});
}
}
}

view raw
TileViewModel.cs
hosted with ❤ by GitHub

You can see that TileViewModel has a dependency on ITileService. Because of this, AutoMapper can’t instantiate a TileViewModel. We need to let AutoMapper know how to supply this dependency, which we can do through configuration.

// Tell AutoMapper to resolve dependencies using MvvmCross's service locator.
Mapper.Configuration.ConstructServicesUsing(Mvx.Resolve);

view raw
AutoMapperProfile.cs
hosted with ❤ by GitHub

The default App.cs for MvvmCross already registers all interfaces that end with “Service”, so we just need to register the view model.

Mvx.RegisterType<TileViewModel, TileViewModel>();

view raw
Register.cs
hosted with ❤ by GitHub

Now, we just need to tell AutoMapper to use the service locator when mapping to TileViewModel

Mapper.CreateMap<Tile, TileViewModel>()
.ConstructUsingServiceLocator();

view raw
CreateMap.cs
hosted with ❤ by GitHub

And the magic is complete. Now, we can use AutoMapper as usual.

var tiles = await _tileService.LoadTilesAsync();
var tileViewModels = Mapper.Map<IList<TileViewModel>>(tiles);

view raw
MapViewModels.cs
hosted with ❤ by GitHub

When we map to TileViewModel, each instance is resolved with Mvx.Resolve, which knows how to supply an implementation of ITileService. You can see a complete demo app at https://github.com/CuriousCurmudgeon/MvvmCrossAutoMapperSample

Startup Founders & Risk

Real Life Sciences (RLS) failed for many reasons. The tech team consisted of me and one of the co-founders. (And for the first few months it was just me.) The tool we built was functional, but not spectacular. We used a lot of tech we weren’t familiar with, which slowed progress. The team was distributed across four cities, and none of us had experience working remotely. Consequently, communication was poor. The only funding came from a family member of one of the co-founders.

But I think the biggest reason for failure was risk imbalance among the founders (and me).

I was initially brought in as a full-time consultant to build the first version of the product. At this point, the four co-founders were all working part-time in various capacities. After a few months, the technical co-founder lost her day job when that startup went under and she shifted over full-time to RLS. Two other founders were working on finding funding and the fourth founder did… something. I never was quite sure what he did.

At this point we had four founders in the following situations

  • The technical co-founder was working with me full-time building the product.
  • The two business/sales co-founders were working with our alpha customer and trying to secure funding, but only part-time.
  • The fourth co-founder was doing… something.

We were now in a situation where the people responsible for securing funding had little to no risk compared to the technical people. Both of them had good jobs and no incentive to quit them. It’s unclear what level of success would have even been required to bring them in full-time. I’m not blameless either. I enabled the situation by continuing to work for equity after the money ran out. It doesn’t matter how much of the pie you own when there is no pie.

I know it is almost impossible to be part of a startup where all co-founders take on an equal risk. There are too many circumstances outside of work for that to be possible, but don’t make the same mistakes I made.  If you see a situation where the risk is extremely lopsided, bring it up. And if nothing changes, look for your exit.

Knowing When To Quit

Note: I started this post in October 2012 after quitting my previous job at the end of February 2012. I never posted it, but feel it is appropriate now that the company exists in name only. I’ve made slight changes, but most of the post exists as I originally wrote it.


I haven’t been paid since August. The only co-worker I see on a daily basis is my cat, who always thinks it’s her turn with the keyboard. I would love to have a week of physical interaction with the rest of my team. And even with all of that, my new job is still awesome.

Knowing

I’m not a quitter by nature, but in February I actually did it. I quit. I had been trying to make it work. I really was. Eventually though, I had to accept that sometimes a job just isn’t right for you. The tech may not be interesting. Maybe the pay is mediocre. Possibly your main project has no direction. And sometimes all of these converge into one… what? I mean, it’s not terrible. You can live with it. After all, they are giving you money to write code, right? And your co-workers are all really nice.

But what if you don’t need the money? Or you spend a good chunk of your time wondering why you came to work today? Or every time you look something up on StackOverflow you get distracted by the Careers 2.0 postings along the right side. That’s where I found myself this winter, so I quit.

Quitting

I wrote an email on a Friday, slept on it over the weekend, and then sent it first thing on Monday morning. By mid-morning, I knew that I was going to be unemployed in two days. I had no plan, just the usual “exploring opportunities” and “researching startup ideas”. But I didn’t need the money and I felt amazing. The happiest I had been about my career in awhile.

Moving Forward

And then everything just fell into place. Former co-workers and classmates heard I was available and within days I had multiple options. I decided to work remotely for a former classmate’s startup. And when the money ran out I just kept working.

I get to work with an up to date stack on a greenfield project (the first true greenfield of my career). I get serious input into the architecture. I get the freedom to work whatever hours I want, from wherever I want. And, right now, I don’t get paid. Sometimes though, it pays to be a quitter.


Postscript

It’s now May 2014. That startup never did get any more funding. I continued to work on it intermittently, but cut my hours back significantly. I got a lot of equity thrown at me, but even 100% of zero is still zero. Amusingly, I was so underpaid before, that even though I didn’t get paid for the last five months of work, I still made almost as much as I had the previous year.

I was already having doubts that funding was coming around the time I wrote this post, but I didn’t have anything else on the table at the time, so I stuck with it. I need to collect my thoughts, but for now I’ll just say that you should avoid a startup where there is an extreme risk imbalance among the founders.

Two Year Recap

The short recap of where I’ve been for the past 2 years.

On February 29, 2012, I quit my job at Summersault working on Adopt-a-pet.com. I was struggling with RSI and the work wasn’t fulfilling. The backend was a mess and the project had no direction. I had butted heads with other developers over some issues repeatedly and no progress was being made. My plan was to take some time off to rest my arms and look at some startup ideas.

That plan literally lasted one day. On March 1 an old college friend contacted me asking if I wanted to come work at her new startup. Over the next 6 months we made progress, but funding dried up and the product died in a private beta. Professionally, the best things to come out of it were that I got to say I was a professional Ruby developer and that I had experience working remote.

From there, I transitioned into my current role as a remote developer for InfernoRed Technology. I’m back in the .NET world, which still feels weird. I hadn’t owned a single machine running Windows since 2008. Now I’m writing Windows 8.1 apps. It also broke my streak of not having professional experience with a new job’s primary language. I went from C# -> Perl -> Ruby -> Python -> C#. (Yeah, there was a brief Python foray in there.)


The real purpose of this post was to get back into the swing of writing and publishing. Over the past couple of years I have started writing several posts, but never finished. I’m a creature of habit, and if I don’t include writing in my regular routine, it just doesn’t happen. Hopefully this is a new start.