What's up with ASP.NET Mobile Controls, IE Mobile, and Silverlight?
The Web Browsing experience has really heated up for mobile devices over the last year or two. I credit unlimited data plans, the proliferation of 3G networks, and mobile browsers becoming more and more capable at rendering “standard” web content. I remember when we started down the path of enabling mobile Web Development with a product called the Mobile Internet Toolkit back in 2002. Remember MIT? It was rebranded a few times and eventually rolled in…and out… of Visual Studio as ASP.NET Mobile Web Controls. So what’s the deal Microsoft? What’s up with web development for Windows Mobile anyway? It’s a fair question, and I’m hearing it a lot these days.
Web Developers, we haven’t forgotten about you. It’s true… we’ve been all over the NETCF “Smart Client” architecture while it seems like the rest of the world was jumping the AJAX train. For many types of applications and for “occasionally” connected devices, the Smart Client architecture is much more empowering. We wanted to create a great platform experience built around .NET that enabled disconnected device scenarios. I will admit though… there are some very compelling reasons to build web apps and there are some devs out there who would rather code in Jscript than C# (I’m trying hard to understand this). The lure of cross platform code and centralized deployment is probably at the top of my list for building a web app. At the bottom of that list, when your network goes down – that app is useless. We could toss around pros and cons all day, but the important point is that mobile web development is, undeniably, a very powerful medium that is not going away anytime soon. So what are we doing about it?
I did a post a few weeks ago called “App Ready for… “, discussing some of the major changes in platform releases on Windows Mobile in general, but let’s talk about our web story…flash back a few years and we’ll move forward from there.
ASP.NET Mobile Web Controls
At the center of the mobile web developer space, there exists the fundamental question: Will the web conform to mobile devices, or will mobile device conform to the web? While no developer wants the extra work of building a mobile web site *in addition* to a standard site, only recently have devices really started to handle the web with grace. While Microsoft sometimes gets a lot of grief for being the last one to the party, we started this one about six years ago….
· The Problem: Thousands of mobile devices with varying levels of support for web content. Some devices could handle full HTML, others cHTML, and still others only supported WML, etc. Eventually the market would converge on common technologies, but until that time…how could we help developers build web content that could be consumed by any mobile device?
· A Solution: We created a set of ASP.NET controls used to build simple web forms. We followed the conventional ASP.NET model, already familiar to developers, and then created a bunch of controls that could dynamically render themselves based on the requesting device capabilities. We built up a library of device profiles (capabilities) and then wrote adapters for all the common markup languages a device might use. In theory, you could have a single, mobile web page that could be consumed by any type of mobile devices. A WAP phone might render a calendar control over a series of simple text pages whereas a HTML browser might display a nice, graphically rendered calendar. We launched this as the Mobile Internet Toolkit (download) and then merged it into Visual Studio as ASP.NET Mobile Controls.
· Reality Check: Managing every device profile out there is a lot of work…even for Microsoft. Most business only need to serve content to a handful of device (not hundreds or thousands), so keeping track of all the profiles is quite a bit of overhead in this solution. Even though you can develop a single page that dynamically renders content to many devices, you still need to test all those permutations to make sure they look the way you intended. That’s a lot of testing. Because Mobile Controls must render on all the profiles, this really limits how complex a web page could be and makes building a rich web UI difficult. In other words, the most complicated thing you do, has to render on the most basic device…and that’s very limiting. Mobile devices and web browsers are evolving very quickly with the ability to consume standard web content and let’s be real-- nobody really wants to write two versions of their web site (unless absolutely necessary). The writing on the wall was that Mobile Controls would bridge the gap until mainstream web support arrived on mobile devices.
At least once a week, I see a post of someone asking what happened to ASP.NET Mobile Web Controls in Visual Studio 2008. Indeed, you will no longer find it installed as part of the environment after VS2005.
If you happen to be one of those huge portals that still needs to deliver content to all kinds of devices, you can still use it. We stopped doing new development some time ago when the new ASP.NET architecture started to expose all the same adapter abilities we were including in the mobile forms. It was a lot of work to maintain the profiles and it made more sense to let customers profile the handful of devices they needed vs. trying to maintain and test a huge list ourselves. The product team released all the code and tools you would need to continue development on your own in this area if you wanted to do it. There are a handful of teams inside Microsoft that have done just that… build on the last release for their own product needs. You can too. For a good summary and links to everything you need, check out:
https://www.asp.net/mobile/road-map/
Although we removed ASP.NET Mobile Web controls in VS2008, but you can add basic support back in yourself (no drag and drop designer). Most mainstream devices now support full (or nearly full HTML) and web content. IMHO, unless you are truly intending to target a large range of mobile device types with all levels of browser capabilities (above and beyond Windows Mobile), it’s easier to just developer straight web pages and include your own conditional logic (as needed) to make them render properly. You don’t need Mobile Controls to do that… you can use standard ASP.NET and HTML.
If you really, really, really want to see this technology back in Visual Studio… speak loudly! Tell us about your needs and use cases. Post your comments here and I’ll make sure the product guys hear about it.
Internet Explorer Mobile
Okay, so here I am telling you that mobile web browsers are quickly evolving to consume standard web content and yet… IE Mobile isn’t exactly desktop IE (yet). IE Mobile has some good stuff in the works. Some of you have seen the updated browsers version on the latest 6.1 device builds that include basic goodies like Zoom and better AJAX/DOM support. One of the challenges we’ve always had is that Windows Mobile runs on a wide array of hardware that varies greatly in capabilities. It’s a lot harder to build a browser that looks great and performs great on every Windows Mobile device in the market than let’s say…ah, a competitor that has one basic hardware model. =) Never less, we accept that challenge… You might have heard a little about a new browsing experience on the way… you can get a little preview by pulling down the new 6.1.4 emulators. What makes this any different? Check out the details here.
Internet Explorer Mobile 6 has the following unique features:
Support for Website META Language (WML)
Non-touch Pointer navigation experience
Adobe Flash Lite 3.1 (optional)
Touch and Gesture support for Windows Mobile Professional
Mobile device optimizations to wrap text to the screen
Improved Standards Support
If you are still working with WM5 and WM6 devices, it’s a good idea to note your IE Mobile browser version (type “about:version” in the URL) and see these past posts. There are some subtle difference in regards to DOM/AJAX support in browser builds on the last few releases of WM5/6. It’s important to understand those if you are doing AJAX work. Yes, you can do it folks… but be prepared to do a little tweaking for mobile browsers.
I do want to make one point clear that confused me at first (maybe it’s just me)…You are going to hear a lot about the new “Internet Explorer Mobile 6” in the coming months. Hmmm… but my WM6 devices report MSIE6 as the browser agent string. Isn’t that the same thing? Short answer…NO. There has been some significant re-work to in the browser code since the release with WM6. You will see some new user agent strings to reflect this (compatible; MSIE 6.0; Window CE; IEMobile 8.12; MSIEMobile 6.0) as opposed to the old agent info.
As always, Widows Mobile also supports a number of third party browsers (e.g. – Opera, Skyfire, etc.) you are welcome to use. You are not locked into IE Mobile (though we hope you love the new release).
Silverlight
It’s been a long time… since the first Silverlight Mobile demo at MIX in 2007. Since then, we’ve been running around showing off “what is to come” to Windows Mobile as Silverlight. Have you noticed that the demos all kind of look like the desktop demos for Silverlight. In fact, some of them are. The idea is to bring a the same great Silverlight experience we deliver on desktops today… to mobile devices. On one hand, I want this to ship like…yesterday. As a developer, and someone who has learned the lessons the hard way… DON’T SHIP A PRODUCT BEFORE IT’S READY. I’m an anxious as you are, but I also want this to be right and I’m glad the product team is doing the right thing here. This has also been a moving target since Silverlight 2 has bounded forward. The Silverlight Mobile team is hard at work to align their efforts with the Silverlight 2 work going on with the desktop. The good news is that if you are on par with Silverlight as a desktop technology, you’re in great shape to take off with Windows Mobile. Keep looking for public announcements. We’ll keep you posted.
In Summary
If you want to develop web pages for both desktop and mobile platforms, consider Silverlight for Mobile (when it becomes available) or normal ASP.NET/HMTL over ASP.NET for Mobile-- unless you know that your device cannot support either of these alternatives. As devices browsers have become more powerful, they are able to process the same native HTML and ASP.NET targeted by the desktop, thus making the overhead of ASP.NET Mobile development less important. ASP.NET Mobile Controls supports a variety mobile devices through specific markup adapters and device profiles made available when development stopped on the product. While ASP.NET Mobile Controls automatically render content to match device capabilities at runtime, there is quite a bit of overhead associated with testing and maintaining all the device profiles out there. Development support for these controls, while included in Visual Studio 2005, is not included in Visual Studio 2008. Run-time support can be added back in, but is likely to be discontinued in future builds of Visual Studio.
Cheers,
Reed