Soso, auf die Kompatibilität kommt es an

[stuempel]

Ich habe ja nur testweise Android auf mein TouchPad aufgespielt und muss sagen - die App-Rezensionen sprechen da aber eine völlig andere Sprache. An allen Ecken und Kanten unterirdisch, weil außer den Nexus-Besitzern scheinbar jeder in weiten Teilen mit Inkompatibilität zu kämpfen hat.

Sorry, aber solche Probleme sind mit als webOS-Nutzer genau wie Apple-Kunden nun einmal nur aus der Ferne bekannt ;)

[neocron]

inkompatibilitaeten gibt es nicht nur unter den Hersteller Varianten ...
diese gibt es sogar innerhalb der eigenen Vanilla Versionsreihen.
gleiche API aber leicht unterschiedliches Verhalten ...
ein Graus fuer Entwickler!

[RazorHail]

ich habe selten so einen schwachsinn gehört

98% der apps laufen auf 100% aller 'android' devices (mit android market pre-loaded)

die einzigen apps die probleme machen, sind spiele, und das liegt daran, dass die entwickler native code verwendet haben - welches dann natürlich nicht auf allen arm-chipsets gleich läuft

es gibt natürlich auch entwickler die eigenhändig den download ihrer apps für bestimmte geräte verbieten.
aus den verschiedensten gründen (copyright, localization, optimization, etc.)

[neocron]

RazorHail schrieb:
--------------------------------------------------------------------------------
> ich habe selten so einen schwachsinn gehört
>
> 98% der apps laufen auf 100% aller 'android' devices (mit android market
> pre-loaded)
da wuerde ich allein aufgrund eigener Erfahrung widersprechen!
hast du da zufaellig eine Quelle fuer?

Mit Sicherheit ist es nicht so drastisch wie im ersten Post dargestellt.
Das liegt aber in der Natur des Play Stores ...
ein immenser Anteil an "Apps" besteht lediglich aus Toenen, Bildern/Wallpapers" oder absolut trivialen Aufgaben (wie Webcontent anzeigen)!
Da wo es sofort schwieriger wird, ist zB. wo spezielle Netzwerkdienste noetig sind, oder spezielle Medien, oder wie du schon sagtest staerker optimierte Anwendungen (Spiele)

Man wird ja schon durch die Entwickler "geschuetzt" in dem Apps nur fuer bestimmte Geraete freigegeben werden.
Und denoch bemerkt man Probleme doch noch immer wieder! (zumindest ist dies bei mir so)

[ozelot012]

stuempel schrieb:
--------------------------------------------------------------------------------
> Ich habe ja nur testweise Android auf mein TouchPad aufgespielt und muss
> sagen - die App-Rezensionen sprechen da aber eine völlig andere Sprache. An
> allen Ecken und Kanten unterirdisch, weil außer den Nexus-Besitzern
> scheinbar jeder in weiten Teilen mit Inkompatibilität zu kämpfen hat.
>
> Sorry, aber solche Probleme sind mit als webOS-Nutzer genau wie
> Apple-Kunden nun einmal nur aus der Ferne bekannt ;)

Du sagst es. ;)

Bei Apple funktioniert es meistens. Wirklich ernsthafte Probleme hatte ich mit dieser Firma nie.

Ja ich weiß, das LTE im iPhone 5 ist verkappt.

[rabatz]

Kannst du für deinen hier geschriebenen Blödsinn auch Beispiele nennen oder hast du das nur wo aufgeschnappt?

[Suven]

RazorHail schrieb:
--------------------------------------------------------------------------------
> ich habe selten so einen schwachsinn gehört
>
> 98% der apps laufen auf 100% aller 'android' devices (mit android market
> pre-loaded)

Ich bin selbst kein Android-User, aber ich kann mir vorstellen, dass es bei Apps deren UI nicht gerade in XML geschrieben wurde bei den vielen verschiedenen Formaten und Auflösungen Probleme geben kann.

Dann hört man immerwieder von Apps die erst noch auf andere Architekturen portiert werden müssen. Ich glaube nicht dass sich das auf Spiele beschränkt. In sehr vielen Fällen, war einfach schon massigst C-Code vorhanden, den man nicht in Java neu schreiben möchte. Da weicht man eben auf native Apps um. Wenn ich mich recht entsinne war das beispielsweise auch beim Firefox so.

Dann hat nicht jedes Handy die selben Hardwarekomponenten verbaut. Da machen einige Apps dann schlicht auch keinen Sinn mehr.

Außerdem ist das OS-Splitting bei Android so groß, wie nirgends anders. Sehr viele User nutzen alte Android-Versionen, weil ihnen der Zugang zu neuen Version verwährt wird.

Das sind dann also schon 5 Faktoren die Apps technisch gesehen inkompatibel machen.



1 mal bearbeitet, zuletzt am 15.09.12 15:29 durch Suven.

[rabatz]

neocron schrieb:
--------------------------------------------------------------------------------
> RazorHail schrieb:
> ---------------------------------------------------------------------------
> -----
> > ich habe selten so einen schwachsinn gehört
> >
> > 98% der apps laufen auf 100% aller 'android' devices (mit android market
> > pre-loaded)
> da wuerde ich allein aufgrund eigener Erfahrung widersprechen!
> hast du da zufaellig eine Quelle fuer?
>
> Mit Sicherheit ist es nicht so drastisch wie im ersten Post dargestellt.
> Das liegt aber in der Natur des Play Stores ...
> ein immenser Anteil an "Apps" besteht lediglich aus Toenen,
> Bildern/Wallpapers" oder absolut trivialen Aufgaben (wie Webcontent
> anzeigen)!
Naja hier muss man sagen, dass es bei Android noch relativ wenige im Vergleich zu iOS gibt. Hier musss man sich sogar die Klingeltöne aus dem Store ziehen, weil man normale MP3s, die man schon gekauft hat nicht einfach ohne kompliziertes Herumgefrickel verwenden kann. Das ist den meisten zu blöd oder sie sind einfach überfordert und kaufen einen Song den sie schon besitzen dann nochmals als Klingelton. Das müllt den Store noch viel mehr zu als ein paar Themes und Wallpaper bei bei Android.

> Da wo es sofort schwieriger wird, ist zB. wo spezielle Netzwerkdienste
> noetig sind, oder spezielle Medien, oder wie du schon sagtest staerker
> optimierte Anwendungen (Spiele)
Komisch, dass ich damit noch nicht Probleme hatte, obwohl ich wirklich eine Vielzahl von Apps verwende.

> Man wird ja schon durch die Entwickler "geschuetzt" in dem Apps nur fuer
> bestimmte Geraete freigegeben werden.
> Und denoch bemerkt man Probleme doch noch immer wieder! (zumindest ist dies
> bei mir so)
siehe oben

Du bist echt ein komischer Kautz. beschwerst dich seit 2 Jahren über die Unzulänglichkeiten von Android und Samsung und hast trotzdem mindestens schon das 4. Android-Gerät von Samsung. Kauf dir doch endlich mal ein iDevice, wenn du doch Apple ohnehin überall in Schutz nimmst.

[neocron]

Die Nutzung von handler.proceed(...,...) in
onReceivedHttpAuthRequest () resultiert in Android 4.x darin, dass die Authentifizierungsdaten gespeichert werden. Jeder folgende HTTP Request des WebClients wird diese nutzen um weitere Elemente der Page zu laden.
Unter 2.2 geschieht dies nicht!
Der behandelte Request wird erfolgreich Authentifiziert, jeder weitere, jedoch, fuehrt wiederum zum Ausloesen des onReceivedHttpAuthRequest ( ), auch wenn die mitgegebenen Daten korrekt waren!

Ein Socket.close( ), welcher zB. in der Telnet Implementierung in Apache Commons Net genutzt wird erzwingt im Android 4.x jegliche stehende "read" Operationen auf dem StocketInputStream zu beenden und somit die entsprechenden Threads zu schliessen!
Unter Android 2.2 jedoch geschieht dies nicht!
Dort wird close( ) geblockt, notfalls unendlich lange, bis die "read" Operation beendet wurde!

In beiden faellen erhaelt man unterschiedilche Verhalten ein und des selben Codes (bzw. resultierenden APKs)!

[rabatz]

Suven schrieb:
--------------------------------------------------------------------------------
> RazorHail schrieb:
> ---------------------------------------------------------------------------
> -----
> > ich habe selten so einen schwachsinn gehört
> >
> > 98% der apps laufen auf 100% aller 'android' devices (mit android market
> > pre-loaded)
>
> Ich bin selbst kein Android-User, aber ich kann mir vorstellen, dass es bei
> Apps deren UI nicht gerade in XML geschrieben wurde bei den vielen
> verschiedenen Formaten und Auflösungen Probleme bestehen können.
Layout in XML oder in Java macht bei Android vom Ergebnis her nahezu keinen Unterschied. XML ist eben eleganter und schöner getrennt und daher sauberer.

> Dann hat nicht jedes Handy die selben Hardwarekomponenten verbaut. Da
> machen einige Apps dann schlicht auch keinen Sinn mehr.

Naja gute Apps können sich fast an jede Gegebenheit anpassen. Hatte schon 4 Androiden und noch nie wirkliche Probleme in dieser Hinsicht

> Außerdem ist das OS-Splitting bei Android so groß, wie nirgends anders.
> Sehr viele User nutzen alte Android-Versionen, weil ihnen der Zugang zu
> neuen Version verwährt wird.

Das Problem wird hochgespielt. Klar bei Sicherheitsupdates ist es ein Problem. Von den Features eher kaum, da viele Neuerungen oft durch eine Support-Library auch für ältere Versionen verfügbar gemacht werden können. Die Fragment-API ist hier ein schönes Beispiel. Diese wurde unter Honeycomb eingeführt und konnte durch die Support-Library auch unter Gingerbread verwendet werden und hat dort bis auf ein paar Details gleich funktioniert. Also von der Funktionalität sind Updates eher unkritisch.

[neocron]

rabatz schrieb:
--------------------------------------------------------------------------------
> neocron schrieb:
> ---------------------------------------------------------------------------
> -----
> > RazorHail schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > ich habe selten so einen schwachsinn gehört
> > >
> > > 98% der apps laufen auf 100% aller 'android' devices (mit android
> market
> > > pre-loaded)
> > da wuerde ich allein aufgrund eigener Erfahrung widersprechen!
> > hast du da zufaellig eine Quelle fuer?
> >
> > Mit Sicherheit ist es nicht so drastisch wie im ersten Post dargestellt.
> > Das liegt aber in der Natur des Play Stores ...
> > ein immenser Anteil an "Apps" besteht lediglich aus Toenen,
> > Bildern/Wallpapers" oder absolut trivialen Aufgaben (wie Webcontent
> > anzeigen)!
> Naja hier muss man sagen, dass es bei Android noch relativ wenige im
> Vergleich zu iOS gibt. Hier musss man sich sogar die Klingeltöne aus dem
> Store ziehen, weil man normale MP3s, die man schon gekauft hat nicht
> einfach ohne kompliziertes Herumgefrickel verwenden kann. Das ist den
> meisten zu blöd oder sie sind einfach überfordert und kaufen einen Song den
> sie schon besitzen dann nochmals als Klingelton. Das müllt den Store noch
> viel mehr zu als ein paar Themes und Wallpaper bei bei Android.
wer hat hier von "zumuellen" gesprochen?
oder von Apple?
Es ging doch nur um die Kompatibilitaet der Applikationen zu verschiedenen Android Geraeten!?
Wie kommst du jetzt bitte auf den Apple Store oder Itunes, oder Klingeltoene auf dem iPhone?

> > Da wo es sofort schwieriger wird, ist zB. wo spezielle Netzwerkdienste
> > noetig sind, oder spezielle Medien, oder wie du schon sagtest staerker
> > optimierte Anwendungen (Spiele)
> Komisch, dass ich damit noch nicht Probleme hatte, obwohl ich wirklich eine
> Vielzahl von Apps verwende.
dann liest du anscheinend die Bewertungen der Applikationen nicht ...
Auch wenn es bei dir "problemlos" laeuft, zeugen Kommentare der Nutzer nicht selten von Kompatibilitaetsproblemen!

>
> > Man wird ja schon durch die Entwickler "geschuetzt" in dem Apps nur fuer
> > bestimmte Geraete freigegeben werden.
> > Und denoch bemerkt man Probleme doch noch immer wieder! (zumindest ist
> dies
> > bei mir so)
> siehe oben
siehe oben!

>
> Du bist echt ein komischer Kautz. beschwerst dich seit 2 Jahren über die
> Unzulänglichkeiten von Android und Samsung und hast trotzdem mindestens
> schon das 4. Android-Gerät von Samsung. Kauf dir doch endlich mal ein
> iDevice, wenn du doch Apple ohnehin überall in Schutz nimmst.
muss es wieder um mich gehen?
ist es so schwer fuer dich einfach beim Thema zu bleiben?
Was soll das bitte?

[rabatz]

Beide Beispiele sind Fremdlibraries die im OS mitgeliefert werden.
Hier hat sich also entweder die Library selbst oder die Konfiguration dieser geändert. Vor allem hat sich der Komfort in beiden Beispielen für den Entwickler eher erhöht. Wenn du also die App für 2.2 geschrieben hast, wird sie sich in 4.0 auch noch genauso funktionieren, obwohl man sie unter 4.0 schon einfacher schreiben könnte. Dass eine App die man unter 4.0 entwickelt hat nicht unbedingt unter 2.2 genauso funktioniert, würde ich ohnehin nicht voraussetzen. Alles andere wäre Humbug.
Im übrigen: wenn du ein C-Programm schreibst und mit einer anderen Compilerversion übersetzt, kannst du auch nicht davon ausgehen, dass alles genauso funktioniert. Es ist eher die Regel, dass es nicht so ist.

[Suven]

rabatz schrieb:
--------------------------------------------------------------------------------
> Suven schrieb:
> ---------------------------------------------------------------------------
> -----
> > RazorHail schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > ich habe selten so einen schwachsinn gehört
> > >
> > > 98% der apps laufen auf 100% aller 'android' devices (mit android
> market
> > > pre-loaded)
> >
> > Ich bin selbst kein Android-User, aber ich kann mir vorstellen, dass es
> bei
> > Apps deren UI nicht gerade in XML geschrieben wurde bei den vielen
> > verschiedenen Formaten und Auflösungen Probleme bestehen können.
> Layout in XML oder in Java macht bei Android vom Ergebnis her nahezu keinen
> Unterschied. XML ist eben eleganter und schöner getrennt und daher
> sauberer.

Kern der Aussage zielte gerade auf Apps ab die viele Grafiken verwenden und so ihr eigenes LAF bieten. Die sind dann schlicht in einer falschen Auflösung vorliegend und so nicht mehr so aussehen können wie der Entwickler sich das gedacht und auch durchgetestet hat... Es gibt Menschen die wollen das etwas sehr gut und nicht nur irgendwie funktioniert.

> > Dann hat nicht jedes Handy die selben Hardwarekomponenten verbaut. Da
> > machen einige Apps dann schlicht auch keinen Sinn mehr.
>
> Naja gute Apps können sich fast an jede Gegebenheit anpassen. Hatte schon 4
> Androiden und noch nie wirkliche Probleme in dieser Hinsicht

So ein Schwachsinn. Wenn ich eine Foto-App habe, dann macht die App keinen Sinn wenn du keine Kamera verbaut hast. Eine NFC-App macht ohne NFC keinen Sinn. So ist das nunmal. Ist keine Kritik ans OS, aber schlicht ein weiteres Beispiel für inkompatible Apps.



2 mal bearbeitet, zuletzt am 15.09.12 15:46 durch Suven.

[neocron]

rabatz schrieb:
--------------------------------------------------------------------------------
> Suven schrieb:
> ---------------------------------------------------------------------------
> -----
> > RazorHail schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > ich habe selten so einen schwachsinn gehört
> > >
> > > 98% der apps laufen auf 100% aller 'android' devices (mit android
> market
> > > pre-loaded)
> >
> > Ich bin selbst kein Android-User, aber ich kann mir vorstellen, dass es
> bei
> > Apps deren UI nicht gerade in XML geschrieben wurde bei den vielen
> > verschiedenen Formaten und Auflösungen Probleme bestehen können.
> Layout in XML oder in Java macht bei Android vom Ergebnis her nahezu keinen
> Unterschied. XML ist eben eleganter und schöner getrennt und daher
> sauberer.
wieso ist dies "eleganter" oder sauberer?
obendrein ist dies auch nicht gerade resourcenschonend ... weshalb Google selbst Umleitungen anbietet um dessen entgegen zu wirken! (siehe zB. convertview)

>
> > Dann hat nicht jedes Handy die selben Hardwarekomponenten verbaut. Da
> > machen einige Apps dann schlicht auch keinen Sinn mehr.
>
> Naja gute Apps können sich fast an jede Gegebenheit anpassen. Hatte schon 4
> Androiden und noch nie wirkliche Probleme in dieser Hinsicht
natuerlich nicht ...
aus irgend einem Grund trifft es dich nicht ... und nur die anderen, die sich dann in den jeweiligen App-Reviews zeigen!

>
> > Außerdem ist das OS-Splitting bei Android so groß, wie nirgends anders.
> > Sehr viele User nutzen alte Android-Versionen, weil ihnen der Zugang zu
> > neuen Version verwährt wird.
>
> Das Problem wird hochgespielt. Klar bei Sicherheitsupdates ist es ein
> Problem. Von den Features eher kaum, da viele Neuerungen oft durch eine
> Support-Library auch für ältere Versionen verfügbar gemacht werden können.

> Die Fragment-API ist hier ein schönes Beispiel. Diese wurde unter Honeycomb
> eingeführt und konnte durch die Support-Library auch unter Gingerbread
> verwendet werden und hat dort bis auf ein paar Details gleich funktioniert.
> Also von der Funktionalität sind Updates eher unkritisch.
Wie gut funktioniert die? ich habe auch schon ueberlegt diese zu nutzen, hab mich aber bisher nicht durchgerungen!?
Gerade fuer die Fragment-API waere es hilfreich!

[Suven]

neocron schrieb:
--------------------------------------------------------------------------------
> rabatz schrieb:
> ---------------------------------------------------------------------------
> -----
> > Suven schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > RazorHail schrieb:
> > >
> >
> ---------------------------------------------------------------------------
>
> >
> > > -----
> > > > ich habe selten so einen schwachsinn gehört
> > > >
> > > > 98% der apps laufen auf 100% aller 'android' devices (mit android
> > market
> > > > pre-loaded)
> > >
> > > Ich bin selbst kein Android-User, aber ich kann mir vorstellen, dass
> es
> > bei
> > > Apps deren UI nicht gerade in XML geschrieben wurde bei den vielen
> > > verschiedenen Formaten und Auflösungen Probleme bestehen können.
> > Layout in XML oder in Java macht bei Android vom Ergebnis her nahezu
> keinen
> > Unterschied. XML ist eben eleganter und schöner getrennt und daher
> > sauberer.
> wieso ist dies "eleganter" oder sauberer?
> obendrein ist dies auch nicht gerade resourcenschonend ... weshalb Google
> selbst Umleitungen anbietet um dessen entgegen zu wirken! (siehe zB.
> convertview)

Wo immer man native Nutzerelemente nutzen kann, sollte man das tun, klar. Aber es gibt natürlich Situationen bei denen man eigene/platsparendere/whatever Elemente benötigt.
Schau dir mal die Top 10 der Bezahl- und die Top 10 der kostenlosen Apps an und sag mir, wieviele von denen ausschließlich native Bedienelemente nutzen... (Tun im übrigen [sinvoller Weise] auch schon die Google Apps nicht: z.B. Maps oder der Music-Player)

Edit:/ Ach ich war garnicht gemeint.. Da bin ich wohl in den Zitatleveln durcheinander geraten ;)



1 mal bearbeitet, zuletzt am 15.09.12 15:55 durch Suven.

[neocron]

rabatz schrieb:
--------------------------------------------------------------------------------
> Beide Beispiele sind Fremdlibraries die im OS mitgeliefert werden.
Seit wann ist
WebViewClient eine Fremdlibrary?
Und es ist sogar egal wo sie her kommen!
Fakt ist, der gleiche code verursacht unterschiedliches Verhalten!
dabei ist egal ob ich den Code geschrieben habe, oder drittanbieter!
Sie nutzen die selbe API, die sowohl in 2.2 als auch 4.x besteht!

> Hier hat sich also entweder die Library selbst oder die Konfiguration
> dieser geändert.
nein, es ist egal ob eine drittlibrary unterschiedliches verhalten im System ausfuehrt oder mein Code!
fakt ist: Unterschiedliche Systeme, gleicher Code -> unterschiedliches verhalten!
darum geht es!

> Vor allem hat sich der Komfort in beiden Beispielen für
> den Entwickler eher erhöht.
Wieso das? Der entwickler muss ueberhaupt ersteinmal herausfinden, welcher TEIL des Codes denn tatsaechlich unterschiedilches Verhalten aufweist!
Und er muss dafuer ein Workaround schaffen, welches auf beiden systemen das gleiche Verhalten implementiert! Ergo-> Mehraufwand!

> Wenn du also die App für 2.2 geschrieben hast,
> wird sie sich in 4.0 auch noch genauso funktionieren, obwohl man sie unter
> 4.0 schon einfacher schreiben könnte.
Es aendert nichts daran, dass gleiche APIs unterschiedliche Funktionen aufweisen!
Und das ist hinderlich!

> Dass eine App die man unter 4.0
> entwickelt hat nicht unbedingt unter 2.2 genauso funktioniert, würde ich
> ohnehin nicht voraussetzen.
natuerlich nicht, es wird stets in der kleineren Version entwickelt!
Nur nimmt man dann auch an, dass zB. ein close() das gleiche macht, wie close() in der hoeheren API version!

> Alles andere wäre Humbug.
richtig, in hoeherer Version zu entwickeln waere problematisch!

> Im übrigen: wenn du ein C-Programm schreibst und mit einer anderen
> Compilerversion übersetzt, kannst du auch nicht davon ausgehen, dass alles
> genauso funktioniert. Es ist eher die Regel, dass es nicht so ist.
Ich benutze keinen anderen Compiler ... ich benutze die gleiche API!
Abwaertskompatibilitaet wird genau dadurch geschaffen, dass gleiche APIs auch gleiche Funktionen aufweisen (egal ob sie unterschiedlich implementiert sind).
Es geht nur um Systemtransparenz, welche hier nicht vollends geschaffen wurde!
Wie gesagt, es sind Beispiele, die mir bereits aufgefallen sind, und meine Entwicklungsarbeit auf Android ist bei weitem nicht so ausgiebig wie bei anderen!
wie ich sagte gilt dies auch hauptsaechlich in bestimmten Bereichen, die nur kleine Teile der Apps benoetigen! Denoch aergerlich, wenn man des oefteren Workarounds suchen muss ...
RTP waere zB. das naechste!
Wobei dort die Moeglichkeiten der API die Arbeit einschraenken, und nicht die Unterschiede in den APIs!



1 mal bearbeitet, zuletzt am 15.09.12 16:12 durch neocron.

[rabatz]

neocron schrieb:
--------------------------------------------------------------------------------
> rabatz schrieb:
> ---------------------------------------------------------------------------
> -----
> > Suven schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > RazorHail schrieb:
> > >
> >
> ---------------------------------------------------------------------------
>
> >
> > > -----
> > > > ich habe selten so einen schwachsinn gehört
> > > >
> > > > 98% der apps laufen auf 100% aller 'android' devices (mit android
> > market
> > > > pre-loaded)
> > >
> > > Ich bin selbst kein Android-User, aber ich kann mir vorstellen, dass
> es
> > bei
> > > Apps deren UI nicht gerade in XML geschrieben wurde bei den vielen
> > > verschiedenen Formaten und Auflösungen Probleme bestehen können.
> > Layout in XML oder in Java macht bei Android vom Ergebnis her nahezu
> keinen
> > Unterschied. XML ist eben eleganter und schöner getrennt und daher
> > sauberer.
> wieso ist dies "eleganter" oder sauberer?
> obendrein ist dies auch nicht gerade resourcenschonend ... weshalb Google
> selbst Umleitungen anbietet um dessen entgegen zu wirken! (siehe zB.
> convertview)

Eleganter uns sauberer deswegen, weil man die Attribute der View eben in einem eigenen XML-File erstelllen kann. Dieses File könntest du auch von einem Designer gestalten lassen, der gar keine Ahnung von Java hat.

> >
> > > Dann hat nicht jedes Handy die selben Hardwarekomponenten verbaut. Da
> > > machen einige Apps dann schlicht auch keinen Sinn mehr.
> >
> > Naja gute Apps können sich fast an jede Gegebenheit anpassen. Hatte schon
> 4
> > Androiden und noch nie wirkliche Probleme in dieser Hinsicht
> natuerlich nicht ...
> aus irgend einem Grund trifft es dich nicht ... und nur die anderen, die
> sich dann in den jeweiligen App-Reviews zeigen!

Da kann aber Android selbst in den seltensten Fällen etwas dafür. Meistens liegt es daran, dass die Hersteller wieder einmal Inkompatiblitäten durch die eigenen Anpassungen eingebaut haben.

> >
> > > Außerdem ist das OS-Splitting bei Android so groß, wie nirgends
> anders.
> > > Sehr viele User nutzen alte Android-Versionen, weil ihnen der Zugang
> zu
> > > neuen Version verwährt wird.
> >
> > Das Problem wird hochgespielt. Klar bei Sicherheitsupdates ist es ein
> > Problem. Von den Features eher kaum, da viele Neuerungen oft durch eine
> > Support-Library auch für ältere Versionen verfügbar gemacht werden
> können.
>
> > Die Fragment-API ist hier ein schönes Beispiel. Diese wurde unter
> Honeycomb
> > eingeführt und konnte durch die Support-Library auch unter Gingerbread
> > verwendet werden und hat dort bis auf ein paar Details gleich
> funktioniert.
> > Also von der Funktionalität sind Updates eher unkritisch.
> Wie gut funktioniert die? ich habe auch schon ueberlegt diese zu nutzen,
> hab mich aber bisher nicht durchgerungen!?
> Gerade fuer die Fragment-API waere es hilfreich!

Prinzipiell funktioniert alles wie nur bei Activities. Die Activity ist dann meist nur noch eine Zwischenschicht und die meiste Logik verlagert man ins Fragment. Fragments selbst kann man dann einfacher wiederverwenden, was bei hirarchischen Listen oder ähnlichem sehr hilfreich ist. Es ist alles ein bisschen komplizierter aber der Benefit macht das meiner Meinung nach wieder wett.
Bis jetzt hatte ich noch nichts gefunden, was mit der Support Library nicht funktioniert hat. Man muss halt immer brav alles von der Support-Library importieren anstatt von der "normalen" API.

[neocron]

rabatz schrieb:
--------------------------------------------------------------------------------
> > wieso ist dies "eleganter" oder sauberer?
> > obendrein ist dies auch nicht gerade resourcenschonend ... weshalb
> Google
> > selbst Umleitungen anbietet um dessen entgegen zu wirken! (siehe zB.
> > convertview)
>
> Eleganter uns sauberer deswegen, weil man die Attribute der View eben in
> einem eigenen XML-File erstelllen kann. Dieses File könntest du auch von
> einem Designer gestalten lassen, der gar keine Ahnung von Java hat.
Wuerdest du also Stuetzraeder auch als "elegant" bezeichnen?
Es ist also eher ein Vereinfachungswerkzeug!

> > >
> > > > Dann hat nicht jedes Handy die selben Hardwarekomponenten verbaut.
> Da
> > > > machen einige Apps dann schlicht auch keinen Sinn mehr.
> > >
> > > Naja gute Apps können sich fast an jede Gegebenheit anpassen. Hatte
> schon
> > 4
> > > Androiden und noch nie wirkliche Probleme in dieser Hinsicht
> > natuerlich nicht ...
> > aus irgend einem Grund trifft es dich nicht ... und nur die anderen, die
> > sich dann in den jeweiligen App-Reviews zeigen!
>
> Da kann aber Android selbst in den seltensten Fällen etwas dafür. Meistens
> liegt es daran, dass die Hersteller wieder einmal Inkompatiblitäten durch
> die eigenen Anpassungen eingebaut haben.
richtig, darum ging es doch auch! Genau das sagten doch die Vorredner schon?

>
> > >
> > > > Außerdem ist das OS-Splitting bei Android so groß, wie nirgends
> > anders.
> > > > Sehr viele User nutzen alte Android-Versionen, weil ihnen der Zugang
> > zu
> > > > neuen Version verwährt wird.
> > >
> > > Das Problem wird hochgespielt. Klar bei Sicherheitsupdates ist es ein
> > > Problem. Von den Features eher kaum, da viele Neuerungen oft durch
> eine
> > > Support-Library auch für ältere Versionen verfügbar gemacht werden
> > können.
> >
> > > Die Fragment-API ist hier ein schönes Beispiel. Diese wurde unter
> > Honeycomb
> > > eingeführt und konnte durch die Support-Library auch unter Gingerbread
> > > verwendet werden und hat dort bis auf ein paar Details gleich
> > funktioniert.
> > > Also von der Funktionalität sind Updates eher unkritisch.
> > Wie gut funktioniert die? ich habe auch schon ueberlegt diese zu nutzen,
> > hab mich aber bisher nicht durchgerungen!?
> > Gerade fuer die Fragment-API waere es hilfreich!
>
> Prinzipiell funktioniert alles wie nur bei Activities. Die Activity ist
> dann meist nur noch eine Zwischenschicht und die meiste Logik verlagert man
> ins Fragment. Fragments selbst kann man dann einfacher wiederverwenden, was
> bei hirarchischen Listen oder ähnlichem sehr hilfreich ist. Es ist alles
> ein bisschen komplizierter aber der Benefit macht das meiner Meinung nach
> wieder wett.
Als ich mit meinen Applikationen anfing waren Fragments neu und nur den Tablets vorbehalten, und ich habe diese wegen der damals nicht vorhandenen abwaertskompatibiltaet nicht genutzt.
Nun schiebe ich das "porten" etwas vor mir her :D

> Bis jetzt hatte ich noch nichts gefunden, was mit der Support Library nicht
> funktioniert hat. Man muss halt immer brav alles von der Support-Library
> importieren anstatt von der "normalen" API.
hmmm ok danke. Ich denke ich schau es mir bei gelegenheit mal an, so viele Activities sind es zum Glueck nicht!

[rabatz]

neocron schrieb:
--------------------------------------------------------------------------------
> rabatz schrieb:
> ---------------------------------------------------------------------------
> -----
> > > wieso ist dies "eleganter" oder sauberer?
> > > obendrein ist dies auch nicht gerade resourcenschonend ... weshalb
> > Google
> > > selbst Umleitungen anbietet um dessen entgegen zu wirken! (siehe zB.
> > > convertview)
> >
> > Eleganter uns sauberer deswegen, weil man die Attribute der View eben in
> > einem eigenen XML-File erstelllen kann. Dieses File könntest du auch von
> > einem Designer gestalten lassen, der gar keine Ahnung von Java hat.
> Wuerdest du also Stuetzraeder auch als "elegant" bezeichnen?
> Es ist also eher ein Vereinfachungswerkzeug!

Naja nicht nur! Ein als Baum strukturiertes XML ist weitaus schöner und leserlicher als eine Reihe von Java-Settern.

[chrulri]

Du benutzt nicht die gleiche API. Du benutzt vielleicht die gleiche API im Sinne von du rufst die gleichen Klassen und Methoden auf. Jedoch hast du im einten Falle die API-8 im anderen Fall die API-14/15. Das einzige was gleich bleibt ist die Signatur.
Man könnte auch bei jedem Change innerhalb der API eine neue Signatur hinbasteln (Methoden/Klassen umbenennen) wenn dir das lieber ist. Jedoch kriegst du dann ganz viele "NoDefClassFoundError" und ähnliches weil die Signatur nicht aufgelöst werden kann. Einzige Alternative dabei: Reflection (siehe Beispiel unten)

Mit einer neuen API Version kann sich also auch bekanntes Verhalten ändern.
Ich finde es gut, dass die API mit neuern Versionen optimiert / verbessert wird. Auch wenn man deshalb für ältere Versionen teilweise einen Workaround programmieren muss.

Ein Beispiel für einen solchen Workaround (Signaturwechsel) kann ich dir sogar liefern: https://github.com/chrulri/droidawake/blob/master/src/com/chrulri/droidawake/CompatService.java
Hintergrund: http://developer.android.com/reference/android/app/Service.html#startForeground(int, android.app.Notification) gibt es ab API-5. Für APIs <5 hiess die Methode dazu "setForeground(..)".

Das Problem ist hier nicht die API, sondern der Wunsch des Entwicklers (in diesem Fall: Ich) abwärtskompatibel zu sein.
Zum Glück steigen die API-14+ Anteile stetig.