Beiträge von Marco Feltmann

1) Eigentlich speicherst Du die Daten auf dem Flash Speicher des Telefons. (Ganz eventuell, sofern unterstützt, auf der SD Karte). Andere Möglichkeiten hast Du da nicht. (Heruntergeladene Bilder sind KEINE Shared Preferences, lass Dir nix erzählen!)

2) Ich verstehe die Frage nicht ganz. Wenn Du die Bilder offline nutzen willst, hilft Dir ein Webserver ja gar nix.
Wie dem auch sei, Bilder sollten nicht in einer Datenbank gespeichert werden. Vor Allem bei SQLite Datenbanken blockierst Du Dir durch die langen Zugriffszeiten die komplette Datenbank (bei MySQL nur die komplette Tabelle) und die Datenbank wird elendig groß.
Wenn Du zu den Bildern noch weitere Informationen speichern möchtest (wie oft angesehen, Kategorie oder was weiß ich), dann packst Du diese Informationen in eine Datenbank und speicherst nur den Pfad zum Bild ab.

Yo proto,

bis dato hatte noch nie jemand vor so etwas zu machen, weil das aus Usersicht einfach eine Frechheit ist.
Ich meine, wenn jemand ernsthaft von mir erwartet, dass ich 128 Checkboxen anklicke, hat derjenige doch den Schuss nicht gehört.

Naja, mal davon ausgegangen, dass Du wirklich einen guten Grund für so viele Checkboxen hast:
erstell sie dynamisch im Code.

Du sollst Dich an den Zweig ranhängen:

case MESSAGE_READ:
				byte[] readBuf = (byte[])msg.obj;
				String string = new String(readBuf);
				Toast.makeText(getApplicationContext(), string, 0).show();
				break;

Der müsste Dir ja permanent via Toast mitteilen, dass Du Daten gesendet bekommen hast.

Gute Frage, klingt aber machbar. Schließlich schafft die SD Karte das ja auch.
Eventuell reicht es ja, wenn Du Dich irgendwie in den Event Bus rein hängst und das 'Karte eingefügt' Event triggerst.

Wie genau sich das praktisch umsetzen lässt kann ich Dir auch nicht sagen.

Ich steck' nicht tief genug drin um Dir zu sagen, wann was wie warum ausgeführt wird.
Deshalb solltest Du ja den Debugger benutzen.

Wichtig ist zu wissen, wann die onReceive aufgerufen wird und was im Intent steht.

Du kannst Dein Intent dann so erweitern, dass es auf Broadcasts reagiert. Oder was auch immer die Änderung der Lautstärke so triggert.
Ich glaube, das ist die RINGER_MODE_CHANGED_ACTION

Hihi, ich hege weder Zorn gegen Apple noch gegen Samsung/Google/HTC/Sony/Microsoft/Canonical/Sonstwen.

Ich habe mich lediglich der Auffassung der Three Dead Trolls In A Baggie angeschlossen: Every OS Sucks.

Ich sehe jetzt zwar nicht, wo Du da den Modus umstellst, aber egal.

Hast Du Dich mal mit dem Debugger reingehängt und nach der Minute geprüft, welchen Wert der AudioManager hat?
Für mich sieht das Ganze übrigens so aus, als würde immer Deine buildUpdate Methode aufgerufen sobald ein Intent rein kommt.

Also entweder kommt kein Intent rein (Service falsch programmiert) oder es kommt ein Intent rein.
Dann müsste Dein Intent kommen, wenn Du den Status manuell auf 'lautlost' stellst. Es wird dann buildUpdate aufgerufen und der Status automatisch auf 'normal' gestellt. Ergo kann sich die Ansicht auch nicht ändern.
Genau so geht es auch auf der anderen Seite. Wenn Du den Status manuell von 'lautlos' auf 'normal' stellst, wird buildUpdate aufgerufen und der Status automatisch auf 'lautlos' gestellt. Auch hier ist keine Änderung sichtbar.

Vermutlich trennst Du nicht richtig zwischen Update nach Timeout und Klick auf das Widget.

Da kommst Du aber nur mit dem Debugger weiter.

Hallo tööö,

aus eigener Erfahrung sage ich Dir: der Apple Dreck mit den 100€/Jahr ist genau so wie der Android Dreck mit den 25€ einmalig.
Das ist alles nur auf den ersten Blick neu und anders, im Prinzip jedoch alles dasselbe. Vor Allem demnächst mit Swift.

Von dem Edge Kram würde ich vermutlich die Finger lassen, weil man sich damit an Samsung binden dürfte wie man sich mit dem iPhone an Apple gebunden hat. Synchronisation mit dem Gerät möchte Samsung über ihre (je nach verwendetem Betriebssystem unglaublich bugverseuchte) Kies App realisieren wie Apple über ihre (je nach verwendetem Betriebssystem unglaublich bugverseuchte) iTunes App.

Die Edge ist (zumindest noch) kein android-spezifisches Feature sondern etwas, das Samsung sich einfallen lassen hat. Ein vom eigentlichen Display abgetrennter Bereich mit eigenen Controls. Viele samsungspezifische Features waren in der Vergangenheit einfach nur zusammengefrickelt und alles Andere als stabil. Bei CM und Ähnlichen dürfte das normale Display einfach nur gebogen sein.

Bis CM und Andere da nachgezogen und das in ihre Distributionen hineinintegriert haben wird es sicherlich seine Zeit dauern – und vermutlich wird Samsung diese Zeit nutzen jedes auftretende Gerücht einer Eigenimplementierung sofort mit ein paar entsprechend bezahlten Anwälten auf Wahrheitsgehalt zu überprüfen.

Warum es bei Apple (noch…) keine Edge Leiste gibt liegt übrigens daran, dass sie es verstehen Dinge zu trennen. Sie können abstrahieren.
Ein Bedienelement am Gerät, egal wie unglaublich toll, cool und edgy es sein mag, hat immer noch zur Folge, dass man das Gerät in die Hand nehmen muss.
Zum Wechseln des Titels oder Tätigen eines Anrufs das Gerät aus der Tasche ziehen, wo man doch Kopfhörer mit Bedienelementen in Fingernähe hat, ist meiner Meinung nach ziemlich 1998.

-----
Eventuell wichtige Zusatzinformation:
Ich habe ~2009 das erste Mal mit Android Berührung gehabt, mit einem Android Fork für den OpenMoko Neo FreeRunner, ein Smartphone, dass absolut quelloffen war. Die Android Forks mit 1.6 liefen solala, die mit 2.1 schleppend bis gar nicht und alles war irgendwie Gefrickel.
Dann kamen aus beruflichen Gründen das Galaxy Ace, Galaxy S2 und Galaxy S4 (sowie diverse Nexus, Xperias und HTCs) und nach nunmehr fast fünf Jahren muss ich immer noch sagen: Android ist eher Gefrickel.

Aber ich mag klassenorientierte Programmiersprachen ja auch nicht besonders.

Sobald Du android.R importierst, wird jeder Inhalt aus den Ressourcen im Android Paket gesucht.
Das willst Du nicht.

Das Problem dürfte sein, dass Du jetzt mit Gradle bauen willst, das Projekt aber noch auf javac eingestellt ist.
Du musst es also entweder komplett auf Gradle migrieren (eigentlich hätte Gradle darauf hinweisen müssen, dass es das so nicht bauen kann) oder alles wieder auf external build stellen.

Vergleiche http://stackoverflow.com/a/17314800

Ja, so etwas übersieht man gerne mal.

Den Code bekommst Du lesbarer hin, wenn Du im Editor in die Quelltext Ansicht wechselst, ihn dort einfügst und das Ganze dann abschickst.

Vielleicht sehe ich dann auch, wo Du die Abfrage des Telefonstatus und die dazugehörige Anpassung des Widgets vornimmst.

Gern, aber das allein hilft Dir ja noch nicht.

Was machst Du denn beim Testprojekt so gravierend anders, dass es da funktioniert und hier nicht?

Moin!

Viel Spaß dann bei der Entwicklung.

Oh, und wenn Du mit dem iPhone so überhaupt nicht zufrieden bist, lass lieber die Finger von dem Samsung Dreck und leg' Dir ein Google Nexus Gerät zu.
Samsungs Updatepolitik ist… ich bin mir ehrlich gesagt nicht sicher, ob die überhaupt existiert.

Was sagt LogCat? Vor Allem für den Bereit 'Error'?

Das hängt ganz davon ab, auf welche Javainternen Klassen sich diese Klassen beziehen.
Die Java Runtime wurde nicht 1:1 übernommen, also kann auch nicht alles, das auf einem Java Desktop funktioniert in Android laufen.
Hinzu kommt, dass Android Implementierungen für viele Sachen nutzt, die bei Java anders geregelt sind und entsprechend die Javainternen Klassen nicht eingebunden hat.

Was geht und was nicht ist schwer zu sagen, das musst Du für jede Klasse selbst herausfinden.
Eventuell hilft Dir die Dokumentation ein bisschen weiter, in der Du Dich von java.awt.font runterhangeln kannst.
http://developer.android.com/r…font/package-summary.html

Wenn Du mit einem Activity Stack arbeitest (also eine Activity die nächste aufruft und so weiter), dann beendet 'finish' nur die aktuelle Activity.
Dementsprechend springst Du auf die vorige Activity zurück.

Das ist gut so, das ist gewollt so, das entspricht den Navigatonsrichtlinien von Google Android.
Zum kompletten Verlassen ist immer noch der Home Button da.

Vergleiche die offizielle Dokumentation

Hier musst Du Dich wohl ein wenig in die Handler einlesen.

Stichwort: Im case MESSAGE_READ: alles einbauen, was Du zur Darstellung benötigst.

Magst Du bitte den Quellcode einmal im 'Quellcode' Modus des Beitragseditors zischen die code - Tags einfügen?
Sonst gehen die Zeilenumbrüche kaputt, und das ist wirklich ätzend. Vor allem bei so langen Codes.

Damit änderst Du den Pfad für das komplette Android SDK.
Hat natürlich den Vorteil, dass dann der ganze SDK Krams nicht auf dem Server landet.

Dosbox/Command Prompt/Power Shell öffnen.
Ins <AndroidSDK>/tools Verzeichnis wechseln

android.exe move avd --name Nexus_5_API_21_x86  --path D:/AVDs/Nexus5

(Name und Pfad entsprechend anpassen. Übersicht erhältst Du mit 'android.exe list avd')
Fertig.

Pro-Tipp:
Emulator sein lassen und Testgeräte kaufen lassen.
Testet und debuggt sich wesentlich schneller und angenehmer.