Beiträge von Temar

Zitat von marcel3067

Nach dem schreiben des Goldcard codes wurde die karte nicht mehr erkannt " Unbekanntes Datenformat"

Wie hast du denn das goldcard.img auf die Karte geschrieben? Unter Linux mit 'dd' oder unter Windows mit dem Editor?

Zitat

Nach einer Formatierung der KJarte ging es wieder, dann hab ich Daten aufgespielt, im Bootmenü bekomm ich jetzt "Not Allowed"

"Not allowed" bedeuted, dass dein G1 die Karte nicht als Goldcard erkennt. Da gibt es jetzt zwei Möglichkeiten:

• Du hast einen Fehler beim Abschreiben/Umschreiben der CID-Nummer gemacht.
• Beim Neuformatieren wurde der MBR neu geschrieben und damit der goldcard code gelöscht.

Zitat

Kann mir da jemand helfen?

Wenn du es nach Anleitung gemacht hast, dann sollte eigentlich kein Neuformatieren nötig sein, weil du nur den Bootcode ersetzt und nicht die Partitionstabelle überschreibst. Trotzdem kann man normalerweise bedenkenlos die Karte danach umpartitionieren und neu formatieren ohne dass der Goldcard-Code gelöscht wird.

Entweder hast du also die Karte beim Formatieren wirklich komplett neu initialisiert (inkl. Bootcode) und damit den Goldcard-Code überschrieben oder aber schlicht die CID falsch abgeschrieben oder falsch umgeschrieben. Überprüfe am besten erstmal, dass die CID stimmt und lass dir ein neues Goldcard-Image schicken. Dann schreib dieses Image drauf und versuche dabei die Partitionstabelle nicht zu überschreiben (Offsets im Disk-Editor beachten!). Wenn nach der ganzen Prozedur deine Partition noch funktioniert, du also nicht neuformatieren musst, dann sollte es auf jedenfall klappen.

HandyCalc kann Graphen plotten: http://handycalc.wordpress.com/

Zitat von Sico

wenn ich z.B. ein DateTime Month ausgeben will, kommt es vor, dass z.B. der Januar nur als 1 ausgegeben wird.

Zur Verarbeitung bräcuhte ich aber die Ausgabe 01.

Naja, getMonth() gibt ja nur nen Integer zurück. Diesen musst du in nen String konvertieren, wenn du sowas wie 01 haben willst.

Zitat

Wie stelle ich das am einfachsten an?

String month = String.format("%02d", date.getMonth());

Zitat von maxisma

Naja.. Cyanogen weiß was er tut.
Ich glaube er ist bisher der beste "CustomROM-Entwickler" den ich kenne..

Ich zweifele nicht die technische Kompetenz von Cyanogen an, sondern seine Entscheidung sowas auf die normale Userbasis loszulassen. Der Autor des BF-Schedulers selbst sagt ausdrücklich, dass der Code hoch experimentell, nicht vollständig und schon gar nicht gross getestet ist. Das ganze soll nur demonstrieren, dass der Linux CF-Scheduler im Desktop Bereich Schwächen hat.

Ich weiss nicht ob dir bewusst ist was ein Scheduler macht, daher schreib ich's hier einfach nochmal: Ein Scheduler verteilt die CPU-Zeit auf die einzelnen Prozesse die gerade Rechenzeit benötigen. Er managed sozusagen alle Programme und bestimmt wann welches Programm Rechenzeit erhält.

Ein Scheduler ist somit eine der zentralen Komponenten eines Kernels und sollte daher absolut stabil laufen. Cyanogens Entscheidung einen Scheduler aufzunehmen, der vor zwei Wochen das erste Mal erfolgreich gebootet wurde halte ich daher für eine reine Ego-Entscheidung. Hier geht es nur um den Schwanzvergleich zwischen Rom-Developern: "Mein Rom ist schneller als deins.". Das dabei die Daten der User flöten gehen können interessiert nicht.

Die Entscheidung ist insofern kritisch, weil Cyanogen genau weiss, dass die Masse seiner Benutzer keinen blassen Schimmer hat und einfach nur flasht was sie von ihm vorgesetzt bekommen.

Zitat von whitenexx

Die aktuelle Forenaufteilung (besonders ganz unten im Forumindex) gefällt mir nicht so gut.

Meinst du die Geräteliste? Ich finde die passt eigentlich.

Zitat

Was haltet ihr von einer Überarbeitung der Forenaufteilung? Hat jemand Vorschläge wie man einen guten übersichtlichen Index aufbauen könnte?

Das einzige was mich wirklich stört ist die Aufteilung in:

• Tutorials & Faqs
• Tutorials & Faqs : Anfänger
• Tutorials & Faqs : Fortgeschrittene

Was soll da wo rein? Was kommt in "Tutorials & Faqs" und was kommt in die Unterkategorien? Wer definiert eigentlich was ein Anfänger-Tutorial und was ein Fortgeschrittenen-Tutorial ist? Das ist doch immer relativ zum eigenen Wissensstand.

Zitat von whitenexx

Hmm bei dem Experimental ROM von cynanogen wurde der Scheduler getauscht, ist das auch beim neuen originalen Google ROM so? Oder nur bei "cynanogen"?

Bisher nur Cyanogen. Der Scheduler wird vermutlich auch nie Einzug in den Linux Kernel halten geschweige denn von Google in Android aufgenommen werden. Das ganze ist ein Proof of Concept um auf Probleme im Linux-Scheduler CFS aufmerksam zu machen. Ob BFS jemals "fertig programmiert" wird ist fraglich. Die Linux Entwickler sind schon dran die Probleme im CF-Scheduler zu finden und ihn anzupassen.

Aus den obigen Gründen bin ich auch kein Fan von Cyanogen Roms. Der BF-Scheduler hat das Licht der Welt am 25.08.2009 erblickt und ist somit gerade mal 2 Wochen alt, völlig ungetestet und eigentlich nur als "Proof of Concept" designed. Trotzdem ist das erste was Cyanogen macht dieses Ding in seinen Kernel reinzupatchen, obwohl er genau weiss, dass die Masse seiner Benutzer keine Ahnung hat von dem was er da macht und ohne Sinn und Verstand alles flasht was ihnen in die Finger kommt. Danach kommt dann wieder die Sintflut an Problempostings, weil sich die User alle möglichen Probleme einfangen.

EDIT:

Zitat

Weiß zufällig jemand wie genau BFS funktioniert bzw. wo der allgemeine Unterschied zwischen BFS und dem alten Scheduler ist? (außer jetzt das BFS nicht so aufgeblasen ist mit altem Code...)

Er verteilt einfach alle Prozesse die nicht idle sind extrem aggressiv auf alle Rechenkerne, ohne Rücksicht auf Caching oder ähnliches zu nehmen. Das macht ihn extrem simple, allerdings auch ungeignet für große Systeme mit mehr als 16 Kernen.

Zitat von schlüpferknoten

und wegen dem schnellen rom: da kann ich nur das neue von cyanogen empfehlen. er hat da was eingebaut was das handy unglaublich schnell macht.

Ja, das ist der neue BFS Scheduler: http://thread.gmane.org/gmane.linux.kernel/886319

Den sollte man aber mit vorsicht geniessen. Der Entwickler des BFS schreibt:

Zitat

The unfortunate part is that BFS is still far from a working, complete state, yet word got out that I had "released" something, which I had not, but obviously there's no great distinction between putting something on a server for testing, and a real release with an announce.

Das ganze ist nur eine Testversion, die weit entfernt von vollständig ist. Es kann also zu allerlei Problemen kommen (wie man auch aus Berichten auf der ML entnehmen kann). Wer eine stabiles System will sollte auf den BFS verzichten.

Zitat von whitenexx

Der Drawer (Apps-Menü), das aufmachen und schließen des Menüs ruckelt.

Das ruckt bei mir auch mal ganz kurz beim Öffnen. Danach ist's flüsig. Muss halt erst die Icons laden. Den Drawer benutze ich aber eh kaum, weil ich wie gesagt alles Wichtige auf den Desktops habe.

Zitat

Ich hätte nicht gedacht das der Flashspeicher so schnell kaputt geht...also schon klar das der nach einer gewissen Anzahl von Schreibzugriffen kaputt geht, aber das es nun sooo viele sind (bei dem kleinen Gerät)...hm die Größe mag täuschen. Ist ja ein fast vollwertiges Linux drauf.

Das Problem ist ja nicht Linux an sich, sondern der zu kleine Speicher. Linux kann ja nix dafür dass es auslagern muss, weil du andauernd neue Apps startest

So ein Flash-Block überlebt etwa 100.000 (Quelle: Wikipedia) Schreib-Lösch-Zyklen - mit wear levelling kann man das bedeutend nach oben pushen. Das haben aber nur die teueren Karten. Bei den billigen Karten muss sich das Dateisystem darum kümmern. Das macht aber weder ext2/3/4 noch eine Swap Partition. Bei billigen Karten müsstest du also eine Partition anlegen, diese mit einem Flash-Filesystem formatieren und darin dann eine Swap-Datei anlegen - das macht aber keiner. Teure Karten können das wie gesagt selbst ausgleichen.

Jetzt mal eine einfache Überschlagsrechnung: Sagen wir mal ein Block hat eine Größe von 64Kb. Die Karte schafft 6MB/s, also könntest du einen Block 96 mal pro Sekunde schreiben. Da aber so ein Block immer erst gelöscht werden muss, halbieren wir die Anzahl auf 48 mal schreiben pro Sekunde. Um die 100.000 Schreib-Lösch-Zyklen für einen Block zu erreichen benötigst du also ca. 2084 Sekunden. Wenn du es drauf anlegst, kannst du also deine SD-Karte in 34 Minuten schrotten.

In täglichen Betrieb dauert das natürlich länger. Bei billigen Karten, die kein wear levelling machen werden allerdings immer die gleichen Blöcke geschrieben. Wie gesagt nimmt eine Swap-Partition keine Rücksicht auf den Datenträger - sie beginnt mit dem swappen am Anfang und schreibt nach hinten. Die Daten werden nicht gleichmässig verteilt. Somit sind 100.000 Scheibzugriffe doch recht schnell erreicht. Bei intensiver Nutzung kannst du ne billige Karte leicht in nem halben Jahr schrotten.

Zitat von whitenexx

Das oben genannte Szenario war auch mehr ein Beispiel.
Also im Prinzip möchte ich morgens in der Bahn z.B. Musik hören, gleichzeitig Mails checken und was twittern. Vielleicht auch noch das ein oder andere laufen haben... (zur Zeit ist das nur schwer möglich, Musik stockt manchmal)

Hehe, noch nie probiert - so multitaskingfähig bin ich nicht

Zitat

Im Moment ruckelt es schon, wenn ich "nichts" laufen habe ( das Menü ).

Das Apps-Menü (Drawer)? Oder der normale Desktop, wenn du umschaltest?

Ich verwende den Drawer nur sehr selten. Alle wichtigen Apps hab ich auf den Desktops verlinkt.

Zitat

Vermutlich liegts stark an der SD Karte, da die Icons von den Apps jedesmal von SD geladen werden.

Wenn du Maxima verwendest, dann hast du ja eigentlich schon Swap. Demnach werden die Icons wohl aus dem Swap ausgelagert. Ne schnellere Speicherkarte kann auch jedenfall nicht schaden.

Zitat

Du scheinst ja eine Tendenz gegen Swap zu haben. Oder täusche ich mich?

Ich habe generell erstmal nix gegen Swap, es gibt nur einfach besseren Ersatz. Also warum mit etwas rumärgern, wenn es Besseres gibt?

Zudem muss man wissen auf was man sich bei Swap einlässt. Spätestens wenn die SD-Karte anfängt den Geist aufzugeben, dann kommt es zu ganz eigenartigen Problemen. Apps stürzen sporadisch ab (bis hin zum kompletten Systemcrash), Datenverlust, Hänger bei den Apps, usw. Das ganze ist schleichend und bis man es wirklich auf die SD-Karte schiebt ist es vielleicht zu spät.

Zitat

Ich sehe dich als erfahrenen User, deswegen muss ich mir nun stark überlegen ob es Sinn macht auf der neuen Karte Swap zu nutzen...oder doch lieber Compcache...

Nunja, das kommt ja stark auf deine Anforderungen an. Wenn du wirklich soviel Anwendungen parallel laufen haben willst, dann bist du vielleicht mit Swap besser bedient (einfach beides mal ausprobieren). Jetzt weisst du ja auf was du dich einlässt. Wenn dich der Preis der SD-Karten nicht stört, dann ist es ja durchaus legitim Swap zu verwenden. Grosse Class-6 Karten (8-16GB) kosten allerdings schnell mal 80 Euro und mehr und da sag ich mir halt, dass mir der Swap-Spass zu teuer kommt. Ganz abgesehen davon, dass in meinem Anwendungsfall Compcache sowieso schneller ist.

Zitat von whitenexx

Ja, aber dann nicht so viele Apps. Ich möchte schon ein paar Apps mehr im Hintergrund laufen lassen, wenn es geht. (Twitter, IM, Mail, Browser usw.)

Mit einer Swap-Partition wird die Größe des Speichers nur durch die Größe deiner SD-Karte eingeschränkt. Je größer deine Swap-Partition, desto mehr Speicher hast du. Ob das Sinn macht ist jetzt ne andere Frage.

Der ständige Zugriff auf die SD-Karte zum einlagern und auslagern von Speicherseiten, dazu noch die Rechenzeit aller Programme dürfte einiges an Batterie kosten. Wenn du andauernd Apps wie z.B. IM oder Twitter laufen hast, dann kann dein Handy auch niemals vollständig in Standby schalten.

Warum jetzt der Browser oder Mail unbedingt dauernd laufen müssen ist mir auch ein Rätsel. Mails kannst du auch in festen Intervallen von 5 Minuten checken. Dann könnte dein Handy zumindest 4 Mins und 59 Seks in Standby schalten.

Zitat

Ich vermute mal bei Class6 Karten gibts von Hersteller zu Hersteller Unterschiede, gibts schon irgendwo Benchmarks oder welche Karte empfiehlt ihr mir?

Generell heisst Class-6 erstmal, dass die Karte eine garantierte Transferrate von 6MB/s schafft. Keine Ahnung ob es einen Hersteller gibt wo die Karten im Mittel deutlich mehr machen.

Zitat von whitenexx

Okay dann stell ich noch eine Frage: Mit welcher Konfiguration kann ich mehrere Apps gleichzeitig ausführen?

Versteh die Frage nicht. Das kannst du doch so und so. Sogar ganz ohne Compcache oder Swap.

Zitat

Kann man nicht Swap + Compcache kombinieren?

Ja, aber das ist sinnlos. Dann hast du die Nachteile aus beiden Welten.

Zitat

Der Lebenszyklus einer SD Karte spielt doch eigentlich nicht so eine "große" Rolle, bei den aktuellen Preisen...

Kauf dir erstmal ne 8 oder 16GB Class 6 Karte. Dann reden wir weiter.

Zitat

Wie ist das eigentlich mit Apps2SD, kann ich gewisse "ausgewählte" Apps auch intern speichern/installieren?

Ja, wenn du auf deiner System-Partition genug Platz hast. Musst du allerdings per Hand machen und Updates musst du dann auch manuell machen.

Du könnest auch ein paar Apps auf die interne Apps-Partition verschieben und dann mit nem symbolischen Link auf der Apps2SD-Partition wieder einbinden. Dann würde zumindest das Update wieder funktionieren.

Zitat

Oder ist das ein simples mounting des Installationsverzeichnisses auf SD? Dann ist es ja nicht mehr so einfach glaub ich.

Der ganze App-Ordner wird einfach von der SD-Karte gemounted.

Zitat

Hmm das glaub ich nicht so ganz. Ich mein es gibt so viele tolle ROMs, viele Optimierungen und und und, ich denke da wird doch wohl noch einiges mehr als beim original ROM gehen. Sonst würde ja jeder einfach beim originalen bleiben.

Die ganzen Community-Roms fügen neue Features hinzu, wie z.B. mehrere Desktops oder sogar komplett neue Oberflächen (Hero). Das alles kostet Speicher und Ram ist nunmal der Haupt-Performancekiller auf dem G1. Da hilft auch das hochtakten der CPU nix. Man muss sich halt zwischen Features (Komfort) und Performance entscheiden.

Zitat

Welches ROM benutzt du Temar?

Das Originalrom mit Root und ein paar Erweiterungen von mir.

Zitat von Spartacus

ich habe in letzter Zeit viel über den sock_sendpage() Exploit gelesen, der scheinbar sauber funktioniert und bis Kernelversion 2.6.29.
Ein blick in die Telefoninfo des G1 verrät: Kernelversion 2.6.27

2.6.27 heisst nicht automatisch, dass der Kernel anfällig ist. Auch den 2.6.27er Kernel kann man patchen. Das wurde wohl mit dem neuesten Update gemacht.

Zitat

Nun stellt sich doch die Frage ob es nicht möglich wäre, spätestens seit das NDK erschienen ist, um C-code in Android apps zum laufen zu bringen, ein app zu schreiben, welches das Handy rootet.

Die App gibt's schon. Findest du bei xda-devlopers.com.

Zitat

Das wäre doch eine viel saubere Lösung als das Upgraden auf ein Community-image, nachdem man auf rc29 gedowngraded hat.

Du musst ja nicht auf ein Community Image upgraden. Es reicht eigentlich wenn du deinen SPL und das Recovery-Image austauschst. Allerdings kann es dir passieren, dass dein Recovery und/oder der SPL mit einem zukünftigen Update wieder überschrieben wird. Dann musst du wieder downgraden um erneut Root zu bekommen.

Mit der offiziellen Firmware kann es dir halt jederzeit passieren, dass deine Root-Bemühungen wieder zunichte gemacht werden. Auf der anderen Seite muss man sich die Frage stellen ob man Root überhaupt braucht.

Zitat von whitenexx

Soweit läuft alles gut, aber irgendwie ist das ganze System nach einiger Zeit ziemlich schnell lahm (auch wenn man alle Tasks killt), was vielleicht daran liegt, dass ich viele Applikationen installiert habe.

Viele Applikationen sollten nicht stören, da die ja in der Regel nicht aktiv sind. Die Anzahl der Applikationen spielt eigentlich nur dann eine Rolle, wenn du sie dir auflisten lässt, z.B. wenn du den Drawer öffnest oder im Market auf "Meine Downloads" gehst.

Zitat

Nun hab ich herrausgefunden, dass dieses Geschwindigkeitsproblem vielleicht an meiner SD-Karte liegt, denn ich nutze die originale 2GB miniSD. Scheinbar ist die zu langsam? (Ich hab ja Swap auf SD ausgelagert)

Das kann gut sein, besonders wenn dein System viel swapt. Eine Class 6 Karte schadet auf jedenfall nicht

Zitat

Meint ihr das könnte daran liegen? Wie ist das mit Apps2SD, das ist ja standardmäßig beim maxisma ROM dabei und aktiv, aber irgendwie finde ich die Apps nicht auf der SD....vielleicht sind die doch im internen Speicher?!

Die sind auf einer Linux-Partition. Deshalb siehst du sie auch nicht auf der normalen SD-Karten-Partition. Mit einem Root-File-Manager kannst du dir die Apps anzeigen lassen.

Zitat

Wie kann ich Apps2SD überprüfen?

Im Terminal "mount" eingeben, dann Pfad checken wo das Apps2SD gemounted ist.

Zitat

Desweiteren: Was ist nun besser? Swap, Compcache, oder beides?

Compcache, aus 2 Gründen:

• Die Performance ist besser als bei Swap.
• Compcache belastet deine SD-Karte nicht.

Besonders wenn du Anwendungen starten willst ist Compcache schneller, da beim einlagern und auslagern von Seiten ja deine SD-Karte gefragt ist. Wenn du dann gleichzeitig noch ne App startest (über Apps2SD) dauert das halt. Der aber aus meiner Sicht wichtigste Punkt ist, dass Compcache deine Karte nicht belastet. Eine SD-Karte erlaubt halt nunmal nur eine gewisse Anzahl an Schreibzyklen. Danach kannst du sie wegschmeissen. Dauerndes swappen geht massiv auf die Lebensdauer der Karte.

Zitat

Welches ist denn zur Zeit das schnellste und beste ROM für das G1? (Ohne jetzt aufs Design zu achten)

Das Schnellste Rom ist vermutlich das Original-Rom. Das beste Rom liegt im Auge des Betrachters.

Ah, gut zu wissen. Danke dass du deine Lösung gepostet hast.

Zitat von delicious2k

wie kann ich jetzt anständig einen OnClick event für den "Variablen" tab??

Dieser Satz kein Verb

Ich nehme mal an, du willst abfangen wenn das "Variablen" Tab aktiviert wird. Das kannst du über die setOnTabChangedListener() Funktion der Klasse TabHost machen.

Zitat von Killua

Ist es im wesentliche egal welche der zwei Funtkionen ich in der main activity ("getDefaultSharedPreferences" oder "getSharedPreferences") verwende ?

getSharedPreferences() nimmt die Shared-Preferences des aktuellen Contexts. getDefaultSharedPreferences() nimmt immer die globalen SharedPreferences().

Zitat

Ich mein klar man hat bei dem erst genannten noch den default wert aber der ist doch nicht zwingend notwenig oder ?

"Default" bezieht sich hier auf die Default-Datenbank. Es wird also die Standarddatenbank verwendet, in welcher alle globalen Preferences abggelegt werden. Du kannst ja auch Preferences nur zwischen bestimmten Activities sharen indem du sie in einer anderen Datenbank ablegst.

Zitat

Was die Ausgabe angeht, klar die lässt sich zum Beispiel mit TextView realisieren - das kann man doch aber bestimmt auch xml seitig realisieren oder ?

Klar, einfach ein XML-Layout mit den Widgets definieren und die Werte der TextViews dann in der onCreate() Methode der Activity setzen.

Zitat

- ok du meinst also xml vom server abrufen schauen was drinsteht und wenn vibirieren gefordert ist das flag prüfen, also den wert aus der datenbank abrufen ob true oder false - jo das ist ne gute Lösung.

Du kannst das checken der Einstellungen auch in die Vibrator-Klasse verschieben. Also dein Hauptprogramm läd die XML-Datei runter und checkt ob es vibrieren soll. Wenn es vibrieren soll, dann ruft es immer MyVibrator.vibrate() auf. Die MyVibrator.vibrate() Methode prüft dann die Preferences und vibriert falls gefordert. Dadurch ist es egal von wo in deiner Applikation du vibrieren willst - du kannst einfach vibrate() aufrufen und es wird nur vibriert falls das auch in den Preferences aktiviert ist.

Zitat

Du verwendest oben in deinem Beispiel getDefaultSharedPreferences - getDefaultSharedPreferences benötigt doch einen wert der übergeben werden soll (context) quasi den default wert, handelt es sich bei diesem default wert um das was übergeben wird wenn die anfrage nach dem eigentlichen z.b. pref_checkbox negativ verläuft ?

Ich verwende getDefaultSharedPreferences() weil es einfacher ist. getDefaultSharedPreferences() ist eine statische Funktion - sie benötigt also, im Gegensatz zu getSharedPreferences(), keine Instanz des PreferenceManagers. Den Wert, den man getDefaultSharedPreferences() übergenen muss ist der aktuelle Context. Da jede Activity von Context abgeleitet ist, kannst du einfach deine aktuelle Activity übergeben.

SharedPreferences preferences = PreferenceManager.getDefaultSharedPreferences(this);

ist einfach kürzer und sauberer als:

PreferenceManager prefman = new PreferenceManager();
SharedPreferences preferences = prefman.getSharedPreferences();

Zitat

handelt es sich bei diesem default wert um das was übergeben wird wenn die anfrage nach dem eigentlichen z.b. pref_checkbox negativ verläuft ?

Wenn die Anfrage nach pref_checkbox negativ verläuft, dann wird immer der zweite Wert der Getter-Methode zurückgegeben:

preferences.getBoolean("pref_checkbox", false);
preferences.getString("pref_username", "Ich bin ein Default-Wert");

Im ersten Beispiel wird also false zurückgegeben, falls "pref_checkbox" in der Datenbank nicht existiert. Im zweiten Beispiel wird "Ich bin ein Default-Wert" zurückgegeben falls "pref_username" nicht existiert.

Zitat von Killua

In erster Linie war es der Aufbau eines Menüs(Als zum einen das Menü, welches durch die Menütaste erscheint und darauf dann die preferences) ...in Verbindung damit, die Eingabe von Daten wie Benutzername und Passwort, welche gespeichert werden sollen....danach das aktivieren/deaktivieren des vibrators durch eine checkbox. Soweit sind wir im Prinzip....folgendes soll nun erstmal folgen...

Ok, das solltest ja jetzt soweit laufen.

Zitat

Die eingebenen Daten sollen in der Main Activity ausgegeben werden (Quasi man statet das Programm und sieht dann Ihr Benutzername ist xyz und ihr Passwort: qwert..... das Ziel davon soll eigentlich nur sein das ich quasi Prüfen kann ob die Felder ausgefüllt sind und zum anderen den Benutzer gleich beim Start darüber informieren kann das alles ok ist.)

Die Daten kannst du dir ja jetzt in deiner MainActivity direkt über die SharedPreferences besorgen und dann überprüfen ob sie Ok sind.

SharedPreferences preferences = PreferenceManager.getDefaultSharedPreferences();


boolean value_check = preferences.getBoolean ("pref_checkbox", false);
String value_user = preferences.getString ("pref_username", "");
String value_pass = preferences.getString ("pref_password", "");

Die Ausgabe sollte dann auch kein Problem mehr sein.

Zitat

Danach ist es mein Ziel natürlich die eingegeben Daten Sinvoll zu verarbeien....in dem ich z.b. zu irgend einem Server Connecte auf dem z.b. eine xml datei liegt. Mein Programm soll diese xml auswerten können (nichts aufwendiges), quasi findet es die info "vibrieren" (ihr auch die antwort auf deine frage auf was ich mit der vibrieren funktion hinaus möchte) und prüft daraufhin ob er überhaupt vibrieren darf (ist in den preferences der haken grün).

Das ist dann auch der Moment in dem dein Programm checken sollte, ob das "Vibrieren"-Flag gesetzt ist - also genau bevor es vibrieren würde. Das Parsing einer XML Datei dauert aus der Sicht der CPU eh schon ewig und somit kommt es auf die minimale Verzögerung beim Auslesen des Vibrieren-Flags aus der Datenbank auch nicht mehr an. Anders würde es aussehen, wenn du alle paar Millisekunden entscheiden müsstest ob das Handy vibrieren soll oder nicht. Dann müsste man sich über Änderungen an den Preferences informieren lassen, weil andauerndes Polling der Datenbank einfach zuviel Ressourcen brauchen würde.

Zitat von Killua

Du meinst also die vibartor funktion sollte darauf lauschen wenn man so sagen kann - wenn die Einstellung geändert werden. Und nicht umgekehrt.... allein schon deswegen um dem von dir Beschrieben Problem vorzubeugen.

Das hört sich in der Tat besser an allerdings hab ich die SDK jetzt schon des öfteren gewälzt und mir ist bis dato keine methode aufgefallen die das kann....Hättest du den Namen parat ?

Das mit dem Lauschen ist nicht so einfach. Es gibt zwar einen onPreferenceChangeListener aber der informiert einen nur über Änderungen an der eigenen Instanz der Preference (soweit ich das jetzt im Kopf habe - müsste nachschauen). Der Vibrator müsste also selbstständig Änderungen erfassen. Die Implementierung hängt also davon ab was du vor hast.

Beschreib doch mal was du genau machen willst, dann können wir schauen wie eine elegantere Lösung ausschauen könnte.

Zitat

P.s.: Vielen Dank das du immr so ausführlich Antwortest, man trifft selten jemand in einem forum der einem gleich sogut hilft Vielen Dank

Kein Problem. Wir haben ja alle mal irgendwann angefangen.

Zitat von Killua

Soweit funktioniert auch alles wunderbar....sehe ich es richtig das ich keine kürzere/andere Möglichkeit habe als so vorzugehen, wenn ich über den status des buttons (ob grün oder net) entscheiden will was passieren soll....

Nicht unbedingt kürzer, aber wesentlich lesbarer/wartbarer:

public boolean onPreferenceClick (Preference preference)
{
    SharedPreferences preferences = getPreferenceManager().getSharedPreferences();


    if (preference.getKey().equals("pref_checkbox"))
    {
        String toast_message = null;


        if (preferences.getBoolean("pref_checkbox", false))
        {
            toast_message = "Aktiviert";
            Vibrator.vibrate(9223372036854775807L);
        }
        else
        {
            toast_message = "Deaktiviert";
            Vibrator.cancel();
        }


        Toast.makeText(EditPreferences.this, toast_message, Toast.LENGTH_SHORT).show();


        return (true);
    }


    return (false);
}

Aber damit wir über das gleiche Thema reden: Es geht hier um persistente Einstellungen. Es ist nicht sehr elegant die Klicks abzufragen und daraufhin eine Klasse zu manipulieren. Wenn du nämlich von einer anderen Klasse als der EditPreferences aus die Einstellungen veränderst, dann bekommt das der Vibrator nicht mit. Der sauberere Weg ist es also die Vibrator Klasse abzuleiten und sie die Einstellungen abfragen zu lassen. Dann ist es nämlich egal wo du in deinem Programm die Preferences veränderst.

Zitat

...und sehe ich es richtig das ich ebenfalls die SharedPreferences Funktion verwenden muss wenn ich zum Beispiel auf das Benutzernamen oder Passwortfeld zugreifen möchte - um den Inhalt zu ermitteln ?

Das machst du genauso wie bei der Checkbox. Nur heisst die Funktion zum abfragen des Werts dann nicht getBoolean() sondern getString() - also getString("pref_username", "");

Zitat

(Wo speichern meine Anwendung das eigentlich, also die Infos die der Benutzer eingeben hat ?)

In einer sqlite Datenbank. Die Einstellungen sind also persistent.

Zitat von Killua

thx - eine Frage - du verwendest bei dem ersten als return typ boolean....es gibt aber gar kein return...ist der return immer true ?

Oh ja, sorry. Ich hab das mehr so aus dem Kopf zusammengetippt - war mehr als Pseudo-Code gedacht. Du musst True zurückgeben, wenn dein Listener den Click behandelt, ansonsten False. False signalisiert Android, dass das Click-Event weiter nach unten durchgereicht werden muss, so dass andere Handler den Click behandeln können. True signalisiert, dass das Event behandelt wurde und nicht weiter durchgereicht werden soll.

Also musst du beim zweiten Beispiel True zurückgeben und das erste Beispiel muss so aussehen:

public boolean onPreferenceClick (Preference preference)
{
     if (preference.getKey().equals("pref_checkbox"))
     {
         // checkbox wurde geklickt
             
         return (true);
     }


     return (false);
}