Much to my pleasent surprise, I now have some basic ASP.NET AJAX (Atlas) pages working on Windows Mobile without modifying any of the Atlas client-side scripts.
Over the weekend, I was thinking more and more about the concept of modifying the Atlas client-side scripts. Although I was willing to do it, I felt it was worthwhile to look at a couple of more things before I took that leap. Thankfully I did.
You’ll recall that I mentioned last week that the Atlas scripts just don’t seem to work with Windows Mobile. I then went on to dig into the details of the scripts and confirmed that there was code in there that just would not work with Windows Mobile. Well it turns out that my observation was correct but needs to be qualified…
The accurate statement is that the Debug version of the Atlas scripts contains code that just won’t work on Windows Mobile.
If you’ve ever looked at the release version of the scripts you know they are very hard to work with. There is a minimum of whitespace and virtually no carriage-returns. Also all of the variables are named a, b, c, d… This is all done, of course, to minimize the size of the script files. The debug scripts, on the other hand, are written normally with carriage-returns, indentation, proper variable names, etc.
All of my testing was done with the debug scripts (Visual Studio default) and all of my research was done with the readable debug scripts.
Well get this, the release version of the scripts have somewhat different functionality from the debug versions; most notably, the release scripts remove a number of error checks. These checks include many of the checks that are used when connecting events to the DOM. In release mode, the steps in this process still fail as they do in the debug scripts but the release scripts ignore the errors. This ultimately allows the pieces of the client-script code that do work with Windows Mobile to run and setup some basic events.
These differences allow the MEDC demo I mentioned last week to work as long as your project is in release mode or you explicitly set the script manager to use the release scripts.
That’s one problem down ... On to the next...
Now when it came to my simple test code, it turns out that just changing to the release scripts does not solve the problem. I owe a huge Thank You to Reed Robinson at Microsoft for resolving this issue. The page I was using for my tests had a button that one clicks to update one Label (but not the other Label). Well because the button by default generates a submit and the Windows Mobile DOM doesn’t have the properties necessary for the Atlas scripts to wire-up everything they need, which include the form object's submit and click events, the page was always doing a full update.
Reed pointed out that if I set the button’s UseSubmitBehavior property to false and provide a server-side click event handler that things work. Once I looked at the generated code this makes perfect sense. When you disable the submit behavior, the client side script handles the button’s client-side onClick event (instead of form events) to initiate the server call. IE Mobile supports this event just fine so things work.
Note: (added about 90 miutes after original post) I've experimented further and it appears that the server-side click event handler is not necessary. It appears that setting UseSubmitBehavior to false is all that's necessary.
So I’m happy to report that we can use Atlas with Windows Mobile – we’ll just need to compile a complete list of do's and don't's. I really wish it would’ve occurred to me much sooner to switch out of Visual Studio's default setting of debug. In hindsight (usually 20/20 J), it should’ve been part of my experiments. I can’t thank Reed Robinson enough for his help in getting the button event behavior worked out.
With these breakthroughs, I should be able to start putting together some samples real soon.
Posted
Sep 24 2007, 11:53 AM
by
jim-wilson