1. Foren
  2. Kommentare
  3. Handy
  4. Alle Kommentare zum Artikel
  5. › Android, iPhone und WebOS bestimmen die…

Probleme bei Applikationsentwicklung

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Probleme bei Applikationsentwicklung

    Autor: zilti 31.12.09 - 13:50

    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.

  2. Re: Probleme bei Applikationsentwicklung

    Autor: QDOS 31.12.09 - 13:58

    der iPhone-Prozessor versteht Java-Bytecode?

  3. Re: Probleme bei Applikationsentwicklung

    Autor: Hanswurst123 31.12.09 - 14:00

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

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

  4. Re: Probleme bei Applikationsentwicklung

    Autor: QDOS 31.12.09 - 14:10

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

  5. Re: Probleme bei Applikationsentwicklung

    Autor: mars96 31.12.09 - 14:27

    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.

  6. Re: Probleme bei Applikationsentwicklung

    Autor: Siga32490724047 31.12.09 - 14:44

    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.

  7. Und das ist auch gut so.

    Autor: oni 31.12.09 - 15:37

    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.

  8. Java etc.

    Autor: ino 31.12.09 - 16:42

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

  9. Re: Probleme bei Applikationsentwicklung

    Autor: X99 31.12.09 - 17:43

    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.

  10. Portierung

    Autor: Alex Keller 31.12.09 - 17:54

    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)

  11. Re: Portierung

    Autor: X99 31.12.09 - 18:49

    Nach der logik kann alles Java.

  12. Re: Probleme bei Applikationsentwicklung

    Autor: tunnelblick 31.12.09 - 19:06

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

  13. Re: Probleme bei Applikationsentwicklung

    Autor: zilti. 31.12.09 - 21:57

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

  14. Re: Probleme bei Applikationsentwicklung

    Autor: harmless 01.01.10 - 09:12

    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.

  15. Beweis?

    Autor: so-isses 01.01.10 - 10:37

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

    Kannst du das belegen?

  16. Re: Probleme bei Applikationsentwicklung

    Autor: tunnelblick 01.01.10 - 12:41

    nicht kann. alles *ist* java.

  17. Re: Beweis?

    Autor: zilti 01.01.10 - 13:30

    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.

  18. Re: Probleme bei Applikationsentwicklung

    Autor: zilti 01.01.10 - 13:33

    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.

  19. Re: Java etc.

    Autor: nope 01.01.10 - 16:28

    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.

  20. Re: Probleme bei Applikationsentwicklung

    Autor: nope 01.01.10 - 16:33

    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.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. dSPACE GmbH, Paderborn
  2. Vodafone GmbH, Düsseldorf
  3. CCS 365 GmbH, München
  4. Studierendenwerk Hamburg Anstalt des öffentlichen Rechts, Hamburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 555,55€ (zzgl. Versandkosten)
  2. täglich neue Deals bei Alternate.de
  3. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Threadripper 3970X/3960X im Test: AMD wird uneinholbar
Threadripper 3970X/3960X im Test
AMD wird uneinholbar

7-nm-Fertigung, Zen-2-Architektur und dank Chiplet-Design keine Scheduler-Probleme unter Windows 10: AMDs Threadripper v3 überzeugen auf voller Linie, die CPUs wie die Plattform. Intel hat im HEDT-Segment dem schlicht nichts entgegenzusetzen. Einzig Aufrüster dürften sich ärgern.
Ein Test von Marc Sauter

  1. Via Technologies Centaur zeigt x86-Chip mit AI-Block
  2. Nuvia Apples Chip-Chefarchitekt gründet CPU-Startup
  3. Tiger Lake Intel bestätigt 10-nm-Desktop-CPUs

Macbook Pro 16 Zoll im Test: Ein Schritt zurück sind zwei Schritte nach vorn
Macbook Pro 16 Zoll im Test
Ein Schritt zurück sind zwei Schritte nach vorn

Keine Butterfly-Tastatur mehr, eine physische Escape-Taste, dünnere Displayränder: Es scheint, als habe Apple beim Macbook Pro 16 doch auf das Feedback der Nutzer gehört und ist einen Schritt zurückgegangen. Golem.de hat sich angeschaut, ob sich die Änderungen auch lohnen.
Ein Test von Oliver Nickel

  1. Audioprobleme Knackgeräusche beim neuen Macbook Pro 16 Zoll
  2. iFixit Kleber und Nieten im neuen Macbook Pro 16 Zoll
  3. Macbook Pro Apple gibt fehlerhafte Butterfly-Tastatur auf

Energiewende: Grüner Wasserstoff aus der Zinnschmelze
Energiewende
Grüner Wasserstoff aus der Zinnschmelze

Wasserstoff ist wichtig für die Energiewende. Er kann als Treibstoff für Brennstoffzellenautos genutzt werden und gilt als sauber. Seine Herstellung ist es aber bislang nicht. Karlsruher Forscher haben nun ein Verfahren entwickelt, bei dem kein schädliches Kohlendioxid entsteht.
Ein Bericht von Werner Pluta

  1. Brennstoffzelle Deutschland bekommt mehr Wasserstofftankstellen
  2. Energiewende Hamburg will große Wasserstoff-Elektrolyseanlage bauen

  1. K-ZE: Elektro-Dacia soll 15.000 Euro kosten
    K-ZE
    Elektro-Dacia soll 15.000 Euro kosten

    Renault will den eigentlich nur für den chinesischen Markt gedachten Elektro-Mini-SUV K-ZE über seine Marke Dacia auch nach Europa bringen. Es könnte das günstigste vollwertige Elektroauto auf dem deutschen Markt werden.

  2. China: Yibin nimmt fahrer- und schienenlose Straßenbahn in Betrieb
    China
    Yibin nimmt fahrer- und schienenlose Straßenbahn in Betrieb

    In der chinesischen Großstadt Yibin fährt künftig eine Straßenbahn ohne Schienen: Auf Gummireifen folgt die Bahn einer Spur auf der Straße und kann bis zu 300 Personen befördern. Die Bahn ist auch autonom ohne Fahrer einsetzbar.

  3. IT: Für Berlins Windows-10-Umstellung wird es immer enger
    IT
    Für Berlins Windows-10-Umstellung wird es immer enger

    Das Betriebssystem Windows 7 ist ein Auslaufmodell: Im Januar 2020 beendet Microsoft den kostenlosen Support, dann drohen Sicherheitslücken. Doch in der Berliner Verwaltung warten noch Tausende Rechner auf ein Upgrade - 30.000 müssen wegen eines Fehlers zudem neu bespielt werden.


  1. 14:26

  2. 13:27

  3. 13:02

  4. 22:22

  5. 18:19

  6. 16:34

  7. 15:53

  8. 15:29