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

From: tek1 <tek1_at_pobox.com>
Date: 04/11/03
Message-id: <4.3.2-J.20030411120739.03432ac8@smtp.comcast.net>
At 15:45 03/04/11 +0900, you wrote:

>     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.

I agree that bandwidth is precious, but just because and application itself 
is small doesn't mean that the application will not use a lot of bandwidth. 
You can have a small 10K program that constantly sends data back and forth 
to and from the server, wasting a lot of bandwidth, but have a much larger 
program that attempts to store a lot of data on the phone (conserving 
bandwidth in the long-run), but require much more logic (and thus 
application size) to be able to perform local lookups instead of requesting 
every single piece of data from the server everytime (i.e. performing a 
currency calculation locally as opposed to asking the server everytime for 
the result of  $93.42 + $23.73 or other dollar amount).  Large application 
sizes only require a longer initial download and bandwidth usage, but over 
the long-run could save the consumer money by performing more logic locally 
instead of making excessive requests to the server).

Also, I hardly think that DoCoMo wants to conserve bandwidth.  The more 
data packets flowing through their network, the more money that they make...


>     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.

I agree that it is important "to keep things as simple as possible". 
Standard object-oriented programming is *simple* to understand, but trying 
to cram all the logic into one class and discard many object-oriented 
techniques is not and makes the program much for difficult to understand. 
The whole purpose of Java and object-oriented programming is keeping things 
"simple", keeping object-specific logic within the object.

Also, your application/business requirements dictate in large part how big 
the application will need to be, in order to handle all of the 
functionality.  Of course, you can always cut functionality, but will 
certainly leave the user wanting more and asking, "Why doesn't the 
application do this?"

Further, the possibility of an application being "forced quit" at anytime 
requires additional "defensive" programming to make sure that data is saved 
appropriately and the application can resume later where the user "force 
quit" (whether it was on purpose or accidentally).  A lot of 
double-checking must also go into whether the data was successfully 
received (i.e. what happens if the signal is lost while data was being 
downloaded to the phone?).

Also, MIDP1.0 was a good start, but obviously has a lot of functionality 
missing, especially from the high-level components, which may require the 
development of custom components.  Also, SSL is unfortunately not part of 
the MIDP1.0 standard.  Fortunately, DoCoMo, AU, and JPhone have built it 
in, but it is not built-in in other countries (i.e. no SSL support for 
Nokia 7210 nor Motorola T720) and the developer must take other measures to 
provide similar security functionality.

Last, Java aside, how much space on the phone does *one* of the ultra 
high-quality photos (available in the new 505i camera-phones) consume? 
Quite a bit.  Given that, I think that DoCoMo could have drastically 
increased the size of Java applications.




>     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.

The consumer is the one who feeds the programmer.  Making the customer 
happy, so that they stay as your customer, is the most important.  Besides, 
when have programmers ever slept?  :P


>     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.


I believe that DoCoMo was first in the world, as they came out with "DoJa" 
(DoCoMo Java) before the MIDP1.0 specification was completed.  The rest of 
the world waited and ALL support the MIDP1.0 specification.  DoJa is very 
similar to MIDP, but still has its differences and it is not a walk in the 
park to port between the two.  Both MIDP and DoJa sit above the CLDC 
layer, the latter which I believe is the same for both.  The differences 
are in MIDP and DoJa.
Received on Fri Apr 11 19:23:08 2003