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. Universitätsmedizin der Johannes Gutenberg-Universität Mainz, Mainz
  2. Fachhochschule Südwestfalen, Meschede
  3. Parador GmbH & Co. KG, Coesfeld
  4. Blickle Räder+Rollen GmbH u. Co. KG, Rosenfeld

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-66%) 16,99€
  2. 2,49€
  3. (-70%) 5,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


In eigener Sache: Golem.de sucht Produktmanager/Affiliate (m/w/d)
In eigener Sache
Golem.de sucht Produktmanager/Affiliate (m/w/d)

Attraktive Vergünstigungen für Abonnenten, spannende Deals für unsere IT-Profis, nerdiger Merchandise für Fans oder innovative Verkaufslösungen: Du willst maßgeschneiderte E-Commerce-Angebote für Golem.de entwickeln und umsetzen und dabei eigenverantwortlich und in unserem sympathischen Team arbeiten? Dann bewirb dich bei uns!

  1. In eigener Sache Aktiv werden für Golem.de
  2. Golem Akademie Von wegen rechtsfreier Raum!
  3. In eigener Sache Wie sich Unternehmen und Behörden für ITler attraktiv machen

Sendmail: Software aus der digitalen Steinzeit
Sendmail
Software aus der digitalen Steinzeit

Ein nichtöffentliches CVS-Repository, FTP-Downloads, defekte Links, Diskussionen übers Usenet: Der Mailserver Sendmail zeigt alle Anzeichen eines problematischen und in der Vergangenheit stehengebliebenen Softwareprojekts.
Eine Analyse von Hanno Böck

  1. Überwachung Tutanota musste E-Mails vor der Verschlüsselung ausleiten
  2. Buffer Overflow Exim-Sicherheitslücke beim Verarbeiten von TLS-Namen
  3. Sicherheitslücke Buffer Overflow in Dovecot-Mailserver

Jobs: Spielebranche sucht Entwickler (m/w/d)
Jobs
Spielebranche sucht Entwickler (m/w/d)

Die Hälfte aller Gamer ist weiblich. An der Entwicklung von Spielen sind aber nach wie vor deutlich weniger Frauen beteiligt.
Von Daniel Ziegener

  1. Medizinsoftware Forscher finden "rassistische Vorurteile" in Algorithmus
  2. Mordhau Toxische Spieler und Filter für Frauenhasser

  1. Internetdienste: Ermittler sollen leichter an Passwörter kommen
    Internetdienste
    Ermittler sollen leichter an Passwörter kommen

    Die Bundesregierung will Ermittlern den Zugriff auf Nutzerdaten bei Internetdiensten wie Mail-Anbieter, Foren oder sozialen Medien erleichtern. Die IT-Branche und die Opposition sehen einen "Albtraum für die IT-Sicherheit".

  2. Netflix und Youtube: EU-Kommissarin warnt vor hohem Energiebedarf des Internets
    Netflix und Youtube
    EU-Kommissarin warnt vor hohem Energiebedarf des Internets

    Youtube, Netflix und Prime Video sind die Dienste, die besonders viel Internetverkehr generieren und damit auch einen besonders hohen Energiebedarf nach sich ziehen. Das sieht die Vizepräsidentin der EU-Kommission kritisch.

  3. Galaxy Fold: Samsung dementiert eigene Verkaufszahlen
    Galaxy Fold
    Samsung dementiert eigene Verkaufszahlen

    Samsung widerspricht sich selbst. Das Unternehmen bestreitet die Angabe eines ranghohen Samsung-Managers, der verkündet hatte, weltweit seien bereits eine Million Galaxy Fold verkauft worden. Vieles bleibt ungeklärt.


  1. 12:25

  2. 12:10

  3. 11:43

  4. 11:15

  5. 10:45

  6. 14:08

  7. 13:22

  8. 12:39