 |
|
   |
|
|
 |
A: Please refer to Appendix B of the SDKTools & APIs Reference for a complete description of errors that can be diplayed via the Mobile Browser with suggestions for solving them. If you are still not able to resolve the problem, use the HTTP Reply Utility to enter the URL for your deck that is causing the error. Email the reply output from the utility and include a detailed description of the error to developer@openwave.com. The Openwave developer support staff will try to help you resolve the problem. Q: How do I remove cached data from the phone or simulator? A: To reset the Mobile Browser and remove all data (decks and variables) from its cache, bring up the Mobile Browser menu and then select the "Reset" function. The mechanism for viewing the Mobile Browser menu is different on each phone. For details, refer to the Mobile Browser Phone Reference. If you are using Simulator v4.0 (or higher), you may clear the cache by selecting Edit->Reset Cache from the UP.Simualtor menu bar. Q: How do I resolve the "key exchange is disabled" error message on my phone or simulator? A: It means the encripted private key for your client has somehow been corrupted, and the Mobile Access Gateway Server is no longer able to perform a key exchange to authenticate your phone or simulator as a registered subscriber. This problem typically happens only when connecting to our Developer Mobile Access Gateway Server (devgate2.uplanet.com) using the Simulator v3.2. The simulator stores the private key in the Windows registry. The registry can sometimes be overwritten or deleted during system initialization or when the SDK is un-installed or re-installed. To resolve this problem, you will need to delete your subscriber account on the Mobile Access Gateway Server and then re-create it via the Mobile Access Gateway Provisioning section of the Openwave developer web site. Q: Why won't the Mobile Browser's alert inbox display more than nine alert messages? A: The Mobile Browser alert inbox card may contain up to nine individual alert entries (URLs). After the ninth entry in the card is occupied, subsequent alerts with new URLs will overwrite the previous alert that occupied the ninth entry. The alert inbox UI was designed to address the following requirements: Simple UI.Any UI complexit that could be confusing to new users was avoided. Most alternative interfaces (e.g. multiple screens, locking models, etc.) were shown to be too complex during initial end-user testing. No data loss.Users who sign-up for too many notification services, or are being spammed by a mallicious service, should not loose any existing alerts in the alert status card. Persistent navigation path. The alert status card is not simply a place to check for pending alerts. It is also a quick way to navigate to notification-enabled applications (e.g. UP.Mail). Users should not have to learn two navigation paths to these applications. This would be especially painful in the case where a user had no new alerts (e.g. no mail), but wanted to read old messages. A simple and consistent path through the alert status card simplifies usability of notification-enabled applications. UI should meet the common case of alert usage. During market research, it was determined that most end users (in excess of 90%) would commonly use less than three notification-enabled applications on a regular basis. Predictable/configurable behavior for expert users. In particular, expert users should be able to decide what application goes in the first item of the alert status card. Users can control this by deleting alerts, which results in the re-ordering of the alert list. Q: Does the Mobile Browser & Mobile Access Gateway Server support user authentication? A: The Mobile Access Gateway Platform supports HTTP basic authentication and SSL certificate authentication. If you try to access a URL that is password-protected by the web server, the Mobile Browser will automatically prompt the user for the name and password. The username and password are then stored in the subscriber session cache by the Mobile Access Gateway Server (typically between 8-24 hours, depending on how the Mobile Access Gateway is configured). To clear the subscriber session cache, you must reset the Mobile Browser (select the "Reset" function from the Mobile Browser menu). The Mobile Access Gateway (v3.1 and higher) supports SSL certificate authentication. The Mobile Access Gateway's SSL certificate can be authenticated by a secure (HTTPS) Web server to verify the Mobile Access Gateway operator (wireless carrier) as an authentic business entity. Please note that if you use the Simulator in HTTP Direct mode, it does not support user authentication or access to secure web servers (over HTTPS). To test secure web sites using the simulator, you must run it in Mobile Access Gateway mode (i.e. connected to an Mobile Access Gateway Server). Q: How long are notifications stored by the Mobile Access Gateway Server before and after they are sent to the subscriber? A: When an application sends a notification request (alert or prefetch) to the Mobile Access Gateway Messenger service, the app specifies the TTL (time to live) for the notification. The TTL defines how long the notification will remain in the pending state in the Mobile Access Gateway database. If the TTL expires before the Mobile Access Gateway can communicate with the subscriber's handheld device, then the notification will not be delivered and will be set to the expired state. The default TTL is 60 days. However, this value is configurable by the Mobile Access Gateway operator (carrier) and may differ on a per-Mobile Access Gateway basis. A notification is considered to be completed as soon as its state is set to delivered, expired, or undeliverable. After a notification is completed, its status record is retained in the Mobile Access Gateway's database (where it can be queried by the operator or the application that sent the notification) for 48 hours, by default. This value is also configurable by the Mobile Access Gateway operator. Q: What are the size limitations for a deck? A: WML and HDML decks are packaged in a MIME wrapper entity referred to as a "digest". App developers can package multiple entites into a digest (e.g. decks, images) to minimize the number of requests to the Web server for related content entities. Digests are transmitted over the wireless network within single packets, the maximum size of which is 1492 bytes (Mobile Access Gateway v3.x) or 2000 bytes (Mobile Access Gateway v4.x). However, 28 bytes of that are reserved for the packet header. We recommend that you keep the size of each digest under 500 bytes, to minimize the download time and increase efficiency for the end-user. Q: How is the HTTP session with my Web server managed? A: Each HTTP (or HTTPS) session between an Mobile Access Gateway subscriber and your HTTP server is maintained and cached by the Mobile Access Gateway Server. An Mobile Access Gateway subscriber's HTTP session cache is persistent across sessions between the phone and the Mobile Access Gateway Server. Therefore, your HTTP server does not have to worry about the phone chagning cells, falling in/out of range, or being powered on/off. In all cases, the HTTP session remains active until either the Mobile Access Gateway or the Web application terminates the session. The Mobile Access Gateway will only terminate the HTTP session either when A) the user resets the Mobile Browser (via the Mobile Browser built-in menu); or B) the HTTP session timeout occurs. The timeout value is configurable by the Mobile Access Gateway network operator (carrier). Most operators configure the session timeout to be between 8-24 hours. Q: How can my application determine the Mobile Browser version? A:
Q: How do I bookmark the current card/deck? A: Some phones have a physical key (usually labeled "MARK") that allows the user to bookmark the current card through a single keypress. On phones that don't have a MARK key, the user must select the "Mark Site" function from the Mobile Browser menu. The mechanism for viewing the Mobile Browser menu is different on each phone. For details, refer to the Mobile Browser Phone Reference. In WML, all decks are public by default, which means they are also bookmarkable by default. If the current deck is written in HDML, then the MARKABLE="TRUE" or PUBLIC="TRUE" tag must be set in order for the card/deck to be bookmarkable. Otherwise, the user will get an "Access control error" message, which indicates that the deck is private (i.e. only accessible from other decks in the same domain). Q: Why do I get an error of type 1022 Invalid Redirect format when I connect through the Mobile Access Gateway? A: Using a Response.Redirect from within Microsoft ASP code can result in a 1022 Invlalid Redirect Format error if you do not specify the complete path to the file you are redirecting to. This error is not seen in HTTP direct mode, only when you are connecting through an Mobile Access Gateway. This behavior conforms with RFC 2068 Section 14.30 Response. Redirect should be called using an absolute URI. Q: Why is my image not shown at the top of the page? The phone just selects the first link automatically! A: Phones with the Mobile Browser versions 4.0 up to version 4.1.16r automatically select the first link on a card regardless of the content above the link. This issue has been resolved in the Mobile Browser version 4.1.16r and higher. The SDK 4.1 exhibits this behavior as well (i.e the first link on a card is automatically selected). Below is a list of phones we have tested.
|