Beiträge von Temar

    Zitat von Killua


    gibt es den eine Funktion welche automatisch ausgeführt wird sobald der Button gedrückt wird ? - also quasi sowas wie ein interrupt


    Entweder so:


    Beim oberen Code die "implements" Anweisung bei der Klassendeklaration beachten!



    Oder so:


    Natürlich solltest du überall noch auf null testen, denn findPreferences() gibt null zurück, falls der Identifier ungültig ist.

    Zitat von Killua


    Was macht es für einen Unterschied wenn ich z.b. in der preferences.xml eine Checkbox anlege...

    PHP
    <CheckBoxPreference  
    android:key="pref_checkbox"  
    android:title="@string/pref_checkbox_title"  
    android:summary="@string/pref_checkbox_title_summary">
    </CheckBoxPreference>


    oder direkt in meinem Programm...

    PHP
    CheckBoxPreference auth = new CheckBoxPreference(this);
    auth.setTitle(R.string.pref_checkbox_title);
    auth.setSummary(R.string.pref_checkbox_title_summary);
    auth.setKey("pref_checkbox_test");
    getPreferenceScreen().addItemFromInflater(auth);


    Die XML Lösung ist sauberer, weil:


    • Weniger Fehleranfällig, weil weniger Code.
    • Zukunftssicherer bei eventuellen SDK-Änderungen.
    • Dein Code kann sich auf die Geschäftslogik konzentrieren => Besser lesbarer Code.


    Zitat


    Und meine zweite Frage wäre wie bzw. über was ich die Checkbox (welche ich in der xml datei angelegt habe) anspreche ?


    Mit Hilfe des Identifiers. Dabei hast du fünf Möglichkeiten:


    • Mit findPreference() innerhalb der PreferenceActivity um die GLOBALEN Preferences anzusprechen
    • Mit getPreferenceManager().getSharedPreferences() innerhalb der PreferenceActivity um die GLOBALEN Preferences anzusprechen.
    • Mit getPreferences() innerhalb einer Activity um die LOKALEN Preferences DIESER Activity anzusprechen.
    • Mit getSharedPreferences() innerhalb einer Activity um die GLOBALEN Preferences anzusprechen.
    • Mit PreferenceManager.getDefaultSharedPreferences() um die GLOBALEN Preferences aus einem beliebigen Context anzusprechen.


    Deine Checkbox hat also die Id "pref_checkbox".


    INNERHALB der PreferenceActivity kannst du die Checkbox so ansprechen:


    Code
    // Möglichkeit 1: findPreferences()
    // Damit bekommst du ein Handle auf eine preference Instanz
    Preference pref_checkbox = findPreference ("pref_checkbox");
    
    
    // Möglichkeit 2: getPreferenceManager().getSharedPreferences()
    // Damit kannst du den Wert direkt abfragen ohne Preferences Instanz.
    SharedPreferences preferences = getPreferenceManager().getSharedPreferences();
    boolean value = preferences.getBoolean ("pref_checkbox", false);



    Aus einem BELIEBIGEN Context kannst du so auf die SharedPreferences zugreifen:


    Code
    // Möglichkeit 5: Von irgendwo auf die GLOBALEN Preferences zugreifen.
    SharedPreferences preferences = PreferenceManager.getDefaultSharedPreferences();
    boolean value = preferences.getBoolean ("pref_checkbox", false);


    Möglichkeit 3 und 4 gehen analog. Bei Möglichkeit 5 kannst du auch findPreferences() verwenden, sofern du eine Instanz des PreferenceManagers hast.

    Zitat von loeppel


    Ja das meinte ich ja auch, wie ist es mit JNI ist das Verfügbar? Gibt ja noch weitere methoden um auf native Libs zuzugreifen - was würde sich da eigenen.


    JNI geht und sollte sich eignen. Willst ja eh nur eine handvoll Funktionen von libotr aufrufen.


    Zitat


    Ein Java IM gibts irgendwie kaum, also zumindest aktive mit Multi-Protokoll. Wie gesagt die WebApp die ich gepostet habe taugt ganz gut und nutzt ein paar upstream libs für die Protokolle, da könnte man sich einiges "abschauen".


    Naja, es gibt einige Java-Libraries für verschiedene Protokolle. Die sollte man eigentlich relativ einfach auf Android portieren können:


    Jabber: http://www.igniterealtime.org/projects/smack/
    MSN: http://jml.blathersource.org/
    Yahoo: http://jymsg9.sourceforge.net/


    Mehr konnte ich auf Anhieb nicht finden. Gibt aber bestimmt auch eine ICQ Java-Implementierung.


    Ich würde einfach die Android GoogleTalk App forken, dann haste Jabber abgedeckt und schonmal was lauffähiges mit dem du in aller Ruhe die libotr testen kannst. Sobald das dann läuft kann man sich der Unterstützung anderer Protokolle widmen.

    Die normale Mail App ist äusserst bescheiden und hat Probleme mit vielen IMAP Servern. Deshalb hat sich jemand hingehockt und das Ding geforkt. Nennt sich K9-Mail und gibt's im Market.

    Meine Favs:


    - Astrid
    - Note Everything
    - Wapedia
    - K9-Mail
    - Ebay Pkt Auction
    - Toggle Settings
    - Car Mode Widget
    - Klicktel
    - Alk Copilot
    - G-Mon
    - TasKiller
    - SnapPhoto
    - ConnectBot
    - AndFTP
    - ES File Explorer
    - Translate
    - Better Terminal Emulator
    - Oi Safe
    - Wikitude
    - Qype

    Zweiter Teil:


    So, wie sieht nun die Klasse EditPreferences aus. Erstaunlich einfach, nämlich so:



    Die Android Klasse "PreferenceActivity" erledigt alle Aufgaben für uns. Das einzige was wir ihr mitteilen müssen ist, wo sie die XML Datei findet, die alle unsere Preferences enthält - nämlich "R.xml.preferences". Der Identifier ist aus dem Ordner und dem Namen der Datei zusammengesetzt. Den Namen der Datei darfst du frei wählen (in diesem Fall "preferences") und der Ordner ist immer "xml", da es sich um eine allgmeine XML Datei handelt. Du legst also im Ordner "res/", unterhalb von "xml/" eine Datei mit dem Namen "preferences.xml" an. Die könnte z.B. so aussehen:


    res/xml/preferences.xml:


    Das ganze ist aus einem Projekt von mir bei dem der Benutzer seinen Benutzernamen und ein Passwort eingeben muss, damit ich im Namen des Benutzers auf einen Dienst im Internet verbinden kann. Symbolisch enthält dieser Einstellungsdialog also eine Kategorie für alle Account-Informationen und zwei Textfelder für den Login und das Passwort.


    Die Kategorie hat einen Titel, dessen String in der strings.xml mit der Id "pref_account_title" hinterlegt ist. Dann gibt es das erste Textfeld für den Benutzernamen, welches die Id "pref_account_username" hat. Dieses Textfeld benötigt eine Zusammenfassung (summary) als Hilfetext, einen Titel (title) für den Namen der Einstellung und einen Dialog Titel (dialogTitle) für den Dialog der eingeblendet wird, wenn der Benutzer einen Wert eingeben will. Diese Strings sind unter den Ids "pref_account_username_summary", "pref_account_username_title" und "pref_account_username_dialogTitle" hinterlegt. Das gleiche gilt für das Passwort Feld mit der Id "pref_account_password".


    Wir erweitern also unsere strings.xml, so dass das ganze so aussieht:



    Damit haben wir jetzt alle Daten angegeben und Android kann den Einstellungsdialog anzeigen, sobald man auf den Menüpunkt in der Activity klickt. Alle Daten die der Benutzer angibt werden automatisch gespeichert.


    Eine Liste aller möglichen Einstellungsdialoge findest du in der SDK Dokumentation. Im wesentlichen kannst du alle Dialoge nutzen, die Android anbietet (TextDialog, Radio-Buttons, Multiple-Choice, DropDown-Lists, usw.).[hr]

    Zitat von Killua


    Ich hab jetzt auch soweit alles angepasst - eine fragen hätte ich aber....und zwar das "@+id" in der xml datei bedeutet das die id einfach hochgezählt wird ?


    Nein, das heisst einfach nur, dass danach der Name eine Identifiers angegeben wird. Wofür genau das "+" Zeichen steht hab ich vergessen. Ist aber auch nicht wichtig. In der SDK-Dokumentation ist das irgendwo erklärt. Da man aber eh immer "@+id/" schreiben muss habe ich das verdrängt.

    Zitat von Killua


    Allerdings hatte ich bisher mit Zahlen bei der Zuweißung der casefälle gearbeitet. Daher eine kurze Frage - was bedeutet das "R.id." vor dem main_menu_options_prefs.


    Ok, sehe schon wir müssen etwas weiter ausholen. Die Klasse "R" wird automatisch von der Android Build-Umgebung erzeugt. R steht dabei für "Resource" und somit enhält die Klasse alle XML Dateien, die du im Ordner "res/" erzeugst.


    Auf diese Weise kannst du ganz einfach Menüs erstellen, ohne dich um irgendwelche Nummern kümmern zu müssen. Das ganze geht auch mit Strings, Preferences, Layouts, usw. - eben alles was du in die XML Dateien unterhalb von "res/" reinschreiben kannst. Jeder Eintrag in den XML Dateien erhält dabei einen eindeutigen Identifier. Diese identifier kannst du über die Klasse "R" ansprechen und Android weiss dann was gemeint ist.


    Wie erstellt man jetzt also einen Menüeintrag "sauber"? Zuerst mal überlegst du dir einen Namen für die XML Datei, die alle Menüpunkte für deine Activity enthalten soll. Da unser Beispiel-Menü in der Main-Activity eingeblendet werden soll und Einträge für das Optionen-Menü enthält, nenn ich das ganze jetzt mal "main_menu_options.xml" (der Name ist egal, du solltest dir aber ein Schema überlegen). In dieser Datei soll es einen Menüpunkt geben mit der Aufschrift "Einstellungen". Du erstellst also die Datei "res/menu/main_menu_options.xml" und schreibst da folgendes rein:


    res/menu/main_menu_options.xml:

    Code
    <?xml version="1.0" encoding="utf-8"?>
    <menu xmlns:android="http://schemas.android.com/apk/res/android">
        <item android:id="@+id/main_menu_options_prefs"
            android:icon="@android:drawable/ic_menu_preferences"
            android:title="@string/main_menu_options_prefs_title"/>
    </menu>


    Damit definieren wir also ein neues Menü mit einem Menüeintrag für "Einstellungen". Der Name des Menüeintrags ist "main_menu_options_prefs", er hat ein Icon mit der Id "drawable/ic_menu_preferences" und einen Titel mit der id "main_menu_options_prefs_title". Die Id des Menüeintrags darfst du frei wählen, es macht aber Sinn, wenn sie in dein Schema passt - daher "main_menu_options_prefs". Das Icon wird von Android zur Verfügung gestellt, daher beginnt auch der Eintrag mit "@android:". Eine Liste aller Icons findest du irgendwo in der SDK Dokumentation. Den Title wiederum definieren wir selber (soll "Einstellungen" sein und daher vergeben wir wieder eine Id, die in unser Schema passt: "main_menu_options_prefs_title". Damit haben wir jetzt einen gültigen Menüeintrag erstellt - allerdings funktioniert er noch nicht, da wir uns zwar eine schöne Id für unseren Titel ausgedacht haben, aber diese Id noch nicht definiert haben. Wir müssen also "main_menu_options_prefs_title" erstmal definieren.


    Wie alle Strings, die du irgendwo in deinem Programm definierst, schreibst du die Übersetzung von "main_menu_options_prefs_title" einfach in die die strings.xml welche du unter "res/values/strings.xml" findest oder neu erstellen musst. Das sieht dann so aus:


    res/values/strings.xml:

    Code
    <?xml version="1.0" encoding="utf-8"?>
    <resources>
        <string name="main_menu_options_prefs_title">Einstellungen</string>
    </resources>


    Warum so umständlich? Warum schreiben wir nicht einfach den String "Einstellungen" in die res/menu/main_menu_options.xml Datei?


    Das geht zwar, ist aber schlechter Stil. Wann immer du einen String benötigst - ganz egal wo in deinem Programm - solltest du einen Eintrag in der strings.xml definieren und diesen dann über R.string.<id> ansprechen. Das hat den Vorteil, dass du dann nur deine strings.xml übersetzen musst und schon kannst du dein Programm für alle möglichen Sprachen anbieten oder zur Laufzeit zwischen z.B. Deutsch und Englisch hin- und herschalten.


    Nachdem wir jetzt ein Menü definiert haben und einen gültigen Menüeintrag können wir das ganze jetzt in unserer Activity mit Hilfe der Methoden onCreateOptionsMenu() und onOptionsItemSelected() aktivieren:




    Zitat


    Der teil mit startActivity war mir nicht bekannt. Daher habe ich nun , um bei dem Namen zubleiben, eine EditPreferences.class angelegt.


    Um zu deiner letzten Frage zu kommen, nein diesen Teil habe ich noch nicht.
    Daher meine Frage wie der weiter verlauf nun aussehen würde (aufbau der Preferences).


    Dazu schreibe ich gleichmal was. Mach hier mit dem ersten Teil erstmal Schluss, sonst wird der Post zu lange. Kannst ja schonmal dein Menü anpassen.

    Zitat von Killua


    Wie bewerkstellige ich nun folgendes...
    Ich klicke auf einen der erstellten Menüpunkte - daraufhin öffnet sich eine Einstellungsdialog


    Du musst die Methode onOptionsItemSelected() implementieren und dann die id des Menüpunkts abfragen. Daraufhin kannst du z.B. eine Activity starten, die es dir erlaubt die Preferences zu bearbeiten.


    Angenommen die id deines Menüpunkts ist main_menu_options_prefs und die Klasse, die deine Preferences-Activity repräsentiert ist EditPreferences, dann geht das so:



    Zitat


    in dem ich Dateneingeben kann und speichern kann, sodass ich diese gegebenfalls zu einem späteren Zeitpunkt für etwas verwenden kann (siehe Beispielbild).


    Hast du den Teil schon?

    Sers,


    hast schon gesehen? Die neuen Ergebnisse sind online: http://forum.xda-developers.com/showthread.php?t=547752


    Wie zu erwarten war ist CompCache schneller als das Swap Device. Bei dem vorherigen Test hat das Backing-Swap wohl zu oft zugeschlagen. Interessant ist, dass im normalen Betrieb compcache nur einen Hauch schneller ist als das Swap-Device. Hier hätte ich auch schon einen eindeutigeren Vorteil erwartet. Ich denke aber, dass der Effekt wesentlich gravierender wird wenn man Applikationen verwendet, die Android zwingen nahezu alles auszulagern/aus dem Speicher zu werfen - z.B. Alk Copilot.

    Zitat von maxisma


    Compcache braucht aber eine Menge CPU Zeit und damit auch Batterie!


    Hat das mal jemand gemessen? Wäre sehr interessant. Ich bin mir nämlich nicht sicher ob das rumhacken auf der SD-Karte wesentlich weniger Strom braucht. Die Compressions/Decompressions-Zeiten sollten bei compcache ja extrem kurz sein.


    Die einzige Information über Stromverbrauch des ARM1136EJ-S (das ist der Rechenkern im MSM7201A) konnte ich hier finden. Dort wird das ganze mit 0.4 mW/MHz angegeben. Nachdem eine microSD-Karte wahrscheinlich auch so um die 50mA benötigt dürfte das ein Nullsummenspiel sein.


    Zitat


    Außerdem sind Android Apps ja recht klein, daher sollten 6 MB/s vollkommen ausreichen ;)


    Du hast bei deinem Beispiel aber nicht bedacht, dass die Grösse einer Applikation nichts über deren Speicherverbrauch aussagt. Der Webbrowser ist auch nur 500kb gross, kann aber deinen gesamten Speicher zumüllen wenn du genug Seiten öffnest.


    Für einen vernünftigen Test müsste man die Benchmark Tools auf der Compcache Seite portieren. Wenn man das aber mal so über den Daumen peilt müsste Compcache einem Swapfile um längen überlegen sein. Würde mich wundern wenn nicht. Bin gespannt was bei weiteren Tests rauskommt.

    Zitat von maxisma


    2.2 ist draußen :)
    Besuch den Blog!


    Habe gelesen, dass du compcache zugunsten von swap rausgehauen hast. Hast du das selber auch mal verglichen? Der Thread den du verlinkt hast ist nämlich ziemlich nutzlos, weil zusätzlich zu compcache noch eine Swap Partition aktiv war. Es war also kein Vergleich compcache vs stock sondern compache+swap vs stock.


    Rein rechnerisch müsste eigentlich compcache schneller sein als eine Swap Partition. Da ich beides nicht benutze ist das bei mir zwar nur von akademischen Interesse, aber bei einem klaren Sieg der Swap-Partition müsste man sich schon fragen wo die ganze Leistung verloren geht. Compcache sollte eigentlich um Welten schneller sein als ein Swap-Device welches auf eine Partition auslagern muss, die mit maximal 6MB/s geschrieben werden kann.

    Zitat von Vaan


    Ich hab die Datei mal bei Rapidshare hochgeladen (Datei ist zu groß fürs Forum^^). Es sind im übrigen auch Platinenbaupläne drin x)
    http://rapidshare.com/files/26…0_SVC_ENG_090227_1.0_.pdf


    Diese Dokumentation ist für die Treiberentwicklung ungeeignet, da sie nur die technischen Aspekte abdeckt. Gut ist, dass ihr zumindest jetzt mal wisst welche Chips verbaut sind. Ob ihr an die Dokumentation für die einzelnen Chips rankommst ist ne andere Frage.


    Bevor ihr nicht detailierte Entwickler-Doku habt braucht ihr eigentlich mit dem Cracken der Original-Firmware nicht weitermachen. Wie schon geschrieben ist der Aufwand für Reverse Engineering einfach zu hoch, da in 2 Jahren eh niemand mehr das Handy benutzt.

    Zitat von mastersimsim


    Wie kann ich eine XML-Datei einer .apk-File öffnen.


    Wozu?


    Zitat


    Beispielsweise wenn ich /system/app/contacts.apk entpacke,
    wie kann ich dann btn_dial.xml (-> res/drawable-finger/btn_dial.xml) öffnen.


    http://devtcg.blogspot.com/200…oid-binary-xml-files.html


    http://jf.andblogs.net/2009/06/23/its-alive/



    Zitat


    Ich meine, ein XML-Datei wird in eine Binär-Datei umgewandelt.
    Stimmt das?


    Ja.


    Zitat


    Der Link funktioniert nicht.

    Zitat von DJS


    Kann das wie ich es oben beschrieben habe keiner programmieren.


    Meiner Meinung nach macht es mehr Sinn, wenn du deine Wünsche mal an Swordi heranträgst. Der ist aus Österreich (kannst also auf Deutsch schreiben) und freut sich immer über Verbesserungsvorschläge: [email protected]


    So eine App neu zu entwickeln ist kein 5 Minuten Job. Inklusive Testen sitzt man da ganz schnell mal 20 Stunden dran. Danach hat man dann eine App, die so simple ist, dass sie ausser dir keiner benutzt. 90% von dem was du gerne hättest hat Swordi schon implementiert. Eine Option einzubauen, die es dir erlaubt die Sortierung zu ändern ist dann wirklich nur ein 5 Minuten Job. In deinem Fall macht es einfach keinen Sinn das Rad neu zu erfinden.

    Zitat von loeppel


    Hmm das stimmt natürlich. Ich dachte nur mit libpurple würde man eben viele Netze abdecken. Was für Muli-Protokoll Messenger die unter einer OSS Lizenz stehen gibts denn für Android.


    Die libpurple hat aber einen Rattenschwanz an Abhängigkeiten, die du alle portieren müsstest. Die bessere Variante ist es einen OSS Java-IM-Client anzupassen und dann per JNI die libotr verwenden.


    Zitat


    Java libs müssten sich ja eigentlich auch nutzen lassen oder? Leider gibt es keine OTR implementierung in Java, dazu wurde mal ein Projekt gestartet, das hat jedoch nie code veröffentlicht. Die libotr ist wohl auch nicht ganz trivial.


    Sie ist mathematisch nicht ganz trivial, das stimmt. Von der Portierung her sollte es aber wenig Probleme geben.


    Zitat


    Aber die glibc soll es ja geben, also sollten ja einfache, auf glibc beruhene libs laufen oder nicht?


    Nein, genau das ist das Hauptproblem. Du hast keine glibc zur Verfügung sondern nur eine abgespeckte micro-libc (bionic).

    Zitat von Vaan


    Wir im KM900-Arena-Forum von Handy-FAQ.de versuchen/möchten Android auch auf unserem Arena zum laufen bekommen.
    Leider fehlt uns das Know-How dazu.
    Wir beschäftigen uns zur Zeit damit, wie man das hauseigene Betriebsystem von LG, das auf dem Arena ist, "knacken" kann, so das wir die Firmware usw. modifizieren können.


    Das knacken der Firmware ist nicht euer eigentliches Problem. Die Treiber sind es. Selbst wenn ihr es schafft, dass ihr beliebige Firmware Images flashen könnt, so fehlen euch immernoch die Treiber für GSM, WLAN, Kamera, Lagesensor, Grafikchip, usw.


    Ihr solltet also erstmal schauen ob ihr Datenblätter über die verbauten Chips bekommt und wie ihr an einen GSM Stack kommt bzw. den GSM Stack ansprechen könnt, falls er als getrennte Firmware (wie beim G1) dabei ist.


    Ohne vernünftige Dokumentation über die Chips lassen sich auch keine Treiber schreiben. Bei einer Halbwertzeit von 2 Jahren lohnt sich Reverse Engineering einfach nicht. Selbst wenn ihr taugliche Dokumentation über die Chips auftreiben könnt so muss jemand schon extreme Langeweile haben um solch ein grosses Projekt (Treiber schreiben, Linux System portieren, Android anpassen) durchzuziehen - nur um nach 2 Jahren festzustellen, dass das ganze nicht mehr benutzt wird.