IEMobile Team Weblog

Information about Internet Explorer for Windows Mobile

  • Another AJAX Sample for IE Mobile (plus JSON and ASP.NET AJAX tips)

    A couple of quick pointers for samples and tips on using AJAX and IE Mobile:

    1. The Channel9 Wiki has a sample app using AJAX with IE Mobile put together by the Windows Mobile SDK team.
    2. MelSam's blog has a Powerpoint deck from MEDC 2007 covering building AJAX Applications on IE Mobile.  This also has some tips on using JSON and ASP.NET AJAX with IE Mobile.

    Enjoy!

    -Charles

    Adding a link to Jim Wilson's Blog where he gives some details about his experience with ASP.NET AJAX and IE Mobile.  As it turns out there was an issue with running Debug vs. Release version of the ASP.NET AJAX scripts.  Thanks Jim!

    -Dave

  • IE Mobile support of ActiveX

    I wanted to get a quick note down into our Blog to help clear some confusion.

     

    Yes, IE Mobile does support ActiveX quite extensively.  In fact, the Windows Media Player is an ActiveX control.  Adobe Flash is a good example of a 3rd party ActiveX control. 

     

    There are some platform differences that everyone needs to be aware of.

    ·         You can’t run Windows based ActiveX controls on a Windows Mobile devices.  (X86 and ARM processors are too dissimilar.)

    ·         So the Windows Mobile ActiveX controls need to be compiled for our platform and the ARM processor.

    ·         Windows Mobile IE Mobile does not support automatic download of ActiveX controls.  This was a deliberate decision made to increase device security and to avoid the first point (a X86 version of a control being pushed down to a ARM based device). 

     There are 2 ways an ActiveX control can get on your device.  Both require user interaction.

    1.      Installing it from a synced desktop

    2.      Copying a CAB file to the device and installing it locally 

    Hope this helps!

    Dave

    Test Lead

  • IE Mobile Standards Support

    Hello everyone, my name is Charles Morris and I’m a program manager on the IE Mobile team.  One of the most frequent questions that we get is around which standards are supported by our browser, so we thought it would be helpful to write up a blog post to pull it all together.

    Standards Support Overview
    Here is a high level summary of which levels of various standards are supported by IE Mobile:

    • HTML: 4.01
    • XHTML: Basic, 1.01 (with some exceptions)
    • WAP: 1.2.1, 2.0
    • CSS: Level 1, Level 2 (partial), Mobile Profile 1.0, Wireless (WAP) CSS 1.1
    • Scripting/DOM: JScript 5.6, DOM Level 0, DOM Level  1 (partial), DOM Level 2 (partial)

    There are more details on IE Mobile standards support up on MSDN.

    Although AJAX is not a standard, we are often also asked if we “support AJAX” in this context.  As mentioned in earlier blog posts, IE Mobile does support the XMLHTTP object used to exchange data with the server asynchronously, as well as the DOM/CSS support listed above to update your page dynamically with the new data.

    Reference Documentation
    Of course, high-level summaries don’t do you much good if you are trying to find out if the browser supports a specific tag/object/selector/etc.  Luckily, our hard-working documentation team has also assembled detailed reference material for precise answers to those sorts of questions.

    Unfortunately those references aren’t always easy to find amongst the mass of information up on MSDN.  We hope that things have gotten better with the new content structure for the Windows Mobile 6 Documentation, but just in case here are a few direct links for the most commonly used references:

    Note: To find out what methods/properties you can use for a specific HTML element, see Common Properties for HTML Elements as well as the element’s entry in the HTML Element Reference.

    What’s New in Windows Mobile 6
    Those who have developed web applications for IE Mobile on Windows Mobile 5.0 or earlier versions of the platform may be wondering what specific improvements have been made for the recently released Windows Mobile 6.  So, here is a list of the standards-related improvements that were made for this release:

    HTML Element Support

    • <hr> color support
    • <iframe> support
    • <button> support

    CSS Support

    • -wap-marquee support
    • list-style-image support
    • E > F support
    • E + F support

    Script/DOM Support

    • Feature detection
    • Custom properties
    • element.className
    • element.parentNode
    • element.childNodes
    • element.appendChild()
    • element.id (now writeable)
    • element.insertBefore()
    • element.removeChild()
    • element.replaceChild()
    • document.body
    • document.createElement()
    • document.documentElement
    • document.getElementsByTagName()
    • document.title (now writeable)

    The Future
    The IE Mobile team is committed to continuing improvements to standards support in our browser for future releases.  Unfortunately, I can’t give out any specifics at this time but do watch this space!

    -Charles

  • Requesting Pages in a specific Language using Accept-Language Header support

     

    I will first like to introduce myself since I am posting for the first time on the IEMobile blog. My name is Hiren and I work as a developer in the IEMobile team.  Most of the content in the this entry is targeted towards general Windows Mobile device users with a small section  at the end detailing IEMobile’s support for encoding detection targeted specifically towards web authors.

    The Scenario:

    Often times you want to be able to view web pages in a language different than the OS language for your Smartphone or PocketPC device. For example, a user may want to view pages in Japanese even though the default language for the device he/she is using is English. Web browsers support this scenario using an HTTP header called “Accept-Language” (defined in section 14.4 of HTTP 1.1 Header Field Definitions) which specifies a preferred Language for the web browser to the web server. If the server has the page available in the requested language the user will be able to view the page in that language which may or may not be same as the language for the device. For example, to set the preferred language to Finnish you could set the value of Accept-Language to “fi-FN” where the lowercase “fi” indicates Finnish and the uppercase “FI” indicates the country, Finland.

     That’s great. How do I set the Language?

    IEMobile supports setting the Accept-Language header to a desired language via a registry key. You can set the following registry key to one of the acceptable language tags for the Accept-Language header. 

    HKEY_CURRENT_USER\ Software\ Microsoft\ Internet Explorer\ International\ AcceptLanguage

     RFC 1766 defines the acceptable values for the language tag.  It refers to ISO 639 list for language codes and ISO 3166 list for country codes.  You can actually specify multiple different preferred languages and a quality value indicating the preference level for each of them as well. For details, please refer to the HTTP header documentation (section 14.4 of HTTP 1.1 Header Field Definitions).

    Note:

     If the OS version you have supports this feature it does not matter if this key is not present by default in the registry. You should be able to create the registry key if it already does not exist and this will work.

    Another thing to note is that you only need to enter the language code and not the entire header as the value of the above registry key. For example, “fi-FN” will be a valid value to set for the above registry key.

    Which versions of the OS support this?

    Only devices running Windows Mobile 2003 Second Edition ( including WM 5 ) or later support setting the accept-language header via the registry. This does not work for devices running older versions of the OS (even if you see the above key present in the registry).

    Caveats

    1.       You will need to reboot the device after you change the registry for the changes to take effect.

    2.       You will also need to make sure you have the required font for the desired language installed on your device if you want to display pages in any East Asian languages like Chinese for example.

    Switching between the two supported languages without changing the registry (Only for  Smartphones)

    Smartphone devices actually support two different languages out of the box. You can switch between these two languages by changing the setting in Settings | Regional Settings | Language. For example, most of the English phones also offer German as the other available option in the above setting. The Accept-Language header value sent out by IEMobile respects the language specified in this setting. In other words, if you just want to switch between these two languages while browsing you can just change the above setting and you don’t need to modify the registry as mentioned above. However, if you want to view pages in any other language then you will have to user the registry method specified above.

    Note:

    If the above specified registry key exists then the language specified in the registry key takes precedence over the language specified via the setting in Regional settings.

     

    Specifying the character encoding for pages ( Target Audience: Web Authors )

    A related topic for web authors is how to mark a page with a specific encoding so that the browser understands which encoding the page uses. HTML 4 specification section 5.2.2 mentions different ways of marking the character encoding for a page. IEMobile follows the standard as mentioned in section 5.2.2 for the most part. Specifying the “charset” param on the “Content-Type” header or a META declaration with “http-equiv” set to “Content-Type” works as mentioned in the standard. However, the 3rd method of specifying the encoding on a per element basis by setting the “charset” attribute on the element tag is not supported.

    Detecting the encoding of the page based on the byte order mark (BOM) is only partially supported.  IEMobile supports detection of utf-8 BOM header but utf-16 detection via BOM is not supported. However, utf-16 encoding can be used if the page is explicitly marked as such by the above mentioned supported methods.

    -          Hiren.

  • Update to IE Mobile Adobe Flash support

    We recently found out that the Adobe Flash player 7 for Pocket PC supports a direct call into the player by an activeX object via JavaScript.  This opens up a direct way for websites to verify if IE Mobile browsers have Adobe Flash installed and even its version.  

     

    The activeX object only takes two lines of code.  See example below.

     

    <html>

    <head>

    <title>Flash Alert</title>

    </head>

    <body>

    <script language=javascript>

    axo = new ActiveXObject("ShockwaveFlash.ShockwaveFlash");

    axo.GetVariable("$version");

    alert(axo.GetVariable("$version"));

    </body>

    </html>

  • Why doesn't Adobe Flash always render for IE Mobile?

    Hi this is Dave, the Test Lead for IE Mobile.

     

    Yes, there is an Adobe Flash player for Pocket PC.  The Adobe Flash Player 7 for Pocket PC (sorry Smartphone users) works on a ton of sites but there have been some complaints that it doesn’t work everywhere.  The reason for this discrepancy was not openly clear so the IE Mobile Test team decided to conduct an investigation.

     

    Our investigation quickly revealed some common issues:

    ·         Many sites used a commonly shared JavaScript sniff for Adobe Flash support.  This JavaScript would than write out VBScript to detect Adobe Flash support and appropriately render the ActiveX control object for Flash *or* some alternative non-Adobe Flash content. 

    Ø       Unlike desktop IE, IE Mobile does not support VBScript and it is unlikely that we would add support because it would increase our memory footprint by as much as 400K.

    ·         We also found a few rare cases of the use of the <embed> tag to host variables for Adobe Flash object.

    Ø       <embed> is not is not a part of the HTML 4 or xHTML 1 specifications and as of right now, IE Mobile does not support it.

     

    Adobe’s warnings about using JavaScript:

    http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14526#builtin

    “Ease of use makes script-based detection the method of choice for most people. However, the drawbacks are significant.”

     

    Examples of what not to do:

    Here are some commonly used problematic JavaScript examples pulled from real websites. 

     

    else if (navigator.userAgent && navigator.userAgent.indexOf("MSIE")>=0 
       && (navigator.appVersion.indexOf("Win") != -1)) {
            document.write('<SCR' + 'IPT LANGUAGE=VBScript\> \n'); //FS hide this from IE4.5 Mac by splitting the tag
            document.write('on error resume next \n');
            document.write('FlashCanPlay = ( IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.")))\n');
            document.write('</SCR' + 'IPT\> \n');
    }

    Or

    // Check the browser...we're looking for ie/win
    var isIE = (navigator.appVersion.indexOf("MSIE") != -1) ? true : false; // true if we're on ie
    var isWin = (navigator.appVersion.toLowerCase().indexOf("win") != -1) ? true : false; // true if we're on windows


    // This is a js1.1 code block, so make note that js1.1 is supported.
    jsVersion = 1.1;

    // Write vbscript detection on ie win. IE on Windows doesn't support regular
    // JavaScript plugins array detection.
    if(isIE && isWin){
    document.write('<SCR' + 'IPT LANGUAGE=VBScript\> \n');
    document.write('on error resume next \n');
    document.write('flash2Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.2"))) \n');
    document.write('flash3Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.3"))) \n');
    document.write('flash4Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.4"))) \n');
    document.write('flash5Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.5"))) \n');
    document.write('flash6Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.6"))) \n');
    document.write('flash7Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.7"))) \n');
    document.write('flash8Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.8"))) \n');
    document.write('flash9Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.9"))) \n');
    document.write('<\/SCR' + 'IPT\> \n'); // break up end tag so it doesn't end our script
    }

     

    Or even this:

    else if (navigator.userAgent && navigator.userAgent.indexOf("MSIE")>=0 && (navigator.userAgent.indexOf("Windows 95")>=0 || navigator.userAgent.indexOf("Windows 98")>=0 || navigator.userAgent.indexOf("Windows NT")>=0 )) {

      var tVersionString = "";

      document.write('<SCRIPT LANGUAGE=VBScript\> \n');

      document.write('on error resume next \n');

      document.write('set tSWControl = CreateObject("SWCtl.SWCtl") \n');

      document.write('if IsObject(tSWControl) then \n');

      document.write('tVersionString = tSWControl.ShockwaveVersion("") \n');

      document.write('end if');

      document.write('</SCRIPT\> \n');

     

    The common problem is that the UserAgent sniffs allow IE Mobile to pass through because we have ”MSIE” and “Windows” in our UserAgent.

     

    IEMobile’s UserAgent values:

    http://blogs.msdn.com/iemobile/archive/2006/08/03/Detecting_IE_Mobile.aspx

    • Our old UA: Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320)

     

    • Our new UA: Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 6.7)

     

    Example of the use of <embed> tag.  Please don’t do this.:

    <a href="http://fakesite.com/index.htm">" Title for control</a><br><embed enableJSURL="false" allowScriptAccess="never" allownetworking="internal" enableJavascript="false" allowScriptAccess="never" allownetworking="internal"    enableJavascript="false" src="http://fakesite.com/sample.swf" flashvars="m=1368734076&type=video" type="application/x-shockwave-flash" width="430" height="346"></embed>

     

    How can site owners make sure that Adobe Flash will work on IE Mobile?

     

    Adobe’s Recommendation:

    How to detect the Flash 4 Player without using JavaScript

    http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14086

     

    “This approach to Flash Player detection relies on two key elements; a Flash plug-in "sniffer" that uses the GetURL action which only the Flash 4 Player will respond to, and an HTML page with a META refresh tag. The index page of the site will use a Flash movie to detect for version 4 of the Flash Player and direct those browsers to the Flash 4 content. If the user hits the index page either without the Flash Player or with version 2 or 3 of the player, the META refresh tag will automatically send them to a non-Flash page which will prompt them to download version 4 of the Flash Player. This scheme works without using any JavaScript, making it both simpler and more browser-compatible.”

     

    IE Mobile’s recommendation:

    We are not hopeful enough to think that sites that use JavaScript for Adobe Flash detection are going to switch over to a non-script dependent method just because Adobe Flash doesn’t work on IE Mobile.  We are just not a big enough player.  Our best hope is to ask site owners to slightly modify their existing site code to allow Adobe Flash to display on IE Mobile. 

     

    Our research determined that the easiest way for Adobe Flash to work on IE Mobile is to add an additional “else if” statement, to their existing JavaScript, to specifically sniff out IE Mobile (Look for “CE” and “Win”) and than to allow for the ActiveX Adobe Flash control to render.  The existing desktop browser sniffing logic will continue to work and in just a few lines of code you give support to IE Mobile.

     

    I know what you are thinking.  “What if you’re using IE Mobile on a SmartPhone? There is no Adobe Flash Player 7 support for SmartPhone.” or “What if the PPC device doesn’t have the Adobe Flash player installed?” 

     

    It is clear that our recommendation is not ideal because we risk not displaying the alternative “non-Flash” content that I mentioned at the top of the Blog.  Realistically this situation is no worse than today’s experience because we are not displaying the Adobe Flash or the alternate non-Flash content on these sites already.

     

    We could make the first example from above work by entering in the green “else if” statement below:

     

    else if (navigator.userAgent && navigator.userAgent.indexOf("CE")>=0

       && (navigator.appVersion.indexOf("Win") != -1)) {

                            FlashCanPlay = true;

    }

    else if (navigator.userAgent && navigator.userAgent.indexOf("MSIE")>=0 
       && (navigator.appVersion.indexOf("Win") != -1)) {
            document.write('<SCR' + 'IPT LANGUAGE=VBScript\> \n'); //FS hide this from IE4.5 Mac by splitting the tag
            document.write('on error resume next \n');
            document.write('FlashCanPlay = ( IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.")))\n');
            document.write('</SCR' + 'IPT\> \n');
    }

     

    I hope this helps.

     

    Dave

  • Housekeeping

    Just an FYI to our readers; due to the volume of spam that's actually getting through the filters (still!) I've turned on moderation for the comments.  Don't worry - we're still getting notifications on new comments, and we're still reading them.  They might just take a little longer to show up than you're used to.  We're sincerely sorry about that, but it's better than advertisements for sites of dubious merit polluting the information we're trying to share!

  • Detecting Internet Explorer Mobile's User-Agent on the server

    Changes afoot:

    We recently made a change in the next version of IE Mobile for Windows Mobile, regarding the IE Mobile User-Agent string.  It was a little (ok - a lot!) out of date, and it really didn't suit our needs.  It was a relic of a long ago fragmented product that just didn't reflect the current state of the browser.

    What we discovered as we updated the string was that many sites that thought they were properly detecting IE Mobile really weren't doing it the right way.  Our own MSN sites had a few problems, which they're updating, so that they'll be ready to go when the new crop of devices hits the market.  We've even talked to some very friendly fellows at a big, popular rival search engine company and made sure their seach page will render right when these devices ship.

    In the interests of helping fix the broken sites out there now, and getting people ready for the future, we're releasing our new User-Agent string right here, along with a pointer to some other information.

    Out with the old:

    For Windows Mobile 5.0, our "current" release, the User-Agent header that the browser sends across is one of the following two strings:

    • Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320)
    • Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; Smartphone; 176x220)

    Some of the really broken sites we've seen were looking for the resolution information, and using that to deliver a mobile page.  That's wrong, because that information may be absent on some devices from the User-Agent string (more about that in a minute...)

    Others were using one of many badly written samples out there on the net, finding only, "MSIE 4.01," then kicking the browser out of the site, because they wanted IE 5.5 or IE 6.0 only.

    If you want to detect the current/older IE Mobile browsers, the way to do it is to look for "PPC" or "Smartphone", as well as "Windows CE" in that string.  That's the only sure-fire way to be certain of what you're getting.

    In with the new:

    Moving forward, here's the new IE Mobile User-Agent string:

    • Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile m.n)

    The "m.n" portion is a version number, like "6.7", which can help you page and site authors address feature set.  It also lets us know what to look for when debugging our customer's problems, as each manufacturer often gets a slightly different variant of Windows Mobile with a lot of QFEs for their specific needs.  When this new browser makes it into the "wild" on devices, we'll let you get a list, likely via MSDN, of what we update for each release, so you can decide if you want to take advantage of the new features.

    If you want to detect the new browsers coming out, just look for the string "IEMobile" as part of the User-Agent header.  Since the capabilities of the Pocket PC and Smartphone versions of the browser are identical, and they're built from the identical code base, there's no reason to differentiate them any more. 

    Mixing it up:

    We're also being a little more hard-core about modification to the string.  In the past, OEMs and mobile operators could change this string.  We've locked it down now, although they can still append to it, after the closing parenthesis.  We feel that it's really important that page authors can truthfully and honestly detect IE Mobile, but we still want to allow our OEMs a little room to add additional package information, device strings, or whatever to that header.  We just don't want to delete things that are really important, like that "IEMobile" information!

    Getting the big picture:

    At first glance, it might look like we removed useful stuff from the User-Agent header, but that's not the case.  We've always sent a batch of additional headers along that contain all the good stuff, which you should use if you need more information to render a page properly.  They're designed for this type of work; sniffing the User-Agent isn't.  We've got information available as to screen size, color depth, operating system, CPU type, and even if VoIP is supported.

    The additional headers we send are:

    • UA-pixels: {i.e. 240x320}
    • UA-color: {mono2 | mono4 | color8 | color16 | color24 | color32}
    • UA-OS: {Windows CE (POCKET PC) - Version 3.0}
    • UA-CPU = {i.e. ARM SA1110}
    • UA-Voice = {TRUE | FALSE}

    These headers have been around (other than UA-voice) since at least Windows Mobile 2002, and their purpose is to help you make rendering decisions if you have to do layout adjustments.

    Note that on Smartphones, we may not have the UA-CPU information; it's a privileged API, and we run unprivileged, for security purposes.  The newer release will fix this, as we can at least tell you ARM or X86 builds, even if we can't locate the processor specifics. 

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcepie/html/ceconidentifyingpocketinternetexplorertowebserver.asp has more information about these headers and using them with Internet Information Server.

    In our latest update, UA-pixels, which has the screen size, will also change with portrait or landscape rotation, and, on HiDPI devices, which are capable of changing to high or low resolution, if the user changes the device screen size, the UA-Pixels header will reflect the change, as well. 

    Getting it exactly like you want it:

    There's one more bit of information for page authors, and that's a particular META tag.  If you want, you can build your page with:

    • <meta name="MobileOptimized" content="width">

    Setting it on your page can turn off all of our layout optimizations and do them all server-side or in HTML yourself, if you really want to be particular about how things look.  More information, including a full set of parameters for the content field, is available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/wce51conLayoutMetaTag.asp

    That tag, in particular, tells us to skip our fit-to-screen rendering decisions, and just view the page in the equivalent of "Desktop" view mode.  It's really useful if you try to build pages or sites that are targeted towards mobile end users.

    -Cameron

     

  • Adjusting the maximum size of the IE Mobile cache

    Speaking of the cache, the maximum amount of storage used for the cache is controlled by a registry setting. The default value may be different on every device. The cache may temporarily grow beyond this limit, but the device will periodically remove files from the cache to bring the total amount of space used back within the specified maximum.

    If you want to adjust this limit, modify this registry setting:  “HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Content”. This is a dword value that represents the maximum cache size in KB. Any value less than 0x200 is ignored, and a larger value will be used in that case. So don’t enter a value less than that because you won’t get the results you expect.

    You can adjust the amount of storage used for the history and for cookies in a similar way: by adjusting the registry setting here: “HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\History” and here: “HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Cookies”.

    Be careful editing the registry: this stuff is for advanced users and is not supported. This info is valid up to and including Windows Mobile 5, but may change in a future release.

    -Steve Meredith

  • Location of the IE Mobile cache

    Every so often, I see a report that IE Mobile is not caching web pages on the device. Upon investigation, it turns out that the reporter notices the empty directory “\Windows\Temporary Internet Files” and assumes that is the location of the cache. It is not: the cache is located, by default, at “\Windows\Profiles\guest\Temporary Internet Files”.

    You can change this location, as well as the location of history and cookies, by editing the value of the registry keys found here: “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders”. There is one key for each of cookies, cache, and history, and each value is a string representation of a path.

  • From XML Data Islands to XMLHTTP

    This is Steve Meredith again. Last time, I wrote about XML Data Island support in IE Mobile. The <xml> element is an IE-only extension. Most web authors prefer Ajax these days. This time, I want to change the sample page we developed last time to use XMLHTTP instead of the <xml> element. If you haven’t already, please go read the Data Islands article first.

     

    As a reminder, we are creating a web page that lets you select a food from two dropdown lists. The first list contains a category of food: fruit, vegetables, or nuts. The second list contains foods appropriate to the currently selected category. So if “fruit” is selected, the second list contains kinds of fruit. If “vegetables” is selected, the second list contains kinds of vegetables. We don’t want the browser to request a new page from the server each time the category is changed.

     

    Below is the HTML that used the <xml> element. Again, I have left out the bodies of the two script functions.

     

    <html>

    <head>

    <title>IE Mobile XML Data Island Example</title>

    </head>

     

    <body onload='loadCategoryList(); loadFoodList()'>

     

    <!-- xml data island: 3 categories for dropdown 1, each with different foods for dropdown 2. -->

    <xml id='myFoods'>

      <categories>

        <category name='Fruit'>

          <food>Apples</food>

          <food>Bananas</food>

          <food>Strawberries</food>

        </category>

        <category name='Vegetables'>

          <food>Peas</food>

          <food>Carrots</food>

          <food>Corn</food>

        </category>

        <category name='Nuts'>

          <food>Almonds</food>

          <food>Walnuts</food>

          <food>Pecans</food>

          <food>Pistachios</food>

        </category>

      </categories>

    </xml>

     

    <script type="text/javascript">

    function loadCategoryList() {}

    function loadFoodList() {}

    </script>

     

    <hr />

    Select from the available foods:

     

    <form id='myForm'>

      <select id='categoryList' onchange='loadFoodList()'></select>

      <select id='foodList'></select>

    </form>

     

    </body>

    </html>

     

    Let’s talk about what it will take to change this to an XMLHTTP sample.

     

    1. First, we remove the <xml> element from the HTML.
    2. We need a function to request the XML from server. Let’s call it requestFoodListFromServer().
    3. We need a function that handles the response from that request. Let’s call it processFoodListResponse().
    4. We need to change what function gets called in the body’s onload handler.
    5. We need a global to hold the XMLHTTP request object.
    6. We need another global to hold and XML DOM object with the results from the server.

     

    Our new HTML page looks like this. We’ll fill in the bodies of the functions later.

     

    <html>

    <head>

    <title>IE Mobile XMLHTTP Example</title>

    </head>

     

    <body onload='requestFoodListFromServer()'> <!-- Step 4 -->

     

    <script type="text/javascript">

     

    var g_request; // XMLHTTP request object     Step 5

    var g_foodXML; // XML document object        Step 6

     

     

    function loadCategoryList() {}

    function loadFoodList() {}

    function requestFoodListFromServer() {}  // Step 2

    function processFoodListResponse() {}     // Step 3

    </script>

     

    Select from the available foods:

     

    <form id='myForm'>

        <select id='categoryList' onchange='loadFoodList()'></select>

        <select id='foodList'></select>

    </form>

     

    </body>

    </html>

    Let’s fill in the body of requestFoodListFromServer() first.

     

    // Make an HTTP request for the food list.

    function requestFoodListFromServer()

    {

     // Cancel any outstanding requests.

     if (g_request)

     {

      g_request.abort();

     }

     

     // Make a new XMLHTTP request object.  

     g_request = new ActiveXObject("Msxml2.XMLHTTP");

       

     if (g_request)

     {

      // Call processResponse() when response is received.

      g_request.onreadystatechange = processFoodListResponse;

           

      // Make an asynchronous request.

      g_request.open("GET", "http://iemobile.members.winisp.net/XMLHTTP/myFoods.xml", true);

     

      // Send it.

      g_request.send();

     }

    }

     

    We create a new XMLHTTP request object. The way to do this in IE Mobile is with ActiveXObject(). “Msxml2.XMLHTTP” is the name to pass to this function. We set up the onreadystatechange handler, which is a function that gets called at various times as the request object is processed. Passing ‘true’ to open() as the 3rd parameter causes this process to be asynchronous.

     

    Let’s move on to processFoodListResponse().

     

    // Called when the http request is finished.

    function processFoodListResponse()

    {

     // Done getting response.

     if (g_request.readystate == 4)

     {

      // Success.

      if (g_request.status == 200)

      {

       // Treat as a plain-text reply.

       g_foodXML = new ActiveXObject("Msxml2.DOMDocument");

       g_foodXML.loadXML(g_request.responseText);

     

       // Load both listboxes.

       loadCategoryList();

       loadFoodList();

      }

      else

      {

       alert("Could not get requested food list from server.");

      }

           

      g_request = null;

     }

    }

     

    There’s not much new here. We create a new XML DOM object instead of using the one on the XMLHTTP request object. We do this because we don’t control the content-type for this particular XML file. Normally, in a web app, we control the server and this won’t be necessary.

     

    We have to make a small change to loadCategoryList(). We remove the reference the XML DOM attached to the myFoods <xml> element and replace it with a reference to our global XML DOM object, g_foodXML. Here’s the modified code:

     

    // Initialize the first dropdown (categories) from the XML.

    function loadCategoryList()

    {

     // Get all the categories.

     categories = g_foodXML.getElementsByTagName('category');

     for (g = 0; g < categories.length; g++)

     {

      // Add the category to the <select> element.

      option = new Option();

      option.text = categories[g].attributes.getNamedItem('name').text;

      option.value = option.text;

      document.all.categoryList.options.add(option);

     }

    }

     

    Finally, we have to make the same change to loadFoodList(): replace the reference to the <xml> element’s XML DOM and replace it with g_foodXML. Here’s the modified code:

     

    // Initialize the second dropdown (foods) from the XML based on

    // selected category.

    function loadFoodList()

    {

     // Find the name of the selected category in the 1st box.

     selectedIndex = document.all.categoryList.options.selectedIndex;

     categoryName = document.all.categoryList.options[selectedIndex].text;

     

     // Search the XML for the selected category.

     categories = g_foodXML.getElementsByTagName('category');

     for (g = 0; g < categories.length; g++)

     {

      // Found the selected category.

      if (categoryName == categories[g].attributes.getNamedItem('name').text)

      {

       // Delete any current option elements.

       document.all.foodList.length = 0;

     

       // Fill the select element with food from this category.

       foods = categories[g].getElementsByTagName('food');

       for (i = 0; i < foods.length; i++)

       {

        option = new Option();

        option.text = foods[i].text;

        option.value = foods[i].text;

        document.all.foodList.options.add(option);

       }

      }

     }   

    }

     

    That was easy. You can see that the XMLHTTP method requires a little more code than the XML Data Island approach. It also gets the XML data in a separate, asynchronous request so the rest of the UI can be display before the listboxes are initialized. This may be important in a mobile browsing scenario, depending on the size of the data set and speed of the network connection.

     

    You can find the complete HTML source for this sample here: http://iemobile.members.winisp.net/XMLHTTP/sample.htm

  • Extending IE Mobile in so many ways...

    Howdy!

    It's definitely time for another entry, and I'd like to get started updating this space a little more regularly with what's going on in our world here at Microsoft on the IE Mobile team.

    I'm Cameron Etezadi, and I've recently taken over as the development lead for all of our mobile and embedded efforts around Internet Explorer.  That's not just IE Mobile, but also our port of the desktop version of IE 6 which is included in Platform Builder, for those of you building Windows CE based devices needing a big-screen browser.  Our focus, however, remains steadfastly behind enhancing IE Mobile on Windows Mobile devices, and, over the next few releases, we'll share with you some of the cool features and functionality that we're doing. 

    Your job, as a reader, will be to lobby your mobile device provider for upgrades so you can get all the cool new features, as well as write apps and pages that take advantage of the enhancements!

    Rest assured that our previous development lead, Randy Ramig, is still on the team.  He wanted to focus more on architecture and code design, and I'm not only proud to have him on my team in that role, I'm excited about some of the great ideas he's got as we move forward.

    For starters, I asked Randy to give a small internal tech talk about browser extensibility to about 30 or 40 internal developers, testers, and program managers who we consider our "partners."  There's all kinds of momentum inside Microsoft for doing cool web things on connected Smartphones and Pocket PCs, and we thought it would be helpful to group many of the possible technologies in one place for easy reference. 

    As part of that talk, he put together a set of Powerpoint decks which are more or less a laundry list of key extensibility areas for the IE Mobile browser.  I've taken one of those decks and extracted some slides to share.  Download the attached deck, and have a look for yourself. 

    Keep in mind that these slides came from an internal presentation, so they're not polished and slick.  Rather, they're more of what we do to communicate a huge volume of information pretty quickly amongst our developers.  

    When it all comes down to it, I probably have just as much difficulty as you do in finding just what interface or technology I need when I'm trying to get a job done.  Randy's done some very helpful work collecting it all up in one place, so I hope you all find this to be useful.

     

  • XML Data Islands in IE Mobile

    I am Steve Meredith, a developer on the IE Mobile team. I want to continue the blog theme of XML support in IE Mobile. In Windows Mobile 5, we support MSXML3. Prior to then, we supported MSXML2.

     

    An XML data island is simply an XML data set embedded in an HTML document. The browser doesn’t directly render the XML data, but the elements can be accessed via script. You can use this technique to create dynamic web pages that don’t have to make requests to the server for data.

     

    To demonstrate data islands, let’s create a web page that lets you select a food from two dropdown lists. The first list contains a category of food: fruit, vegetables, or nuts. The second list contains foods appropriate to the currently selected category. So if “fruit” is selected, the second list contains kinds of fruit. If “vegetables” is selected, the second list contains kinds of vegetables. We don’t want the browser to request a new page from the server each time the category is changed.

     

    Below is the HTML used to generate the page in Figure 1. The script has been removed for clarity. I will explain it later.

     

    <html>

    <head>

    <title>IE Mobile XML Data Island Example</title>

    </head>

     

    <body onload='loadCategoryList(); loadFoodList()'>

     

    <!-- xml data island: 3 categories for dropdown 1, each with different foods for dropdown 2. -->

    <xml id='myFoods'>

        <categories>

            <category name='Fruit'>

                <food>Apples</food>

                <food>Bananas</food>

                <food>Strawberries</food>

            </category>

            <category name='Vegetables'>

                <food>Peas</food>

                <food>Carrots</food>

                <food>Corn</food>

            </category>

            <category name='Nuts'>

                <food>Almonds</food>

                <food>Walnuts</food>

                <food>Pecans</food>

                <food>Pistachios</food>

            </category>

        </categories>

    </xml>

     

    <!-- You could also put the XML into a seperate file and use src.

    <xml id='myFoods' src='myFoods.xml' />

    -->

     

    <script type="text/javascript">

    <!-- function loadCategoryList() -->

    <!-- function loadFoodList() -->

    </script>

     

    <p>

    This sample shows how to use script and an XML data island to change the values of a second drop-down based on the value of the first.

    </p>

    <hr />

    Select from the available foods:

     

    <form id='myForm'>

        <select id='categoryList' onchange='loadFoodList()'></select>

        <select id='foodList'></select>

    </form>

     

    </body>

    </html>

     

    The key to this technique is the <xml> element. You enclose your XML document between <xml> and </xml>, then use an XMLDocument property to access it via script.

     

    The <xml> element supports the src attribute and the id attribute. If it is more appropriate for your application, you can put the XML in a separate file, and load it into the data island using the src attribute, as follows:

     

    <xml id='myFoods' src='myFoods.xml' />

     

    To access the XML data from script, use the XML DOM. You can access it using the XMLDocument property of the <xml> element. For example, since the <xml> element in our example above has the id “myFoods”, you can get the XML DOM like this:

     

    xmlDoc = myFoods.XMLDocument;

     

    Below is the function to load the first list, categories, with the values from the XML. This function is only called once: it is an onload event handler for the <body> element. We start by using XMLDocument to get the XML DOM for our data. Then, we loop through each <category> element and add the name from the “name” attribute to the category list using the Option object.

     

    // Initialize the first dropdown (categories) from the XML.

    function loadCategoryList()

    {

        // Get the XML DOM for the data island.

        xmlDoc = myFoods.XMLDocument;

     

        // Get all the categories.

        categories = xmlDoc.getElementsByTagName('category');

        for (g = 0; g < categories.length; g++)

        {

            // Add the category to the <select> element.

            option = new Option();

            option.text

               = categories[g].attributes.getNamedItem('name').text;

            option.value = option.text;

            document.all.categoryList.options.add(option);

        }

    }

     

    Below is the function to load the second list, the foods. This function is called when the body is loaded and every time a new category is selected. First, we find out what is selected in the categories list. Then, we get the XML DOM and search for that category. Once we find it, we use the foods in that category to load up the foods list, again using the Option object for loading the <select> element.

     

    // Initialize the second dropdown (foods) from the

    // XML based on the value of the first dropdown (categories).

    function loadFoodList()

    {

        // Find the name of the selected category in the 1st box.

        selectedIndex = document.all.categoryList.options.selectedIndex;

        categoryName = document.all.categoryList.options[selectedIndex].text;

     

        // Get the XML DOM for the data island.

        xmlDoc = myFoods.XMLDocument;

     

        // Search the XML for the selected category.

        categories = xmlDoc.getElementsByTagName('category');

        for (g = 0; g < categories.length; g++)

        {

            // Found the selected category.

            if (categoryName

                    == categories[g].attributes.getNamedItem('name').text)

            {

                // Delete any current option elements.

                document.all.foodList.length = 0;

     

                // Fill the select element with food from this category.

                foods = categories[g].getElementsByTagName('food');

                for (i = 0; i < foods.length; i++)

                {

                    option = new Option();

                    option.text = foods[i].text;

                    option.value = foods[i].text;

                    document.all.foodList.options.add(option);

                }

            }

        }   

    }

     

    There are other solutions to this particular dropdown problem, but hopefully this example demonstrates the use of the <xml> element, the XMLDocument property, and how to use the XML DOM to access the XML.

     

    You can access the complete source file here: <http://iemobile.members.winisp.net/DataIsland/sample.htm>.

     

    Steve Meredith

    IE Mobile

     

  • Customizing IE Mobile with User Stylesheets

    IE Mobile has supported installable user stylesheets ever since Windows Mobile 2003.  User stylesheets provide a powerful way for you to customize the web browsing experience—one of the core features of CSS.  For more information on user stylesheets and the “cascade” part of Cascading Style Sheets, see http://www.w3.org/TR/REC-CSS1#the-cascade. (Note that the spec refers to “reader” stylesheets whereas I prefer the term “user”.  For the sake of this article, consider them as synonymous terms).

     

    Let’s use an example to demonstrate how you can use this feature of IE Mobile.  IE Mobile has a Show Images feature, whereby you can turn off the downloading and display of images on the page.  This can speed up page load times and reduce the amount of data you download over your slow (and possibly expensive) cellular connection.  Instead of the image, you see the placeholder image and the text in the image’s ALT attribute, if there is any text.  Like this:

     

    Now I’m going to be honest with you—I’m not crazy about how this looks.  The placeholder image and alt text take up valuable screen real estate without much benefit.  We are reviewing improving this feature for a future release—perhaps we just remove the placeholder image and still display the ALT text.  For now let’s use a user stylesheet to turn off display of images altogether.

     

    We are going to install a stylesheet that has one simple rule:

     

    img { display:none !important }

     

    This turns off the display of img elements altogether, and IE Mobile knows to not download an image if the element’s display property is set to none.  The !important ensures that this rule will trump any author rules that set the display property of images.

     

    Let’s name this file noimages.css and put it in the \windows directory of the device.

     

    The next step is to tell IE Mobile to load this style sheet.  When the browser app starts, it enumerates the following registry key for user style sheets:

     

    HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\Stylesheet

     

    Every subkey under this represents a style sheet to load.  Each subkey must have the following values:

     

    • “Enabled” – a REG_DWORD value indicating if this style sheet should be loaded or not.  Set it to 1 to have your style sheet loaded.
    • “File” = a REG_SZ value containing the path to the style sheet

     

    For our example, the necessary registry entries would look like this:

     

    HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\Stylesheet\NoImages

    Enabled = 1

    File = “\windows\noimages.css”

     

    There is one last requirement if you are doing this for Windows Mobile 5.0.  For security reasons, the SYSTEM attribute must be set on the style sheet file (\windows\noimage.css in this example). This can be done by setting the SYSTEM attribute on the file on your desktop, and then copying the file to the device via trusted install (more on that below). 

     

    If the browser app is already running, you will have to terminate the browser app and re-start it for the new style sheet to take effect.  On PocketPC, Ctrl-Q will end IE Mobile, and on Smartphone you can turn the phone off and then back on.

    The end result looks like this:

     

    That’s it.  A fairly simple process for a powerful tool to affect the way the browser presents pages.  As an example of this power, our One Column view in the browser is implemented almost entirely with a style sheet (we had to add a little extra code to remove spacer images). 

     

    If you come up with a style sheet you’d like to distribute, you’ll probably want to create a CAB file for app install that will place the style sheet (with the SYSTEM attribute set) on the device, and modify the registry as explained above.  You can read more about how to do this at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/guide_ppc/html/ppc_wce51conapplicationinstallationozup.asp

     

    Randy Ramig

    August 8, 2006 Addendum:  Your CSS file must be stored as Unicode.  You can do this by opening it up in notepad and saving it as Unicode.

  • AJAX on IE Mobile

    Hello Everyone,

    My name is Kevin Grey, I'm an SDET on the IE Mobile Team.  I wrote the following document to help inform people about how to write an AJAX enabled webapp for use on Windows Mobile devices (PocketPC and Smartphone).

    ~~K

    Does IE Mobile Support AJAX? … YES

    We've recently been getting questions regarding whether IE Mobile (aka Pocket IE, PIE, IEMO) supports AJAX.  The answer: Yes, PocketPC and Smartphone devices 2003 and later, support AJAX.

    If you are wondering how you can use AJAX on your website and have it function well from your Windows Mobile browser, here are a couple things you should know:

    1. On Smartphone/PocketPC 2003
      • innerText and innerHTML Properties are only supported on div and span elements
      • Form elements are scriptable as well
    2. On Windows Mobile 5
      • innerText and innerHTML Properties are supported on all elements
      • In addition there is support for document.all and the style object

    *Watch the IE Mobile Team blog for further details on our DOM support.*

    An AJAX Example

    For those of you who live anywhere near the poles and have yet to witness a geomagnetic storm, here is your chance.  A Geomagnetic storm is produced when solar wind particles from the sun warp the Earth's magnetosphere producing pretty lights in the night sky (also known as the Aurora Borealis, Northern Lights, etc). 

    The National Oceanographic and Atmospheric Administration operates a series of Magnetographs which record changes in the Magnetosphere as a result of this solar wind.  Every 3 hours, they publish an index value between 0-9, called the K-Index.  This value represents the severity of the disturbance in the Earth's magnetic field.  Since this interaction is the fundamental cause of a geomagnetic storm, the K-Index should inform you of when you are most likely to witness one.

    Our AJAX Example Goal: To write a webpage that will display the current K-Index for a given location so that people can know if there is a geomagnetic storm occurring.

    The NOAA publishes the K-Index for several locations to a flat text file located here: http://www.sec.noaa.gov/ftpdir/latest/AK.txt  The file is updated every 3 hours.

    Since the file is in a fixed format and therefore cannot be parsed by an XML parser, I've taken the liberty of writing a Webservice which fetches the flat file, parses it out and makes the data available as a simple WebReference:

    http://iemobile.members.winisp.net/GeoMagneticData.asmx

    Now that we've XML-ified our Magnetometer data, we can access this data from our webpage or any other application.

    Invoking the Webservice

    In order to invoke the GeoMagneticData.asmx webservice, you need to perform an HTTP POST sending certain headers and a body with an XML SOAP document.  Here is what the raw HTTP message should look like for this specific webservice:

     POST http://iemobile.members.winisp.net/GeoMagneticData.asmx HTTP/1.1
     Accept: */*
     Accept-Language: en-us
     Referer:
    http://iemobile.members.winisp.net/ajax.html
     soapaction: http://tempuri.org/GetMagnetometerStation
     Content-Type: text/xml; charset=utf-8
     Accept-Encoding: gzip, deflate
     User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 1.1.4322)
     Host: iemobile.members.winisp.net
     Content-Length: 469
     Proxy-Connection: Keep-Alive
     Pragma: no-cache
     
     <?xml version="1.0" encoding="utf-8"?>
     <soap:Envelope xmlns:xsi="
    http://www.w3.org/2001/XMLSchema-instance"
     xmlns:xsd="
    http://www.w3.org/2001/XMLSchema"
     xmlns:soap="
    http://schemas.xmlsoap.org/soap/envelope/">
     <soap:Body>
      <GetMagnetometerStation xmlns="
    http://tempuri.org/">
      <email>nobody@nobody.com</email>
      <password>blank</password>
      <station_name>Boulder</station_name>
      </GetMagnetometerStation>
     </soap:Body>
     </soap:Envelope>

    As a response to this message, we will receive:

     HTTP/1.1 200 OK
     Proxy-Connection: Keep-Alive
     Connection: Keep-Alive
     Content-Length: 648
     Date: Tue, 15 Nov 2005 19:25:49 GMT
     Content-Type: text/xml; charset=utf-8
     Server: Microsoft-IIS/6.0
     X-Powered-By: ASP.NET
     MicrosoftOfficeWebServer: 5.0_Pub
     X-AspNet-Version: 1.1.4322
     Cache-Control: private, max-age=0
     
     <?xml version="1.0" encoding="utf-8"?>
     <soap:Envelope xmlns:soap="
    http://schemas.xmlsoap.org/soap/envelope/"
     xmlns:xsi="
    http://www.w3.org/2001/XMLSchema-instance"
     xmlns:xsd="
    http://www.w3.org/2001/XMLSchema">
     <soap:Body>
      <GetMagnetometerStationResponse xmlns="
    http://tempuri.org/">
      <GetMagnetometerStationResult>
       <StationName>Boulder</StationName>
       <Latitude>49</Latitude>
       <Longitude>42</Longitude>
       <CurrentKIndex>1</CurrentKIndex>
       <CurrentAIndex>1</CurrentAIndex>
      </GetMagnetometerStationResult>
      </GetMagnetometerStationResponse>
     </soap:Body>
     </soap:Envelope>

    Now on to the Javascript which will invoke the webservice and parse the response.  I've broken the request and response portions of the webservice call into two separate functions:

     InvokeWebservice()
     ParseResponse()

    The InvokeWebservice() function will perform the HTTP POST.  It then sets a callback function which will asynchronously invoke ParseResponse() when the HTTP response is received:

    function InvokeWebservice(url)
    {
        // Tell the user that we're invoking the webservice
        result.innerHTML = "Requesting Data..."; 
        //Construct an XMLHTTP Object to handle our HTTP Request
        var xmlHttpReq = false;
        try
        {
            xmlHttpReq = new ActiveXObject("Msxml2.XMLHTTP");
        }   
        catch (err)
        {
            try
            {
                xmlHttpReq = new ActiveXObject("Microsoft.XMLHTTP");
            }
            catch (err2)
            {
            }
        }
        // Specify HTTP Method as POST so that we can upload large amounts of text
        xmlHttpReq.open('POST', url, true);
        // Set the content type to text/xml, otherwise the webservice will not
        // consider it a valid XML document

        xmlHttpReq.setRequestHeader('Content-Type', 'text/xml; charset=utf-8');
        // Set the SOAPAction header, otherwise the webservice won't be invoked.
        xmlHttpReq.setRequestHeader('SOAPAction', 'http://tempuri.org/GetMagnetometerStation');
        // Set a callback to be invoked when the ReadyState changes on the XMLHTTP object.
        // If the ReadyState value == 4, then the request is completed.
        // See for more info:
    http://tinyurl.com/858me
        xmlHttpReq.onreadystatechange = function() 
        {
            if (xmlHttpReq.readyState == 4) 
            {
                ParseResponse(xmlHttpReq);
            }
        }
        // Insert the station name within our XML document 
        // and Send the HTTP Request
        // The XML has been snipped for presentation

        xmlHttpReq.send("<?xml version=\"1.0\" … <station_name>" + 
        document.forms['f1'].stationname.value +
        "</station_name></GetMagnetometerStation></soap:Body></soap:Envelope>");
    }

    The ParseResponse() function receives the XMLHTTP object instance and fetches the values for the StationName, Latitude, Longitude and CurrentKIndex.  It then performs some simple logic on the lat/long values and generates a description.  Then it sets the innerHTML property of a div tag with our pretty-printed text:

    function ParseResponse(xmlHttpReq)
    {
        // Fetch the values from our response XML
        var station_name = xmlHttpReq.responseXML.getElementsByTagName('StationName')[0].text;
        var lat = xmlHttpReq.responseXML.getElementsByTagName('Latitude')[0].text;
        var lng     = xmlHttpReq.responseXML.getElementsByTagName('Longitude')[0].text;   
        var kindex = xmlHttpReq.responseXML.getElementsByTagName('CurrentKIndex')[0].text;
        var descr = "";
        // Pretty Print the Latitude and Longitude values
        
    <SNIPPED>View source for this</SNIPPED>
        
    // Generate the description for our data     
        if (kindex < 0)
        {
            descr = "No Data Available for this Location";
            kindex = "Unknown";
        }
        if (kindex < 4)   
        {
            descr = "Low or No Geomagnetic Activity";
        }
        else if (kindex < 7)
        {
            descr = "Moderate Geomagnetic Activity";   
        }
        else if (kindex < 9)
        {
            descr = "High Geomagnetic Activity -- Auroras Visible in Mid Latitudes";
        }
        else if (kindex <= 10)   
        {
            descr = "Extreme Geomagnetic Activity -- Auroras Visible in Mid and Lower Latitudes";
        }
        // Set the text data as the innerHTML propery of a div tag identified as 'result'
        result.innerHTML = "Station: " + station_name + "<br>\n";
        result.innerHTML += "Location (geomagnetic dipole): " + lat + " " + lng + "<br>\n";
        result.innerHTML += "K-Index: " + kindex + "<br>\n";
        result.innerHTML += descr + "<br>\n";
    }

    With these two functions defined, we can now create some simple HTML to allow us to query for the current K-Index for a given location:

    <p>Station: 
        <SELECT NAME="stationname">
            <OPTION VALUE="Planetary Index">Overall Planetary Index</OPTION>
            <OPTION VALUE="Boulder">Boulder, CO</OPTION>
            <OPTION VALUE="Chambon-la-foret">Chambon-la-foret, France</OPTION>
            <OPTION VALUE="College">College, AK</OPTION>
            <OPTION VALUE="Fredericksburg">Fredericksburg, VA</OPTION>
            <OPTION VALUE="Kergulen Island">Kergulen Island</OPTION>
            <OPTION VALUE="Learmonth">Learmonth</OPTION>
            <OPTION VALUE="Wingst">Wingst</OPTION>
        </SELECT> 
        <input value="Get Index" type="button" onclick='InvokeWebservice("
    http://iemobile.members.winisp.net/GeoMagneticData.asmx");'>
    </p>
    <div id="result"/>

    For a working demo of this page, please visit http://iemobile.members.winisp.net/ajax.html
    Here are some screenshots of the page in action, as seen from a Smartphone 2003 device emulator:

     

             
More Posts Next page »

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker