News Entwicklerinteresse an Android sinkt leicht

@ Notch: Ich als Entwickler kann dir sagen, dass iOS einfach attraktiver aufgrund der zahlungswilligeren Kundschaft ist, nicht aufgrund der geringeren Fragmentierung (wie im Artikel suggeriert). 99 Cent pro App wird in iTunes wie eine "kostenlose" App von den Kunden behandeln, also es wird gekauft ohne mit einer Wimper zu zucken.

Letztendlich muss ich meine Rechnungen bezahlen und das kann ich nicht, indem ich kostenlose Android App herstelle. Und da ich nur begrenzt Zeit habe, ist für mich die Androidplattform leider gestorben. Große App-Hersteller mögen das vielleicht anders sehen.
 
m4f10s0 schrieb:
So, und nun Vergleichen wir mal die Marktanteile aller Plattformen und ziehen diese in das Ergebnis mit ein.

Und jetzt sollen die WP7-Hater weiter haten!
Mein paps pflegt da immer nur zu sagen: "Hinten kackt die Ente".

Wir werden sehen, ja das werden wir ;)

Mal gucken was die Hater dann sagen.. theoretisch müssten sie cheater rufen :D
 
@Genscher: So siehts bei mir auch aus. iOS ist lukrativer bei einem Bruchteil der Arbeit der Entwicklung von Android - die vielen nötigen Testgeräte für android tragen zu der Entscheidung dann den Rest bei.
 
Feuerferkel schrieb:
Ablesbarkeit nicht gegeben, Aussagekraft gegen Null.
klick die linien an
Ergänzung ()

Mike Lowrey schrieb:
Das Problem ist vor allem der Anspruch die ganze Android Plattform beackern zu können. Das dies nicht realisierbar ist, ist mehr als verständlich.
selbstverstndlich weil man sich sonst als entwickler einer großen nutzerzahl versperrt und dann auch mögliche konsumenten deutlich geringer sind...

"Oberklasse der Samsung Galaxy Reihe" ist zahlenmässig ein witz zum gesamten android markt
 
Zuletzt bearbeitet:
Versuchts doch einfach selber mal... Das ist zwar jetzt nur ein klitzekleines Beispiel, aber holt euch das Android SDK und eine Entwicklungsumgebung und startet einfach mal eine kleine App im Emulator. Grauenvoll... Fehlerbehaftet, langsam, kompliziert.

Bei Xcode hingegen wähle ich aus einer Combobox aus, auf welchem Gerät ich testen will und klicke auf den "Start"-Button. Und im Gegensatz zum Android-Emulator ist der iOS-Emulator sogar brauchbar.

Meiner Meinung liegt das auch nicht an Java, wie einige hier behaupten. Ich habe beruflich viel mit Java zu tun und das kann sehr wohl elegant und schnell sein. Das Android-SDK ist qualitativ einfach meilenweit unterlegen und das fällt bereits auf, lange bevor ich mir als Entwickler Gedanken über verschiedenen Auflösungen oder Geräte mache.
 
@MNagler
An Java kanns nicht liegen ;-) Wenn man seine Oberfläche schon zusammenklicken möchte war Netbeans früher das non plus ultra.

Ich schreibe den Code für die Oberfläche eh immer selber, dauert zwar etwas länger, dafür ist der Code kürzer und weniger anfällig für Bugs. Das Android SDK ist aber in der Tat grauenhaft.
 
Mike Lowrey schrieb:
Das Problem ist vor allem der Anspruch die ganze Android Plattform beackern zu können. Das dies nicht realisierbar ist, ist mehr als verständlich.
Dann erklär mal deinem Kunden, deinem Chef oder sonstwem warum die Android-Applikation nur auf z.B. Samsung Galaxy Modellen läuft, und nicht auf dem Xperia des Sohnes deines Chefs.
Es interessiert niemanden, dass die Geräte leistungsschwächer sind oder weiß der Teufel, wenn du ein Android App bauen sollst, dann will man auch alle Android Geräte erreichen können und nicht nur einen Bruchteil dieser Menge.

Und deine Aussage ist doch mal das Paradebeispiel für Fragmentierung! Bauen wir Apps eben nicht für alle Modelle, sondern nur für einen kleinen Teil, muss der Kunde eben schauen, ob sein Modell unterstützt wird. Oder er sieht ein App bei seinen Kumpels und will es auch haben, gibt es für sein Modell aber nicht.
Das wäre nicht nur eine Fragmentierung für Entwickler durch die Android-Platform, sondern auch eine Fragmentierung für den potentiellen Kunden - und DAS wäre das endgültige Aus für Android. Aus (reine Vermutung) 100k Apps im AppStore kann man dann nur noch 5k nutzen, die anderen sind nicht für das Modell. Facebook? Nein gibts für das Modell nicht (wahrscheinlich eine der meistgeladenen Anwendungen). Dann kannst du dir aber sicher sein, dass das nächste Smartphone dieser Person kein Android mehr sein wird, denn man müsste sich ja vorher groß informieren, welche Apps auf dem Gerät laufen. Dann wird eben zu iOS oder WP7 gegriffen bei dem die Anwendungen auf allen Geräten laufen.

Mr_Tee schrieb:
@MNagler
An Java kanns nicht liegen ;-)
Liegt es auch nicht, Java ist mehr als schnell genug dafür. Und wenn der Punkt Java wegfällt bleibt eben nur noch der Schuldige die Android-Platform, und dort die nötige Abstraktion um hunderte verschiedene Hardware-Profile zu unterstützen mit teilweise schlecht optimierten Treibern.
 
Zuletzt bearbeitet:
MNagler schrieb:
Ich habe beruflich viel mit Java zu tun und das kann sehr wohl elegant und schnell sein.

Uhh...also ich arbeite ebenfalls tagtäglich mit Java..und ja Java kann elegant und schnell sein - im Backend. Sobald es sich um UI und eventuell 3 Schichten Framework-Kram dreht, ist es dann aber vorbei. Habe in meiner Laufbahn schon mit allerhand Programmiersprachen zu tun gehabt, aber sobald man bei Java von der Konsole an echte GUIs wechselt hört der Spaß auf. Das Ende von Lied ist, dass Google da wieder seinen eigenen Mist drüber gezogen hat um die GUI zurendern und das das nicht unbedingt elegant oder schnell sein muss, habe sie mit GWT schon eindrucksvoll bewiesen (ja ich weiß, ist am Ende Javascript, aber du weißt worauf ich hinaus will).

Fazit:
Ein Objective C ohne Interpreter im Idealfall nativ auf Maschinencode reißt jedem Java GUI XY Framework über VM den Po bis zum Hals auf. Besonders wenn das Java-Framework von Google kommt. Das da noch mehr im Argen liegt möchte ich nicht ausschließen, dass Java nicht die richtige Wahl ist, aber auch nicht.

@Topic:
Also mich wundert es nicht. Wenn ich denn in die MobielApps Entwicklung einsteigen würde, dann ganz sicher mit iOS. Besserer AppStore -> bessere Positionierung meiner eigenen App, Support kann in Grenzen gehalten werden, ich kann im Bedarfsfall sogar alle möglichen, eingesetzten Geräte vorhalten und darauf testen (sehr wichtig, wenn es kommerziell wird), besserer Entwicklersupport, Testing ist quasi mit inbegriffen (Feedback durch die Appstore Zwerge), eine universal App läuft auf allen Geräten...ach ich könnte da den ganzen Tag weitermachen...
Ist ein bisschen so wie bei den Desktops. Ich will ne Software entwickeln, die mich wenig Aufwand kostet und sich einfach verbreiten lässt...dann entwickel ich sicher nicht für Linux, wo ich ja schon ca. 8 verschiedene Installer anbieten muss...
 
"Blackberry Tablets, Windows Phone? Und bada nicht. Bada hat schon doppelt so viel verkauft wie beide anderen zusammen. "

hab bada knapp 1,5 jahre verwendet, nebenbei noch android und jetzt mal was "neues" - wp7 und ich muss sagen, dass bada ein scheiss gegen wp7 ist. vom app-store und der stabilität brauch ma da gar net erst reden....
 
"Oberklasse der Samsung Galaxy Reihe" ist zahlenmässig ein witz zum gesamten android markt
Stimmt. Aber im Vergleich zu iOS eben nicht. Android ist nicht gleich Android - die einzige Gemeinsamkeit ist effektiv der Name. Diese Erkentnis muss sich so langsam mal durchsetzen.
Alleine durch TouchWiz und Sense ist es defakto ein anderes Betriebssystem. Insbesondere aus Sicht der GUI Entwicklung.
Und wie gesagt es war ein Beispiel. Du kannst dich auch auf Tegra, TI, Qualcomm sonst etwas beschränken.
Der einzige Unterschied zum aktuellen Stand ist doch nur das man klar sagt was Phase ist. Derzeit funktionieren Apps auf vielen Geräten einfach nicht oder nur schlecht. Kaufen kann man sie trotzdem.

Dann doch lieber direkt klar sagen: Diese App ist nur für Geräteklasse X.

Dann erklär mal deinem Kunden, deinem Chef oder sonstwem warum die Android-Applikation nur auf z.B. Samsung Galaxy Modellen läuft, und nicht auf dem Xperia des Sohnes deines Chefs.
Es interessiert niemanden, dass die Geräte leistungsschwächer sind oder weiß der Teufel, wenn du ein Android App bauen sollst, dann will man auch alle Android Geräte erreichen können und nicht nur einen Bruchteil dieser Menge.
Es geht hier nicht um die Sicht von BWLern sondern um die technische Sicht. Nicht die BWLer jammern, sondern die Devs und häufig vor allem die von kleinen Software-Klitschen.

Bauen wir Apps eben nicht für alle Modelle, sondern nur für einen kleinen Teil, muss der Kunde eben schauen, ob sein Modell unterstützt wird.
Ist doch jetzt schon der Fall. Mit dem Unterschied das der Kunde es nur am eigenen Leib merkt und nicht im Vorneherein merkt.
Wie gesagt: Es ist NICHT MÖGLICH alle Geräteklassen gleich zu unterstützen. Sonst würden wir immer noch alle single core armv11 nutzen.

Das wäre nicht nur eine Fragmentierung für Entwickler durch die Android-Platform, sondern auch eine Fragmentierung für den potentiellen Kunden - und DAS wäre das endgültige Aus für Android.
Aufwachen! Guck dir mal die EA Games im Android Store an. 3/4 davon sind auf einem Bruchteil der Geräte verfügbar. Ich besitze selber eines, insofern spreche ich da aus Erfahrung.
 
GrooveXT schrieb:
Fazit:
Ein Objective C ohne Interpreter im Idealfall nativ auf Maschinencode reißt jedem Java GUI XY Framework über VM den Po bis zum Hals auf. Besonders wenn das Java-Framework von Google kommt. Das da noch mehr im Argen liegt möchte ich nicht ausschließen, dass Java nicht die richtige Wahl ist, aber auch nicht.

Aber das liegt dann doch an dem schlechten GUI-Framework für Java bzw. Android. Nur das Objective-C direkt in Maschinencode übersetzt wird, macht noch keinen Unterschied. Aber Apple wird einige Jahre mehr Erfahrung haben, wie man ein gutes GUI-Framework konzipiert, als Google es hat.
Das ganze dürfte dann aber spätestens nicht mehr bei Spielen greifen, denn da gelten dann die OpenGL ES Schnittstellen, es seiden Google hat da etwas drüber gebastelt.

Mike Lowrey schrieb:
Es geht hier nicht um die Sicht von BWLern sondern um die technische Sicht. Nicht die BWLer jammern, sondern die Devs und häufig vor allem die von kleinen Software-Klitschen.
Richtig, aber wenn es eine "kleine Software-Klitsche" ist, die sich nicht versucht alleine durch eigene Apps für Android über Wasser zu halten (Gott bewahre), dann wird ebenso für Kunden gearbeitet. Und erkläre dem Kunden mal warum dein App nachher auf dem Samsung Galaxy Y Plus i9000 Advance blabla nicht funktioniert, welches der Sohn des Auftraggebers hat und da eben auch getestet wird.
Spätestens hier sieht es für die Firma nicht gut aus, entweder der Vertrag deckt ab, dass es auf allen Geräten laufen muss (aua), einige Geräte ausgeschlossen sind (und das war nicht dabei...) oder dem Kunden von vornerein gesagt wird, dass das App nur auf 5% aller Androids laufen wird, Geräte die mind. die Leistung eines Samsung Galxy S haben (wunderbar wenn eines dann zwar die Specs erfüllt aber die Umsetzung mies ist). Bei Punkt 3 wird noch vor Unterzeichnen des Vertrages der Kunde zur Konkurrenz gehen, die das dann verschweigen und dem Kunden nachher sonstwas erzählen.
Die aktuelle Situation bringt jeden Entwickler in echte Grenzsituationen.
Aus den Gründen lehne ich kategorisch jede Anfrage zur App-Entwicklung für Android ab, da kann irgendwer sonstwieviel zahlen wollen.
Es ist einfach eine Zumutung, und in den Griff bekommt man das Problem dann nur, wenn dutzende Testgeräte angeschafft werden, dieses Problem gab es schon einmal und nannte sich J2ME - Java für Handys. Google hat daraus nichts gelernt.

Mike Lowrey schrieb:
Ist doch jetzt schon der Fall. Mit dem Unterschied das der Kunde es nur am eigenen Leib merkt und nicht im Vorneherein merkt.
Wie gesagt: Es ist NICHT MÖGLICH alle Geräteklassen gleich zu unterstützen. Sonst würden wir immer noch alle single core armv11 nutzen.
Wenn die Abstraktion von Android gut ist und nicht zuviel Performance verschlingt müsste auch ein ARM11 für die meisten Dinge reichen, einzig aufwenige 3d Spiele oder andere besonders rechenintensive Dinge dürften dann an die Grenzen stoßen. Da aber im Hintergrund munter ein Facebook dauerhaft im Hintergrund laufen kann oder sonstwas stößt man eben auch mit einem ARM11 an die Grenzen, ein hausgemachtes Problem.
 
Zuletzt bearbeitet:
Und wenn schon über die hälfte alle Apps sind sowieso schwachsinn.
(Meine Meinung)
 
GeneralAnal schrieb:
Sieht eher so aus als fällt das Interesse jeweils leicht.
Ja, die Interpretation der Ergebnisse is mal wieder sehr reißerisch und könnte tatsächlich von einem Grundschüler stammen. Blackberry sackt in die Tiefe, alle Plattformen werden im Schnitt uninteressanter, aber Android, dass 2% mehr verloren hat als iOS (und prozentuell gesehn dürfte der Interessenverlust von Android wohl noch UNTER dem Durschnitt liegen, sprich es weniger verloren haben als der Durchschnitt), an dem macht man die Überschrift aus. Is nicht Euer Ernst? -.-' OMG

@Notch: Weil iOS "leicht" zu coden ist. Allerdings sind die Möglichkeiten auch sehr beschränkt verglichen mit Android. Weiters stehen die Sterne für Bezahl-Apps im Apple-Store wesentlich besser. Google Play suckt auf Grund der schlechten Bezahlmöglichkeiten. Is zu kompliziert... (Das is 'ne Tatsache, dass nicht jeder eine Kredikarte hat und sich auch nicht extra für ein paar 4,50€-Apps eine zulegen wird -auch keine verhältnismäßig schwer aufzutreibende Prepaid-Karte.) Zwanzig andere Market-Anbieter ändern daran auch nicht viel, weil deren Angebot nicht unbedingt so groß ist.

MfG, Thomas
 
MNagler schrieb:
...
Meiner Meinung liegt das auch nicht an Java, wie einige hier behaupten. Ich habe beruflich viel mit Java zu tun und das kann sehr wohl elegant und schnell sein. Das Android-SDK ist qualitativ einfach meilenweit unterlegen und das fällt bereits auf, lange bevor ich mir als Entwickler Gedanken über verschiedenen Auflösungen oder Geräte mache.

Ja das liegt nicht an Java sondern wenn ich mich nicht irre daran das der Apple Emulator eine x86 VM ist und die App für den Emulator als x86 Compiliert wird während die App wie sind ein den Appstore kommt natürlich für ARM Compiliert wird. Bei Android hingegen wird per QEMU eine ARM CPU emuliert was natürlich viel Leistung verschwendet. Bei den meisten Apps (alle die nur Java Verwenden und nicht nativer Code) wäre dies aber gar nicht nötig und eine VM mit einem x86 Android (habe ich selbst noch nicht Probiert, vor-allem die USB-Debugging Verbindung zum SDK könnte problematisch sein) könnte vielleicht eine interessante Alternative sein.
 
Zuletzt bearbeitet:
Mike Lowrey schrieb:
Stimmt. Aber im Vergleich zu iOS eben nicht.
da überschätzt du aber scheinbar die "samsung galaxy oberklasse" maßlos....oder du unterschätzt die ios zahlen.
Samsungs durchschnittlicher smartphone verkaufspreis dümpelt irgendwo bei 200€ rum, im letzten quartal (oder wars jahr?) haben sie 36 millionen smartphones gesamt verkauft, wenns gut läuft sind max ein drittel davon galaxys der oberklasse....dagegen stehen 37 millionen iphones, wenn man wohlwollend noch ipads aussen vor lässt.
Wobei apple dabei davor und vorletztes jahr deutlich mehr geräte abgesetzt hat wie samsung, der gesamtmarkt dürfte also ungleich größer sein den man hier erreicht.


@wer hat n vernünftiges ide
natürlich kein komplexer oder 100% sauberer vergleich aber man sieht schon wo grundsätzlich mehr aufwand betrieben werden muss und wo weniger (oder wer viel erfahrung mit ide erstellung hat und wer weniger).
http://www.youtube.com/watch?feature=player_embedded&v=OF5mGoKcm80
 
Zuletzt bearbeitet:
ice-breaker schrieb:
Die Frameworks kümmern sich um die Auflösung ;)
Aber eben nur, wenn du die Standard-UI-Elemente wie die TableViews usw. nimmst, willst du darüber hinaus etwas eigenes machen, musst du dich selbst um jede Auflösung kümmern.

Also kümmert sichs Framework eben nicht um die Skalierung entsprechend der Auflösung, genau wie ich sagte. Vollbild-Elemente zu skalieren ist keine Kunst.
 
Zurück
Oben