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?
Received on Mon Jul 7 23:25:52 2003