Home / Archive by category "Mobile"

Facebook, iPads, and the dangers of ASP.NET browser detection

ASP.NET webforms automatically tries to detect the capabilities of the user’s web browser to render appropriate HTML and javascript to the client. It does so by parsing the user-agent string and doing a series of regular expression matches to try and identify the browser in its local database of browser capabilities.

Yes, user-agents and regular expressions, just like it’s 1999.

Obviously, this can go horribly wrong.

Recently we had an issue in production where users on iPads were being presented with a truly wretched user experience. Javascript was completely disabled, layout was skewed, design elements were misplaced…. We finally tracked the issue down to an issue with the browser definition files on an older web server, and the unique user-agent string that gets sent when a user browses from within the Facebook iPad application. If you’re on an iPad using Safari, your user agent string will typically look something like this:

Mozilla/5.0 (iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10

In an older (ASP.NET version 4.0) version of the browser definition files, this won’t be recognized as an iPad, because iPads didn’t exist yet. But the “Safari” and “Version/###” in the user agent string will be picked up by the safari.browser file, and you’ll at least get javascript enabled.

However, if you’re browsing from within the Facebook app your user agent string will be:

Mozilla/5.0 (iPad; CPU OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Mobile/10A523 [FBAN/FBIOS;FBAV/5.3;FBBV/89182;FBDV/iPad2,5;FBMD/iPad;FBSN/iPhone OS;FBSV/6.0.1;FBSS/1; FBCR/;FBID/tablet;FBLC/en_US]

Notice no “Safari” within the user agent string. In our case ASP.NET couldn’t recognize the browser at all, so it downgraded the experience to no javascript and downgraded table layout.

This issue can be fixed with custom definitions in your App_Browsers folder, or by installing .NET 4.5 with the updated browser definition files on your server.

Or better yet, ditch webforms entirely and use simple layout with progressive enhancement. Even patching the servers, this ancient method of parsing user agent strings is not a good long term strategy.

 

Creating Bit.ly shortened URL’s from Windows Phone 7 in C#

You’re no doubt familiar with URL shorteners on sites such as twitter, where they are practically mandatory. For example, my previous post,  How to Create Screenshots for Windows Phone 7 Marketplace without a Phone, weighs in at a hefty 109 characters. And that’s without any tracking codes that may be mandatory for marketing or affiliate programs. But with the use of any URL shortener (Bit.ly in this case), we’re down to a mere 20 characters (http://bit.ly/rc72Ac).

URL shorteners have other advantages as well. If you’re working with affiliate programs typically the only way you get paid is by placing your affiliate code in the URL itself. Affiliate directories will also typically add some tracking variables to the URLs, and you’re left with a long ugly URL that’s downright unseemly to include in an email, share on a facebook wall, or anywhere else you cannot control the link text being presented. And there is alos the cance people will use the URL and just omit your affiliate code, for whatever reason. URL shorteners can help prevent this.

In addition, most provide some excellent tracking and analytics  – often in real time and for free. You can view number of clicks,  referrers, county of origin, even get a QR code if you wish.

Any decent URL shortener will come with an API, and many of these services have C# libraries for interfacing with them directly. I chose  bit.ly for this example, but most services have a very similar API.

Signing up for an account is straigtforward, and once you do so you’ll automatically have an API key on your “Settings” page. There is already a codeplex project for a bitly library, but unfortunately it does not work for Windows Phone 7. Most other examples found online use synchronous calls which is not permitted in WP7 programming (for good reason), so we’ll start from scratch.

To make any API call, you’ll need to supply your username, and your API key. Simply log in to your account and go to http://bitly.com/a/your_api_key. Bitly offers a standard REST based API, the full documentation can be found by following the “API” link at the bottom of their page. Documentation for the method we’ll be looking at to shorten a URL can currently be found here:

/v3/shorten

For a long URL, /v3/shorten encodes a URL and returns a short one.

Parameters

  • format (optional) indicates the requested response format. supported formats: json (default), xml, txt.
  • longUrl is a long URL to be shortened (example: http://betaworks.com/).
  • domain (optional) refers to a preferred domain; either bit.ly, j.mp, or bitly.com, for users who do NOT have a custom short domain set up with bitly. This affects the output value of url. The default for this parameter is the short domain selected by each user in his/her bitly account settings. Passing a specific domain via this parameter will override the default settings for users who do NOT have a custom short domain set up with bitly. For users who have implemented a custom short domain, bitly will always return short links according to the user’s account-level preference.
 Two important points: the URL must be URL encoded. No spaces, question marks, or any other odd characters. Also, the format parameter can specify either text , XML, or JSON. Text is the simplest to work with – only the shortened URL is returned. If you’re only working with one link to shorten at a time, this is an obvious choice. However,  if you’ll be sending multiple requests to bitly at one time, or you can’t guarantee the return order of your requests, you’ll want to use XML or JSON. Both of these return both the shortened URL and the original, so you can match them if necessary.
For this example, we’ll just use text, since in my app we’ll never be submitting multiple requests per page. To shorten the URL in bitly, all you need is open a web request to the URL specified by the API:
  1.  
  2. string url = string.Format(@"http://api.bit.ly/v3/shorten?login={0}
  3. &apiKey={1}&longUrl={2}&format=txt",
  4. BITLY_LOGIN, BITLY_API_KEY, HttpUtility.UrlEncode(longUrl));
  5.  
  6. WebClient wc = new WebClient();
  7. wc.OpenReadCompleted += new OpenReadCompletedEventHandler(wc_OpenReadCompleted);
  8. wc.OpenReadAsync(new Uri(url));
  9.  

Since we specified the text format, the result will contain the URL only:

  1.  
  2. void wc_OpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
  3. {
  4. Stream stream = e.Result;
  5. var reader = new StreamReader(stream);
  6. var shortenedUrl = reader.ReadToEnd();
  7. }
  8.  

I’ve wrapped the above methods in a class that you can find on github. To use, simple call the Shorten method with a callback, like so:

  1.  
  2. new WP7NetHelpers.BitlyShorten().Shorten(
  3. HttpUtility.UrlDecode(ProductFeed.Instance.URL),
  4. this.ShortenCallback);
  5.  
  1.  
  2. private void ShortenCallback(string url)
  3. {
  4. // do something with url;
  5. }
  6.  

Enjoy!

A Quick Tour of Amazon’s Mobile App Developer Program

OK, my mobile app isn’t quite ready yet, but this post from the people at AWS caught my attention. One of the main difficulties in developing Android applications is that there’s not one app store (not even one draconian one), but several different app stores available. Amazon hopes to fill that void by developing its own app store for any Android device, and while only time will tell if it is successful, given Amazon’s track record of quality and market reach any mobile developer needs a foothold here. If you sign up now, it’s free for the first year:

If you are using the SDK to build an Android application, I would like to encourage you to join our new Appstore Developer Program and to submit your application for review. Once your application has been approved and listed, you’ll be able to sell it on Amazon.com before too long (according to the Appstore FAQ, we expect to launch later this year). If you join the program now we’ll waive the $99 annual fee for your first year in the program.

You can list both free and paid applications, and you’ll be paid 70% of the sale price or 20% of the list price, whichever is greater. You will be paid each month as long as you have a balance due of at least $10 for US developers and $100 for international developers. The Amazon Developer Portal will provide you with a number of sales and earnings reports.

The store will provide rich merchandising capabilities. Each product page will be able to display multiple images and videos along with a detailed product description.

Joining the program is simple. If you already have an Amazon.com custome or affiliate account (and who doesn’t), you can simply use that account:

After this, it’s about 4-5 confirmations until you’re signed up. Is this you name? Agree to terms of service? Agree to pay us the $99 after your first year? If you charge for apps, what’s your bank account info?

By the way… only a $10 minimum payout is very cool…

After that you’re in!

Of course, the rest of the site is incomplete. They do have samples of the submit an app page, reports, and account pages that are interesting. It looks like you’ll have considerable control over your application’s launch cycle- including pre-orders and limited release windows. The reports look basic but adequate for most developers. I do hope they open up an API that lets you get more information on the who/what/where of downloads… but it’s a welcome and much needed addition to the android marketplace.