Member Sign In
Search for...
Keywords
- AT&T API Platform FAQs
- AT&T API Platform SDK
- AT&T Application Resource Optimizer (ARO) FAQs
- AT&T Developer Program Website FAQs
- AT&T Foundry FAQs
- AT&T U-verse® Enabled FAQs
- AT&T U-verse® Enabled FAQs for iOS
- Content Policy FAQs
- Data Connectivity and APN FAQs
- Device Capabilities (Beta) FAQs
- EDGE FAQs
- GPRS FAQs
- IP Multimedia Subsystem (IMS) FAQs
- Java FAQs
- Laptop Connect FAQs
- Legacy Location Based Services (LBS) FAQs
- Legacy Short Message Peer-to-Peer Protocol (SMPP) FAQs
-
Legacy Short Message Service (SMS) FAQs
- Location API FAQs
- Messaging API FAQs
- mHealth Platform FAQs
- Most Popular
- Notary Management API FAQs
- OAuth 2.0 FAQs
- Payment API FAQs
- SMS API FAQs
- UMTS FAQs
- WAP Push API FAQ
- Wholesale Application Community (WAC)
- Java FAQs
- Expand All Collapse All
For phones, we currently support WAP/WML and xHTML for over-the-air provisioning. Markup compatibility is dependent upon the browser in the device and varies by device and manufacturer.
With the exception of certain premium content on AppCenter, AT&T does not develop, co-brand, private-label, or host Java applications. Developers are expected to provide their own hosting solution and are responsible for provisioning.
All AT&T Java-enabled wireless devices follow Sun Microsystems' MIDP 2.0 guidelines for over-the-air provisioning.
Yes, all of AT&T's wireless devices support reception of calls and messages while applications are running. Typically, if a call is received while a MIDlet is executing, the device will invoke the MIDlet's pauseApp() method and switch to the voice interface. Some devices also support using the platform request method to invoke calls from within a Java session. The only limitation to receiving calls and e-mail while a Java application is running is when the application is invoking streaming methods such as Sockets or RTSP. In most cases, these methods take precedence over network notifications and must be kept in mind when developing these types of applications.
For Official MEdia Net and MEdia Mall Content Providers, the Java Implementation Guide
describes the standards for provisioning pages, as well as some best practices for your MIDlet.
For example, we request that MIDlets be optimized for specific devices. We also recommend
having a splash screen, help screen, and instruction screen. Any application timers which limit
interactivity should be limited to 3 seconds, to avoid the appearance that the device is
"locked up."
Enterprise Certified Solution Partners are required to submit solutions to the Enterprise Solution Certification
program. There are specific certification criteria for Java ME applications that target phones
and BlackBerry handhelds.
AT&T does not provide synch cables or software to load MIDlets from the PC to devices
because AT&T's wireless network is designed for over-the-air provisioning. Some
manufacturer Web sites may offer synch cables for the devices they make.
Java ME applications can be downloaded to BlackBerry devices through the synchronization
cradles that are sold with the devices.
Yes, we provide many options to access devices remotely in Emulators. Many device manufacturers also offer emulators on their developer sites. For BlackBerry handhelds, emulators are included with the BlackBerry JDE.
Direct Bill integration is required to process customer payments for premium content. The DirectBill platform is available only to Official MEdia Net and AppCenter Content Providers.
Both ATT.net and AppCenter are promoted and marketed through online, print, and television advertisements. The advertising plan for these portals is based on seasonality, target markets, and company wide promotions.
All Java applications on AT&T's wireless network must be signed in order to ensure that only authorized Java applications can gain access to specific secure data, applications, and other network and device resources.
AT&T does not distribute this information.
It depends on whether the user has purchased an application as part of a subscription or as a single transaction. If it's part of a subscription, then the user should be able to go back and download the application again without having to make a new purchase. In order to encourage users to try a number of different applications, we configure direct buy links so that users can re-download an application for free for a period of 60 days.
Yes, this is required. We expect you to stand behind your application in terms of its features and functions. Content Providers need to provide their customers with contact information in the form of a URL, e-mail address, or phone number that is easily accessible from within the application.
Yes.
Content Providers are generally paid 60 days after the transaction has been processed.
To ensure the best end-user experience possible, AT&T requires that Content Providers provide high-quality applications that are specifically tested on the devices on which they will be deployed. We've developed testing programs specifically for this purpose. AT&T provides information about Certification, Signing and Testing.
Absolutely. Check out Messaging Aggregators.
The majority of AT&T's wireless devices support MIDP 2.0 with CLDC 1.1 support. Proprietary APIs vary by manufacturer. Most manufacturers have developer programs which offer SDKs and other tools for each of their devices. AT&T doesn't provide libraries for extending MIDP 2.0.
All Java ME MIDlets reside in persistent storage on the device and execute locally. Your MIDlet may also use the local Record Store on the device for storing items such as high scores, user settings, expiration information, and so on.
