Beiträge von UweApps

So, hat etwas gedauert, aber nun bekommst du wenigstens mal eine erste Antwort. Bislang hatte ich mich vor Unittests noch gedrückt, wollte auf 'ne gute Gelegenheit warten um selber mal meine Apps zu testen. Danke für die Frage!

Es ist anscheinend so, dass bei lastname.getEditText().requestFocus(); kein wirklicher Focus gesetzt wird - es wird im Log auch kein Keyboard erwähnt, bei einer normalen Activity mit normalem EditText passiert das dagegen wunderbar.

Du kannst mit lastname.setText("h") den Wert setzen, aber ich hab es nicht geschafft, mit sendKeys irgendetwas in dem Feld unterzubringen.

Also erste Vermutung: Problem mit den Besonderheiten der Preferences - wie gesagt - bei einer normalen Activity hatte ich keine Probleme mit dem senden von Tastencodes.

Die Besonderheit wird auch deutlich, das du lastname.setText aufrufen kannst - obwohl das nicht der EditText sondern der EditTextPreference ist. Eigentlich würde ich erwarten, dass auch lastname.getEditText().setText() funktioniert, tuts aber nicht:

lastname.setText("aa");
lastname.EditText().setText("XYZ");
sendKeys("A B C");
sendRepeatedKeys(1,KeyEvent.KEYCODE_H);

Anschließend ist lastname.getText und preferences.getString(LASTNAME,"n/a") beides ganz brav "aa" - und das sollte es ja nicht sein. Und lastname.getEditText().getEditableText().toString() ergibt "XYZ" - da ist also ein Unterschied zwischen dem Inhalt der EditTextPreference und dem Inhalt des "zugehörigen" getEditText(). Und die Tastatureingaben sind schon mal gar nicht angekommen..

Sehr rätselhaft...

Und leider kennt EditTextPreference kein requestFocus() - das wäre sonst eigentlich der Weg, auf den man zuerst kommen würde.

Wer weiß mehr???

Du suchst den ProgressBar - wahrscheinlich in der Variante Widget.ProgressBar.Large.

Der ist sogar in der grafischen Layout-Einrichtung vorhanden.

getParent() wird von Eclipse zwar akzeptiert, liefert aber leider eine NullPointerException - also so gehts auch nicht.

Aber mit MyActivity.this.setResult hab ich beste Erfahrungen.

das ist eine Lösung - ansonsten startest du eine andere Activity, die muss dann aber die Tabs selber auch wieder aufbauen - Activities sind halt unabhängige Teile, die jeweils den vollen Schirm bekommen

Hallo Lucas,

du hast zwar einen Antwort-Intent gebaut, aber nicht zurückgegeben.

Schreib mal EditItem.this.setResult(RESULT_OK, defaultIntent); vor den finish();

Das erklärt aber nicht unbedingt den Absturz - da müsstest du mal die Logs anschauen, was da angemeckert wird.

das mache ich auch so - in einer App sogar bei Datenbankzugriffen, aber nicht weitersagen...

Hab noch was gefunden für dich: XML-Adapter.

Die PhotoListActivity und RSSReaderActivity könnten dir weitere Anregungen geben. Dort wird nämlich teilweise nachgeladen...

Ich hatte den Eintrag noch ergänzt - der erste Absatz beschreibt am Ende jetzt deine Anwendung.

Du kannst zwar die Daten blockweise laden, das ist aber nicht wirklich praktisch. Dann musst du nämlich immer selber entscheiden, was und wo du gerade bist...

Entweder die Datensätze einzeln laden oder alles auf einmal - wenn du alte Einträge lokal speicherst, brauchst du sie ja nicht unbedingt noch mal laden, aber das entscheidet am besten ein selbstgebauter Adapter.

Der Adapter muss aber schon am Anfang wissen, wieviel kommt, sonst halt notifyDataSetChanged() aufrufen, wenn sich die Anzahl ändert.

Wenn du dir einen Adapter selber baust (siehe API-Demo), kannst du dir mit Log.v im Adapter die erzeugten Einträge ausgeben lassen - er macht tatsächlich nur die, die der ListView gerade mal wieder braucht. Ich denke mal, der ListView holt sich erst mal die Gesamtzahl und dann so viele Views aus dem Adapter, bis er den Bildschirm voll hat. Beim Verschieben werden dann weitere geholt. Übrigens auch welche, die er schon mal hatte, wenn sie zwischendurch mal vom Schirm verschwunden sind. Das Verhalten sieht man sehr schön bei Apps, die Daten für Listeneinträge dynamisch aus dem Internet nachladen - das dauert ja etwas.

Wenn du nur ein Array benutzt, dann könntest du so was machen, aber dynamischer wirst du mit:

myItemAdapter = new MyItemAdapter();
myListView = (ListView) findViewById(R.id.myListView);
myListView.setAdapter(myItemAdapter);

Wenn du dann noch myItemAdapter und myListView als private Membervariable der Activity deklarierst, kannst du sie in onResume() etc. auch verwenden - dort wirst du notifyDataSetChanged() wahrscheinlich einbauen.

Dann brauchst du natürlich auch eine Datenstruktur, die der Adapter nutzt - beim Array (feste Länge) ist das eher langweilig, eine ArrayList o.ä. gibt dir mehr Flexibilität.

Und das Layout mit simple_list_item_1 ist ja nur für einfache Sachen - schau dir noch mal den Inflater im API-Demo an, der kann auch deine XML-Layouts verwursten und du kannst hübsche Listeneinträge mit bunten Bildchen und putzigen Schriftarten in deine Liste einfüllen lassen.

Dafür gibt's beim ListView den BaseAdapter und ein paar weitere Adapter - du findest ein kurzes Beispiel in den API-Demos.

Zusatzinfo: da du wahrscheinlich mit einem XML-Layout arbeitest, brauchst du myListView.setAdaper(myListAdaper);

Dieser ListAdapter liefert immer einen fertigen Listeneintrag und der ListView ruft sich die Einträge, die er gerade braucht.

Sollte sich aus irgendwelchen Gründen an den Daten, die der Adapter nutzt, etwas ändern (z.B. Eintrag gelöscht), dann musst du den Adapter mit notifyDataSetChanged() darüber informieren.

Intents werden manchmal auch aus anderen Gründen gepackt, z.B. um Daten wieder zurück zu geben, um Services zu starten oder Anfragen ans System (ok, auch Services).

Ich hab sie am Anfang auch etwas unhandlich gefunden, aber mittlerweile hab ich mich dran gewöhnt.

da solltest du mal Datenblätter von Android-Geräten wälzen - ich glaube, das meistens nur reine Ausgänge eingebaut werden.

Falls jemand ein Android mit Kabel-Headset hat, kann er/sie sich bitte gerne melden, es gab schon mehr Anfragen dazu...

Leider sind die Activities bei Android relativ unabhängig und die Speicherverwaltung kann einem da auch noch mal einen Strich durch die Rechnung machen.

Wenn du die Daten konsistent halten willst, dann am besten in die SQLiteDB reinstecken, die Activities sollten sich dann in onResume mit den aktuellen Daten versorgen. Bei kleinen Datenmengen kannst du auch die Prefs als Speicher benutzen - man muss ja keine Konfiguration für diese Daten einbauen. Man kann auch die serialisierte Form eines Documents in ein DB-Feld speichern - die Daten sind dann auch bei Stromausfall/Abbruch der App noch im letzten Zustand - ein Vorteil gegenüber reiner Hauptspeichernutzung.

Das hat zusätzlich den Vorteil, dass du schon mal Daten hast, auch wenn noch nix aus dem Internet angekommen ist.

Ob du die Daten in einer Document-Struktur hältst oder lieber eine eigene Struktur aufbaust, ist eher Geschmackssache - kommt auch drauf an, ob du die Daten im XML-Format wieder rausgeben möchtest - da ist Document klar im Vorteil. Nur die Zugriffe in den Baum sind ziemlich nervig, wenn man einzelne Werte braucht.

@kilphil: du warst schon wieder schneller... *g*

Hab bislang noch gar nix zu mir geschrieben und schon 53 Beiträge geschrieben - nun wird's mal Zeit...

Bin schon etwas älter, eine meiner ersten Programmiersprachen war Fortran (hab mal Maschinenbau studiert), hab aber auch einige andere kennengelernt (Cobol, Pascal, Forth, Basic, C, C++, Scheme (Lisp), Prolog...). Vor 10 Jahren hab ich dann mit Perl auf Webservern angefangen, meine Spezialgebiete sind schöne Formulare (Versicherungsanfragen, Layout-Konfiguration) und reguläre Ausdrücke. Außerdem mag ich auch formale Sprachen und Compiler-/Interpreterbau - wenn man den Trick erst mal kennt, kann man lustige Sachen bauen...

Seit 15 Jahren arbeite auch auch als Gebärdensprachdolmetscher - meistens für gehörlose Informatik-Studenten, darum hab ich auch viel von den "wissenschaftlichen Grundlagen" im Hinterkopf, aber man merkt erst, dass man es wirklich verstanden hat, wenn man es auch mal richtig benutzt. Java hab ich mehrmals gedolmetscht, aber nie selber Programme geschrieben. Da war Android ein guter Anfangspunkt mal in einer richtig großen API vernünftige Programme zu schreiben.

Angefangen mit Android hab ich im Oktober 2011 mit dem Buzzword-Bingo-Beispiel aus der c't, hab dann aber auch einige eigene Projekte angefangen. Ein paar Apps hab ich auch schon im Market - meine Apps-Homepage hat mehr Infos dazu.

Hallo Marco, kein Problem - wir nehmen auch wieder aufgewärmtes.

Ich hab das mal so gemacht, dass ich jede Activity aufgerufen hab mit startActivityForResult(...) und wenn eine Activity ordnungsgemäß _alles_ beenden will, dann gibt sie dem Result-Intent einfach eine entsprechende Variable mit auf den Weg - im anschließenden onActivityResult kann dann gleich weiter gefinisht werden.

Allerdings eventuell auf dem Weg noch ein paar Daten sichern oder Cursor/Services schließen etc. Aber das macht wahrscheinlich besser der onPause(), der im Verlauf von finish() aufgerufen wird. Darum sollte finish() auch das letzte sein, was du in onActivityResult aufrufst.

Anmerkung am Rande: bitte in reloadData auch dataCursor.close() aufrufen - gibt sonst verwirrende Fehlermeldungen zu völlig falschen Zeitpunkten.

Zu befürchten hast du nichts, nur solltest du die Möglichkeiten der res-Verzeichnisse schon mal im Auge behalten - denn ähnliches gilt für deine Strings, damit du Übersetzungen machen kannst.

Aber erst mal alles in einem Layout-Verzeichnis unterbringen - du willst ja auch sehen, dass was funktioniert.

Und wenn du Später™ auch mal andere Auflösungen, Systemversionen und Sprachen ausprobierst, wirst du dich freuen, wenn du nur im res-Verzeichnis was ändern musst.

ich glaub, über den Punkt stolpern noch einige, ich musste auch erst mal genau nachschauen, bis ich gefunden hab, dass -1 ein gültiger Wert bei moveToPosition ist.

Zuerst hatte ich nämlich noch einige andere Vorschläge zum weiteren Testen, wollte auch nachfragen, wie du die Daten in die DB reingeschrieben hast - dort vermutete ich einen Fehler bei _id oder ähnliches. Erst als ich meinen Datenbankcode noch mal angeschaut hab, fiel mir auf, dass der moveToFirst noch dazwischenfummelte.

Hoffentlich haben wir jetzt die richten Stichworte drin, dass andere die Lösung auch finden.

Kommt auch drauf an, was du auf dem Server alles machen kannst. Lucas hat recht: im einfachsten Fall kannst du die Daten einfach über HTTP rüberschieben, das geht immer und die Weiterbearbeitung mit PHP oder Python ist relativ einfach.

Bei SOAP müsstest du die Daten in XML verpacken, auf dem Server könntest du dann in einem einfachen SAX-Parser die Datensätze rausfischen und dann in die DB schubsen. Das gilt dann aber auch für die Rück-Richtung. Bei SAX auf Android muss man übrigens leider immer den Driver angeben, die Doku ist da etwas unvollständig, hier der Hinweis bevor du dich totsuchst:

XMLReader xr = XMLReaderFactory.createXMLReader("org.xmlpull.v1.sax2.Driver");

JSON oder verpacken der Daten mit interface Serializable für deine Datenklassen lohnt nur, wenn du auf dem Server auch Java machen kannst.

In jedem Fall musst du der App eine Antwort mit Erfolg-Meldung schicken, aber rechne auch damit, dass vielleicht mal die Rückmeldung nicht ankommt - gerade wenn man noch nicht ganz wieder zu Hause ist, ist die WLAN-Verbindung noch nicht stabil...

Ob du HTML5 oder native Apps schreibst kommt auch drauf an, was du noch alles in deiner Anwendung machst und wie gut du dich in den anderen Entwicklungsumgebungen zurechtfindest.

Vielleicht suchst du auch nach dem Befehl finish() - dann endet deine Activity auf Knopfdruck und die vorige kommt wieder zum Vorschein. Ansonsten gibt es bei Android ja meistens den Back-Button am Gerät.

Aber Killphil hat recht - die eigenen lokalen Variablen der ersten Activity können verloren gehen und müssen deshalb entweder gesichert oder wieder neu erzeugt werden (z.B. wenn die andere Acitivity die Datenbank ändert oder sonst etwas speichert oder löscht).