Java Reference
In-Depth Information
available on the devices you're targeting, and performing regular surveys of the market.
I find it best to keep track of what APIs I plan to use as I design and implement my
application, and correlate them against the JSRs that define those APIs. Then, when it's
time to bring my application to market on a different device, I can check to see which
packages are offered by the new hardware and scope my porting effort accordingly.
Sites like the Wireless Universal Resource File (WURFL) device description repository
at
http://wurfl.sourceforge.net
and the support database for J2ME Polish (a library
originally targeted at Java ME's predecessor, J2ME, that simplifies cross-device devel-
opment) at
http://devices.j2mepolish.org/
are invaluable in planning your product
launch or porting efforts. A little research as you design your application can pay big
dividends when rolling it out to consumers.
Marketing and Selling Your Application
There are a myriad of channels for Java ME applications today, each with their own set
of business challenges. Many readers see wireless operators as the logical channel for
application distribution, given the popularity of the MIDP today. Still others target web
distribution to hardware directly or bundle applications with hardware at manufactur-
ing time. A small percentage of you may be working directly with platform or hardware
manufacturers, and so your channel to the consumer (and the notion of a consumer
itself!) is quite different.
You can distribute your application to consumers in a number of ways. Certainly
direct distribution is a possibility, by publishing a link to your application (see Chapter 3
for how to package your application for the different configurations). This may sound
simple, but it poses an obvious business question: How will you get paid for your applica-
tion? Free distribution, advertising, and per-download or subscriptions via credit card or
PayPal fulfillment are all possibilities.
Because of the need for privilege by most applications and revenue by most
developers, a typical deployment for a mobile application involves both third-party
certification and business negotiations. The process of third-party certification typi-
cally involves a business program such as Java Verified, which tests your application,
and assuming it passes testing, cryptographically signs your application for distribu-
tion. Usually accompanying this signed endorsement is access to additional privileges;
for example, most MIDP implementations won't permit HTTP transactions without
prior user approval unless a member of the Java Verified testing authority has signed
the application. Once signed, you can distribute your application through aggregators,
who broker the carrier relationship on behalf of you and many other developers, reim-
bursing you for sales (typically via a premium-SMS push or direct billing). Another
distribution path is to negotiate with one or more wireless operators to distribute your
application. This involves crafting the business relationship—how much will con-
sumers pay for your application, and how will it be obtained?—as well as additional
testing, which usually results in a second cryptographic signature for your application.
