Blowing the doors to Palm - Java programming for Tungsten handhelds

[John D.]

i would hasten to point out that by learning to program in java, you
free yourself from the boundary of programming for just one particular
os or hardware product. it is an AMAZING feeling to see my apps running
on both my palm vx and my motorola i95cl color javaphone, and to know
that they could run just as well in any nokia/samsung/whatever
java-enabled phone, rim blackberry, or even wince (after installing the
jvm)!

Well, if you can make a living selling tic-tac-toe games or
ring-tones - that's fine. Once you start adding features and
functionality that will essentially limit your choices of OS and
hardware. For example, if your program requires internet access that
will limit your choices of devices it will run on.

You present Java as a silver bullet to all portability problems, but you
fail to realize that people has been doing the exact same thing all along:
write core functionality in a portable manner and pack OS-specific features
into interface libraries. For example, QT (http://www.trolltech.com) is much
better choice for cross-platform GUI development than Java.

I would hasten to point out that by learning more about computer
architecture, OS design and generic algorithms/data structures,
you will know exaclty where the boundary of programming for just one
particular os or hardware product lies, and that your so-called "freedom"
sometimes means self-restricting "confinement".

 

[asj]

Well, if you can make a living selling tic-tac-toe games or
ring-tones - that's fine. Once you start adding features and
functionality that will essentially limit your choices of OS and
hardware. For example, if your program requires internet access that
will limit your choices of devices it will run on.

heh, sorry, but you obviously do not code in midp.

the interface for http connections is MANDATORY for all midp vendor
implementations, which means that if a device is midp-capable, it will
allow AT LEAST http (in addition, there may be other protocols
supported, like sockets or datagrams). of course, whether or not the
user has internet access to take advantage of this is beyond the control
of anyone but the user - lol.

btw, the apps we do are network-aware. they are enterprise apps, not
games (although why some people are so snobbish about games i don't know
- the games industry is probably larger than the one for enterprise, and
ringtones are exceedingly popular with consumers).

trolltech? interesting but how exactly does that relate to coding for
motorola phones, nokia phones, palm, or whatever?

as i pointed out, java may not be the perfect solution for portability,
but it by far the best solution out there in terms of REAL deployment of
apps, since the range of devices capable of running j2me far exceed
trolltech's qt or whatever:

http://wireless.java.sun.com/device/

 

[Tor Iver Wilhelmsen]

For example, QT (http://www.trolltech.com) is much better choice for
cross-platform GUI development than Java.

No becaue you end up using that travesty of a programming language
called C++.

 

[username]

No becaue you end up using that travesty of a programming language
called C++.

yet another religious remark in this thread.

 

[Arthur Hagen]

No becaue you end up using that travesty of a programming language
called C++.

Going from one onion oriented, slow and bloated language to another, you
mean? Going from Java to C++ is much like "speeding up" your old WV bus by
removing the brakes.

 

[asj]

Going from one onion oriented, slow and bloated language to another, you
mean? Going from Java to C++ is much like "speeding up" your old WV bus by
removing the brakes.

lol - i like that!

 

[Joseph Millar]

Going from Java to C++ is much like "speeding up" your old WV bus by
removing the brakes.

hahahaha...thanks for the chuckle.

--Joe

 

[Alex Buell]

hahahaha...thanks for the chuckle.

What's a WV?

 

[Joseph Millar]

What's a WV?

A VW by any other name...I think we all know what he meant,
especially if you have ever driven one, it brings new meaning
to the term "underpowered". I had one in college, damn that
thing was cold in the winter with that air cooled putt-putt
of an engine.

--Joe

 

[John D.]

the interface for http connections is MANDATORY for all midp vendor
implementations, which means that if a device is midp-capable, it will
allow AT LEAST http (in addition, there may be other protocols
supported, like sockets or datagrams). of course, whether or not the
user has internet access to take advantage of this is beyond the control
of anyone but the user - lol.

That does leave out Palm III, doesn't it? You cannot ignore hardware
limitations.

Besides, what are you talking about is several vendors supporting
consitent API across hardware devices. That is rather exception
than a rule. This does not present much of a portability problem.
I can argue the same that if you stick to core POSIX API then
your application will be portable across any UNIX platform.

The problem is that as time passes some manufactureres will introduce
new hardware faster that others (they are competitors after all).
That will lead to custom extentions (if they decide that the standard
is holding them back - it is all about money after all). Sure they will
still support "core" API's, but "custom extentions" are what makes
applications competitive. So you will end up doing it as it always has
been done: writing portable core functionality and interface libraries
to encapsulate non-portable extentions.

 

[John D.]

yet another religious remark in this thread.

He does not really mean that since he posted using news-reader
written largely in Lisp running in the program that was written
in C/C++ running under OS that was written mostly in C/C++.
It is one of those love/hate relationships.

 

[John D.]

Going from one onion oriented, slow and bloated language to another, you
mean? Going from Java to C++ is much like "speeding up" your old WV bus by
removing the brakes.

Parking brake, that's it.

 

[asj]

That does leave out Palm III, doesn't it? You cannot ignore hardware
limitations.

palm III was never supported i believe. it was only palm v and up.

The problem is that as time passes some manufactureres will introduce
new hardware faster that others (they are competitors after all).
That will lead to custom extentions (if they decide that the standard
is holding them back - it is all about money after all). Sure they will
still support "core" API's, but "custom extentions" are what makes
applications competitive. So you will end up doing it as it always has
been done: writing portable core functionality and interface libraries
to encapsulate non-portable extentions.

well, the vendors have the liberty of doing so, and in fact should do so
to differentiate their products...but the focus is on whether the
DEVELOPER is knowleageable enough to know when to use these
device-specific apis, and when not to...it all comes down to CHOICE.

i have been developing cross-platform apps on servers for awhile and
always laugh when microsoft-apologists (who probably couldn't coded a
line of j2ee if their cojones depended on it) insist java is NOT
cross-platform...of course it isn't, IF the developer insists on using
app-server specific extensions.

 

[Carlos Bazzarella]

carlos:

white castle is still selling the same burger after several decades,
cars probably have less horsepower on average than the behemoths of
yesteryear, and touch tone phones have basically been stagnant for
years...what's your point?

My point was basically that for a device where you want 3rd-party
developers to innovate on, you need to continuously improve the
hardware to allow new-unforseen software innovations.

Now running Java (J2ME) on a 68K dragon ball 16mhz machine is like
telling Microsoft to use 'Logo' to develop Word The point is
Java requires better hardware then that for acceptable 3rd-party
application performance.

there is a market for a handheld at that
price range (price being affected by the cost of making the
handheld)....at the same time, palm has expanded its range of products
towards the higher end to accomodate users who want more processing
power.

I fully understand your point but today handheld devices are expected
to do a lot more than 7 years ago so hardware must improve; but yes
the same old thing is still available cheaper for users who wants it.


Carlos.

 

[Carlos Bazzarella]

the point is: consumers don't care about technology, only functionality.
That's why all your arguments in favor of Java, are just technobabble,
irrelevant to consumers.

Not necessarly !!! We have users of Formulae 1 that were delighted to
be able to switch devices completely (Sharp Zaurus to iPaq for example)
and still run Formulae 1. This is functionality users want; Users want
the freedom to run their apps on any device they buy and not be tied down
to a certain Device/OS combo. Java did enable us to do that much easier
than with C/C++.


Carlos.

 

[asj]

Users want
the freedom to run their apps on any device they buy and not be tied down
to a certain Device/OS combo. Java did enable us to do that much easier
than with C/C++.

juntao does a good job (some hype, but what can you do?) of summarizing
the "Java Everywhere" mantra, in addition to giving some interesting
facts:

for example:

How big is the "Everywhere" market, anyway?
No one knows, but it will be bigger than anything we know of. I will
just give you one number: the cell phone ringtone download business in
Europe alone is $1.4 billion dollars for the last year. In contrast, the
entire global J2EE server market is $2.25 billion. Ringtone downloading
is a very "dumb" service and offers very limited value to customers.
Imagine the market size of hundreds of billions of smart Java devices
accessing J2EE backends and paying for the service on a monthly basis.
J2ME operator Vodafone is the biggest company in Europe and J2ME
applications are already the second largest revenue source for its
content services.

I am an enterprise developer, do I have to start over to learn J2ME?
No. In fact, the best feature of "Java Everywhere" is that it makes it
easy for existing Java developers to migrate to new application areas.
For example, familiar Java language features and all major IDE tools are
available in J2ME. In addition, many design patterns, best practices and
performance tips can still be applied with little modification. Vendors
like Nokia, IBM and Sun are making major efforts to provide end-to-end
Java tools and educational programs for existing Java developers.
However, we have to note that "Java Everywhere" emphasizes on developer
skill transfer rather than cross-platform runtime environments. Due to
the physical constrains of small devices, many J2SE API libraries are
not available in J2ME profiles or are only available in a lightweight
form. We have to investigate and understand those changes.

 

[Andreas Rueckert]

On Mon, 11 Aug 2003 10:13:51 -0300,

My point was basically that for a device where you want 3rd-party
developers to innovate on, you need to continuously improve the
hardware to allow new-unforseen software innovations.

Now running Java (J2ME) on a 68K dragon ball 16mhz machine is like
telling Microsoft to use 'Logo' to develop Word The point is
Java requires better hardware then that for acceptable 3rd-party
application performance.

Has anyone experience with J2ME on a device like the Palm M100
(a dragon ball with 2 MB)? I'm trying to run the J2ME version of
Java-Chess ( http://www.java-chess.de ) on it and wonder how
close my emulator (Pose on Linux) is to the real device.
I think it worked ok so far and blamed the our software for
the occasional out of memory exceptions.

Ciao,
Andreas

 

[Federico]

Hi all,



There is a method in java which permits to scan the conten of a folder
on the file system?

The situaon is that I have a folder which contains other folders and
xml files.

I need to scan all these folders and when I find the xml files take
some data from them to create dynamically other xml files, then
continue to scan all the other folders, in the bottom-up way,

How can I do?

Thank you
Fede

 

[William Brogden]

Hi all,



There is a method in java which permits to scan the conten of a folder
on the file system?

The situaon is that I have a folder which contains other folders and
xml files.

I need to scan all these folders and when I find the xml files take
some data from them to create dynamically other xml files, then
continue to scan all the other folders, in the bottom-up way,

How can I do?

The File class in the java.io package provides the methods you need.