Beiträge von Marco Feltmann

Dieser spezielle Fall ist ein ConfigurationChange und wird in der Doku erläutert.

onPause() und onResume() werden meines Wissens bei einem Drehen des Gerätes nicht aufgerufen, da die Activity nicht verlassen wurde.

Da ist mir nichts bekannt (zumal ich nicht so der RSS-Fan bin).

Eventuell wäre das ja mal ein Projekt für Dich?

Ich steh' ja total auf Systemstandard.

Da ging mal das Gooseberry Board durch die Medien.

Sieht auch schon bestellbar aus. Zumindest in dem Shop.
Allerdings sind keine lieferbar, Du musst also im Zweifel etwas warten.

Was spricht gegen Raspberry Pi?
Zur Not gibt es auch ein Projekt Android on Raspberry Pi.

+puh+
Über zweieinhalb Stunden Arbeit für nix und wieder nix.
Naja, egal.

Projekt via Eclipse erstellt. Gegebenenfalls musst Du einmal nen Clean durchführen.
Sollte komplett fehlerfrei sein und die einzige Warnung im Layout kommt auch nur, weil ich einen Button fest verlabelt habe.
(a.k.a. "Ist nur zum Test, brauch ich später nicht" -> "Och, ist ein nettes Feature, lass ich doch drin.")

Ich hoffe, Du findest die Dokumentation einleuchtend und das Beispiel hilfreich.
Bei dem Seriellgespiele kann ich Dir allerdings nicht weiterhelfen.

(Ich bin ein Fuchs, wa? Die generierten Zeichenketten sehen aus als kämen sie direkt vom Controller. Das heißt, Du kannst diesen Service als Dummycontroller für Testzwecke nutzen und meinetwegen auch noch um andere Dinge erweitern.)

Das beruhigt mich.
Fein fein. =)

(Musste meinen Parser-Ansatz drei mal überdenken. Freut mich, dass dieser einigermaßen gut läuft.)

Kleiner Tipp für weitere Umfragen: Menschen sind keine Computer.
Fragen a lá 'Wie viel x haben Sie?' mit '<10; <100; <1000' zu optionieren ist kontraproduktiv.
'1' wäre gemäß eurer Umfrage '<10', wer aber schick verschleiern will, kann ohne zu lügen '<10000' daraus machen.

Mein Lieblingsbeispiel aus einem Dilbert diesbezüglich:
"Wie hoch erwarten Sie die Auflage?"
'Zwischen zwei und fünf Millionen.'
"Wahnsinn, Sie haben den Zuschlag!"
'Es ist alles eine Frage der Formulierung, und schon klingt "Acht" nach einer ganzen Menge.'

Ach ja, ein Ergebnis möchte ich auch haben.

Und, hast Du einmal den Default Handler ausprobiert?

Zitat von nomad

- MySerialReader.zip (project) kann nicht rauf geladen werden zu gross 1.52mb

Ist das bereits ohne die .gen/, .out/ und .build/ Verzeichnisse?

Wenn Du nicht mit einem Debugger an das Gerät kommst und Dir keinerlei Logausgaben zwischenspeichern kannst wird das alles ausgesprochen schwierig.
Kannst Du nicht wenigstens in den Entwickleroptionen 'Fehlerberichte im Menü "Ein/Aus"' aktivieren und Dir die Logs dann nach dem Crash beim String umwandeln zuschicken lassen?

Irgendwie musst Du ja an die Daten kommen und ich vermute, dass deine 'Strings' ByteArrays sind, die sich nicht so einfach umwandeln lassen.
Doch ohne klare Aussagen und harte Fakten (die nur der Debugger und die Logs liefern können) wird das schwer zu testen.

Hast Du ganz eventuell eine API Übersicht zu dem Microcontroller, aus der idealerweise als Codebeispiel hervor geht, was genau das Ding zurückliefert?
Mit diesen Daten könntest Du Dir für Testzwecke eine simulierte Datenquelle bauen und entsprechend mit Logs und Debugger testen.

+hm+
Unglücklicherweise schweigt sich die Dokumentation des XmlPullParsers darüber aus, ob der jetzt eher SAX oder eher DOM nutzt.
Vielleicht ist die Klasse auch überladen? Oder es dauert wirklich sehr lange.
(Im Fall des Parsers wird ja jedes Element durchgesprungen statt wie in Deinem achteckigen Rad nur das eine Element. Dein achteckiges Rad kann sich aber bei rtept und wpt verschlucken, der Parser nicht.)

Ich habe einmal nachgeschaut und damals™ den DefaultHandler erweitert.

Anstatt das Du dort in einer Schleife hantieren musst, werden Callback Methoden aufgerufen wenn die entsprechenden Ereignisse eintreten. In meinem Fall sind das:

public void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException;
public void characters(char[] ch, int start, int length) throws SAXException;
public void endElement(String uri, String localName, String qName) throws SAXException;

Langsam war der auch, allerdings weil ich jeden gefundenen Wert dort in eine SQLite Datenbank via DAO geschrieben hatte.
Ich hoffte eigentlich, dass es daran lag. Allerdings war meine Implementierung (speichersparend, leistungssparend) immer noch 5x langsamer als meine iOS Variante. C vs. Java halt.

Das Problem ist, dass Du die Liste mit den Bildern erst zurück gibst, nachdem auch das letzte Bild geladen wurde.
(onPostExecute())

Das ist ja auch prinzipiell der richtige Weg, da Du sonst nicht im Mainthread bist und dementsprechend nicht in das UI malen kannst.

Spontan fällt mir nur ein, dass Du den Downloadansatz etwas änderst:
statt einmal 5 Bilder zu laden lädst Du 5x ein Bild.

Du kannst ja Deinen Task so bauen, dass er ein bis n URLs annimmt. Und wenn Du ihm nur eine URL gibst und das Bild dieser URL dann zurück gibst, sollten die einzelnen Bilder schneller zurückgegeben werden.

Wenn ich an Stelle des Kreises einfach eine Kerbe in den mittleren Kreis malte und diesen entsprechend drehte sollte das reichen.
Insgesamt finde ich die Erstellung eigener Views alles andere als intuiitiv.

ich glaube, das Sample muss ich mal ganz ausgiebig studieren und analysieren.
Morgen.

Das ist auf jeden Fall eine gute Lerngrundlage.
Danke dafür!

Ich fürchte, Dein Fehler liegt darin, dass Du das Rad neu erfindest – und zwar achteckig.

Eine GPX-Datei ist zwar eine Textdatei, aber sie ist gleichzeitig auch eine XML Datei.
Und eben solche XML Dateien lassen sich am Besten mit einem XML Parser abarbeiten.

Eventuell kannst Du an Hand dieses Beispiels Deinen eigenen Parser bauen:
http://www.vogella.com/articles/AndroidXML/article.html

PS: OsmAnd nutzt, wenn ich den Quellcode richtig interpretiere, alles Mögliche mit C++ und hat für die Android App nur das UI mit Java implementiert.
So schnell wie OsmAnd wirst Du die Datei mit Bordmitteln vermutlich nicht parsen können.

Also zunächst einmal finde ich es toll, dass sich die Leitungen beim Schaltbild quasi intelligent aneinander anpassen.
Leider habe ich keine Möglichkeit gefunden, die Simulation einer Logikschaltung zu starten. Vermutlich habe ich es falsch benutzt.

Moin,

ich suche ein Potentiometer als View.
Also so ein kreisrunder Knopf zum dran drehen und drauf drücken.

Es gibt zwar Apps, die so etwas benutzen, ich finde aber kein Standardelement dafür.
Wenn jemand sachdienliche Hinweise dafür hat, wo ich so etwas finden kann, habe ich ein offenes Ohr.

Selber bauen wäre auch eine Möglichkeit, ich müsste dann nur ein paar hilfreiche Hilfestellungen bekommen.
Der ganze Velocity-Kram, der mir via 'Tracking Movement' angeboten wird, führt regelmäßig zu Abstürzen…

Wenn jemand was hat oder kennt, bitte petzen.

Moin,

Du hängst also direkt am Mikrocontroller. Stimmt allerdings, dann kommst Du nicht mehr an die Ausgaben.
Einerseits könntest Du (je nach Device) Crash Logs aktivieren und nach dem Absturz übertragen.
Ist aber nach wie vor schwierig zu debuggen.

Besser wäre es, Du würdest für die Tests von der Hardware absehen und die Eingaben durch den Microchip simulieren.
Für Deinen Serial Reader würde ich einen Unittest (TestNG oder JUnit) vorschlagen. Dann hättest Du den Test reproduzierbar und könntest nach jeder Änderung am Code schnell testen, ob Du irgendwas Wichtiges kaputt gemacht hast.

Auf jeden Fall solltest Du die Eingaben zunächst simulieren.

Für mich sieht es so aus als würdest Du irgendwo im Hintergrund mit der Hardware kommunizieren und dann an den Mainthread Dinge posten. Das halte ich für einen ungünstigen Weg, da Du Dir so Abhängigkeiten schaffst. Eventuell wäre hierfür ein Callback der bessere Lösungsansatz. Dann bekäme Deine App die notwendigen Informationen auf direktem Wege und müsste sich um die Verteilung kümmern. Dein SerialReader hat mit der Anzeige der gelesenen Daten ja eigentlich nix zu tun.

Mal sehen, ob ich da was gezimmert bekomme, das Dir beim Debuggen helfen könnte.

// Nachtrag
Da scheint aber eine Menge Musik in Deiner Main Activity zu stecken. Zu viel, als dass ich das mal eben überblicken könnte.
Hast Du eventuell irgendwo das komplette Projekt auf einem Server liegen? Idealerweise in einem Sourcecode Management System hinterlegt?

Soweit ich die Sache verstanden habe, gibt es die drawable-*dpi Ordner für appspezifische Dinge. Sprich: Icons.
Diese sind ja in vorgegebenen Dimensionen da und variieren dementsprechend jeweils in ihrer Größe und DPI gemäß der Dokumentation.

In die *large Ordner hingegen kommen (quasi) DPI-unabhängige große Bilder. In dem Fall kannst Du nur von Mindestmaßen ausgehen, die das jeweilige Display unterstützt.

Android würde in dem von dir konstruierten Szenario die Icons aus dem mdpi-Ordner ziehen, Hintergrundbilder aber dynamisch nach Bildschirmgröße entweder aus dem drawable-large oder drawable-normal.

Also: in die drawable-*dpi Ordner nur Bildmaterial mit fest vorgegebenener Größe gemäß Entsprechung. (Es ist dem Icon egal, ob davon 9, 20 oder 81 auf einen Screen passen.)
Für Bildmaterial mit Größen in Abhängigkeit der Bildschirmgröße die drawable-*large Ordner nutzen.

Du wirst im LogCat Deiner IDE eine entsprechende Error-Ausgabe finden.
Diese sagt Dir, was genau wann wo schief gegangen ist.

Okay, danke für den Tipp!
Badges mag Android offenbar auch nicht. (Es gibt wohl einen BadgeContentProvider, aber so wie ich es verstanden habe nur bei Samsung ROMs)
So wichtig ist die Funktionalität nicht, also lasse ich sie weg.