Monthly Archives: September 2013

Music to Code By

When I was in college, I used to listen to music all the time when studying. I worked at KGLT (still one of the best alternative college stations in the country) as a DJ and the assistant manager (which meant sometimes being referred to by the music director – all innocence and sweetness – as the “ass. mgr.” in written communications). I had access to all kinds, but mostly liked grungy, thrashy music…and liked all of it loud. People would ask how I could ever study like that. But, believe it or not, the volume served to drown out external distractions and helped me focus.

I no longer find that true of the hard stuff. I still crank it up on occasion, but even find that on my bike rides or while running that I prefer thinking in relative silence. So while working, my musical choices have become more judicious. I still find Classical unappealing in this setting, needing a little more pep in the morning. (That’s why NPR always goes off  after 8:00 a.m!)

One of my favorites is Alberta Hunter’s Downhearted Blues: Live at the Cookery. If you’ve never checked out this wonderful performer, you owe it to yourself to not only enjoy the music, but also to fully consume her inspirational story.  There’s a good bio here but I was first introduced to her and her music by the documentary Alberta Hunter: My Castle’s Rockin’, which captures just how remarkable she was as a performer and a person. (You can find it here).

Accompanied on piano by the elegant gentleman and composer, Gerald Cook, Hunter really struts her stuff. Even at age 82 she still had the charm and impeccable timing that originally made her a star way back when. It’s worth watching just to see how a professional does it. I also find inspiring both her self-effacing modesty and her sometimes risque banter.

Most of all, Hunter has some wise advice – some of which will bring tears to your eyes if you’ve ever felt blocked or frustrated. Her words are without question informed by a life spent first working her way up the hard way to stardom, then chucking it all to change careers. She prudently fudged her age, conjured up a high school diploma, went to nursing school and worked in health care until forcibly retired in 1977 at the age of 82. Then resumed her musical career at an age when most people are probably just thinking about what the nursing home will serve for lunch today.

IKnow IEquatable

Well, now anyway. Sometimes I think the statement “Necessity is the mother of invention.” should – when applied to coders – be restated as “Necessity is the mother of fruitless hacks, StackOverflow searches and more code.” Catchy, eh?

Prior to my somewhat painful re-education (not going to use a diaeresis this time), I was operating under the ridiculous assumption that comparing to collections would be straightforward…if not downright simple. But my code kept telling me two identical collections were not. Of course a better coder would immediately recognize a reference problem underlying this. First I had blithely tried:

if (savedExercisesCollection != ExercisesCollection)
{
 for (int i = 0; i < ExercisesCollection.Count; i++)
 {
 ExercisesCollection[i].Order = i;
 }

App.StorageSettings["SettingsChanged"] = true;
}

But that was always returning true. Next, I turned to LINQ (’cause it is the solver of all problems, isn’t it?). Well, at any rate, my thinking was that it would actually compare the values. And it is elegantly concise:

if (savedExercisesCollection.Except(ExercisesCollection).Any())
{
 for (int i = 0; i < ExercisesCollection.Count; i++)
 {
 ExercisesCollection[i].Order = i;
 }</pre>
App.StorageSettings["SettingsChanged"] = true;
 }

I had also tried SequenceEqual but with the same sad results…until I stumbled across the IEqualityComparer<T> IEquatable @ http://msdn.microsoft.com/en-us/library/bb348567.aspx.

if (!savedExercisesCollection.SequenceEqual(ExercisesCollection))
{
 for (int i = 0; i < ExercisesCollection.Count; i++)
 {
 ExercisesCollection[i].Order = i;
 }

App.StorageSettings["SettingsChanged"] = true;
}

Now I was on the path to righteousness. All it would take is adding a comparer to my original class. I approached this with some trepidation since I’m relying on being able to serialize portions of that class. But the only way to know if something will blow up is to light the fuse. Turns out no worries.

I modified the class as follows:

[DataContract]
 public class Exercise : IEquatable<Exercise>
 {
 public List<Asset> AssetsList;

public Exercise(int id, int order, string description)
 {
 Id = id;

Order = order;

Description = description;

AssetsList = new List<Asset>();
 }

[DataMember]
 public int Id { get; set; }

[DataMember]
 public int Order { get; set; }

[DataMember]
 public string Description { get; set; }

 public bool Equals(Exercise other)
 {
 //Check whether the compared object is null.
 if (ReferenceEquals(other, null)) return false;

//Check whether the compared object references the same data.
 if (ReferenceEquals(this, other)) return true;

//Check whether the products' properties are equal.
 return Id.Equals(other.Id) && Order.Equals(other.Order);
 }

The take-home lesson from this is that unless an ObservableCollection is instantiated from the same source as another they are not automatically comparable. I can see this knowledge coming in handy when rehydrating a chunk of JSON, for instance to compare a remotely stored to-do list with one on the client.

Did ya hear the one about the serial killer?

Turns out his victim was found floating in a tub full of corn flakes and milk. Bahhh, dahhh, dahhh, da.

Anyway, in this case it was more that the serializer got killed…by an uncoöperative class. (BTW, that’s not an umlaut over the second “o”. It’s a diaeresis. Lovely sounding term. More on the subject: http://www.newyorker.com/online/blogs/culture/2012/04/the-curse-of-the-diaeresis.html). Typically, this happens because the class has a constructor with parameters. I couldn’t get around that. Well, I don’t want to anyway. I also didn’t want to depart from my vanilla JSON serializer, although in the past I’ve found SilverlightSerializer to be a solution when all else fails…like serializing an entire model. (Why would you want to do that? Long story, for some other time).

The solution is to simply mark up the class with the DataContract attribute and use DataMember for each of the members you want to serialize. In my case, this had the advantage of not serializing a voluminous sub-list I don’t want included. And it allows this class to be used in several places, rather than creating a separate Dictionary or similar.


[DataContract]
public class Exercise
{
 public List<Asset> AssetsList;

public Exercise(int id, int order, string description)
 {
 Id = id;

Order = order;

Description = description;

AssetsList = new List<Asset>();
 }

[DataMember]
 public int Id { get; set; }

[DataMember]
 public int Order { get; set; }

[DataMember]
 public string Description { get; set; }
}

And, voila, we end up with something that can be saved to IsolatedStorage:

[{“Description”:”JUMPING JACKS”,”Id”:0,”Order”:0},{“Description”:”WALL SIT”,”Id”:1,”Order”:1},{“Description”:”PUSH UPS”,”Id”:2,”Order”:2},{“Description”:”CRUNCHES”,”Id”:3,”Order”:3},{“Description”:”STEP UPS”,”Id”:4,”Order”:4},{“Description”:”SQUATS”,”Id”:5,”Order”:5},{“Description”:”TRICEPS DIP”,”Id”:6,”Order”:6},{“Description”:”PLANK”,”Id”:7,”Order”:7},{“Description”:”HIGH KNEES”,”Id”:8,”Order”:8},{“Description”:”LUNGES”,”Id”:9,”Order”:9},{“Description”:”PUSH UP & ROTATE”,”Id”:10,”Order”:10},{“Description”:”SIDE PLANK”,”Id”:11,”Order”:11}]

Market share, market share, market share

First, why is a developer writing about this? The most obvious reason is that there has to be at least some market to make it worthwhile to create and promote apps. What I find misleading, however, is raw percentage numbers. There’s no denying that if a raw percentage is too low, e.g. Blackberry, you’re wasting your time. That platform is dead in the water.

But I also have doubts over the value of Android’s seemingly commanding 80% of worldwide smartphone users. And I find it amusing/disturbing that many still dismiss Windows Phone because it has 1/4th the share that iPhone does. While no one writes off Apple because it has 1/4th the share of Android.

From a developer perspective, it (literally) pays to look deeper into the numbers. Recently I’ve read that a good number of Android apps are simply pirated, which in certain countries is also true for iPhone, since a good many are jailbroken. I’m sure there are many reasons, including the “free” OS ethos Google likes to promote, that Android users don’t pay for apps. And that seems to apply across national boundaries. But in some places, Apple faces the same problem.

80% market share is not as impressive if only 1% of users ever pay for your apps. Granted, that can still be a large actual number. But the point is, again, it’s worthwhile to not just take raw numbers at face value. Because of the underlying lack of value, I’ve never been interested in developing for Android. Technically, it would seem more feasible for a C# developer to move to Java. Prior to Xamarin (which doesn’t solve all my problems), the main barrier to iOS development for me has been finding the time to fit in learning Objective-C. C# has been my bread-and-butter, actual make-a-living, development language for quite some time.

Going forward, I will develop or work with other developers to get into the iOS market. I’ve read a few negatives such as many iPhones in places like China are jailbroken. And that apps are mercilessly copied and slowly purged by an indifferent Apple App Store. (But the latter has happened somewhat to me too in the Windows Phone store, where elements of an app were poorly aped – like some sort of Bizarro Superman version). Yet – if one can do enough outside promotion – the iOS market is definitely worthwhile.

Much has been written about the diminishment of Apple (reflected in its stock price) and even its potential demise if developers ever switch to an Android-first policy en masse. But I doubt I’m the only developer that has noticed that Apple still holds almost half the American smartphone market (never mind tablets). And that, along with European/ANZ markets, is almost certainly where people are not adverse to shelling out 1/3rd the price of a Starbucks latte for apps.

On to Windows Phone. While it has made some impressive gains in certain markets – particularly in Europe (http://www.kantarworldpanel.com/Global/News/Record-share-for-Windows-phone) – there is both good and bad for the developer. First the bad: Windows Phone still doesn’t have a great share in the U.S. It’s just 3.5%…up from about 3.0 from the same quarter last year.

Also (less bad), the people buying Windows Phones tend to be converting from feature phones. While I don’t have proof, I have concerns whether they’re willing to spend on apps. Furthermore, it’s not Android/iOS users jumping ship and giving mind share to Microsoft/Nokia.

Finally, (least bad but also potentially indicative of shallow pockets), the Windows Phones people are getting are not the trophy devices like the Lumia 1020. Rather, the 520 is the most popular phone. I say least bad because – from a developer standpoint – even the lowliest Lumia is still going to hold up pretty well to your coding demands. It might not support some games but that’s an invitation to put more creative thought into the game play rather than the special effects. I have both a 920 and a 620. While I’d never choose the 620 as my personal phone, it’s a dandy little device and runs my code just the same as its bigger, heavier brother.

Also, bear in mind that outside the U.S. phones are rarely subsidized. In Europe, too, everything tends to be more expensive (my wife still reminds me how I paid €3.00 for floss in Italy). Paying for a phone up front would, in my opinion, lead one to the cheaper models. So perhaps given that backdrop doesn’t mean users are going to be payment-adverse when it comes to apps. (More on that below).

The good news for the developer is that market share is growing. It may not be perfect and may not be widespread, but if it was contracting after all this time, there would be no clearer message to get out. What is also encouraging is that – at least for my two current apps in the Windows Phone Store ( 7-Minute Workout – http://www.windowsphone.com/en-us/store/app/7-minute-workout/879efccc-5c9e-4b19-b8e6-346b76ff0133 and Ballistica – http://www.windowsphone.com/en-us/search?q=ballistica) – conversion rates from trial to paid are quite good. 7-Minute Workout, which is a more broadly popular app and is priced at the sweeter spot of $0.99, has a 20.6% conversion rate. Ballistica, which is definitely a niche app (aimed at target shooters and hunters), has a 14.3% conversion rate.

I should point out that despite not (yet) being localized, 7-Minute Workout has done really well in non-U.S. markets, further strengthening my hypothesis (Isn’t that what you call any notion relying on anecdotal data?) that Windows Phone users tend to be more like their iOS counterparts, i.e. willing to pay for good apps.

So when it comes to percentages, a larger paid percentage of a smaller market share may well beat writing apps that never make a dime off a vast pool of freeloaders…did I say that?

On a topical note: I do hope (as expressed in the intro to Outkast’s Hey Ya http://www.youtube.com/watch?v=PWgvGjAhvIw) that Microsoft doesn’t screw up the acquisition of Nokia’s phone assets. It’s still critical that they find a way to build up U.S. market share.