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