class Shape {
    private int width;
    private int height;
    
    Shape(int w, int h) {
        width = w;
        height = h;
    }

    public void setDim(w, h) {
        width = w;
        height = h;
    }
}

Shape s = new Shape(30, 20);
s.setDim(10, 5);    // A
s.setDim(20, 55);  // B
println(s);

Dieser simple Code soll uns als Beispiel dienen. Was wird uns println in der Console anzeigen? Wenn wir beide setDim Aufrufe sequentiell abarbeiten „Shape{width=20, height=55}“, was für jeden verständlich ist. Wie sieht das Ergebnis jedoch aus, wenn wir setDim A und B gleichzeitig parallel ausführen? Nun, das können wir nicht mit Sicherheit sagen. Es kann jedes dieser folgenen Ergebnisse sein: „Shape{width=30, height=20}“, „Shape{width=10, height=20}“, „Shape{width=20, height=20}“, „Shape{width=30, height=5}“, „Shape{width=30, height=55}“, „Shape{width=10, height=5}“, „Shape{width=10, height=55}“, „Shape{width=20, height=55}“, „Shape{width=20, height=5}“. Es ist nicht nur unmöglich vorherzusagen, ob s wie setDim A oder B aussehen wird, auch haben wir zusätzlich „corrupt state“ indem s auch Zustände zwischen A und B annehmen kann. Dies erhalten wir durch mutable state und Funktionen mit Nebenwirkungen (setDim verändert Variablen außerhalb der Funktion).

Bei der funktionalen Programmierung verzichtet man auf veränderbare Zustände (mutable state) und Funktionen mit Nebenwirkungen (side effects). Dies klingt in erster Linie unmöglich, da wir gewohnt sind, ständig Variablen zuverändern.

class Shape {
    public final int width;
    public final height;
    
    Shape(int w, int h) {
        width = w;
        height = h;
    }

    public Shape setDim(w, h) {
        return new Shape(w, h);
    }
}

Shape s = new Shape(30, 20);
Shape s2 = s.setDim(10, 5).setDim(20, 55);
println(s);
println(s2);

Schon durch kleine Veränderungen können wir unsere Klasse „thread-safe“ machen. Unsere Variablen sind nun alle Konstanten. Wollen wir unsere Klasse „verändern“ generieren wir in Wirklichkeit eine Kopie mit unserem neuen Zustand. Unabhängig davon, ob wir nun sequentiell oder parallel arbeiten, println(s) und println(s2) werden immer „Shape{width=30, height=20}“ und „Shape{width=20, height=55}“ in der Console anzeigen. Wir haben immutable state (unveränderliche Zustände) und Funktionen ohne Nebenwirkungen.

Dies ist nur eine kleine Kostprobe zur funktionalen Programmierung und nur eines der Themen, mit denen ich mich intensiv auseinander setze. Am Ende des Jahres angekommen kann ich sagen, dass 2016 für mich ein akademisch prägendes Jahr war. Unter anderem schrieb ich an Papers für IEEE-Konferenzen mit Kollegen von CSUN. Ich freue mich schon auf 2017, um mir weitere Ziele setzen zu können.

The post Funktionale Programmierung appeared first on Mobile USTP MKL.

---------------------------------------------------------
module ColorSliders where

import Color exposing (Color, toRgb)

type alias Model = List Color

type ModelAction
  = Set Color
  | Back


update : ModelAction -> Model -> Model
update action (x :: xs) =
  let all = x :: xs
  in
    case action of
      Set color -> if color == x then all else color :: all
      Back ->
        let
          newHistory' = List.drop 1 all
        in
          if List.isEmpty newHistory' then [Color.rgb 0 0 0] else newHistory'


view : Signal.Address ModelAction -> Model -> Html
view address (x::xs) =
  let
    rgb' color = (String.concat [(toString color.red)
                                ,","
                                ,(toString color.green)
                                ,","
                                ,(toString color.blue)])
    listItem color = li [] 
  in
    div []
      [view' address x
      ,view' address x
      ,input [type' "button"
             ,value "Back in Time"
             ,onClick address Back] []
      ,ol [] (List.map listItem (x :: xs))]

------------------------------------------------------------------------------

Man muss den Code nicht auf Anhieb verstehen, aber jeder Entwickler wird sofort die Toplevel-Definitionen wieder erkennen. Wir können ein Modul mit dem Namen ColorSliders erkennen, welches andere Module importiert. Zusätzlich definiert das Modul ein Model, Modelaktionen. Diese werden von einer “update”-Funktion verwendet, welche eine Modelaktion und ein Model erhält und dafür ein neues Model (ein neuer State) zurückliefert. Eine “view”-Funktion nimmt einen Callback für Aktionen und ein Model und gibt dafür HTML zurück. Keine großen Überraschungen hier. Jede Funktion kann mit einer Typdefinition versehen werden. Dies ist optional. Elm ist eine statisch-typisierte Sprache, d.h. alles hat einen eindeutigen Typ zur Kompilierzeit, der sich im Laufe des Programmes auch nicht ändern kann, jedoch ist der Compiler schlau genug, um Typen selbst herauszufinden, falls wir diese nicht angeben. Dies wird auch als “type inference” bezeichnet. Dies ist eine große Hilfe, da der Compiler sofort schreit, falls wir auf ein Attribut zugreifen wollen, dass es in der Definition des Typs nicht gibt. Auch Null gibt es nicht -> keine NullpointerExceptions.

Ich glaube es ist eine gute Übung, die gleiche Applikation in verschiedenen Sprachen umzusetzen. Dadurch erhält man auch einen guten Vergleich. Daher habe ich die App aus einen meiner vorherigen Beiträge (https://akirchknopf-21110.php.fhstp.cc/allgemein/funktionale-uis-mit-om/) in Elm realisiert.
Das Ergebnis ist natürlich das Gleiche. Der komplette Quellkode ist auch wieder dabei. Vergleicht die Lösungen. Ich hoffe ich konnte damit eure Neugier für andere Sprachen wecken. Haskell wird mich auf jeden Fall noch über Jahre hinweg beschäftigen.

Es ist sicherlich nicht die beste Implementierung, aber auch nicht die schlechteste. Wir haben eine redraw-Funktion, in welcher wir alle Elemente mit den aktuellen Daten aktualisieren. Wir rufen redraw() bei jeder Veränderung auf. Dies alles zu machen ist etwas mühsam und mit mehr Elementen wächst die redraw-Funktion immer weiter und weiter, was eigentlich nicht sehr modular ist.

Dieses Beispiel habe ich in ClojureScript und Om reimplementiert.

Auch wenn man nicht so viel von ClojureScript versteht und auf “Source” klickt, sieht man, dass es nicht “die eine, große redraw-Funktion” gibt. Die Applikation ist in modulare Komponenten unterteilt. Um das Farbfeld zu verdoppeln, habe ich nur den bestehenden Component ein zweites Mal eingefügt (eine Zeile Arbeit) und an die selben Daten geknüpft. Alle Komponenten reflektieren automatisch den State mit dem sie verknüpft wurden und halten sich synchronisiert. So Programme zu schreiben ist meiner Meinung nach einfacher und sinnvoller, als pures JavaScript.

Am Schluss des Artikels angekommen, wäre ein besserer Titel vielleicht “Warum ich von JavaScript auf ClojureScript mit Om umgestiegen bin” gewesen. In einem Artikel kann man nur schwer auf ClojureScript und Om gleichzeitig in Form von ausführlichen Tutorials eingehen. ClojureScript muss man schon für zwei Wochen gelebt haben, um die Vorteile wirklich greifbar zu machen. Wenn das eher nichts für euch ist, hat euch dann hoffentlich das Beispiel ein wenig gezeigt, dass man sich über Abhängigkeiten, Modularität und der Synchronisation von State bei Applikationen Gedanken machen muss … und HTML5 Slider in Aktion. Ich empfehle euch, das Beispiel selber mal in JavaScript auszuprogrammieren. Da bin ich gespannt, auf welche Lösungen ihr kommt. Postet einfach ein Kommentar mit Link.

The post Funktionale UIs mit Om appeared first on Mobile USTP MKL.

Zwei traditionelle Herangehensweisen an das Realisieren dieser Applikation könnten so aussehen:
1) Eine Funktion die zu Beginn die Liste der Kommentare erstellt und eine welche die Updates in die vorhandene Liste einfügt. Dies hat den Nachteil, dass wir zwei Funktionen brauchen die fast das Gleiche machen, dies aber schnell (Vorteil). Zusätzlich ist es nicht besonders data-driven und sehr imperativ, da die Liste ständig manipuliert wird und ein Eigenleben durch Hidden-State entwickeln kann. template(model) != view. Eine weitere Überlegung: Was ist wenn wir im Nachhinein beschließen, dass Kommentare sowohl veränderbar und löschbar sind, natürlich von jedem Browser aus und dass soll jede andere Person sofort in ihren Browsern sehen können. Dies würde wieder zwei weitere Funktionen benötigen, die darüber Bescheid wissen müssen, welches Kommentar die Veränderung und Löschung betrifft (weiterer State 🙁 ). Da können wir froh sein, dass JS single-threaded ist, denn in anderen Programmiersprachen wären wir nun in der Locking-Hölle (4 Funktionen die auf denselben State zugreifen – shared State).
2) Eine Funktion welche die bestehende Liste komplett entfernt und zusammen mit allen vorherigen Updates neu aufbaut. Nachteil: schlechte Geschwindigkeit/Performance | Vorteil: data-driven, functional, template(model) == view, kein Hidden-State

Facebook hat erkannt, dass man mit keiner der beiden Lösungen glücklich wird. Dies liegt der Entstehung von React zugrunde. Dabei ist React aber kein Framework, es zwingt den Nutzern nichts, wie zum Beispiel Routers oder Templates, auf. Man muss bestehende Applikationen nicht komplett auf React umstellen, sondern kann es für einzelne Komponenten verwenden und es spielt dabei gut mit anderen Bibliotheken wie jQuery zusammen.
Die Herangehensweise von React zu unserem vorherigen Beispiel ist es, eine Funktion zu erstellen, welche für eine gegebene Liste von Kommentaren das HTML erzeugt, also die Funktion von 2). Diese ruft React selbstständig auf, falls sich die Liste von Kommentaren verändert, wenn wir zum Beispiel an das Kommentaren-Array die Updates anhängen. Dabei greifen wir das HTML nicht direkt an, sondern ändern nur ein JavaScript-Array. React produziert nun selbstständig das HTML und vereint es mit dem was schon im DOM vorhanden ist. Daher löscht es nicht das gesamte DOM, sondern fügt nur die Differenz ein. Mit dieser Herangehensweise haben wir alle Vorteile der beiden anderen. Wir bekommen ein functional, data-driven Interface ( template(model) == view ), behalten aber die Geschwindigkeit der imperativen Lösung 1) durch das Vereinen von Differenzen mit dem was schon am Bildschirm vorhanden ist.

Ganz konkret sieht das in React dann so aus:
Variante 1 mit Properties:

/** @jsx React.DOM */
var Kommentare = React.createClass({
    render: function() { return (
        <ol>
            {this.props.kommentare.map(function (kommentar) {
                return (<li>{kommentar}</li>);
            })}
        </ol>
  );}
});

var kommentare = ["Kommentar 1", "Kommentar 2"];

setInterval(function() {  // "Server-Verbindung"
  var neueKommentare = ["Kommentar 3"]; // vom Server
  kommentare = kommentare.concat(neueKommentare);
  React.renderComponent(
    <Kommentare kommentare={kommentare} />,
    document.body
  );
}, 50);

Variante 2 mit State:

/** @jsx React.DOM */
var Kommentare = React.createClass({
    getInitialState: function() {
        return {kommentare: []};
    },
    componentDidMount: function() {
        setInterval(function() { // "Server-Verbindung"
            var neues_array = this.state.kommentare.concat(neue_kommentare);
            this.setState({kommentare: neues_array});
        }, 50);
    },
    render: function() { return (
        <ol>
            {this.state.kommentare.map(function (kommentar) {
                return (<li>{kommentar}</li>);
            })}
        </ol>
  );}
});

React.renderComponent(
  <Kommentare />,
  document.body
);

Der Grundbaustein von React ist der Component (React.createClass), welcher definiert, wie das resultierende DOM aussehen soll. React wird mit einer optionalen domain-specific-language ausgeliefert, namens JSX (hier das XML-Markup im JavaScript). Das JSX wird vor dem Ausliefern zu JavaScript kompiliert. Hat man größere Projekte steigert JSX die Leserlichkeit ungemein und kann ich daher nur empfehlen. Wer lieber pures JS schreiben will, muss Elemente mit zum Beispiel

React.DOM.div({})

erzeugen, was natürlich weitaus schwieriger zu lesen ist als

<div></div>

.
Als React-Umsetzung unseres Beispiels sind zwei gleichwertige Varianten angeführt. Ein setInterval simuliert in beiden Varianten die Server-Verbindung. Variante 1 verlässt sich dabei nur auf Daten von außen (kein Hidden-State). Jedes Mal, wenn wir neue Kommentare vom Server erhalten, hängen wir diese an unser Kommentaren-Array an und lassen React die Liste an Kommentare neu rendern (React.renderComponent-Funktion). Wie schon zuvor erwähnt, wird nicht die gesamte ol-Liste neu gerendert, es werden nur Differenzen zwischen neuem und alten State appliziert. In Variante 2 definieren wir einen Component, der sich selbst um seine Server-Verbindung kümmert und sich selbst neu rendert (mit jedem Aufruf von this.setState()). Es bleibt dem Programmierer überlassen, welche Variante bevorzugt wird. Meine Empfehlung geht an Variante 1, da kein Hidden-State verwendet wird.
Wie in den Varianten gezeigt wird, bedarf es nur einer Funktion (render), welche definiert wie das Component zu jedem Zeitpunkt auszusehen hat. Wir kümmern uns danach als Programmierer nur mehr um das Manipulieren von Daten (Arrays, Objecte, …) und nicht um das Manipulieren des DOMs (createElement, getElementBy…, appendChild, … fällt alles weg 🙂 ). Das macht React für uns. Hiermit können wir besseren Code schreiben, da wir nicht ständig Funktionen wie appendChild, innerHTML und der Gleichen aufrufen müssen und können unsere ganze Aufmerksamkeit unserem Model widmen.

The post UIs mit Facebooks React appeared first on Mobile USTP MKL.

Publikation:
http://dl.acm.org/citation.cfm?id=2556288.2556994
Robinson, Simon, Jennifer S. Pearson, and Matt Jones, ‘A Billion Signposts: Repurposing Barcodes for Indoor Navigation’, in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI ’14 (New York, NY, USA: ACM, 2014), pp. 639–642 <http://dx.doi.org/10.1145/2556288.2556994>

The post Navigate by Barcode appeared first on Mobile USTP MKL.

Wer solche Messungen mit Bluetooth auf Android-Geräten schon einmal durchgeführt hat, muss schnell feststellen, dass ein fortlaufendes Auslesen dieses RSSI-Wertes in Android nicht so einfach funktioniert. Dies liegt daran, dass dar Event zum Auslesen nur gefeuert wird, wenn ein neues Gerät gefunden wurde. Da das andere Gerät nach dem ersten Mal schon bekannt ist, bekommt man nur eine einzelne Momentaufnahme des Wertes, was Beobachtungen über die Zeit schwer macht. Verändert sich der Abstand der Geräte zueinander, muss man die Mess-Applikation daher neu starten.

Um den Messvorgang einfacher zu gestalten, habe ich eine einfache Funktion geschrieben, die auch für andere Entwickler und Tüftler interessant sein könnte.

package com.example.rssi_test.app;

import android.app.Activity;
import android.bluetooth.BluetoothAdapter;
import android.bluetooth.BluetoothDevice;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.content.IntentFilter;
import android.os.Bundle;
import android.util.Log;

public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        bluetooth_search();
    }

    public void bluetooth_search() {
        final BluetoothAdapter mBluetoothAdapter = BluetoothAdapter.getDefaultAdapter();
        if (mBluetoothAdapter == null) {
            return;
        }
        if (!mBluetoothAdapter.isEnabled()) {
            Intent enableBtIntent = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
            startActivityForResult(enableBtIntent, RESULT_OK);
        }

        registerReceiver(new BroadcastReceiver() {
            @Override
            public void onReceive(Context context, Intent intent) {
                BluetoothDevice device = intent.getParcelableExtra(BluetoothDevice.EXTRA_DEVICE);
                short rssi = intent.getShortExtra(BluetoothDevice.EXTRA_RSSI, (short) 0);

                Log.i("rssi", "" + rssi);

                unregisterReceiver(this);
                mBluetoothAdapter.cancelDiscovery();
                bluetooth_search();
            }
        }, new IntentFilter(BluetoothDevice.ACTION_FOUND));

        mBluetoothAdapter.startDiscovery();
    }
}

Diese einfache Funktion registriert einen Handler, welcher feuert, wenn ein Gerät entdeckt wurde. Es wird der RSSI ausgelesen, der Handler entfernt und die Erkennung neugestartet. Dadurch kann dasselbe Gerät mehrmals ausgelesen werden.
Hier sind ein paar meiner Messungen.

Wie man sieht, sind die Werte nicht allzu aussagekräftig. Falls man erkennen will, ob jemand durch eine Tür geht, würde ich jedoch nach einem RSSI-Wert größer (positiv größer) -60 Ausschau halten.

The post RSSI-Messungen von Bluetooth auf Android appeared first on Mobile USTP MKL.