Beiträge von Marco Feltmann

  • Android für ein Device kompilieren

    Aber nur sehr quasi. ;)


    Ich hätte gern eine eigene unbranded uncustomized custom ROM, weil es für das Zielgerät kein Stock ROM gibt.
    Sonst nähme ich liebend gern das Stock ROM. ^^


    Es gibt zwar einen Community-Versuch, das Ganze irgendwie zu erstellen. Der hat sich auf 2.2 spezialisiert, hinkt seit Jahren mit einem Release hinterher und so wirklich schlau werde ich aus deren Projekt auch nicht.

  • Android für ein Device kompilieren

    Ich weiß zwar nicht, wie gut ich hiermit aufgehoben bin, aber fragen kostet ja bekanntlich nix. ;)


    Ich würde gern die 2.3er Sourcen von Android nehmen und so zusammenschustern, dass ich sie auf ein Gerät bekomme. Also quasi ein reines nacktes Android ohne Schnickschnack und Schickimicki.


    Hat das schon mal jemand von euch gemacht und kann mir ein, zwei Tipps geben?
    Das einzig Hilfreiche zu dem Thema findet man unter http://source.android.com/source/initializing.html, doch irgendwie hilft mir das nicht so recht weiter.

  • Game Loop

    Also mit der Implementierung hat deine App ja null Chance zurück in die Runloop zu springen, in der sie alle Events, Zeichnungen etc.pp. durchführen kann.
    Wie es besser geht weiß ich aktuell nicht, kann ich aber gegebenenfalls bis morgen herausfinden. ;)

  • Contextmenü über Optionmenü öffnen

    Na dein View. ;)


    Die Frage ist, wo genau du openContextMenu() aufrufen möchtest.
    Im Allgemeinen solltest du das beim OnLongClickListener() deines Views machen.
    Dieser hat als zu überschreibende Methode nur

    Java
    onLongClick(View v);


    Also dürfte klar sein, welches View du übergeben musst.


    Wenn du nicht über einen LongClickListener arbeitest (dürfte beim Menü nicht gehen), dann musst du etwas tricksen.
    (Wobei ContextMenüs nur über einen LongClick geöffnet werden sollten und Menüs nicht als Auswahlfeld für ein Untermenü vorgesehen sind)


    menuItem.getActionView() wäre zum Beispiel eine Möglichkeit, an ein View zu kommen.

  • Lustiger Fehler beim Einbinden des Badges als Signatur

    Wenn ich versuche, mein Signaturbadge als Signatur einzubinden, erhalte ich folgende Fehlermeldung:

    Zitat

    Das Bild »http://android-developers.de/androidforum-1589.png« überschreitet die erlaubte Maximalgröße. Die maximale Größe liegt bei 530*200 Pixel und 20 kB.


    Da es 745x98px ist, stimmt diese Aussage. Kurios ist sie dennoch.


    Mag bitte jemand das Größenlimit für die Signatur hoch oder die Breite des Badges heruntersetzen?

  • SQLiteDatabase Best Practice

    Ich verstehe. (nicht ganz, da deine 5 Cursor ja alle dieselben Werte haben und damit die anzuzeigende Zahl immer gleich wäre)


    Genau dafür ist halt Object.clone() da. Du musst dann das Objekt natürlich noch auf den Cursor casten.

  • nochmal broadcast und activity

    Na, das Eine hat aber mit dem Anderen eher weniger zu tun. ;)


    Also in meinem Fall wäre es ein simples

    Java
    Map<String, Object> userInfo = new HashMap<String, Object>();
userInfo.put("newLocation", location);
Broadcaster.send(new Broadcast("LocationDidChange", this, userInfo);


    Activityübergreifend wirst du keine Location übergeben bekommen. Das kotzt mich persönlich ja sowas von dermaßen an... +sigh+


    Als Extra kannst du nur Parcelable und Serializable Objekte reinstopfen. (Ärgert mich gerade auch ganz extremst, weil ich mein Design auf den letzten 20% mal wieder komplett über den Haufen werfen kann)


    Der Nachteil ist, dass in beiden Fällen wie folgt vorgegangen wird:
    Objekt wird genommen, Objekt wird zerlegt, Objekt wird zusammengepackt, Paket wird übergeben, Paket wird genommen, Paket wird zerlegt, neues Objekt wird erstellt, Paketinhalte werden neuem Objekt zugewiesen.


    In meinem Fall (knapp 500 Objekte, die ich in einer List übergeben wollte) wird das ein unglaublicher Memory Overkill. Activities halten absolut nichts von Objektorientierung. -.-


    Also drei Möglichkeiten:
    - über eine Datenbank ausweichen
    - Eigenimplementation von Location die entweder das Parcelable oder das Serializable Interface implementiert
    - die wirklich relevanten Werte als primitive Datentypen übergeben


    Ein Fleißbienchen bekommst du für Möglichkeit vier:
    - herausfinden, wie man Speicheradressen weitergibt und einfach mit dieser Referenz arbeiten
    (So wie ich die Activities verstanden habe, ist das explizit nicht erwünscht, da diese Activities ja losgelöst voneinander funktionieren sollen und vermutlich zumindest applicationsweit einen eigenen Speicherbereich zugewiesen bekommen – die Speicherbereiche der anderen Activities für sie also schlicht nicht zugreifbar sind.)

  • Custom Views

    Der Lars Vogel hat ein Tutorial für die Erstellung eines CustomViews.
    Nach diesem habe ich auch schon ein rudimentäres eigenes View gebastelt bekommen.


    Lediglich das Layouting will nicht so as ich wohl will. Da mache ich mutmaßlich irgendwas in der onLayout() falsch. ^^

  • Datenübertragung per WLAN

    Du bekommst nur einen Datenstream. Du sendest nur einen Datenstream. Alles Andere ist Implementierungsdetail.


    Da Seekbar von ProgressBar erbt, geht das mit den Standardmethoden der Progressbar.
    Also setMax() für den Maximalwert, setProgress() für den aktuellen Wert und Änderungen bekommst du über einen OnSeekBarChangeListener mit.
    Steht alles so in der Doku. ;)

  • Datenübertragung per WLAN

    Wir können dir sicherlich nicht sagen, was genau du tun musst, damit aus deiner Lüftersteuerung die angefragten Werte zurückkommen.
    Genausowenig können wir dir sagen, was genau du tun musst, damit du deine geänderten Werte in die Lüftersteuerung gepumpt bekommst.


    Dementsprechend können wir dir auch nicht sagen, was deine Methoden beinhalten müssen.


    Kurz: mit den spärlichen Informationen haben wir keine Möglichkeit, dir deine App zu erstellen. :P


    Dein WLAN Modul im Mobiltelefon stellt dir erst einmal gar nix zur Verfügung, du musst permanent nachfragen.
    Dein WLAN Modul im Mobiltelefon stellt der Lüftersteuerung gar nix zur Verfügung, du musst permanent senden.


    Alle relevanten Informationen stehen nämlich im TCP Protokoll deiner Lüftersteuerung.
    Also ob das bitweise übertragen wird, als csv, als JSON oder sonstwie und welche Keys es zu welchen Werten gibt etc.pp.


    Du hast eigentlich mehrere Möglichkeiten:
    - du besorgst dir die Dokumentation zu der Lüftersteuerung
    - du probierst einfach mal rum was so passiert
    - du stellst mir so ein Teil zur Verfügung und ich finde das für dich heraus
    - du beauftragst jemanden, der sich mit sowas auskennt (könnte gleichbedeutend mit Möglichkeit 3 sein)


    Das ist gerade ungefähr so als stündest du vor einem Auto, sagst du könntest es nicht fahren und wir wissen noch nicht einmal, ob du überhaupt einen Schlüssel dafür hast.

  • nochmal broadcast und activity

    Wie bereits angedeutet nutze ich dieses Konzept unter dem Namen 'Notifications' ganz rege unter iOS, ich weiß daher nicht, ob und wie sich das Ganze in Android so umsetzen lässt.


    Jedenfalls habe ich halt eine Klasse, die komplett static arbeitet: Listener registrieren, Broadcast senden, Listener entfernen.
    Ein Broadcast ist bei mir einfach ein Objekt mit einem Namen, einem Sender und einer Map<String,Object>, die weitere Infos enthält.
    Ein Listener ist bei mir ein Interface, welches lediglich die Methode 'receivedBroadcast(Broadcast)' implementiert.


    Damit das mit den Listenern einigermaßen funktioniert, habe ich noch eine Klasse, die aus Listener, Namen und Sender eine Zuordnung zusammenleimt.


    Diese static Klasse nimmt also den Broadcast, er auf ihre send(Broadcast) Methode gelegt wurde.
    Dann prüft sie einfach, welcher Listener für diesen Absender und/oder diesen Namen registriert ist und ruft dessen receivedBroadcast() Methode auf.


    Sofern das Ein- und Aushängen der Listener sauber funktioniert, läuft das alles ganz rund.


    ---


    Nachdem diese Gegebenheiten abgesteckt sind, ist dann die Lösung deines Problems ziemlich simpel:
    Deine Activity registriert sich für alle Broadcasts des Senders 'Service', den sie hoffentlich kennt. (Falls nicht hängst du für jeden möglichen Namen des Broadcasts einen Listener ein.)
    Dein Service registriert sich für alle Broadcasts des Namens "SomeActivityDidChangeSharedPreferences".


    Passiert im Service irgendwas, sendet er irgendwas an deinen Broadcaster.
    Passiert in der Activity irgendwas, sendet sie irgendwas an deinen Broadcaster.


    So bleibst du dann recht dynamisch. Baust du noch was in den Service ein bekommt deine Activity auch das mitgeteilt.
    Änderst du über eine andere Activity irgendwas Wichtiges an den SharedPreferences, bekommt dein Service auch das mitgeteilt.


    Ein typischer man-in-the-middle. ^^