Probleme bei Applikationsentwicklung

[zilti]

Ein Riesenproblem mit den neuen, vielen verschiedenen Systemen ist: Sie alle haben keine Java-Implementierung. Das alte Palm OS hatte z.B. Java. Web OS nicht mehr.
So muss man für jedes System wieder die ganze API "lernen" um Programme zu portieren.
Viele Mobiltelefone machen es vor, und zeigen dass durch die Implementierung von Java die Programme einfach so ausgeführt werden können.
Besonders schräg ist das Ganze beim iPhone: der iPhone-Prozessor ist ein Java-Bytecode-Prozessor, d.h. er versteht direkt Bytecode. Java bzw. JavaFX fürs iPhone gibt es allerdings (noch) nicht.
Dies alles macht es Softwareentwicklern nicht gerade leichter.
Nein, es ist nicht Freitag, dies ist kein Troll-Thread und soll es auch nicht werden.

[QDOS]

der iPhone-Prozessor versteht Java-Bytecode?

[Hanswurst123]

Das Betriebssystem mit "Rückstand" kann Java ;)

Die meisten Windows Mobile Handsets haben irgend eine Java Implementierung dabei.

[QDOS]

die rückständigen "Handys" haben auch alle ne Java-Implementierung… Eigentlich schräg, wenn man darüber nachdenkt…

[mars96]

Java ist bei webOS auch drin, aber es ist nicht vollständig und steht nur dem Betriebssystem zur Verfügung. Ich gehe mal davon aus das sich das noch ändern wird...wäre jedenfalls besser.

[Siga32490724047]

J2ME ist etwas weniger als Java womit Jython ginge (gehen würde).

Interessant sind aber die Entwicklungssysteme, die verschiedene Ziel-Codes erzeugen. Dann muss man nicht verschiedene Entwicklungsysteme nutzen und kann trotzdem (per Plugins vielleicht in Zukunft) Code für Android, WebOS, WinMobile(?), eher nicht Iphone und sonstwas erzeugen, testen und hochladen.
Automatisches Cross-Plattform-Entwickeln/MultiFacing von Apps.
Z.b. dann auch für andere Auflösungen oder grau-Stufen-EBooks.

Nützliche Anwendungen aus dem anderen Diskussions-Thread hier brauchen oft auf dem Handy nicht wirklich viel Rechenpower sondern holen einfach Infos aus dem Netz, die man unterwegs gerne hätte und brauchen könnte.
Warum soll ich nicht per Formulator auf jedem Handy bei McDrive einkaufen sollen. Oder ich sehe meine Tischnummer im Restaurant und bestelle per Handy elektronisch. Dann gibts auch keine Verständnis/Aufschreib-Probleme.

Action-Spiele sind etwas anderes. Die können/sollen die ruhig weiter in handoptimiertem Assembla proggern.

[oni]

Ich mag Java. Eben genau wegen der Portabilität. Aber Java ME kann man getrost in die Tonne kloppen. Ich habe lange Zeit Java ME entwickelt und bin dabei auf eine Menge schräge Schoten gestoßen. Grund: Jeder Smartphone-Hersteller implementiert seine JVM leicht unterschiedlich.
Damit laufen zwar normale Programme, die nur "Grundlagen" machen, aber sobald man etwas mehr machen will, d.h., an die Hardware ran will, wird es eklig. Muss man z.B. direkt auf dem Dateisystem Daten ablegen, gibt es da zwar einen JSR für, aber wie die Dateipfade aussehen, ist von Modell zu Modell unterschiedlich. Dann gibt es Modelle, bei denen über jenen JSR (ich glaube es war der 75) das gesamte Filesystem read-only ist - bis auf einen ganz bestimmten Ordner bzw. Pfad. Das ganze artet dann am Ende in eine Anpassungs-Orgie an zig Modelle aus mit kruden OS-Erkennungen.
Auch beim UI-Design gibt es unschöne Eigenheiten. Nimmt man das "hauseigene" lcdui, dann rendert jedes Handy die Oberfläche anders. Und fast immer wirkt sie zusammengeschustert und unintuitiv. Texteingabefelder, die nur Zahlen akzeptieren sollen, bringen dann bei Touchscreen-Telefonen trotzdem eine Buchstabentastatur auf den Schirm, die erst manuell umgeschaltet werden muss - Eingabe eines Buchstabens ruft dann Fehlermeldungen hervor. Am Ende findet man sich dann wieder low-level auf Canvas-Ebene UI-Elemente mit drawRect und drawString malend und mit ActionListeners um sich schmeißend oder man nimmt UI-Libs von Drittanbietern wie LWUIT, die eine Art "Mini-Swing" aufs Handy bringen, was zwar gut funktioniert, aber wegen ineffizienter Canvas-Implementierungen auf vielen Handys langsam und träge ist.

Also: Wenn Java, dann Java SE. Stark genug sind moderne Smartphones. Ansonsten ist es das kleinere Übel, gerätespezifische APIs zu nutzen. Weiterhin werden praktisch alle modernen Geräte in irgendwelchen C-Derivaten programmiert. Wer einmal C kann, wird auch damit nach kurzer Zeit klarkommen.

[ino]

> Jeder Smartphone-Hersteller implementiert seine JVM leicht unterschiedlich.

So ist es wohl.

Zur Ausgangsfrage - Android ist Java-only, soweit ich das sehe. Interessant fuer mich, weil ich aus einer anderen Ecke komme und Java eher nicht mag. Damit faellt das Android als interessante Plattform fuer mich erst einmal flach.

[X99]

Java, immer dieses Java.
Und nein, wie auch hier schon oft genug genannt, es ist eben NICHT Plattformunabhängig.
Wer mal für die mobilen Geräte entwickelt hat, wird feststellen, dass diese unterschiedliche Umfänge anbieten.
Ein Beispiel fürs Nokia E71:
.
.
SR 179 Location API for J2ME™ 1.0
JSR 180 SIP API for J2ME™
JSR 184 Mobile 3D Graphics API for J2ME™ 1.1
JSR 205 Wireless Messaging API 2.0
JSR 226 Scalable 2D Vector Graphics API for J2ME™ 1.1
JSR 234 Advanced Multimedia Supplements 1.0 (audio3d)
JSR 234 Advanced Multimedia Supplements 1.0 (music)
.

Da aber jedes Handy da was anderes anbietet und dann noch hinzu kommt, dass die Hälfte zwar das steht aber nicht ausimplementiert ist, kriegt man da echt ne Kriese.
Dazu kommt noch, und da brauchen wir uns wirklich nicht drüber streiten, die miese Performance. Man erkennt sofort, dass es ich um ne Java Software auf dem Gerät handelt.
Natürlich muss man sich bei Objective-C auf dem iPhone einarbeiten aber das geht sehr schnell und man hat viel mehr Möglichkeiten. Dazu kommt noch die c/c++ Unterstützung.
Ich war gerade erst auf einer Veranstalltung von Nokia, wo die hinter einer Glaswand saßen und von vielen Gruppen, Android, Nokia .. iPhone Entwicklern hören wollten was sie gut und was schlecht finden und da waren sich alle ziemlich einig. Auch wenn Nokia das nicht hören wollte.

[Alex Keller]

Das iPhone kann Java, aber nur eingeschränkt, siehe Tutorials im Netz.

Ich möchte keine "reine" Portierung, siehe schlechte Rezessionen Tomtom Navigation (Nach Updates wurde endlich das WinMobile"artige" GUI entfernt)

[X99]

Nach der logik kann alles Java.

[tunnelblick]

android kann java. sämtliche applikationen sind sogar java :) beweis? siehe wiki.

[zilti.]

Jap, Android "kann" Java. Allerdings hat es die standard-Java-Libs nicht.

[harmless]

Dass Applikationen speziell für das iPhone geschrieben werden müssen, ist kein Nach-, sondern ein Vorteil für die Plattform.
Ja, das bedeutet mehr Arbeit wenn man Software portieren will. Dafür bekommt der Benutzer dann aber besser an das Gerät angepasste Programme.

[so-isses]

> der iPhone-Prozessor ist ein Java-Bytecode-Prozessor, d.h. er
> versteht direkt Bytecode.

Kannst du das belegen?

[tunnelblick]

nicht kann. alles *ist* java.

[zilti]

Ja, kann ich, hier: http://openbook.galileocomputing.de/javainsel8/javainsel_01_003.htm#mj62b28af723d259ce53ec009d54952893
(Abschnitt "Java on a Chip"). Ich gehe zumindest mal davon aus dass "Java ist auch eine Insel" seriös ist.

[zilti]

Gerade da wären wohl wieder einige wenige, standardisierte Handy-Betriebssysteme gut. Da gäbe es dann (hoffentlich) ausgereiftere Implementierungen.
Aber Beispiel Opera Mini: Dort haben es die Entwickler auch geschafft, eine Java ME-Anwendung zu schreiben, die auf fast allen Handys läuft.

[nope]

Man kann seine Programme für Android komplett in Java schreiben, was dann (theoretisch) auf allen Android-Geräten laufen soll. Man hat aber auch die Möglichkeit, über das NDK das ganze Programm (oder zumindest performace-kritische Teile) nativ in C++ zu schreiben, was zumindest auf verschiedene Hardware-Platformen angepasst, bzw. einzeln kompiliert werden muß. Im Moment spielt das aber eher keine große Rolle, da bisher alle Androiden einen ARM Prozessor und soweit ich weiß auch recht ähnliche Chips haben.

Bezüglich J2ME:
Da liegt die Zukunft eh ziemlich im Dunkeln. MIDP3 ist ja auch irgendwie seit Jahren in der Mache und eine der größten Neuerungen sollen sein, daß man nun auch mit Alpha-Transparenzen zeichnen kann. Verglichen mit anderen APIs wie Android oder iPhone, wo freies Drehen und Verzerren von Graphiken kein Problem darstellt, hat man bei J2ME selbst bei den Rotationen in 90° Schritten noch immense Probleme.

J2ME war vielleicht mal toll, als Handys noch Schwarzweiß waren und eine einheitliche API zur Darstellung von Forms noch ein riesen Fortschritt waren... mittlerweile ist der Rückstand zu modernen APIs aber kaum noch aufzuholen.
Wie träge die Weiterentwicklung von J2ME ist, merkt man z.B. auch daran, daß es immer noch auf Java 1.3 / 1.4 aufbaut, d.h. die "neuen" Features aus Java 1.5 (was immerhin auch schon 5 Jahre alt ist) wie Generics oder for-each-Loops sind schonmal gar nicht so ohne weiteres nutzbar.

[nope]

Zu Opera Mini muß man aber auch sagen, daß die Webseiten für den Browser zuerst auf einem eigenen Proxy-Server für die Darstellung auf dem Handy aufbereitet werden, es ist also keine reine J2ME Implementierung, sondern ein nicht ganz unwesentlicher Teil des Browsers läuft nichtmal auf dem Telefon.