The Mobile Internet Toolkit (MIT) has been around for a while and has evolved to become part of the .NET solution architecture. In a nutshell it provides support for Web browser-based devices utilizing HTML, cHTML, WML, and XHML markup languages. Because of this, device support goes well beyond the Windows CE/Mobile device. When you build a solution you are essentially creating an application which will run on many, many devices including cell phones, PDAs, and even desktop units. Some of the hardware platforms which the ASP.NET Mobile Internet Server Controls targets include Alcatel, Ericsson, LG, Mitsubishi, Motorola, NEC, Nokia, Palm V, Palm VIIx, Palm M505, RIM Blackberry, Samsung, Sanyo, Siemens, Sony, and Sprint, as well as Windows Mobile Smartphones and Pocket PCs.
Many of these devices have a screen with four rows of real estate in which to develop a user interface. Keep this in mind when designing your application. Another point to remember is that, due to the Web client-based architecture, in order for your solution to work the wireless network must be there 100% of the time. Be it CDMA, GPRS, or Wi-Fi, if there is no network then there is no application and zero productivity. Browser-based solutions are termed "thin clients". While they offer a wide range of functionality for server-based development and deployment, without a constant connection you are out of luck! So much for 7x24-based application deployment, unless you have redundant networks, multiple servers and coverage meeting the five nines standard (that is, 99.999% availability). This is something to keep in mind when suggesting solutions to customers. Note: a few companies are experimenting with web servers which run right on the device, thus eliminating the need for a constant connection.
Taking the Mobile Controls out for a spin
I decided to kick the tires of the MIT server controls by developing an application similar to one I had seen several years ago which lets the user enter in a state and a city and then returns the current weather forecast. Instead of forcing the user to guess the state and city abbreviations, I provided them with a list of states which the end user could scroll and page through. Once the state is selected they can browse through a list of cities. This gives the user the ability to see what the weather is like in nearby cities in addition to their own city.
The government Web site (http://iwin.nws.noaa.gov) posts constant weather information for all of the fifty United States. The data is in a simple ASCII text format, although they do have a new location-based service in SOAP format. Developing the app in C#, I decided to acquire the location information by creating a WebClient connection and then writing some parsing logic to create a list of cities using a SortedList. As the code below shows, it's easy to build an http streaming client connection using WebClient, Stream and StreamReader classes within dot NET.
Printer-friendly version