(keitai-l) Re: new 505i phones (Java)

From: Paul Lester - Theta <paul_at_thetamusic.com>
Date: 04/11/03
Message-ID: <3E9664A2.2187C4A@thetamusic.com>
    There is one advantage to a smaller limit.  That is, it keeps
us all using less bandwidth.  And though one can not really use
object oriented Java, and you need to redo various parts of java,
that's a big plus.

    Bandwidth is like a precious resource like oil, computer memory,
hard disk space, water, or uranium.  It shouldn't be wasted.  But we all
do (including me), so I'm not the one that should be saying so.

    But I am a little on the extreme of always trying to minimize the size
of things, and to use as little as possible and to keep things as simple
as possible.

    The hard thing to do is to keep things both very short and very simple.
But thats what good programming is all about.  DoCoMo's size limit
helps us to do just that while the larger size limits of the other
providers act as a force against this.

    But I must agree with all of you that it would be nicer to have a bigger
limit, but then customers want more, and projects invariably take longer.
And sleepless nights for programmers increase.

    Also I am wondering, but I heard there were more flavors of Java outside
Japan for mobile devices than in Japan.  Like 90 or something.  Are all of
them based on the same MIDP and CLDC classes?  And if I recall DoJa extends
MIDP and so does all the rest.  Isn't the difference in the CLDC classes?
I'm too lazy to look it up.

    I'm so stuck in ringtones I don't think much about the whole microedition stuff.

    Also DoJa was the first micro edition java for phones in Japan and one
of the first in the world.  I think Korea beat Japan for first.  So its not surprising
it should have its own standard.  When it was made, it was the standard.

    JPhone's and AU's java seemed nonstandard when they came out.

tek1 wrote:

> At 10:52 03/04/11 +0900, you wrote:
>
> >On Thu, 10 Apr 2003, tek1 wrote:
> >
> > > Unbelievable.
> >
> >I don't see why.
>
> Even with obfuscation and downloading text and graphics to storage, 30K is
> not a lot to work with for a complex application that has to make up for
> the inadequacies of MIDP (i.e. no double/float usage) and that tries to
> have maintainable, object-oriented code.
>
> Also, Docomo increased the application size from 10K->30K in going from the
> 503i->504i.  One would think that they would have increase the size again,
> especially with the competition (JPhone and AU) and the rest of the world
> that follows the MIDP1.0 standard offering 50K+.  The Nokia7210 is 64K and
> MotorolaT720 is 100K.
>
> I think that developers, when given a choice between DoCoMo (Japan only;
> 70% market share; 30K app size; proprietary MIDP) and the rest of the world
> (AU, JPhone, Europe, the Americas, Korea, China, etc.; 50K+ app size;
> MIDP-standard), that developers will go with the latter first and then for
> DoCoMo later.  DoCoMo's strategy was ok, so long as the rest of the world
> didn't have many Java-capable devices, but DoCoMo will need to increase the
> app size significantly and either 1) offer many more features than the MIDP
> standard in its proprietary MIDP-like platform, or 2) adopt the MIDP
> standard.  Otherwise, they risk "losing" the applications created by
> talented developers in other countries around the world.  AU and JPhone
> won't have this problem, as the only porting issues that developers in
> other countries would face would be the (fairly easily-handled) Japanese
> language issues, and not the more difficult programming language
> differences (MIDP->DoJa).  It will interesting to see what happens with the
> 506i series.  :)
>
> This mail was sent to address paul.lester@lincmedia.co.jp
> Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/

--
*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*=*+*F=m(dv/dt)
Paul B. Lester
thetamusic.com(有)
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 Fri Apr 11 09:53:12 2003