Kotan Code 枯淡コード

In search of simple, elegant code

Menu Close

Tag: wp7 (page 1 of 2)

Windows Phone 7 Marketplace Continues to Disappoint

When Windows Phone 7 first came out, I remember all of the skeptics and the members of the “cult of Apple”, and even the Android fans, all telling me that WP7 was a passing fad and  that Microsoft had wasted its chance to enter the mobile phone market with its failed mobile Operating Systems, “PocketPC” and “Windows Mobile”. I told them all they were insane, because Windows Phone was awesome.

I still firmly believe this. From an overall experience point of view, Windows Phone allows me smoother, faster, more efficient access to everything I need than iOS. My common everyday workflows on a Windows Phone are faster and less intrusive than they are on an iOS device (I won’t even talk about Android… I can barely stomach 30 seconds of interaction with most droids).

So, if I still think that the core of Windows Phone 7 is so awesome, why is the word disappoint in the title of this blog post? The answer is simple: the marketplace or the “app store”. Today, long after the “it’s just a v1 product” excuse has expired, I can go to the Windows Phone marketplace and I become nauseous with what I see there.

Firstly, if you look at the list of top games in the Marketplace, they are either first-party (Microsoft made them or paid someone else to make them under their iron fist) or they are made by giant third-parties like Electronic Arts or any of it’s 80 bajilion subsidiaries. You still see a few good examples of non-MS games but, the point remains – Microsoft and the other gaming giants pretty much own that segment of the Marketplace. This is completely explainable – making a game for a mobile platform is a pure and simple ROI (Return on Investment) calculation. How many potential buyers are there * price per game – production cost total / potential buyers = potential profit. The reason we don’t see as many ports of ridiculously popular iOS games is simple: the ports would probably cost more to make than they would earn. Note probably there, because that notion is very subjective and easily influenced by the paranoia of any given decision maker. Bottom line? Developers are still skeptical.

Secondly is the experience of the marketplace. When I flip through Apple’s App Store, I see a wide variety of great stuff – so much stuff, in fact, that I can’t possibly sift through it all. However, I feel somewhat confident that Apple’s “featured”, “popular”, and other filtering and sorting systems will allow me to find relatively good examples of the type of application I am looking for.

Today, when I go sifting through the Windows Phone marketplace, I feel like I’m walking through the “old times square”. You know, the one that used to be peppered on all sides by strip clubs, peep shows, adult video stores, with a drug dealer on every corner. I’m not exaggerating – In the “most popular” filter for most of the apps in the marketplace I regularly skim past 4 or 5 apps with half-naked women on their icon. I understand that Microsoft may not have full control over this because, after all, if boobs are popular, then boobs are popular and what can they do about it??

The problem is that I can’t see the forest for the trees in their marketplace. I cannot find anything with ease and often some of the most amazing Windows Phone apps don’t show up anywhere – I have to search for them by obtuse keywords that friends have given me who told me about these great applications. Not only is the marketplace diluted with immature fart apps, “boobs” apps, and other garbage for which I have no use, but the worst offense of all is that the marketplace is sinking under a deluge of irrelevant stuff that they could easily filter out. It would literally take them a few hours. But they don’t do it.

Every single time I go to the marketplace to check out what’s new, I see countless apps written entirely in foreign languages that are obviously designed for foreign audiences. If I have to scroll past 150 apps (this is also not an exaggeration, this happened to me recently) just to see something that actually pertains to my search, I am going to give up looking.

And that’s exactly what I have done. I no longer use my Windows Phone for apps. It is a sad, sad commentary because I love Metro, I love Windows Phone, and I absolutely adore the integration, the “hub” concept, and everything else that operating system does so well. But even for a “low app” consumer like me who only regularly uses 3 or 4 apps, the current state of the marketplace turned me off.

If the marketplace’s current state can turn me off, someone with an absolutely insane tolerance for shitty experiences, then I can’t even imagine how quickly standard consumers are being turned off by that same marketplace.

Slide Deck from my NYC Code Camp Presentation

For those of you who attended my Code Camp NYC presentation on casual and indie gaming with Windows Phone 7 and “the cloud”, I have finally managed to find and upload the PPT slide deck. Ironically enough, the reason it took me so long is because I had trouble with the cloud drive on which the deck was stored 😉

I will be posting code samples that go along with this presentation in one form or another soon… so stay tuned!

Indie and Casual Game Development with Windows Phone 7

App Store Developer Experiences – Separating the Wheat from the Chaff

This weekend I spent a considerable amount of time working with Apple’s In-App Purchase system so that I could get sample code and screenshots for the In-App Purchases chapter of my upcoming book on Mac OS X Lion programming. The experience easily ranks among the most frustrating learning curves I have experienced for any technology. I read and re-read the iTunes Connect Developer Guide, read and re-read the StoreKit Programming Guide, read and re-read five or six other documents. As is typical with Apple documentation, each document provided a tiny nugget of insight hidden deep among the prose and, only upon reading each document a third or fourth time did the true “how to” information surface.

To be fair, there is a learning curve to any new development platform and it’s a foolish assumption that the App Store portion of any mobile platform should be “easy”. The problem here is that Apple consumers always assume that Apple stuff “just works” and Apple developers know better – it’s rarely that easy.

So, how painful should an App Store experience be? I feel that there needs to be some level of complexity. After all, you are participating in a supply chain where real money and real products exchange hands and this exchange needs to be secure and Apple needs to be able to weed out those who would attempt to defraud or dilute the marketplace.

What it really boils down to is this – the marketplace vendor (Apple, Microsoft, and Google, for example) has a choice when they design the interaction between developers and the marketplace. They can choose how much work they do on behalf of the developer and how much work the developer must do.

Let’s take a quick example. On Mac OS X, you must manually validate the receipts issued by the App Store. Very early in the life of the Mac App Store, Angry Birds did not validate receipts. As a result, it was possible for people to take a legitimate, purchased App Store bundle, rip out the legit receipt and replace it with the receipt for a Free application … and then the bundle could be distributed (read: pirated) outside the App Store.

This manual validation process involves using a third party command-line tool to generate ANSI C classes that rip open the PKCS file and extract individual bits and bytes from the underlying, encrypted binary data. You’re not done there. You then need to figure out how to utilize the ASN.1 code that was generated on your behalf in order to validate the receipt you find in your App’s bundle. Once you get that working, you’re going to need to modify your code further so it doesn’t look like everybody else’s code to avoid giving hackers a replacement pattern on which to search for malicious injection and hijacking (e.g. replace the return value in your “IsRecieptValid()” function to always be YES, etc).

While I am all for security, and I can certainly see the need for this level of security, what I disagree with is the fact that Apple is deferring this particular task to developers. Many developers are going to skip this process because it is maddeningly difficult to get right and it employs a skill set that many developers new to Mac OS X will simply not have (low-level C, encryption “by hand”, etc). The argument here is that it’s a necessary evil so suck it up, be a man, take your lumps, blah blah.

But does it have to be? Do we really need to go through that effort? We can’t even re-use libraries we find sitting on github because any of them with a common surface area are detectable by hackers who have access to the same code, making all our hard work completely meaningless.

I don’t know what the Android store is like but I know that the Windows Phone 7 store does not foist this kind of gruntwork requirement onto WP7 application developers. The security infrastructure takes care of this kind of thing. Hell, the security infrastructure on iOS even lets us make web calls to validate receipts, and Apple promised we could do the same for Lion but – are you going to explain to your users that you don’t know if the app is legit because you can’t communicate with iTunes? (this is why DRM-haters hate iTunes, BTW…). Windows 8’s security and signing infrastructure mirrors that of Windows Phone 7 and will not require developers to drop into generated C code to validate the legitimacy of the application – “it just works”.

So, what’s a developer to do? Nothing, of course. The potential target audience of all Mac laptop and desktops make this a necessary evil if you want to make commercial applications for Mac OS X. So we will have to suck it up and take our beating if we want to reach that target audience. The point is that we shouldn’t have to. It should be easier, it should be simpler, it should just work.

Remember: If it seems more complicated than necessary, it probably is. That said, there are times (like this) when you can’t do anything about it other than rant and rave.

Struggling with SSL and Cloud-Backed Mobile Applications

While it is still certainly very common for mobile developers to build applications that stand on their own and do not communicate with the Internet, every day more and more mobile applications are released that are what we used to call “Smart Clients”. These apps sit on your mobile device (and are not browser apps or browser-shell apps). They might store data locally as a cache or back-up mechanism but the bulk of the application’s information comes from the Internet or, if you’re really upping the buzzword quota, the Cloud.

Let’s say you’re building a recipe application for mobile devices. This app is designed to let people access their recipes from any location so long as they have network data access. When you start the app, it queries a cloud-hosted server for your recipes and probably does so using some kind of secure authentication mechanism. Based on how a lot of cloud service providers are working lately, it’s very realistic to assume we’re doing Basic HTTP authentication over SSL.

Now we get into the real benefit of putting the data in the cloud – cross-platform access. I decide to write a Windows Phone 7 app and an iOS app. They both talk to the same recipe database and I should be able to share data among them seamlessly. Why would I do this? Because many people own a non-Apple phone and an iPad. Additionally, families often share service accounts where different family members have different mobile devices. Think Evernote here – they have apps for Mac, Windows, iPhone, iPad, Android – all access your shared, cloud-hosted store of notes.

Here’s the rub, the sticky bits, the source of the last 3 nights of frustration for me: not all services provided in the cloud surface clean, valid SSL certificates.

What does that mean? It means that when you make HTTP requests over SSL from an SDK, you are at the mercy of the limitations of that SDK. For example, if I am writing a desktop or server application in .NET and I know that a cloud database I’m talking to has SSL certs that don’t match their host names, I just write code that looks like this to manually override the cert validation:

ServicePointManager.ServerCertificateValidationCallback =
    ((sender, certificate, chain, sslPolicyErrors) => true);

I can put conditional logic in there to only let certain certificates from certain hosts go through, but you get the idea. Bottom line is I have some back-up plan where I can write code to counteract what most people consider “bad net citizenship” (SSL certs that trigger warnings or worse, fail outright).

What about with iOS? What happens if my iPhone application runs into a bad SSL certificate. Again, I should not have to write this kind of code, but it is possible. When you are picking your cloud service providers, I would add a lot of extra weight to providers whose data comes through on clean SSL certs.

Here’s the juicy part of the iOS code (part of an NSURLConnection delegate class) that manually overrides the SSL cert by responding to an authorization challenge:

- (BOOL)connection:(NSURLConnection *)connection
   canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace
    NSString *challenge = [protectionSpace challenge];
    if ([challenge isEqualToString:NSURLAuthenticationMethodServerTrust]) {
        return YES;

- (void)connection:(NSURLConnection *)connection
    didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
    NSURLCredential *credential = nil;
    NSURLProtectionSpace *protectionSpace;
    SecTrustRef trust;

    protectionSpace = [challenge protectionSpace];
    trust = [protectionSpace serverTrust];
    credential = [NSURLCredential credentialForTrust:trust];

    // say "yes" to everybody... Note, this is BAD
    [[challenge sender] useCredential:credential

Why do I say this is bad? Well, the whole point of an SSL certificate is to establish a secure connection between you and the remote server. If someone gets between you and the remote server (called a man-in-the-middle attack) they can do all kinds of nasty crap to your data and, because you’ve written the above code, they might be able to get away with it.

But let’s say that you’re willing to accept that risk and you plow on. So now you decide to write a Windows Phone 7 app that reads from the same cloud database. Your code fails because the SSL cert doesn’t match the host name (again, this is a really common problem when cloud hosts do things to support massive numbers of clients). Well, you just use the ServicePointManager class like you did with the desktop .NET app, right? Ooops. No, actually, you’re utterly screwed. No such class exists in the WP7 SDK. In fact, there is absolutely no way in WP7 to override the validation of SSL certificates. In short, if an SSL cert chain fails and your WP7 app is on the client side of it, your app will not be able to talk to the remote server.

Case in point: I’ve been doing some experimenting with hosting an instance of CouchDB on Cloudant as an add-on to an application hosted in AppHarbor. This is great and they give you a nice SSL URL with a username and password embedded so that you can do awesome JSON goodness with CouchDB’s HTTP API. However. The certs from Cloudant fail validation on both iOS and WP7. About the only place it doesn’t fail validation is when using curl from the command line. If you’re using iOS you’ll be forced to hack around the SSL cert validation. If you’re using WP7, you’ll be totally boned.

So, what are the key points I want you to take away from this blog?

  1. If you’re using WP7, complain and never stop complaining until the folks at Microsoft catch up to all the other mobile operating systems and actually give us the ability to intercept auth challenges in the cert chain. Not having the ability to override SSL validation in a WP7 app is assinine. I realize that MS wants us all to be secure, but for the love of all that is good, even Apple allowed us to have this ability, and they are notoriously paranoid about mobile security.
  2. E-mail, phone, or smoke-signal the provider of your cloud service and complain that their SSL certs aren’t good enough. Many of them will have a facility that will let you use your own certificate purchased from one of the authorities on both Microsoft and Apple’s root authority whitelist, but that won’t fix the host name problem. If you are comparing two providers (e.g. two hosts of CouchDB) and one has certs that fail and the other doesn’t, definitely give more weight to the one with good certs.

Again, this is not a pandemic or a problem that affects the entire universe. This problem only occurs when you’re trying to access resources over SSL from mobile devices and the SSL certificate fails validation. This validation failure happens a lot when hosts do creative things with their certificates and their host names. If this applies to your host, give them a call or an e-mail and see if they have workarounds available. The last thing you want to do is write your own proxy to compensate for bad certs, because that’s just going to make the gap between your proxy and the cloud host as vulnerable to MITM attacks as your mobile device would be without the proxy.

So, go forth and consume cloud resources over SSL – just make sure your mobile SDK can override bad certs or your cloud provider has ways of making the certs look valid.

What I’ve Been Up To Lately

I was originally thinking of framing this post in the form of an apology. For example, “I’m so terribly sorry that I haven’t been posting to this blog lately.” I’m not going to do that, however. While I freely admit that the blog has been barren for the last couple of months, it hasn’t been without reason.

Firstly, I have been wrapping up my work on the Windows Phone 7 for iPhone Developers book. I’m really proud of this book and I really like the way it came out. If I had it to do over again and was able to add a few hours to every day I spent working on it, I would’ve spent more time building parallel samples so that the code downloads for the book included nearly as much iOS code as it did WP7 to allow iOS developers to compare real-world, full-functioning scenarios. Oh well, perhaps I’ll include that kind of depth in a future “Mango” edition of the book (if there is such a thing).

Second, I’ve been in the process of moving. I’m packing up stuff, throwing stuff out, and staging my old house for sale. This is time consuming when you’re still working on copy edits, tech edit reviews, oh and trying to squeeze in a little family time in there here and there.

Thirdly, I’ve started working on a new book. I can’t yet tell you the title, but here is a hint: all of the code is written in Objective-C 🙂

Fourth, I’ve been working on a series of articles for the SilverlightShow.net website, all about WP7 for iPhone and Android developers. Check out that series here.

WP7 for iPhone and Android Programmers – Intro to Xaml and Silverlight

In this 2nd article in my 12-article series, I provide an introduction to the generic instantiation language Xaml and how you can use Xaml to produce the most basic Silverlight UI elements on Windows Phone 7.

Click here to read the article.

WP7 for iPhone and Android Developers – Introduction to C#

I’ve started a new series of articles over on Silverlightshow.net. In this series of articles I guide the reader through some of the most important aspects of Windows Phone 7 development, with an eye toward helping readers map their existing iOS and Android knowledge to C#, WP7, and Silverlight.

The first of these articles has just been published here. Head on over and give it a read, I hope you enjoy it.

Dopamine Squirts, Intermittent Reinforcement, and Mobile Apps

Is this you? Your phone vibrates and you pull it out of your pocket to check and see if anything interesting caused the vibration. You have a moment of boredom in a store, in a checkout line, while waiting for your spouse to get dressed – so you pull out the phone and run through a checklist of information to peruse – looking to see if anything exciting has occurred in your digital universe be it Twitter, Facebook, or any of a thousand different things people can check on these days. Finally, after prolonged lack of exposure to your smart phone, your overall sense of boredom is heightened. You get fidgety, you get bored quickly, and you feel disconnected and out of touch. Often times you simply don’t know what to do with yourself w/out a laptop or your mobile phone.

If this is you, don’t be ashamed. You’re just like millions of other people who are being conditioned by their “smart” mobile devices. Every time your phone vibrates to alert you of the possibility of something interesting, exciting, or even mundane (but new) – your brain is getting what psychologists call a “Dopamine squirt”. Over time, your brain links the phone vibration, ring, or the “new SMS” tone to a brief release of dopamine. You feel this tiny little rush of excitement that feels like adrenaline every time your phone vibrates, jingles, rings, or otherwise begs for your attention. Since this is dopamine we’re talking about, you actually suffer mild withdrawal symptoms when you are away from your phone or your phone is idle/quiet for a long period of time. You get fidgety, anxious, bored, etc.

Intermittent Reinforcement is another psychological term that is used to refer to the behavior of people tethered to their smart phones. Even if their phone has been programmed to alert them to the arrival of something new and noteworthy, millions of people will pull out their phones and do a quick scan for “new or interesting stuff”. The next time you’re in an airport, or a Starbucks, or any other crowded place (especially one with business people on their lunch break), sit back and do some people watching. Watch how often people pull out their phone, do a scan, then put their phone back. The scary part comes when you see the same person do this 4, 5, 10 times in a row while waiting in line for their coffee, sandwich, or standing on a street corner waiting for the “walk” signal to light up.

Intermittent Reinforcement is the addictive quality of video games and it is affects us at such a core, low level that no matter what kind of person we are – gamer, geek, artsy, whatever – we are still able to be conditioned using this pattern. The people holding these smart phones (I often call them “holsters”, referring to the level to which people have begun delegating all of their primary brain function to the little devices in their hands rather than thinking for themselves) have been conditioned to check their phones periodically for stimulation, to get the little squirt of dopamine. They pull out their phone, ask it “anything new?”, then put their phone back. 10 seconds later, they’ll pull the phone out again, repeat the process, and so on. The dopamine squirts that build up these subtle, low levels of addiction in people are what makes otherwise sane people crave the dopamine squirt even while driving, so they pull the phone out and check messages, send texts, and other horribly dangerous things.

In laboratory studies, rats are conditioned using Intermittent Reinforcement. They go over to a feeding tube, push a button, and sometimes food comes out. Eventually, the rat develops a pattern where it goes back to the feeding tube, pushes the button, and keeps checking over and over again to see if there is food available. Replace the rat’s food with the smartphone user’s news feed, twitter feed, facebook wall, gaming scores, etc.

Obviously some of these are extremes and the degree to which people are addicted to and conditioned by their mobile devices varies from person to person but here’s the scary part: Even if you are not one of the people I’ve described above, then you either know someone who is or you’ve seen someone who is recently.

My point here isn’t get on a high horse and complain about the state of modern technology. No, my point is that awareness of this phenomenon can make you a better application developer. If you’re aware of the patterns of Intermittent Reinforcement and you know how, over time, this can lead to “dopamine squirts” as people use mobile devices, you can design your application in such a way that it fits into this pattern and even takes advantage of it.

If you’re making a game, remember the rat. Give your users a little nugget of food every time they launch the application. Reward them and build the sense of Intermittent Reinforcement. Give them reason to come back to your game over and over again, day after day, to check and see if there is anything new worth doing, new rewards available, new progress to be made, etc. Your users aren’t rats, but like it or not, smartphone users are just as easily conditioned as rats (myself included, so please don’t think I’m being condescending here).

Even if you’re building a stuffy, boring business application, you can still take advantage of Intermittent Reinforcement and give your users dopamine squirts. Give the user a reason to come back to the app, to “check in” and see what’s new and what’s going on. When they do launch your app, give them something satisfying as a reward for having launched the application, something that will make them want to come back for more, no matter how boring the subject matter might be. One man’s insomnia cure is another man’s fetish.

I’ve said this before but it’s worth saying again – the usage patterns for mobile devices are not the same as the ones for apps in a browser, apps run from a laptop, apps used from a desktop, or even apps or games on a game console. Being aware of these patterns, especially how they affect the behavior of their users, will lead to building better applications that better suit the lifestyles of your users.

Zombie Apocalypse Trainer Now Available

As some of you may know, up until very recently I’ve been working on a book called Windows Phone 7 for iPhone Developers. This book is all about learning how to build Windows Phone 7 applications, even if you’ve never written any code for Windows or for the iPhone before. Despite the iPhone name in the title, the book is just as useful for any new mobile application developer, regardless of background. Comparisons to the iPhone are made just to make some of the concepts in the book easier to grasp for new developers.

Anyway, the last chapter in that book deals with deploying applications to the Windows Phone Marketplace. In order to get screenshots for that chapter and to be able to accurately describe the application submission process, I had to create an application and submit it to the Marketplace.

That application is called Apocalypse Trainer. It’s a simple calorie counter and weight log application, with a twist. Instead of just calling itself a calorie counter, it disguises the act of counting calories with preparing for the zombie apocalypse. Every time you eat 100 calories, a zombie gets close to attacking you. Every time you burn 100 calories, you outrun a zombie. Finally, it keeps track of the number of consecutive days you’ve been under your calorie budget and refers to this as the number of days since the last mauling.

Here’s a screenshot of the application as it looks in the Zune Marketplace:

Apocalypse Trainer

Apocalypse Trainer in the Zune Marketplace

Make no mistake, this is not an application that I intend to make a million dollars from. In fact, I sincerely doubt anyone will actually purchase this application. I deliberately set the application at $2.99 to avoid using up any of my “free app” quota and because I know the application lacks the fit and finish of a commercial application. If, by some random freak chance, people actually start buying and using this application, I’ve engaged the services of an actual designer (I may be a great programmer, but I’m a horrible designer). I figure if 20 people buy the application, I will have enough money to pay him to do the layout and artwork for version 1.5. I’ve seen some preliminary designs and am really happy.

Anyway, I will also be doing a series of blog posts recounting my experiences while writing this application. This is for the benefit of readers of my book (publish date is I believe February or March 2011) and for the readers of this blog who are interested in Windows Phone 7 and the overall experience of deploying an application to the Marketplace.

WP7: Presenting ListBox Items inside a WrapPanel

This morning I was trying to figure out how to display a list of items that ran horizontally across the screen. At first I tried a StackPanel but that didn’t work the way I wanted. After a few minutes of searching I remembered that the WP7 Control Toolkit from Codeplex includes a WrapPanel control. This control does exactly what it says – it lays out the child elements and then wraps them when an element might otherwise be clipped by the edge of the screen or the edge of the parent container.

So then I tried to figure out how I could get this WrapPanel to display items from a data-bound list. This is when I remembered that I wasn’t really thinking in Xaml. I don’t want to bind the child elements of the WrapPanel, what I want to do instead is tell a ListBox that it should use the WrapPanel as a content presenter instead of the default panel that it uses.

The Xaml for this was remarkably simple:

<ListBox x:Name="myList">
<toolkit:WrapPanel ItemHeight="150" ItemWidth="150"/>
<Image Source="103-Person.png" Height="48" Width="48"
HorizontalAlignment="Center" VerticalAlignment="Center"/>
<TextBlock Text="{Binding Name}" Style="{StaticResource PhoneTextSubtleStyle}"
Width="100" TextAlignment="Center"/>

When you supply this listbox with some data (in my case,  just Person objects with a Name property), it might look something like the screen below. I numbered them when setting the people’s names so you could see how the WrapPanel is laying items out horizontally and then wrapping them down to the next level.

A WrapPanel-based ListBox

A WrapPanel-based ListBox

Changing your ListBox so that it uses a WrapPanel to present items is a simple trick, but it can come in really handy and save you a lot of trouble if you want this wrapped layout style.