(keitai-l) Re: kddi + opera

From: Paul Lester <paul_at_thetamusic.com>
Date: 08/31/04
Message-ID: <4133C79F.4C00DB1E@thetamusic.com>
    Both... we do both Brew and Java in my company.  The fees are bad but the
time it takes to develop an app of the same quality.  It takes us about 5 times as long,
but not because it was in BREW.

    Lets say you want to make a service on an AU, Vodaphone or DoCoMo phone in Japan.
You can develop it client side (iappli ) or server side (tomcat + imode/jsky/ezweb browser).
A server side app does not take long, and a client side does not take long.... it is easy to
judge on a case by case basis which is better for what application.

    With BREW, many BREW handsets in the US have no web like browser, just a payment system
called Get It Now!  So to make the equivalent BREW app to the server side Java App you need
to code up browser components inside your BREW app.  These browser components make
the BREW application take 5 times longer than a Java powered (imode/ezweb/jsky) site.

    Both Java and BREW have the problem of solving differences between
handsets.  By between handsets I mean the same carrier like SO505i and N505i in Japan.
And like between the LGVX4400 and LGVX6000 in the US.

    Now if Brew would come with a browser and have a payment system for web pages
as well as BREW apps, than you could save that overhead time and build faster BREW applications.

    Fortunately in Japan, almost all handsets have a browser so you can build a BREW application
in competition with Java applications.  And now with the Opera BREW Browser.... maybe things will
be faster for development.  So I'm very happy with the Opera news.  Maybe now more BREW providers will provide
a browser as well!
----------------------
    If the you code the same application in BREW and Java.... its hard to say which will be faster
or slower to code... It depends if the developer has more experience with Java or more experience
with C++.  Most of the time the Java will code a bit faster because there is less of a chance
of a memory leak due to its lack of pointers, but mobile phone java tends to have memory problems
sometimes..... so I don't know for sure which is actually better.

    But in most cases.... its BREW app versus Java app + Browser.
ex BREW versus imode + iappli.

    Hopefully soon it will be
BREW+Opera Versus IMode+Iappli.

    Then we can let the sparks fly and see who wins.

---------
As for BREW

    I hate those signature files!  They drive me mad!  And I hate the way the drivers to connect the
handsets to computers along with the BREW logger and such sometimes crash my Windows systems
giving me the blue screen of death!  Its horrible.  And I hate the way the handsets reset and go weird
sometimes!  AUGH!  Its worse than appli development... sometimes I have to remove the battery
from the handset to get the handset to work after BREW crashes!

    Worst of all is the testing.  Sometimes to get your program approved by Qualcomm they
insist you fix really silly bugs... and of course sometimes they miss really big bugs.... But in the
end, its a good thing that they have a round of testing they do as well ... as it improves the overall
quality of the BREW application.

    The worst thing I get from Java is sometimes serious bugs in the JRE every two years!  Much less than for
any other language I have worked with (most languages I find serious bugs in the language source, compiler or
interpreter every two months or less)

Benedict Evans wrote:

> Is taht cost difference to do with Qualcomm's fees or developer time
> (or both?)
>
> ---------------------------
> Benedict Evans
> +44 7880 786 727
> On 30 Aug, 2004, at 3:39 pm, Curt Sampson wrote:
>
> > On Mon, 30 Aug 2004, Shawn wrote:
> >
> >>> BREW is five times faster than Java
> >>
> >> ...if *true* would be a comparison of handsets without a Java
> >> accelerator chip, would it not?
> >
> > Unless the engineers have gone really nuts with the Java accellerator
> > chips, which doesn't seem likely to me, BREW is likely always to be
> > faster than Java on the same platform.
> >
> > Of course, that's still pretty meaningless. There are some other very
> > important issues to look at as well, when it comes to any particular
> > application:
> >
> >     1. Does it *need* to be faster? I can't see how my karaoke remote
> >     control or appli for checking billing would be better if they ran
> >     "faster." Heck, even my 3-D version of Densha de GO! runs at a
> >     pretty adequate frame rate.
> >
> >     2. Are you willing to take the hit on development costs to get the
> >     advantages of BREW? I would estimate that a BREW application will
> >     cost you at least five times as much to develop as a similar Java
> >     application.
> >
> > cjs
> > --
> > Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974
> >
> > ***   Contribute to the Keitai Developers' Wiki!   ***
> > ***        http://www.keitai-dev.net/wiki/         ***
> >
> >
> > This mail was sent to address ben@ben-evans.com
> > Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/
> >
>
> This mail was sent to address paul@thetamusic.com
> Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/

--
*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*F=m(dv/dt)
Paul B. Lester
thetamusic.comiLj
Chief Engineer

EMAIL: paul@thetamusic.com
--
http://www.thetamusic.com/

personal homepage: http://pbl1.tripod.com/
personal EMAIL: pbl1@cornell.edu
*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*F=m(dv/dt)
Received on Tue Aug 31 03:31:50 2004