Monthly Archives: May 2010

ASMX ScriptService mistake – Invalid JSON primitive

One group of searches that consistently brings traffic here is variations on the error: Invalid JSON primitive. Unfortunately, the post that Google sends that traffic to doesn’t address the issue until somewhere within its 150+ comments.

Today, the topic gets its own post.

If you’ve worked with ASMX ScriptServices or Page Methods without ASP.NET AJAX’s client-side proxy (e.g. using jQuery or pure XMLHttpRequest code), you’ve may have seen this cryptic error yourself. Or, perhaps you’ve just arrived here due to seeing it for the first time.

Either way, you may be surprised to learn that the most common reason for this error is that you’ve lied to ASP.NET during your AJAX request.

It all begins with the Content-Type

HTTP’s Content-Type header is a fundamental aspect of communication between browsers and servers, yet often remains hidden from us in day-to-day development. The Content-Type header allows an HTTP connection to describe the format of its contents, using Internet media types (also known as MIME types). A few common ones that you’ve probably seen before are text/html, image/png, and the more topical application/json.

Without the flexible negotiation process content types provide, your users’ browsers and your version of IIS would have to both be “ASMX Compatible” and “JSON Compatible” in order for ScriptServices to function. What a nightmare that would be! The IE6 difficulties we face today would pale in comparison.

Further, Content-Type negotiation is part of what allows a single URL, such as WebService.asmx, to represent data in more than one format (e.g. XML and JSON in ASMX’s case).

The benefits of Content-Type negotiation are well worth a bit of occasional hassle.

Okay, but why does that matter?

When your browser sends a POST request, the W3C’s recommendation is that it should default to using a Content-Type of application/x-www-form-urlencoded. The HTML 4.01 spec describes that serialization scheme:

This is the default content type. Forms submitted with this content type must be encoded as follows:

  1. [Omitted for brevity; not relevant to this post.]
  2. The control names/values are listed in the order they appear in the document. The name is separated from the value by ‘=’ and name/value pairs are separated from each other by ‘&’.

For an example of what that means, consider this simple form:

<form method="post">   <label>First Name</label>   <input id="FirstName" value="Dave" name="FirstName" />     <label>Last Name</label>   <input id="LastName" value="Ward" name="LastName" /> </form>

When the preceding form is submitted with URL encoded serialization, the request’s POST data will look like this:

Firebug screenshot showing the URLEncoded POST data

That standardized serialization format allows a server-side backend like ASP.NET to decipher a form submission’s contents and give you access to each key/value pair. Regardless of what sort of browser submits a form to the server, the Content-Type facilitates a predictable conversion from POST data to server-side collection.

In other words, the Content-Type corresponds to a serialization scheme.

What does that have to do with JSON Primitives?

Understanding Content-Type negotiation and how it relates to serialization is important due to its role in coaxing JSON out of ASMX ScriptServices. Specifically, the fact that you must set a Content-Type of application/json on the request means you’re instructing ASP.NET to interpret your input parameters as JSON serialized data.

However, the W3C’s mandate of URL encoding by default means that most AJAX libraries default to that serialization scheme. Similarly, AJAX tutorials targeting endpoints other than ASMX ScriptServices (including even ASP.NET MVC examples) will describe sending URL encoded data to the server.

In other words, when you’re working with a client-side object like this:

var Person = { FirstName: 'Dave',                 LastName:  'Ward' }

The default serialization scheme makes it easy to inadvertently transmit that data to the server as a URL encoded string:


Again, remember that a Content-Type of application/json is a requirement when working with ASMX ScriptServices. By setting that Content-Type on the request, you’ve committed to sending JSON serialized parameters, and a URL encoded string is far from valid JSON.

In fact, it’s invalid JSON (primitive?), hence the cryptic error message.

Instead of the URL encoded string above, you must be sure to send a JSON string:


Whether you’re using XMLHttpRequest directly or a JavaScript library that abstracts the details, getting your request’s serialization wrong is the root of the invalid JSON primitive error. However, a more specific issue tends to be the leading cause of this happening.

When good JavaScript libraries go bad

The most common source of this error stems from a subtlety of using jQuery’s $.ajax() method to call ASMX ScriptServices. Cobbling together snippets of code from the documentation, platform agnostic tutorials, and even posts here on my site, it’s easy to end up with something like this:

// WRONG! $.ajax({   type: 'POST',   contentType: 'application/json',   dataType: 'json',   url: 'WebService.asmx/Hello',   data: { FirstName: "Dave", LastName: "Ward" } });

Notice the JavaScript object literal being supplied to $.ajax()’s data parameter. That appears vaguely correct, but will result in the invalid JSON primitive error.

Why? jQuery serializes $.ajax()’s data parameter using the URL encoded scheme, regardless of what Content-Type is specified. Even though the contentType parameter clearly specifies JSON serialization, this URL encoded string is what jQuery will send to the server:


That obviously isn’t valid JSON!

The solution is as simple as two single-quotes:

// RIGHT $.ajax({   type: 'POST',   contentType: 'application/json',   dataType: 'json',   url: 'WebService.asmx/Hello',   data: '{ FirstName: "Dave", LastName: "Ward" }' });

Did you spot the difference?

Instead of a JavaScript object literal, the data parameter is a JSON string now. The difference is subtle, but helpful to understand. Since it’s a string, jQuery won’t attempt to perform any further transformation, and the JSON string will be unimpeded as it is passed to the ASMX ScriptService.

It doesn’t have to be this way

The problem is trivial once you’re aware of the underlying issue, but there’s not a great reason I can see why things need to be this way in the first place. Either half of this equation could easily provide a remedy.

jQuery – I believe the most correct solution would be $.ajax() attempting to honor the serialization scheme indicated by its contentType parameter. In the case of application/json fixing this could be easy as testing for JSON.stringify and using it if available, to avoid adding any complexity/size to jQuery core.

That would leave it our responsibility to reference a copy of json2.js in older browsers, but that convention wouldn’t be much of a burden. We generally do that anyway when the client-side objects get complex.

Microsoft – It’s absolutely correct that the framework throws an error when you lie to it about what you’re sending. However, a bit of leniency could potentially save thousands of hours spent troubleshooting this problem (if my search traffic is any indication of its prevalence).

Is there any reason that the ScriptHandlerFactory can’t intelligently differentiate between between JSON and URL encoded inputs? If the first non-whitespace character of the request isn’t an opening curly brace, why not attempt to deserialize it as URL encoded before throwing an invalid JSON primitive error?


Originally posted at Encosia. If you’re reading this elsewhere, come on over and see the original.

ASMX ScriptService mistake – Invalid JSON primitive

Accessorizer 2.0 is out!

acc_saw_clock_icon_512_version14.pngAccessorizer by Kevin Callahan is one my absolute favorite utilities, as I’ve mentioned before. Well, now, there’s a new reason to love it. Kevin just released 2.0 over the weekend. And there’s great news for those of you who have bought previous versions: it’s a free upgrade.

If you do any serious amount of Objective-C programming, Accessorizer should definitely be in your toolbox.

©2008-2010 Jeff LaMarche.

Weblog Tools Collection: Cleaning Up A WordPress Database After Plugins and Themes Are Uninstalled

I have been thinking about this post for a while.  It really started to come to me after I went through a server move of my own website which I discussed on this site last month – Moving Your WordPress Site and Database.

I did a lot of manual cleaning of my database to get rid of orphaned tables that had been in the database since the day I first set up a WordPress based website.

The majority of these defunct tables were from either themes or plugins that I had used at different points in the life of  As you all know you try out a lot of stuff on your site – mine had 3 years worth of it in there!

Of course I had uninstalled the theme or plugin but a majority of these do not remove the information they leave in your database. 

Now I am not a developer and I have never claimed to be one nor will I.  However, I do believe this is a situation that can be resolved.

You see there are quite a few plugins and themes in the WordPress repository that already have this feature built in and I have used a few.

For example – the WP-DBManager plugin by Lester Chan does this.


This is the uninstall page for the WP-DBManager and as you can see it will remove database information if you opt to uninstall the plugin.  If your just deactivating it or lets say upgrading it then the options in the database will remain intact.

If this can be done then why not across the board. Why not make this a standard for inclusion in the WordPress Extend site?  If your plugin or theme deposits information into a users database then provide an uninstall option to remove that data/tables.

What do you all think about this? Would really like to hear your thoughts of whether I missing something on this being doable?

iPhone Dev Sessions: Responsive Web-Enabled iPhone Apps

Back in August 2009, Shufflegazine featured an article talking about what makes a good iPhone app. The article has a good discussion about what apps are popular and why, and ultimately concludes that a good app has to be simple, intuitive, responsive, and give users a compelling reason to use it.

Unfortunately, there’s no recipe for how to write a simple, intuitive and compelling app. Our best bet for getting our hands on that recipe is probably this guy, but until he makes that announcement, handling these points is left as an exercise for the reader.

Writing a responsive app, however, is much easier.

A good working definition for a “responsive” app is one that responds to user input quickly and doesn’t hang without telling the user what’s going on. The rule of thumb here is that GUIs should respond to input in no more than 1 second, so the bar is set pretty high, especially for web-enabled apps. This article describes the most common reason GUIs get unresponsive and what to do about it.

How Do These Newfangled GUIs Work, Again?

Cocoa Touch’s GUI (like most GUIs) is built on an “event + event loop” architecture. User interactions like taps and keypresses are translated to events, and these events are then processed one-by-one in the imaginatively named event loop:

GUI Event Workflow

Simplified Event Flow in a Cocoa App

As long as each event gets processed quickly, the GUI stays nice and zippy. But because events are processed serially, one event can back up the whole gravy train. If one event takes five second to process, then the GUI will be completely unresponsive for those five seconds until the event loop can start processing new events again.

But what if you have some GUI resources that take five seconds to load? We can’t load them all at app initialization time because we don’t always know what resources we’ll need when the app is starting up, especially for things like profile pictures. Also, the iPhone is an embedded platform, so memory for preloading is in short supply, anyway. How, then, can we appease the event loop tiki gods? The answer, young grasshopper, is to load such resources asynchronously, and then update the GUI when they’re done loading.

Responsiveness Test Bench

To illustrate these ideas, I’ve made a simple iPhone app that loads an image resource for display in an iPhone app GUI three different ways.

The Responsiveness Tester. The people responsible for the appearance of this iPhone app have been sacked.

Each method loads and displays the same image, but does the loading differently to demonstrate the effect each approach has on GUI responsiveness. The source code for this app is attached to this article if you’d like to play along at home.

When the user chooses a loading technique by tapping its table row, a corresponding method is called to illustrate that loading technique. These methods are called directly from the UITableViewDelegate tableView:didSelectRowAtIndexPath: method, which runs in the event loop, so all this code runs directly in the GUI thread.

First, let’s have a look at the code from the load-from-file example:

 - (void)showSynchFileDemoWithTitle:(NSString *)title {     UIImage *image;     image = [UIImage imageNamed:@"apple-logo.png"];     EagerViewController *view=[[EagerViewController alloc]         initWithNibName:@"EagerViewController" bundle:nil title:title image:image];     [self.navigationController pushViewController:view animated:YES];     [view release]; } 

The code looks like it sounds, right? We load the image from disk, use it to create a new UIViewController, push that UIViewController onto our UINavigationController, and then release the UIViewController back into the wild. This is exactly why synchronous loading is so popular: it’s ridiculously simple. And since we’re just loading a small image from a file, the GUI is still zippy, so synchronous loading is actually fine here.

Now let’s look at loading that same image from a synchronous web request instead of a file:

 - (void)showSynchWebDemoWithTitle:(NSString *)title {     UIImage *image;      NSURLRequest  *request=[NSURLRequest requestWithURL:[NSURL         URLWithString:IMAGEURL]];     NSURLResponse *response=nil;     NSError *error=nil;     NSData *content=[NSURLConnection sendSynchronousRequest:request         returningResponse:&response error:&error];     if(content == nil)         image = [UIImage imageNamed:@"big-red-x.png"];     else         image = [UIImage imageWithData:content];      EagerViewController *view=[[EagerViewController alloc]         initWithNibName:@"EagerViewController" bundle:nil title:title image:image];     [self.navigationController pushViewController:view animated:YES];     [view release]; } 

The code is slightly more complicated, but still not too bad. We set up a web request for the image, wait for it to download, build an image with the contents of that request if it succeeded or load a default image if it failed, and then build our UIViewController from that image. Still nice and easy, but how does it perform?

The problem with synchronous web loading. Hang much?

Turns out, not so well. After the user taps “Synchronous from Web,” the app just kind of sits there for a few seconds before it shows the next view. Why? The synchronous web request loading the image in the event loop takes a while to complete, which blocks the event loop and hangs the GUI. This kind of code is surprisingly common despite the hangs it causes. Unless you’re willing to tick off your customers, which is usually considered harmful, synchronous web loading in the event loop is right out.

So what’s the asynchronous web loading equivalent look like? Behold, ye mortals, and despair…

From RootViewController.m:

 - (void)showAsynchWebDemoWithTitle:(NSString *)title {     LazyViewController *view=[[LazyViewController alloc]         initWithNibNamed:@"LazyViewController" bundle:nil title:title         imageURL:[NSURL URLWithString:IMAGEURL]];     [self.navigationController pushViewController:view animated:YES];     [view release]; } 

From LazyViewController.m:

 - (id)initWithNibNamed:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil title:(NSString *)title imageURL:(NSURL *)imageURL {     if(self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]) {         self.navigationItem.title = title;         if(imageURL != nil) {             self.getlogo = [AtomicAsynchronousWebRequest requestWithURL:imageURL                 andDelegate:self];         }     }     return self; }  - (void)updateLogoWithImage:(UIImage *)image {     [self.logo stopLoadingWithActiveView:[[[UIImageView alloc] initWithImage:image]         autorelease]]; }  - (void) atomicAsynchronousWebRequest:(AtomicAsynchronousWebRequest *)request didFailWithError:(NSError *)error {     if(request == self.getlogo) {         [self updateLogoWithImage:[UIImage imageNamed:@"big-red-x.png"]];         self.getlogo = nil;     }     else {         // We have no idea which request this is. Just log it and move on.         NSLog(@"Failed unrecognized HTTP request: %@", request);     } }  - (void)atomicAsynchronousWebRequest:(AtomicAsynchronousWebRequest *)request didSucceedWithResponse:(NSURLResponse *)response andContent:(NSData *)content {     if(request == self.getlogo) {         [self updateLogoWithImage:[UIImage imageWithData:content]];         self.getlogo = nil;     }     else {         // We have no idea which request this is. Just log it and move on.         NSLog(@"Succeeded unrecognized HTTP request: %@", request);     } } 

Oh… that’s all? Well, I guess that’s not so bad. We pass the URL for our image to the UIViewController initializer, and the UIViewController then starts an asynchronous web request for the image and updates the logo view with an image when the web request either succeeds or fails. (Observant readers will notice some custom methods above. Hang tight, we’ll talk about those in a minute.) What does all this trouble buy us?

Nice and Zippy. Asynchronous Loading FTW!

A wonderfully responsive app, that’s what. The transition from the first view to the second view is instantaneous; the second view shows its spinner until the web request completes or fails, and then the logo is updated with a new image. Why is this UI so snappy? Because all long-running operations are performed outside the message loop, so nothing hangs the GUI thread. Lazy loading for slow resources is clearly the way to go.

And if you think about it, this approach is good not only because it runs faster, but also because it’s more modular. The UIViewController being created knows what it’s displaying; it should probably be loading its resources too, especially if that loading is complex, in case that UIViewController needs to be reused elsewhere in the app.

So… sweet. A twofer.

Being Lazy About Being Lazy

If asynchronous loading is what we need to be doing — and it is – then how can we make it easy? It turns out that asynchronous loading is easier in Objective-C than it is in many other languages.

In Java, for example, asynchronous loading requires you to mess with callbacks and Threads, SwingWorkers, or ExecutorServices, which feels like jumping through a bunch of flaming hoops while wearing a newspaper tutu. In Objective-C, though, web requests are baked into the API and already have asynchronous callback functionality, which means that asynchronous loading can be had essentially for free, especially if we do a little customization of our own.

The app uses two custom classes. I’ll discuss them here just in case the classes themselves or what they do is useful to other developers. Both classes are in the attached source if you want to put your eyes on them, or use them for your own nefarious purpose.


The iPhone SDK’s generalized web request API is NSURLConnection, and you can find a good primer on how to use it here. The NSURLConnection exposes way more features than most apps need, though, like hooks for reacting to redirects and chunked input, which makes it more difficult to use than it needs to be. AtomicAsynchronousWebRequest is a thin wrapper around NSURLConnection that lets developers perform the most common web tasks (namely atomic GETs and POSTs) asynchronously by implementing a dead-simple 2-method protocol.


While the iPhone has a nice “spinner” GUI element (UIActivityIndicatorView) that’s handy for telling the user something is loading, it has no explicit API for populating GUI views lazily. DelayedLoadView is essentially a “container” view that shows a spinner until it’s updated with its “real” content view, which makes handling activity indicators and lazy content really easy, especially for GUIs built-in Interface Builder.


A couple gotchas have been glossed over in the interest of keeping things at least a little brief. Now that we’re past the good stuff, I’ll mention a few of them here, just in case you want to get creative on your own:

  1. All GUI updates must happen on the GUI thread. Cocoa Touch GUI elements, like GUI elements in most toolkits, are not thread-safe. So, if you need to interact with a GUI element, you need to do it from the main thread. If you’re not making your own threads, you probably don’t need to worry about this. If you are, you may need to make use of NSObject’s performSelectorOnMainThread:withObject:waitUntilDone: or similar.
  2. Remember that UIViewController IBOutlets are not initialized after super’s initializer completes. Instead, the UIViewController must be set to appear before IBOutlets are properly connected. This means that failure conditions can’t really be handled inside a UIViewController initializer, so any custom load code you write needs to take that into account. If you want an example of how to work around this issue, check how AtomicAsynchronousWebRequest calls its failure method from its initializer roundabouts using a performSelector call.
  3. UIActivityIndicatorViews are kind of confusing. You probably want to set hidesWhenStopped to YES. That way, startAnimating and stopAnimating will do what you expect them to. If you don’t see a spinner and you expect to, make sure your UIActivityIndicatorView isn’t hidden. If you see a spinner but it’s not spinning, you need to call startAnimating.
  4. Not all long-running operations have asynchronous callbacks baked in. Web requests do, which is very handy, but if you need to do some other kind of loading you’ll have to get creative. If you’re only going to load things now and then, using performSelectorInBackground:withObject: is probably just fine. If you’re going to be doing a lot of loading, though, you won’t want to create a new background thread each time you load something, so you’ll probably want to create a custom NSRunLoop and kick off your loading with performSelector:onThread:withObject:waitUntilDone:. You can synch up the GUI when loading’s done with a simple performSelectorOnMainThread:withObject:waitUntilDone:.


You’re now an expert on how to build responsive network-enabled GUIs! Or at least you know more than you did.

It’s worth mentioning that even though the article focused on loading images, the very same principles can be applied to executing web service calls, loading web pages, or any other task that requires time to complete.

I now expect all apps to have responsive GUIs, even if they’re loading resources from the web. You’ve been warned. I’ve got my eye on you, iPhone developers.

Stay QWERTY, my friends.

Alcatel-Lucent NextGen Communications Spotlight — Learn More »

Examine Daily Routines to Boost Your Mood [Personal Development]

Humans are creatures of habit and we adopt bad habits just as easily as good ones. If you’re looking for a quick, cheap, and easily applied method of improving your mood you can do so through reflection on your daily routines. More »

HomeFamilyHealthMental HealthUnited States

Take a People-Free Photo in a Crowded Place [Photography]

You’re at a popular location and you really would love a photo of the place without all the people in the way. Looks like you’re out of luck and you should just buy a postcard, right? Not with this clever trick. More »

PhotographyBusinessArts and EntertainmentPhotographersCommercial-Advertising

Weblog Tools Collection: 5 free, ultralightweight WordPress themes that pack punch

These WordPress themes may be tiny, but they pack a big visual punch. These themes are great for sites with audiences with limited access to broadband, or any blog that wants to focus on speed and clean design.


Baughxie – a polished but very lightweight two column theme.


Mini – Minimal and elegant three column theme.

Simple Green

Simple Green – Very professional and very fast.


R755 – Simple yet sophisticated. Can be either two or three columns.


Swift – This is actually more of a theme framework than a theme. It has a theme options page with layout, font, and color options. Nicely done.

Hohm Computes Energy Costs and Savings for Your Specific Home [Saving Money]

Microsoft’s energy-conscious Hohm project used to require significant data input on your part to figure out costs and savings when we last looked. Now the webapp uses property records, geo-data, and other information to quickly suggest energy savings for your abode. More »


Treat Your Own Neck

Treat Your Own Neck saved my neck! The book is very thin but packed with the info you need to treat your neck pain. The author clearly explains the physiology of the neck, and describes specific exercises to treat specific types of neck pain/injury. The exercises are simple, but not intuitive.

About a year ago I got a bulged disc in my neck. This had never happened before, and I had no idea what was going on. I had very limited movement and what movement I had was very painful. At first, I thought it was just a sore or stiff neck from an awkward bike riding position, or a slight workout injury. As it progressively worsened over the next couple of weeks I started to realize this was more serious. A visit to my MD and a referral to a neurologist confirmed the bulged disc diagnosis. What was their advice for me? Basically a shrug, and they said, “Sometimes it goes away, sometimes you just have to live with it.” They offered me some muscle relaxants. I couldn’t believe that was all modern medicine had to offer.

I was a little panicked, to be honest. I wasn’t really interested in being partially disabled. I remembered a couple of friends who’d experienced debilitating back problems. They both solved their own issues using some exercises out of book. I figured maybe there was something in there for me, too. Turns out the author, Robin McKenzie, wrote a book for backs, AND a book for necks!

Personally, I’d never have figured this out on my own. By following the exercises in the book my neck pain was reduced the first day, and eliminated within two weeks. For my particular symptoms, the book provided just one specific exercise, and suggested some postural changes while sitting and sleeping. Though my bulged disc is gone, I continue to use this exercise whenever I have a stiff or sore neck (bad posture at work, or long drives), and continue to find immediate relief.

The book is the price of an insurance co-payment and, for me at least, worth many times what I paid.

— Brendon Connelly

Treat Your Own Neck
Robin McKenzie
2006, 46 pages

Available from Amazon

Published by Orthopedic Physical Therapy Products

[Note: Robin McKenzie has also written a well regarded manual for back pain called Treat Your Own Back that can be found here. — OH]

Fix the Web’s Biggest Annoyances with Google Chrome [Chrome]

The internet is undoubtedly a wonderful place, but let’s face it: some web sites are only too happy to serve up annoying ads, unnecessarily heavy Flash elements, and all-around user-unfriendly experiences. Here’s how to make your browsing experience as annoyance-free as possible. More »

WP Like Button Plugin by Free WordPress Templates