Welche Versionen?

Das sind ganz einfache Features und du kannst somit Android Geräte ab zb. 2.1 unterstützen dann deckst du bestimmt 99% des Marktes ab.

Schaust du auch hier

http://developer.android.com/about/dashboards/index.html

Zitat

Mit welchen Browsern kann ich garantiert kompatibel sein?

-> in android hast du die Möglichkeit einen Webview zu nutzen bzw. die aufgebohrte Variante den ChromeWebview
-> HTML5 , Javascript , CSS keine Probleme

Zitat von Juli

Welche eventuellen Schwierigkeit, die speziell bei Androit auftreten, muss ich noch bedenken, bevor ich mein Angebot an den Kunden mache?

Die Einarbeitung. Hier funktioniert NICHTS so wie auf iOS.
Gar nichts.

Oh, und verlasse dich auf den AVD-Emulator noch weniger als auf den iOS Simulator.

also ich würde für android 2.1 entwickeln und die support library nutzen und schon läuft alles glatt =)

Zitat von ChampS

also ich würde für android 2.1 entwickeln und die support library nutzen und schon läuft alles glatt =)

Also ich persönlich traue dieser Support Library ja so gar nicht über den Weg, aber das ist Geschmackssache.

Noch eine Kleinigkeit: alle Collections sind von Natur aus veränderlich. Das hat so seine Tücken.

Zitat

Also ich persönlich traue dieser Support Library ja so gar nicht über den Weg, aber das ist Geschmackssache.

Worauf fusst den diese Aussage ??? Hattest du schon mal Probleme mit der SupLib ?
Eigentlich kann man die Verwendnung nur jedem ans Herz legen, denn
wer hat schon Bock diverese Code-Base´s für 1 Projekt zu pflegen.

Zitat von killphil75

Worauf fusst den diese Aussage???

Auf meinen persönlichen Geschmack und meiner Abneigung gegen Cross Platform Gedöns.
Ersteres steht doch da.

Genau so wie ich es beispielsweise hasse unter 4.x keine ActionBar zur Verfügung zu haben rege ich mich tierisch darüber auf, unter 2.x wertvollen Platz durch eine ActionBar verschwendet zu sehen.

Zitat von killphil75

Eigentlich kann man die Verwendnung nur jedem ans Herz legen, denn wer hat schon Bock diverese Code-Base´s für 1 Projekt zu pflegen.

Ich. Einfach schon deshalb, weil das Look&Feel unter 2.x völlig anders ist als unter 4.x und ich nicht für beide Versionen ein und dieselbe App zur Verfügung stellen will.

Ich vergleiche Googles Politik am Beispiel der Support Library gern mit C++.
Ein Konzept, dass mal durchaus okay war (C/SDKv8) wird auf Grund der Dynamik der Sache um Notwendiges erweitert (C with Classes/Anpassung auf Tablets) und anschließend nur dank des Aufschreis von einzelnen Nutzern verschlimmbessert (pseudo-Objektorientierung/Aufwärtskompatibilität)

Wären sich alle Entwickler im Klaren darüber, dass 2.x auf den dazugehörigen Geräten ganz andere Bedienworkflows hat als 4.x auf den dazugehörigen Geräten, hätte es keine Support Library geben müssen.
Sollte ich irgendwann einmal mit Fragments arbeiten wollen, könnte sich meine Meinung diesbezüglich gegebenenfalls ändern.
Allerdings halte ich sie aktuell nur für einen faulen Kompromiss für die Tablets.
Richtig wäre, zwei komplett getrennte UIs zu haben und diese über dieselben Controller anzusteuern. Da aber Java mit MVC offenbar nicht so gut zurecht kommt (es gibt MVC Frameworks - wtf?) und Activities halt als einzelne von der Anwendung unabhängige Programmteile geplant waren, musste man sich für die Tablets was einfallen lassen. Ich habe zumindest noch keine Notwendigkeit für Fragments auf dem Phone gefunden. Sie kommen immer erst bei Tablets ins Gespräch.

Vermutlich werde ich die Support Library demnächst nutzen müssen, weil die Accessibility Möglichkeiten von 2.x ein Witz (a.k.a. schlicht nicht vorhanden) sind. Von freiem Willen kann hier aber wirklich nicht die Rede sein.

Insgesamt ist das alles nicht so sehr durchdacht, wenn du mich fragst. Das kann ja sogar M$ besser.

Hi,

Zitat

Wären sich alle Entwickler im Klaren darüber, dass 2.x auf den dazugehörigen Geräten ganz andere Bedienworkflows hat als 4.x auf den dazugehörigen Geräten,

mmhh kann ich irgendwie nicht wirklich nachvollziehen.
Hab jetzt ein Jahr lang ein Gerät mit Android 2.3 genutzt und seit ca. 2 Monaten nutze ich eins mit 4.1. Aber so wirklich was anderes ist es nicht klar sieht alles einwenig hübscher aus aber ne große Umstelltung bzw. umdenken bei bedinen gabs nicht.

Zitat

Ich. Einfach schon deshalb, weil das Look&Feel unter 2.x völlig anders ist als unter 4.x und ich nicht für beide Versionen ein und dieselbe App zur Verfügung stellen will.

Als privater Entwickler ist dieser Weg ja auch vollkommen ok aber als Unternehmen geht das garnicht.
Kein Kunde wird dir den Aufwand für die "zweite" App bezahlen.

Zitat

Richtig wäre, zwei komplett getrennte UIs zu haben und diese über dieselben Controller anzusteuern. Da aber Java mit MVC offenbar nicht so gut zurecht kommt (es gibt MVC Frameworks - wtf?) und Activities halt als einzelne von der Anwendung unabhängige Programmteile geplant waren, musste man sich für die Tablets was einfallen lassen.

Ja da muss ich dir zustimmen hätte man von Anfang an versucht beide Geräte abzudecken wäre dieser Weg richtig gewesen. Aber genau hier liegt der Knackpunkt Android war halt als Handy OS geplant und nicht als OS für Tablets.

Zitat

Vermutlich werde ich die Support Library demnächst nutzen müssen, weil die Accessibility Möglichkeiten von 2.x ein Witz (a.k.a. schlicht nicht vorhanden) sind. Von freiem Willen kann hier aber wirklich nicht die Rede sein.

Was meinst du dann mit "Accessibility"?

Um vieleicht noch was zur "Support Library":
Fragement und ActionBar sind immer die Hauptpunkte die genannt werden wenn es um diese Lib geh aber da ist noch viel mehr. Im UI Bereich wäre da noch die ViewPager, ein Konzept was sich unter 2.x nur sehr aufwendig sauber umsetzen läßt. Im Code-Bereich wäre zum Beispiel die vereinfachte Nutzung der Contentprovider für die eigene DB Implementierung zu nehnen.

Mfg Titus

@Lucas de Vil

du reitest die ganze Zeit auf UI Sachen rum, aber die SupportLib bietet bei weitem viel viel mehr.

http://developer.android.com/t…tras/support-library.html

Zitat

Genau so wie ich es beispielsweise hasse unter 4.x keine ActionBar zur
Verfügung zu haben rege ich mich tierisch darüber auf, unter 2.x
wertvollen Platz durch eine ActionBar verschwendet zu sehen.

häh ??? der Widerspruch in sich ... das verstehe ich jetzt nicht ... AB hast du doch unter 4.x ... obendrein du bist doch nicht zur Verwendung dieser Actionbar gezwungen, du bist doch bei GUI Gestaltung unter 2.x genauso frei wie unter 4.x ... -> Stichwort: Styles, Themes ect.

Zitat

Cross Platform Gedöns

nix mit Cross Platform - hier geht es lediglich um die unterstützung verschiedener Versionen/Revisionen ... die Platform Linux - Java Dalvik aka Android ist immer noch die selbe

Zitat

Sollte ich irgendwann einmal mit Fragments arbeiten wollen, könnte sich meine Meinung diesbezüglich gegebenenfalls ändern.

Allerdings halte ich sie aktuell nur für einen faulen Kompromiss für die Tablets.

Das ist etwas zu kurz gedacht, die Auflösungen der Handys nimmt zu bzw. gibt es ja auch Zwitter wie das Samsung Note,
Fragmente unterstützen dich halt wesentlich bei der besseren Nutzung der "Räume" welche größere Auflösungen bieten, indem sie mehr Flexibiltät mitbringen und die Kapselung (GUI/CODE) wesentlich transparenter machen. Das ganze mit herkömmlichen Views (für alle Varianten) zu coden ist ein Albtraum.

Zitat

Insgesamt ist das alles nicht so sehr durchdacht, wenn du mich fragst. Das kann ja sogar M$ besser.

<ironie an> deswegen laufen ja die alten Win95/Win98 Anwendungen noch so gut auf Win7 oder was </ironie aus>

Also Android ist ein Betriebssystem für mobile Platformen was sich in permanenter Entwicklung befindet, eben weil sich auch diese Platformen in einem wahnsinnigen Tempo verändern.
Da es kein geschlossenes System wie IOS ist und niemand die Hand auf der Hardware hat muss man halt damit leben das dies hier ein Prozess ist.... das weiss man aber bevor man Software für diese Platform anbietet

Ich bin froh das Android einiges tut um so kompatibel zu sein (Sup lib), bei meinem IPAd1 bekam ich letztens die lapidare Meldung .> du bekommst kein IO6 Update weil deine Platform nicht mehr unterstüzt wird -> einfach so. Ich hab "geschrien und geweint", aber es hat niemanden interessiert....

Titus
Acessibility ist die Nutzung des Smartphones für behinderte Menschen, vornehmlich Blinde.

Unter 2.x bin ich den Menu-Button gewöhnt, unter 4.x gibts den nicht mehr. (Das meinte ich mit 'dazugehöriger Hardware').

Klar, wenn man mit seinem Altgerät auf 4.x umstellt findet man erst mal keine Unterschiede. Von einem für 2.x konzipierten Gerät auf ein für 4.x konzipiertes Gerät jedoch schon.

Was die zahlenden Kunden angeht: die definitiv sichtbaren Unterschiede wie die Menubar in 4.x und den Menubutton in 2.x zu implementieren ist kein signifikanter Mehraufwand. Falls doch sollte man seine Profession überdenken.

'Vereinfachte Nutzung der Content Provider' heißt doch aber auch, dass man sie bereits unter 2.x ohne Support Library nutzen konnte. Nun ja, wenn sie es vereinfacht haben, umso besser.

killphil
Ja, ich reite auf den UI Sachen rum.
ViewPager, Gestures, alles UI Sachen.
Accessibility als non-UI habe ich bereits genannt, die Datenprovider sind eventuell auch interessant.
Ansonsten haben sie eine unglaublich geringe Anzahl an Systemdingen verbessert - das hätte auch in ein OS Update fließen können...
Ach nein, das Updaten ist ja so eine Sache, da jeder Depp sein eigenes ROM basteln darf. Da ist so eine Support Library der weniger elegante aber einfachere Weg: wälzen wir das Problem einfach an die Entwickler ab.

Wenn ich für 4.x und 2.x entwickeln will, dann will ich unter 4.x die Action Bar und unter 2.x eben nicht.
Bei allen Anwendungen habe ich entweder überall die Action Bar, weil das so mit der Support Library gemacht, oder nirgendwo, weil noch aus 2.x Zeiten. Das nervt mich.
Das meine ich mit Cross Platform: die Bedienung des Entgerätes hat sich komplett geändert, nur dadurch, dass eine Taste geändert wurde. Dadurch hat man trotz Android/Dalvik ein komplett anders Look'n'Feel. Es ist zwar nur im Detail komplett anders, aber dennoch komplett anders.

Ich sage auch nicht, dass Fragments per Definition Mist sind. Sondern dass sie ein lausiger Kompromiss zur Behebung eines früheren Designproblems darstellen.
Ihr Sinn ist schon erkennbar - dennoch mag ich sie gern vermeiden. Eben weil es sich wie eine Bastellösung anfühlt und ich aktuell nicht für Tablets entwickle. (hoffentlich nie, ich halte nix von den Dingern.)

Und hey, ich hab vor Kurzem erst Dungeon Keeper 2 auf dem Windows-7 Rechner meiner Freundin installiert. Abgesehen vom verzerrten Sound läuft das super.

Ja, es wird viel gearbeitet an Android.
(Sinnvolle Accessibility-Implementierung erst in 4.1, in 4.0.x war es zwar vorhanden doch für Blinde nahezu nicht einstellbar, 2.x hatte überhaupt gar nix und alles musste nachinstalliert werden.)
Spannenderweise wird bei Google nachgereicht während Apple vorausgedacht hat. Mal sehen, wie sich M$ so schlägt.

Und was das iPad 1 betrifft: das Ding ist einerseits hardwaretechnisch eine totale Krücke und ein Schnellschuss um auf dem Tabletmarkt Fuß zu fassen. Andererseits ist das Mistding 2,5 Jahre alt und ich bekomme jetzt schon kein 4.1 Update für mein Samsung Galaxy S2. (Ändert sich vielleicht noch, aber ungefähr 6 Monate auf die Anpassung eines Updates und die Freigabe zu warten... das nächste Gerät ist direkt von Google.)
Übrigens ist mit dem iPad 1 auch das iPhone 3G abgeschrieben - nach über 4 Jahren. Hier fasse ich deine Argumentation von vorhin auf:
iOS ist ein Betriebssystem für mobile Platformen was sich in permanenter Entwicklung befindet, eben weil sich auch diese Platformen in einem wahnsinnigen Tempo verändern. ARMv6 gibt es so gut wie gar nicht mehr, ARMv7 ist am Absterben und ARMv7S ist im Kommen. Um den Kompatibilitätsaufwand gering zu halten muss komplett inkompatibler alter Kram halt weichen.

Abgesehen davon hast du iOS 5.1, also mecker nich.
Die Jungs und Mädelz, die auf 4.2 stecken geblieben sind (iPhone 3G) haben Grund zu jammern, da mit dem neuen SDK nur iOS5 und iOS6 unterstützt werden können und kaum jemand sich die Mühe macht iOS <5 zu unterstützen.

Darüber, dass du auf deinem iPad keine neuen Anwendungen mehr lauffähig bekommen wirst, musst du dir frühestens in einem halben Jahr Gedanken machen.

Zugegebenermaßen bin ich auch ein bisschen melancholisch was Android betrifft. Damals™ zu G1 Zeiten, als der Neo Freerunner auf den Markt kam und tatsächlich auch ein Android-Port dafür erstellt wurde, da war Android toll. So neu, so aufregend, ein feines Linux-Gebastel. Ja, so war das anno 2008.
Nun ist es vier Jahre später, die aktuelle Android-Version für das Gerät ist die 2.1 und es ist noch immer ein heilloses Gebastel. (Display kann 640x480 Pixel, Grafikprozessor rennt am Besten mit 320x240 -> Android faktisch nicht nutzbar weil arschlangsam)
Und dann bekommt man ein Samsung Galaxy S2 und später ein HTC One V in die Hand gedrückt und fühlt sich an damals™ erinnert: reines Gebastel.
Das führt sich dann bis in das SDK fort...

Beispiele
Freerunner:
per dfu-util lustige Partitionen auf dem Gerät umherschieben, um ein System zu installieren.
unerklärliche sporadische Abstürze, weil irgendein Treiber nicht vernünftig implementiert wurde.
sporadisch funktionierendes WLAN abhängig von Mondphasen, mittlerem Hochwasserstand und der relativen Luftfeuchtigkeit in Kathmandu.

HTC/Samsung:
sporadisch ausfallende Netzwerkkonnektivität trotz WLAN-Verbindungssymbol und Pingbarkeit, durch erneuten Verbindungsaufbau zu beheben.
sporadisch ausfallende Netzwerkkonnektivität des mobilen Netzwerkes, durch Neustart zu beheben.
sporadisch ausfallender SMS-Empfang, durch Neustart zu beheben.

SDK:
ListView mit unterschiedlichen Anzeigen: Gebastel mit ViewHolder, da es ohne gern mal ruckelig lahm wird.
Liste mit unterschiedlichen Objekten: Gebastel mit irgendwelchen generischen Objekten oder Interfaces dank der dämlichen Typenbindung.
Persistieren von eigenen Objekten: Gebastel mit ORM-Frameworks, weil FileProcessing (XML z.B.) einfach mal arschlangsam ist.

@Lucas: Ok du hast mich überzeugt bzw. nach deinen ausführlichen Darlegungen kann ich deiner Argumentation besser folgen.

Obwohl ich mich bei den Fragmenten immer noch streiten würde, ich sehe die ja weniger als Design-Missgriff,
sondern eher das sie es versäumt haben die Activitys von vorherein flexibel zu gestalten... aber das ist jetzt auch Haarspalterei

Zitat

Acessibility ist die Nutzung des Smartphones für behinderte Menschen, vornehmlich Blinde.

Klingt so als hättest du in diesem Punkt einen konkreten Ansatz bzw Erfahrung. Das fehlt mir natürlich komplett und da verstehe ich deinen Einwand oder auch Ärger wenn Google einfach die Menütaste sterben bzw. an ganz anderer Stelle wieder auftauchen lässt. (v2.x vs 4.x)

Freut mich, dass ich Missverständnisse aus dem Weg räumen konnte.

Ja, im Punkt Accessibility habe ich neben einem konkreten Ansatz auch Erfahrungen, muss mich auf dem Gebiet nur in Android erst einmal tiefer einarbeiten.
Viele wissen halt nicht, dass Smartphones (sofern richtig konzipiert) Blinden das Leben unglaublich leicht machen können - beziehungsweise könnten, wenn man denn auch mal an diese denken würde.

Ich verfolge auch recht regelmäßig den Accessibility-Blog von Marco Zehe und seit kurzem speziell die Sektion über Android.

Ist meiner Meinung nach eine Lektüre und ein wenig Ausprobieren wert.
Vor Allem, wenn man einmal versucht, seinen täglichen Arbeitsablauf auf dem Gerät ohne hinzugucken zu bewältigen.
Da tun sich zwischen den mitgelieferten Standardapps und den nachinstallierten CustomApps Abgründe auf...

hi,

Zitat

Ich verfolge auch recht regelmäßig den Accessibility-Blog von Marco Zehe und seit kurzem speziell die Sektion über Android.

sieht interessant

mfg Titus