Android: Sensor verwenden - Helligkeit auslesen

Von e7 am 06.11.2010, 00:04 in der Kategorie Code-Snippets mit den Tags ambient licht hardware sensor java android. Kompletten Eintrag zeigen

Und wieder ein Traum zerplatzt: Da ja Android-Geräte häufig einen Helligkeitssensor verbaut haben, dachte ich — aus Entwicklersicht gesehen — an so etwas wie einen Belichtungsmesser für Fotografen, insbesondere um bspw. die Stärke eines Blitzes ausmessen zu können. Dummerweise reagiert bspw. mein Sensor nur ab Lichtschwankungen, die ungefähr eine Sekunde Mindestdauer haben. Bei Blitzen, die kürzer als 1/1000 und so sind, leider inakzeptabel.

Hier trotzdem mal der Code bzw. das Vorgehen:

import android.hardware.*;

Wichtig :)

public class TestActivity extends Activity implements SensorEventListener {
    SensorManager sm;
    TextView tv;

Wir benötigen einen SensorEventListener, wofür sich im Moment die Klasse anbietet, und etwas zum Anzeigen.

    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        tv = new TextView(this);
        setContentView(tv);
        sm = (SensorManager)getSystemService(SENSOR_SERVICE);
    }

Hier ist die Zeile mit dem SensorManager wichtig.

    protected void onResume() {
        super.onResume();
        sm.registerListener(this, sm.getDefaultSensor(Sensor.TYPE_LIGHT), SensorManager.SENSOR_DELAY_FASTEST);
    }
    
    protected void onStop() {
        super.onStop();
        sm.unregisterListener(this);
    }

Die Sensor-Events sollten aus Akkugründen nur bei aktivierter Anwendung verarbeitet werden, deshalb in onResume und onStop die entsprechenden Vorgänge. Möglicherweise ist es eine gute Idee, sm.getDefaultSensor vor dem Weiterreichen zu prüfen. Gibt die Funktion null zurück, gibt es nämlich keinen Sensor :)

    public void onAccuracyChanged(Sensor sensor, int accuracy) {
    }
    public void onSensorChanged(SensorEvent event) {
        tv.setText(„Aktuell: „+event.values[0]);
    }

Auch hier sollte man aufpassen, dass event.values auch tatsächlich ein Element enthält, sonst schmiert's ab, aber generell funktioniert's so.

Android: Zeitzonen

Von e7 am 26.08.2010, 18:54 in der Kategorie Code-Snippets mit den Tags sommerzeit zeitzone java android. Kompletten Eintrag zeigen

Mein CalDav-Projekt schreitet weiter voran. Im Moment kämpfe ich ziemlich mit Zeitzonen und anderen Dingen — was bspw. bei mehrtägigen Terminen sehr unschöne Verhaltensweisen zeigt und auch sonst ist eine Verschiebung um zwei oder vier Stunden unschön.

Android scheint Termine grundsätzlich als UTC zu speichern und keine alternativen Möglichkeiten vorzusehen. An sich keine schlechte Idee, außerdem würde es erklären, warum man beim Termin speichern keine Zeitzonen angeben kann, ohne dass man mit Exceptions bombardiert wird.

Momentan löse ich die Problematik folgendermaßen: Am Anfang benötige ich die UTC-Zeitzone, die wird auch als Default gesetzt.

tz_utc = TimeZone.getTimeZone(„UTC“);
TimeZone.setDefault(tz_utc);

Damit kann ich zumindest alles, was UTC ist (hat ein Z am Schluss), einfach verwursten. Termine, die nicht als UTC gespeichert sind, sind im iCal-Format einigermaßen leicht zu unterscheiden:

Beispiel UTC: DTSTART:20100627T140000Z
Beispiel ME(S)Z: DTSTART;TZID=Europe/Berlin:20100809T110000

Ich hoffe mal, dass das so von den Clients konsequent durchgehalten wird, vermute aber eher nicht. Es gibt im Standard noch ein BEGIN:VTIMEZONE, in dem bspw. Sunbird Dinge reinschreibt, die aber erst mal nicht relevant sind. Möglicherweise ist das auch nur das Gegenstück zu dieser misteriösen eventtime von Android, alternativ könnte es auch sein, dass das auch gilt, wenn bei DTSTART nix angegeben ist. Da muss ich mal bei Gelegenheit noch im Standard nachlesen.

Zum Umwandeln jedenfalls setz ich die entsprechende Zeitzone auf bspw. Europe/Berlin, erzeuge das Datum und setze die Zeitzone wieder zurück auf UTC. Anschließend kann ich das Offset draufrechnen/abziehen:

tz = TimeZone.getTimeZone(tzName);
TimeZone.setDefault(tz);
d = mkCaldavDateString(s);
l = d.getTime();
TimeZone.setDefault(tz_utc);
d = new Date(l — tz.getOffset(d.getTime()));


Leider hat ein Date kein .setTimeZone oder so, mit dem man das einfacher hätte machen können. Vielleicht hab ich das allerdings auch übersehen. Ich merks mir einfach mal vor für spätere Optimierungen :) Das mit der Rechnerei ist jedenfalls sehr unschön und ich werd versuchen, da noch ne saubere Lösung zu finden.

CalDAV: Ausverkauft?

Von e7 am 15.08.2010, 22:37 in der Kategorie Zwischendurch... mit den Tags status sourceforge caldav java android. Kompletten Eintrag zeigen

Ich hab vor drei Tagen bei Sourceforge ein CalDAV-Projekt registriert/gestartet und meine Codeschnipsel dort in ein Archiv verpackt hochgeladen.

Inzwischen gibt es schon 11 Downloads. Und das nur, weil da die Stichwörter CalDAV und vmtl. Android drin vorkommen.

Manchmal frag ich mich, warum ich kein Botnetzbetreiber geworden bin.

Zum Status: Im Moment kämpfe ich grad mit der grottigen API vom Google-Java. Vieles ist da, nur dummerweise fehlen so Dinge wie XPath. Einfach rausgelassen (ab 2.2 verfügbar)… Ich hab nun inzwischen schon diverse Bibliotheken eingebunden (Apache Commons, Apache HTTP Core, jaxen…) um nicht alles selbst machen zu müssen.

Immerhin funktioniert debuggen jetzt schon einigermaßen, nachdem ich in der Manifest für application den Wert android:debuggable="true“ gesetzt habe.

Allerdings treten immer noch merkwürdige Fehler bei Jaxen auf, d. h. XPath-Abfragen geben keine Ergebnisse bzw. es tritt eine NullPointerException auf — allerdings nur auf Android, in einer normalen Java-VM klappt es problemlos. Was ich noch angesehen habe: JXPath, aber das will gleich so viel kapseln, dass ich massig Objekte anlegen müsste und Xalan, was massig imports auf die nicht-existente XPath-Library von Java macht.

Neue Lösung: Ein eigener Parser, der nicht ganz XPath implementiert :)

Java & Heredoc

Von e7 am 12.08.2010, 21:10 in der Kategorie Kopfschüttelnd... mit den Tags php heredoc java. Kompletten Eintrag zeigen

Warum hat Java eigentlich keine Unterstützung für Heredoc, wie es bspw. das gute alte PHP hat? Hat man wohl auch weggelassen, weil es zu kompliziert ist?