Beiträge von Marco Feltmann

Dann ist entweder Dein Setup oder Deine App zum Debug ungeeignet.

Ich sehe da erst mal drei Möglichkeiten:

• Bau Dir ein ListView oder TextView, welches all das anzeigt, was Du eigentlich im Log anzeigen würdest. Dann hast Du immerhin einen Blick auf die Logausgaben und kannst ungefähr eingrenzen, wo was passiert.
• Teste das Ganze erst einmal mit einem anderen Input Stream, beispielsweise aus einem selbst geschriebenen Service. Oder einem selbst erstellten Unit Test. Oder sonstwas. Dann hast Du den Port für das Debug Kabel frei und kannst so lange mit dem Debugger arbeiten, bis das alles so funktioniert, wie Du es Dir gedacht hast. Anschließend testest Du dann irgendwie die USB Seite um sicherzustellen, dass auch alles am anderen Ende ankommt, das Du am einen Ende schickst. (Irgendwie könnte stumpf die Ausgabe aller empfangenen Bytes in ein Textfeld sein – auch hier erst die App Seite mit dem Debugger und einem anderen Input Stream fertig bauen)
• Bastel oder besorg Dir ein USB Bridging Board. Es dürfte doch sicherlich möglich sein, sowohl im Debug Mode auf den Daten zu lauschen als auch die Daten zu übertragen. Du müsstest halt fürs Erste die Einstellungen so vornehmen, dass der eine USB Port am Bridging Board die Daten sendet und der andere Port die Daten empfängt. So kommst Du zumindest an die Log Ausgaben. Breakpoints setzen etc.pp. wird dann ein wenig komplizierter, weil der zweite Port dann beides können muss und das Bridging Board die Dinge richtig zuordnen können sollte.

Nicht bei der Fragestellung.

Gern. =)

Die Datenschutzbestimmungen, die ich von parse.com gefunden habe, beziehen sich auch nur auf parse.com bzw. deren Internetauftritt, nicht deren SDK.
Du solltest da wirklich einen Link hin nachreichen.

Gerade mal angemeldet und zunächst hat sich die Anzeige bei 'Entdecke' seltsam verhalten: Deine fünf Ziele tauchten abwechselnd immer im obersten Eintrag des ListView auf. Einmal zum Aktualisieren gezogen und seitdem läuft es fehlerfrei. Sah aber sehr seltsam aus.

Du dürftest demnächst einen Bugreport in Deiner Developer Console haben. Beim Auswählen eines Photos für das Kontaktbild ist mir die App zwei mal nacheinander abgeschmiert.
Photo aufnehmen läuft, Photo aus dem Album holen nicht.

Auch der 'komplett private Account' hat immer noch das Problem, dass die Daten auf irgendeinem Server irgendwo in den USA oder sonstwo liegen…

Oh, und die Darstellung der 'Unterstützt' Anzeige verwirrt mich auch.
Normalerweise ist ein Stern nur liniert, wenn man es markieren kann und ausgefüllt, wenn es markiert ist. Bei Dir ist es genau anders herum.

tl;dr
+ sieht insgesamt super aus
+ schickes View zur Anzeige des 'Lebensweges'

- Registrierungszwang
- Präsentation im Store

Langfassung
Sieht schon mal ganz gut aus.
Hast Du auch einen Demo Account dafür?
(Hintergrund: bei Apple bekommst Du die App nicht in den Store, wenn Du eine Anmeldung voraus setzt und keinen Demo Account bereit stellst.)

Mir persönlich missfällt der Teil mit der Anmeldung ganz arg.
Ich gehöre zur Kategorie 'meine Ziele gehen nur mich etwas an.'

Davon ab weigere ich mich, mich zu registrieren. Denn 'Mit der Registrierung stimmst Du den Datenschutzbestimmungen zu'.
Mag ja sein, aber ich sehe keine Datenschutzbestimmungen. Was ich nicht sehe, dem stimme ich auch nicht zu. Also kann ich mich nicht registrieren.
Hier wäre ein Link zu den Datenschutzbestimmungen total hilfreich.

Insofern würde ich selbst mir eine total offline funktionale Version wünschen, die sich bei Bedarf mit dem Internet synchronisiert.
Idealerweise hätte ich neben öffentlichen Zielen (also online für alle einsehbar) und privaten Zielen (also online für mich einsehbar) auch gerätebezogene, lokale Ziele (also nur auf dem Gerät einsehbar).

Diese Weg-Verlaufsanzeige sieht ja ganz toll aus. =)

Zum Icon…
Also… +ähm+ Ich… +öh+ Nun ja… +äh+ Wenn man nix Gutes zu sagen hat, sollte man einfach den Mund halten.
Hilft Dir dann aber auch nicht weiter.
Für mich persönlich stellt das App Icon absolut keine relevante Beziehung zur App her. Das könnte auch ein Cloud Storage Anbieter sein, eine Mind Map Applikation oder eine Wettervorhersage.
Du solltest wirklich in Erwägung ziehen mit einem oder drei graphisch talentierten Kommunikationsdesignern zu erörtern, welches Symbol sie am Ehesten mit 'persönlichen Zielen' in Verbindung bringen.

Die einfarbigen Hintergründe bei den 'Screenshots' finde ich persönlich etwas seltsam. Wenn es seriös wirken soll, wäre vielleicht ein komplett weißer Hintergrund oder der reine Screenshot eine gute Alternative. Wenn es peppig wirken soll, hättest Du eventuell lieber eine prägnante und leicht wiedererkennbare Textur gezaubert und die Devices vor eben dieser präsentiert.

Ich glaub, das wars von mir.

Sehr gut.
Gegebenenfalls noch mal die Existenz der Extras prüfen, nicht dass Du später aus Versehen von woanders dasselbe View öffnest und Dir dann alles aabschmiert.

All diese Dinge werden über einen Adapter geregelt.

Das ListView fragt den Adapter nach den Daten, der Button sagt dem Adapter, er solle Daten hinzufügen, der Adapter informiert das ListView über geänderte Daten, das ListView fragt den Adapter nach den Daten.

Ein Beispiel zur Arbeit mit ListViews findest Du bei im offiziellen Android List View API Guide.

Wenn Du damit die ungefähre Funktionsweise verstanden hast, hilft Dir sicherlich das inoffizielle ListView Tutorial von Lars Vogel weiter.

Ich ging davon aus, dass Dir das bewusst ist, aber falls nicht: ohne Erfahrungen in der Programmierung steht Dir viel Lernarbeit bevor.

Es gibt keine dämlichen Fragen.
Lediglich faule Fragen und wenig hilfreiche Fragen.

Dann zeig doch mal Deine Implementierung her.
Die writeObject(Stream) und readObject(Stream) sollten reichen.

Dein Objekt ist leer, weil Du eine ArrayList (serializable) übergibst, die Objekte (non-serializable) enthält.
Insofern wird Deine ArrayList korrekt übergeben (was übrigens Blödsinn ist, da Du ja nur ein einziges Objekt übergeben möchtest), bei den darunter befindlichen Objekten schlägt die Serialisierung fehl und das Array ist folgerichtig leer.

Da Du auf meine Frage keinen Sourcecode gepostet hast, nehme ich mir heraus meine Frage selbst zu beantworten:
Du hast Parcable/Serializable nicht verstanden und einfach ein Objekt übergeben, dass eines dieser Systeme von Haus aus unterstützt.
Deine eigenen Objekte haben keinerlei Serializable/Parcable Implementierung.

Wenn keine Persistenz erforderlich ist, dann lass die Finger von den SharedPreferences. Zumal diese sowieso nur Voreinstellungen persistieren sollen.
Davon abgesehen kannst Du Deine eigenen Objekte eh nicht in die SharedPreferences stopfen.

SMS oder Mail persistieren ihre Inhalte, weshalb das dort wesentlich einfacher umsetzbar ist.
Was ist denn nun bei Deiner Serializable Implementierung kaputt?

Keine Ahnung wieso. Frag so etwas doch den Debugger, der kann Dir das sicherlich sagen.
Vermutlich können Deine Objekte kein Serializable, so dass zwar das Array eingetütet wird, Deine Objekte hingegen aber nicht.

Nein, Du sollst nicht den Weg über SharedPreferences gehen. Entweder Du willst Deine Objekte ausschließlich zur Laufzeit im RAM haben (was ich nicht nachvollziehen kann), dann implementier das Serializable/Parcable korrekt. Oder Du willst Deine Objekte persistieren. Dann nutze SQLite oder irgend einen ORM Manager, der Dir den Kram abnimmt.

Call By Reference ist nicht möglich.

Ob Du jetzt zwei mal dasselbe Objekt rüberkopierst oder zwei mal die Inhalte der ArrayList ist im ersten Moment kein Unterschied.
(Im Zweiten schon, da Du statt einer mehrere Objektkopien hast)

Wenn Du aber absolut nicht persistieren willst solltest Du Dir Parcelable oder Serializable ansehen.
http://developer.android.com/r…ndroid/os/Parcelable.html
http://developer.android.com/r…java/io/Serializable.html

Kurz: gar nicht.
Übergib eine Referenz, beispielsweise die _id in der SQLite Datenbank, die die Infos gespeichert hat.

Lang:
Da Java es nicht hinbekommt, irgendetwas 'by reference' aufzurufen, kannst Du auch keine Referenzen auf Objekte übergeben.
Du könntest natürlich Deine Klasse so bauen, dass sie Parcable oder Serializable unterstützt und das Objekt dann als Extra übergeben.
Nur wird vor der Übergabe die Klasse serialisiert/gepackt und nach der Übergabe ein neues Objekt erstellt, dass die gepackten Inhalte übernimmt.
Du hantierst an dem Punkt also so oder so mit zwei völlig unterschiedlichen Objekten herum und solltest dementsprechend gleich in jedem geänderten View die Objekte aus den Datenbankinhalten selbst zusammen zimmern.

Vorweg: für genau so etwas ist dieser Forumsbereich da.

Also dafür gibt es durchaus mehrere Möglichkeiten.

Die zentrale Frage ist, wie genau sich das alles verhalten soll. Wird die Liste nach Eingabe gefiltert? Oder nach Wert? Oder nach Anzahl der Werte? Willst Du das im Nachhinein aufsplitten wollen?

Nehmen wir beispielsweise folgende fiktive Bestellung: 4cl, 2cl, 1/3l, 5dl, 4cl, 2cl, 2cl, 2cl, 4cl
(Den Notruf wegen der Alkoholvergiftung lassen wir mal außer Acht, da der ja für euch kostenlos ist. ;))

(Zur Erklärung: 5dl = 1/2l = 0,5l = Hefeweizen, 1/3l = 0,33l = Bierchen, 2cl = Schnappes, 4cl = doppelter Schnappes)

Du hast jetzt mindestens zwei Möglichkeiten zur Ausgabe des Ganzen:

Zitat

1cl x 0 = 0,00€
2cl x 4 = 2,00€
4cl x 3 = 3,00€
1/3l x 1 = 2,50€
5dl x 1 = 3,00€

Hier hast Du einfach eine HashMap oder ein Dictionary oder sonstwas, welches sämtliche Deiner Tasten als keys hat.
Wann immer eine Taste gedrückt wird, addierst Du die bestellte Menge. Dein ListAdapter geht dann einfach die einzelnen Keys durch und baut sich die Anzeige zusammen.

Zitat

4cl x 3 = 3,00€
2cl x 4 = 2,00€
5dl x 1 = 3,00€
1/3l x 1 = 2,50€

Dies ist ein bisschen komplexer, dafür aber flexibler.
Zunächst einmal solltest Du Dir eine Zuordnung Name->Preis(->Menge) machen. Bei jeder Bestellung schaust Du nach, ob Du die zum Button gehörende Zuordnung Name->Preis schon hast. Falls ja, setzt Du die Anzahl um eins nach oben. Falls nein, fügst Du es Deinem Array hinzu.
Die Sortierung ergibt sich dann aus der Reihenfolge der (ersten) Bestellung jeder Mengeneinheit.

Wenn Du so richtig cool bist, baust Du Dir einen eigenen Array Controller für das Array und Deinen eigenen Objekttypen, der das Hinzufügen von Objekten gemäß Deiner Vorstellung umsetzt.

Dann brauchst Du nur arrayController.addDrinkNamed("2cl"); aufrufen, und die Methode schaut eigenständig, ob es diesen Wert schon gibt (Menge um 1 erhöhen) oder nicht (Wert ins Array packen).

Ist ein Super Übungsprojekt.

Berechnung kannst Du dann auch in den Controller packen. Im Prinzip eine einfache Schleife:

long result = 0;
for(Drink drink : drinksArray) {
  result += drink.getAmount() * drink.getPrice();
}
return result/100;

Pro-Tipp: speichere auf jeden Fall die Einzelbeträge in Cent und rechne sie dann in Euro um.
(Oder Dollar oder wie auch immer. Auf jeden Fall die kleinste mögliche Einheit.)
Fließpunktzahlen haben die Eigenschaft, unglaublich große Wertebereiche darstellen zu können. Sie haben aber auch den Nebeneffekt, sehr ungenau zu werden.

Alles Weitere ist dann eine Frage des Datenmodells.
Du kannst beispielsweise für jeden Deiner Homies/Bros/wie auch immer das heutzutage heißt, einen eigenen fiktiven Account anlegen.
Beispielsweise mit Spitzname und Budget für den Abend.
Dann kannst Du das Ganze in einen Pager einbetten und die Liste wird dann für jeden einzeln angezeigt. Und da Du auch das Budget des Abends eingetragen hast, wird die Anzeige beispielsweise gelb, wenn er nur noch sagen wir 4€ hat und die Eingabe sperrt sich komplett, sobald er rechnerisch pleite ist.

Oh, man kann da soooo viel draus machen.

Hach ja, Forrest Gump.
Gerade gestern Abend erst gesehen.

Ich persönlich würde das Ganze auf die 'Singleton Implementierung des SQLite Helper' schieben.
In den seltensten Fällen sind eigene Singleton-Implementierungen thread-safe.

Also auf der Seite zu GoogleCloudMessaging sieht es für mich so aus, als würden sie den Intent nicht selbst verarbeiten sondern gcm die Verarbeitung überlassen.

Zu Punkt 2: wie kommst Du darauf, dass Du genau das Intent in Deiner App zurückbekommst, dass Du sendest?
Du schickst my_message an den Echo-Server, der ignoriert das und wirft Dir irgendeine Standardantwort zurück.

dateInstance.getTime() liefert Dir das in dateInstance gespeicherte Datum in Millisekunden und entspricht dem Unix Time Stamp.

Da hast Du Dir aber schon tief greifende Gedanken gemacht, sehr schön das.

Prinzipiell lenkt ja alles ab, das irgendwie dafür sorgt, dass Du die Hand vom Lenkrad nehmen musst.
Insofern sind Gesten wohl das Sinnvollste.

Zu den Fragen:
1) Du könntest dem Beifahrer eine via Bluetooth angeschlossene Fernbedienung in die Hand drücken. Gedankensteuerung wäre natürlich das Beste, allerdings sehr schwer umzusetzen.

2) Zur Sprachsteuerung bietet Google seit API 20 soweit ich weiß eine API an, die eigentlich für Android Wear gedacht ist. Eventuell kannst Du damit ein bisschen herumspielen. Ansonsten wirst Du um einen eigenen Empfänger für Deine Gesten nicht umhin kommen, flink zusammenklicken ist da meines Wissens nicht.

3) 2-Finger-Slide hoch-runter könnte noch für Playlist Wechseln gut sein. Wobei man das meist eh nur macht, wenn man gerade im Stau steht.

Ich verstehe die GPL2 so, dass Du sie ausschließlich in Open Source Projekten nutzen darfst.
Niemand verbietet Dir, für Dein Open Source Projekt Geld zu nehmen.
Ich weiß nur nicht, wie Du nach Kauf aus dem Store demjenigen die Sourcen zukommen lassen könntest.