Beiträge von Marco Feltmann

Zitat von masa

falls jemand mal das Problem hat, hier die Lösung:

Das ist schön, sieht mir allerdings nicht nach der sondern schlicht nach einer Lösung aus.

Du löst einfach eine im Webserver eingebaute Browserweiche für den Firefox Version 4.0 unter X11 aus, mehr nicht.
Sobald die NBA der Meinung ist, den Support für Firefox 4.0 zu droppen, hast du dieselben Probleme wieder.

jm2c

Darf er denn Pakete aus unbekannten Quellen ausführen?

Du musst deine layout.xml anpassen.

Dein ListView hat ja jetzt irgend eine ID, nämlich R.id.listViewFlaschen.
(Also: <ListView android:id="@+id/listViewFlaschen" ...)

Die ListActivity verlässt sich auf ein ListView mit ID android.R.id.list.
Diese musst du ihm einfach in der XML geben.
(Also: <ListView android:id="@android:id/list" ...)

Tja, ich hätte da gern mal wieder ein Problem.

Grundlage der Datenhaltung sind XML Dokumente kodiert als UTF-8.
Diese lese ich ein, packe sie via greenDAO in eigene persistente Objekte und stelle sie dann dar.

Lustig:

Android 4.0.3 sagt:

Zitat

5 am Tag sorgt für gesunden Spaß
Öffentliche Pflanzaktion von Rosen
Gartenwelt und Rosenträume

Android 2.3.5 sagt:

Zitat

5 am Tag sorgt f
Ö
Gartenwelt und Rosentr

Gibt es irgendwelche Unterschiede im Handling von XML bei den unterschiedlichen Versionen, so dass ich unter 2.3 ein anderes Ergebnis bekomme als unter 4.0?

Der XML Parser basiert komplett auf java.io, java.xml, org.xml.sax und org.w3c.dom, es ist also nichts dabei, dass ich als unsupporteten Drittherstellerkrams ansehen würde...

Für sachdienliche Hinweise bin ich dankbar.

+hm+
Kann es sein, dass dein Desktop-Browser einen integrierten RSS-Reader hat, dein mobiler Browser allerdings nicht?

Viele RSS-Feeds werden über das http:// Protokoll angesteuert, der von dir angegebene steuert allerdings das feed:// Protokoll an.
(Zumindest auf meinem Desktop Browser)
Und dieses Protokoll muss jetzt nicht zwingend von jedem unterstützt werden.

Schau mal, ob du die URL auch mit feed:// gebaut bekommst.

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

Du kannst via android.os.Build.VERSION.SDK_INT abfragen, welche SDK Version du gerade hast.
Beispielsweise kannst du so einfach switchen und die ContentViews entsprechend setzen.

if(android.os.Build.VERSION.SDK_INT >= 16)
{
    setContentView(R.layout.activity_layout_jellybean);
}
else if(android.os.Build.VERSION.SDK_INT >= 14)
{
    setContentView(R.layout.activity_layout_ics);
}
else if(android.os.Build.VERSION.SDK_INT >= 11)
{
    setContentView(R.layout.activity_layout_honeycomb);
}
else if(android.os.Build.VERSION.SDK_INT >= 9)
{
    setContentView(R.layout.activity_layout_gingerbread);
}
else if(android.os.Build.VERSION.SDK_INT == 8)
{
    setContentView(R.layout.activity_layout_froyo);
}
else if(android.os.Build.VERSION.SDK_INT >= 5)
{
    setContentView(R.layout.activity_layout_eclair);
}
else if(android.os.Build.VERSION.SDK_INT == 4)
{
    setContentView(R.layout.activity_layout_donut);
}
else if(android.os.Build.VERSION.SDK_INT == 3)
{
    setContentView(R.layout.activity_layout_cupcake);
}
else
{
    setContentView(R.layout.activity_layout_base);
}

Das Theming übernimmt ja auch deine Layoutdatei.
Nur wenn du die Layouts so unterschiedlich gestaltest, dass du auch unterschiedliche Activities zur Ansteuerung benötigst, wird das Ganze ausgesprochen spaßig.

Soll das als so eine Art Bannerwerbung da drunter kleben?
Da würde ich vermutlich versuchen, das Ding als Fragment zu implementieren und dann entsprechend in den Activities unten an zu hängen.

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.

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.

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.

Eyup.

Fazit: endlich läuft es.

Diese Mischung unterschiedlicher Views ist ziemlich nervenaufreibend, vor Allem bei der Arbeit mit dem ViewHolder Pattern.
Aber: nichts, was sich nicht lösen lässt.

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.

Definiere 'Rechner'.
Auf meinem iMac habe ich auch überhaupt gar keine Probleme beim Entwickeln ohne irgendwelche Treiber.
Was für einen neuen Rechner mit welchem Betriebssystem hast du denn?

Erst einmal danke für die Antworten.

kogoro
Falls du Fragmente meinst: Ich möchte bis 2.1 unterstützen und traue der nachwirkend eingebauten Aufwärtskompatibilität nicht über den Weg.
Falls du drei komplett losgelöste Activities mit drei eigenen Views, also drei unterschiedliche Screens meinst: können ja, dürfen nein.

killphil75
Oh weh, das klingt ja spaßig...
Ich überlege gerade, ob ich es irgendwie hinbekomme, nur ein ListView mit zwei unterschiedlichen Objekten zu füttern.
Vermutlich muss ich dafür irgendwas Generisches bauen - nur kann ich das auch in unterschiedliche Sektionen aufteilen?

Ich glaube, ich versuche es mal so wie hier dargestellt:
ListView Sectioned Headers in Android

Wäre doch gelacht, wenn ich das nicht geregelt bekäme.

// Nachtrag
Läuft soweit. Jetzt muss ich nur noch schauen, warum er mir ab und an abkachelt, wenn ich zu schnell scrolle. Ah, liegt wohl am ConvertView. Ich seh schon, mit unterschiedlichem Layout-Aufbau wird's noch komplexer.

Moin,

ich würde gern ein recht spezielles Layout erstellen. Gern würde ich auch, dass besagtes Layout vernünftig scrollt.

Der (aktuelle) Aufbau ist wie folgt:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
              android:layout_width="fill_parent"
              android:layout_height="fill_parent">
    <ScrollView android:layout_height="wrap_content"
                android:layout_width="match_parent">
        <LinearLayout android:layout_height="match_parent"
                      android:layout_width="match_parent"
                      android:orientation="vertical">
    <!-- // Placeholder //-->
            <TextView android:id="@+id/placeHolderView"
              android:layout_width="match_parent"
              android:layout_height="128dip"
              android:text="Willkommen! - Platzhalter." />
    <!-- // News oder so //-->
            <ListView android:id="@+id/topFiveNewsList"
              android:layout_width="match_parent"
              android:layout_height="wrap_content"
              />
    <!-- // Statics wa //-->
            <ListView android:id="@+id/staticInfosList"
              android:layout_width="match_parent"
              android:layout_height="wrap_content"
              />
        </LinearLayout>
    </ScrollView>
</LinearLayout>

Ich habe also salopp gesagt eine Art Header und zwei Listen, die unterschiedliche Objekte auflisten: News (nur die letzten fünf) und Infos.

Beim ersten Versuch bekam ich meinen Header oben angeklatscht und die ListViews darunter liefen ganz gut.
Als ich dann vom Test zum Produktivsystem umgeschaltet habe, stellte ich fest, dass je nach Endgerät die unterste Liste komplett fehlte oder arg geschrumpft dargestellt war und eigenmächtig scrollen wollte.

Nun ging ich davon aus, dass ich einfach alle Views in eine ScrollView legen könnte und dann würde sich das schon ausgehen.
Leider mag die ScrollView nur ein SubView, weshalb ich die Views ein weiteres mal in ein Layout verschachtelt habe.

Nun sieht das Ganze spannenderweise aus wie im Screenshot:
Platzhalter prangt oben, Liste 1 und Liste 2 sind mickrig klein und ich kann nur in ihnen scrollen.

Jetzt suche ich Lösungsvorschläge für mein Problem.

Möglichkeiten, die mir in den Sinn kamen, doch von denen ich aus Gründen erst einmal absehen möchte.
1) Das Scrolling des ListViews irgendwie deaktivieren. Bin ich nur absolut gegen, weil es zur Grundfunktionalität des ListViews gehört. Wann immer ich irgendwo eine Grundfunktionalität abschalte, habe ich danach einen Riesenärger am Hals. Vermutung: sieht genauso dämlich aus wie jetzt und lässt sich dann nicht mehr scrollen.

2) Den Header als HeaderView des ersten und die zweite ListView als FooterView des ersten ListViews setzen. Habe ich jetzt nicht so die Lust drauf, da es einerseits das Layout an sich unübersichtlicher macht ("Wo kommen denn jetzt die beiden zusätzlichen Views her?") und andererseits kann ich dann immer noch nicht sicher sein, dass die Anzeige endlich so funktioniert wie ich sie haben möchte.

Meine bevorzugte Lösung wäre irgend etwas von Wegen ListView.setIsScrollable(false) oder ListView.setHeightFitsContent(true) oder sowas.
wrap_content scheint ja offenbar nicht das zu tun, was ich möchte.

Hat jemand nen Tipp?

Zitat von Syntarex

Naja objektorientiert, bleibt objektorientiert.

Sag das nicht so leichtfertig.
Ein bisschen JavaScript oder Objective-C, und du wirst deine Meinung diesbezüglich ganz schnell ändern.

Hihi, dann mal viel Spaß mit Java.

Wenn du schon C# kannst, wird das für dich ja keine allzu große Umgewöhnung und ich denke, dass du ziemlich zügig die ersten Erfolge haben wirst.

Breakpoints und den Debugger.