Q: What is the difference between WML and HDML and which language should I use to develop my application? A: Refer to the technical note: Choosing a Markup Language.
Q: How do I branch my application for HTML, WML, and HDML browsers? A: Before returning the appropriate content type, you should first determine whether or not the client is a standard Web browser or a phone. If it is a phone, you can then determine if it is running Mobile Browser v3.0 or earlier, in which case only HDML is supported. Here is an example (in Perl) that demonstrates how to evaluate and branch on the HTTP ACCEPT header:
Note that more sophisticated apps may choose to branch and customize content based on the browser vendor and/or version number, Mobile Access Gateway version number, or physical device capabilities. This information is also available in the USER_AGENT and X_UP_DEVCAP* headers. For example code, please refer to the SDK example application:
/examples/scripts/whoami.cgi
Q: How do I uniquely identify the end-user so I can store persistent user data on my server? A: The Mobile Access Gateway Server always sends the end-user's subscriber ID in each HTTP request to your Web server. The data (along with some other environment variables) is stored in the HTTP request header. You can capture the subscriber ID and then save it in your database to uniquely index any persistent data associated with that user. For an example (in Perl) of how to capture the subscriber ID, please refer to the following SDK example application:
/examples/scripts/whoami.cgi
Using the subscriber ID is also explained in Chapter 3 of the SDK Developer's Guide included with the SDK.
Q: Why am I getting "Access Control Error" when I try to access my site from a real phone? It works fine with the Simulator. A: This problem is common with newly developed HDML applications. By default, the access control path for an HDML deck is limited to the current domain, in other words the deck is "private". When you access your deck from the Simulator, the request comes from the same domain as the location of your deck (usually your local machine). When you use a real phone, the domain of the card that linked to your deck could be some other domain. To make your deck public, you need to either speicfy PUBLIC=TRUE or MARKABLE=TRUE in the HDML declaration:
In WML, all decks are public by default, but can be set to private on a per-deck basis using the "access" tag. For more information about deck access control, please refer to Chapter 6 of the SDK Developer's Guide.
Q: Why can't I override the "options" soft key (SOFT1) when an input field is displayed? A: The "options" soft key (aka "SOFT1" for HDML) is reserved by the Mobile Browser when an input field is displayed. The browser takes control of this action so that it can present the "text entry mode" function. Users can toggle the current text entry mode by pressing the "options" key on the phone, and the display label changes to indicate the current mode.
If you need to present multiple functions when an input field is displayed, the recommended approach is to group all of the functions in a separate menu card, where each function is defined by a separate item in the menu. Provide a link to the menu card as follows:
WML < do type="accept" label="Menu">
< go href="#menucard"/>
< /do>
HDML < ACTION TYPE="ACCEPT" LABEL="Menu"
TASK="GO" DEST="#menucard">
Q: How do I provide context-sensitive help for my application? A: The Mobile Browser supports the HELP user action. In some cases, the HELP action maps to a physical key on the device. In other cases, the user must select the HELP function from the built-in Mobile Browser menu to invoke the HELP action.
Here is an example of programming the HELP action to display a context-sensitive help card:WML
< do type="help">
< go href="#helpcard"/> < /do>
HDML < ACTION TYPE="HELP" TASK="GO"
DEST="#helpcard">
Q: Can I display bitmap images? A: The Mobile Browser v3.0 and higher supports the display of bitmap images in monochrome (1-bit) BMP format. Mobile Browser 4.0 and higher also supports WBMP format. For simplicity, you can publish your image files in BMP format, and the Mobile Access Gateway Server will automatically convert them to WBMP format if necessary. Images are specified using the IMG element. Please refer to Chapter 4 of the SDK Developer's Guide for more information.
Note that not all phones are capable of displaying bitmap images. In these cases, the Mobile Browser ignores the image content and displays the "ALT" text for the image.
Q: How do I override the Mobile Browser's caching behavior and force a cached deck to be reloaded from the server? A: When the user navigates to a deck that was previously loaded in the cache, the Mobile Browser first checks the deck's time of expiration ("max age" or "TTL"). If the deck has expired, then the browser will reload the deck from the server. Otherwise, it reloads the deck from the cache. The default time of expiration is 30 days. You can set a deck to expire for a specified amount of time (in seconds). You can also set a deck to expire immediately if you want the browser to always reload the deck from the server. This is useful when a deck contains highly volitile information (e.g. stock quotations). For example:
WARNING: Setting a deck's time of expiration to "0" should be used with extreme caution! The negative side-effect of doing this is that the deck will always be re-fetched from the server even if the content has not changed. This can severely degrade the user's perception of your application's performance. Also note that the Mobile Browser will ignore expiration and will always reload a deck from the cache if the user navigates to the deck in the backwards direction (i.e. via the "prev" task). It will also ignore expiration if you goto any card in the current deck. Mobile Browser 4.0 (and higher) allows you to force a deck's expiration to be revalidated when navigated to in the backwards direction, by specifying the "must-revalidate" meta tag.
Q: Why does the Mobile Access Gateway Messenger service return HTTP status code 204 when the notification request succeeded? A: If the Mobile Access Gateway Messenger's response to an Add or Delete Notification request is successful, the Messenger responds with status code 204 ('No Content'); otherwise, a specific error response is constructed. The 'No Content' refers to the fact that no content is returned in the response to the HTTP POST operation.
While status 201 ('Created') might seem more appropriate for Add requests, this is actually not the case, since the Messenger does not return an entity body containing a URL by which the newly-added notification can be referenced (see Section 8.3 of RFC 1945).
Q: How do I make my application play audio files like WAV and MP3? A: You can't. Streaming audio files are currently not supported by WAP. The reason for this is because of the physical constraints of today's wireless networks, which preclude streaming media from being delivered in a practical and efficient manner. This is expected to change with the "next generation" wireless packet data networks.
Q: How do I dial a phone number from my application without requiring the user to enter the number? A: The following examples show how to dial the US number "650-817-1400" in both WML and HDML from within the US. In both cases, the call is dialed when the user presses the "accept" softkey labeled "Call":
WML < do type="accept">
< go href="wtai://wp/mc;6508171400"/>< /do>
HDML < ACTION TYPE="ACCEPT" TASK="CALL"
NUMBER="6508171400">
NOTE: When dialing international numbers, you should include the "+" symbol and escape it with the string "%2B", for example:
< go href="wtai://wp/mc;%2B16508171400">
Q: How do I determine the subscriber's phone number or physical location? A: You can't. For privacy reasons, the Mobile Access Gateway Server / WAP Gateway does not pass the user's phone number or physical location to the application. If you want this information, you must ask the user to enter it manually (e.g. Prompt for a postal code to get the user's location). WAP is working on defining a standard implementation for applications to access this information in a future version of the WAP specification. However, even when this becomes a standard, it is expected that the user will be asked for permission before the WAP browser allows any private data to be passed to an application.
Q: What is WTAI, and how is it implemented? A: WTAI (Wireless Telephony Application Interface) is part of the specification as set out by the WAP Forum (however this is an optional part of the spec). No phone currently fully implements the WTAI library. The Mobile Browser does however implement the make call function of the library to allow the dialling of a number using WML.
Using a "go task with a special url" means that the phone can switch from browser to voice mode and dial a call.
As this is an optional part of the WAP spec not all browsers support it. For example the Phone.com, Eriscsson and Mitsubishi (Trium) browsers all support this WTAI function but the Nokia browser does not. The Nokia browser examines the wml code and provides a "use number" option for anything that it thinks looks like a phone number (the number could of course be a social security number which would limit the usefulness of this browser implementation)
This is an example of the wml code that will dial a voice call:
Where 1234567890 is the phone number.
Q: The http Get method does not transcode non-ASCII characters, how do I resolve this? A: A limitation exists when using the http GET method to encode non-ASCII characters.
Non-ASCII characters which are passed in a URL string using the Get method will not be transcoded correctly. This is due to a limitation with HTTP GET request that it does not contain charset infomation and it is not an Openwave platform problem. Due to the nature of this problem, it is impossible for Openwave to provide a work around for this.
As a resolution, the POST method should be used instead because this method allows you to specify the charset.
Q: What do I need to do to my code to ensure it displays correctly going through the leading WAP Gateways?
A: The WAP Specification has left some room for interpretation with regards to internationalization. This has resulted in some differences in how international content is handled by the leading WAP Gateways and which developers should be aware of.
Openwaves Mobile Access Gateway uses existing web standards and adheres to the internationalization protocols as set out in the HTTP and XML specifications. These dictate that to facilitate internationalization the encoding attribute should be added to the XML declaration of your document with the relevant Charset for the characters it includes.
Eg: < ?xml version="1.0" encoding="ISO-8859-1"?> However the Nokia gateway will also render the international characters even if the encoding attribute and relevant Charset is not present in the XML declaration of a document containing international characters. Therefore to ensure that your application is globally accessible and international characters are displayed correctly though *both* the Nokia and Openwave gateways, the developer must include the encoding attribute and appropriate Charset in the XML declaration.
The code below incorporates the XML declaration with the relevant Charset to display the French characters that are in the code. This approach will correctly display the French characters through both the Openwave Mobile Access Gateway and Nokia gateway.
Q: Multiple DO elements with same name causing complie error when going through certain gateway versions? A:
A: The presence of two DO elements in one card which have the same name will cause a complie error depending on the MAG version you are connecting through.
This will render fine up to MAG 5.0.1 but due to requirements for WAP 1.2 certification will cause the complie error in MAG 5.1 and beyond.
"Two or more do elements with the same name must not be present in a single card or in the template element. (Note: An unspecified name defaults to the value of the type attribute.)"
