(keitai-l) Re: KDDI, BREW and CP

Hi William,

You have a couple of options.

1) Set up a WAP site and distribute the URL however you can. Set the MIME
types up correctly on your webserver and you should be able to start
provisioning the app that way. Disadvantages of this method are that the
consumer has to enter your URL manually into their phone's WAP browser,
which is clunky. Also, you are reliant to some extent on the network
operator having configured their customers' WAP gateway in such a way as not
to fuck up a J2ME download - some restrict filesizes and other such fun.
Likewise you may find some operators restrict access to IP addresses that
have not been pre-approved/are outside their walled garden.

2) Get set up with an SMS aggregator (we use mBlox, who have just entered
the US market via an acquisition: www.mblox.com) who will allow you to
deliver the URL to consumers' phones via WAP Push. This is a nicer process
from an end user perspective, as you can then link up to the aggregators'
API to let people send the app to their phone by typing their number into a
webpage, or texting in, or whatever.

My company has a fair amount of experience with this process - feel free to
drop me a line if you like.

David

-----Original Message-----
From: keitai-l-bounce@appelsiini.net [mailto:keitai-l-bounce@appelsiini.net]
On Behalf Of William Wood
Sent: 16 July 2003 20:20
To: keitai-l@appelsiini.net
Subject: (keitai-l) Re: KDDI, BREW and CP



This is a very fundamental question, and I'm also new to this space, so
forgive me also...

If an application developer wants to test, and deliver, J2ME applications
OTA directly to consumers in the US independent of carrier how is this done?
We have several applications we are applications we are interested in
distributing free off charge here in the US but are having trouble figuring
out how to get started.

In Japan developers are free to make their apps available to the general
public as "unofficial" content providers. Can this be done in the U.S. also?

Any input would be appreciated.



-----Original Message-----
From: keitai-l-bounce@appelsiini.net
[mailto:keitai-l-bounce@appelsiini.net]On Behalf Of Bill Volk
Sent: Monday, July 07, 2003 1:21 PM
To: keitai-l@appelsiini.net
Subject: (keitai-l) Re: KDDI, BREW and CP



Allen is pretty much correct.

I'll add the following:

1. To deploy a BREW app on the phone, you will need a different compiler
than the one delivered in the SDK, and that compiler will run about $1500.
As with J2ME the emulator is really a simulator ... running on the emulator
is no proof of functionality on the phone.

2. There are different BREW versions out there (1.0, 1.1, 2.0) and there
does seem to be some incompatibility between them ... even with code that
doesn't use the new features.

3. I suspect that the BREW/Verizon networking code is more stable than the
J2ME stuff we are seeing.  Right now I'm seeing a "show stopper" (HTTP
networking) on the Nokia 3650/AT&T phone.

4. The architecture of BREW is 'interesting' ... it looks like this started
as C++ and then a decision was made to center development around 'C'.  So
you wind up using a bunch of macros to call methods in the kernel.  It's not
the most readable code.

Bill Volk

-----Original Message-----
 On Behalf Of Allen Eichler
Sent: Monday, July 07, 2003 6:14 AM
To: keitai-l@appelsiini.net
Subject: (keitai-l) Re: KDDI, BREW and CP


I'm still fairly new to this space, so forgive me if I'm about to say
something erroneous or just plain stupid...

Verizon, the largest US carrier, is Brew-only. To deploy widely across the
US one must make a Java and a Brew version of the app.

We develop prototypes in Java since it is much easier to test. Java OTA in
the US is fairly easy, whereas Brew is totally locked-down (i.e., no OTA
downloads until the app passes Brew QA). Early testing on a Brew phone
requires first sending the handset to Qualcomm for a hardware change to make
it "test-enabled."

It appears to me that another big difference between Java and Brew is that
(technically) any developer can offer a J2ME app directly to consumers, but
Brew allows Qualcomm and then the carrier to act as absolute gatekeepers.
I'm not discounting in any way the benefits of working with the carriers. I
realize that there is much consumer "friction" involved with getting the
user to provide a credit card number or go through some other billing
authorization process. I also acknowledge that it is difficult for a
developer, without the help of the carrier, to let many users know that
their product even exists.

Yet, if a developer was willing to go direct by taking on the challenge of
marketing to consumers and creating a "low friction" billing system, the
developer would still have to go through middle-men to reach subscribers
with Brew-only handsets. A Brew-only stance gives the carrier complete
control to: block content they don't like, ensure that there are no free
apps, and to make sure they get their cut. It seems to me that this may also
help with piracy of mobile apps.

Am I missing something here?





This mail was sent to address billy@pim-point.com
Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/



This mail was sent to address mail@davidkaye.info
Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/