Video-Link: https://vimeo.com/17631561
Modern Times
Video-Link: https://vimeo.com/17631561
Manchmal ruft man eine Methode unter .NET aus einem anderen Thread heraus auf. Je nachdem wie die Methode aufgerufen wird, kann es notwendig sein die Methode über Invoke aufzurufen. Mit folgendem Pattern geschieht dies nach Notwendigkeit automatisch:
private void MakeSomeFoo()
{
MethodInvoker method=delegate
{
//Do some foo
DoSomeFoo();
};
if(InvokeRequired) BeginInvoke(method);
else method.Invoke();
}
Im MethodInvoker-Delegate ist der eigentliche Quellcode der Funktion zu finden. Dieser wird je nach Notwendigkeit im korrekten Thread aufgerufen.
Für iOS gibt es ein App namens Audiobus. Mit Hilfe dieser App ist es möglich Audio von einer App zu einer anderen App zu routen. Dabei wird zwischen Input, Effect und Output unterschieden. Auch GarageBand, das Apple eigene Musikstudio für iOS unterstützt AudioBus.
Unter GarageBand gibt es allerdings noch eine andere Möglichkeit Audio zu übertragen. Gemeint sind Inter-App-Audio-Apps – im ersten Moment scheint es sich dabei um ein und die selbe Sache zu handelt. Leider sind AudioBus und Inter-App-Audio-Apps keine Synonyme, sondern zwei unterschiedliche Systeme.

Die Inter-App-Audio-Verbindung in Garageband
Bei den Inter-App-Audio-Apps handelt es sich um ein iOS 7 integriertes System während es sich bei AudioBus um eine externe App handelt. Der Vorteil gegenüber Audiobus ist die einfachere, da integrierte Bedienung. Mittlerweile sind viele Apps dazu übergegangen neben AudioBus auch Inter-App-Audio zu unterstützen. AudioBus wird mit Inter-App-Audio allerdings nicht zwangsläufig nutzlos, denn es bietet ein konsistentes Interface für die Verbindung der unterschiedlichen Instrumente und ist auch aus der Sicht eines Entwicklers einfacher zu nutzen. Außerdem verfügt IAA über keinerlei Möglichkeiten Parameter der Instrumente zu speichern, während dies mit AudioBus möglich ist. Zusammenfassend kann man sagen, das es mit Inter-App-Audio und AudioBus zwei Technologien gibt, welche das gleiche bewirken, wenn auch auf unterschiedlichen Wegen.
Beim TL-WR702N handelt es sich um einen mobilen Access Point von TP-Link für WLAN mit einer Reihe von Zusatzbetriebsmodi. Unter anderem verfügt der Access Point über einen Betriebsmodi namens Client, mit welchem kabelgebundene Geräte in ein WLAN eingebunden werden können. Leider lässt sich dieser Modus nur umständlich aktivieren.
Nach dem Reset des Gerätes kann sich per WLAN mit diesem verbunden werden. Die Einstellung über das Quick Setup funktioniert nicht, da der Client Mode dort zwar eingestellt werden kann, aber anschließend nicht übernommen wird. Stattdessen muss der Modus über das Menü Working Mode eingestellt werden und der AP neugestartet werden.

Der TL-WR702N montiert an einer Wand
Danach ist der TL-WR702N nur noch per Kabel unter der IP-Adresse 192.168.0.254 erreichbar. Die Netzverbindung am Rechner sollte zum Aufbau einer Verbindung auf 192.168.0.1 mit dem Subnetz 255.255.255.0 gestellt werden. Nachdem man sich wieder mit dem Gerät verbinden konnte, kann auf dem Gerät eine statische IP-Adresse im Punkt Network -> LAN eingestellt werden. Nach einem erneuten Neustart ist das Gerät unter der eingestellten IP-Adresse erreichbar. Im letzten Schritt muss in den DHCP Settings der eingebaute DHCP-Server deaktiviert werden. Damit ist der Client Mode nach einem erneuten Neustart nutzbar.
Für den Hackerspace in Neubrandenburg waren wir auf der Suche nach der Möglichkeit ein Kiosk-System unter Ubuntu 12.04 LTS einzurichten. Das System sollte dabei hochfahren, den Browser öffnen und eine Webseite im Vollbild darstellen. In dieser Anleitung wird dabei davon ausgegangen, das System mit der Serverversion von Ubuntu 12.04 LTS installiert wurde. Nach der Installation muss im ersten Schritt der Desktop nachinstalliert werden:
apt-get install ubuntu-desktop
Der installierte Desktop wird beim nächsten Neustart automatisch ausgeführt, so das hier keine weitere Konfiguration notwendig ist. Nun legen wir den Nutzer für den Kioskbetrieb an:
adduser kiosk
Dieser Nutzer soll beim Neustart automatisch angemeldet werden. Dazu wird die Datei /etc/lightdm/lightdm.conf bearbeitet. In diese Datei wird dabei folgendes eingetragen:
[SeatDefaults] autologin-guest=false autologin-user=kiosk autologin-user-timeout=0 autologin-session=lightdm-autologin user-session=ubuntu greeter-session=unity-greeter
Damit sind die ersten grundlegenden Schritte fertiggestellt und der Rechner kann neugestartet werden. Der Rechner fährt nun hoch und loggt sich mit dem Nutzer kiosk ein. In unserem Fall wurde nun der Bildschirm um 90 Grad über die Systemeinstellungen gedreht, da die Webseite hochkant angezeigt werden sollte. Damit der Bildschirm nicht nach einer gewissen Zeit ausgeht, sollte der Bildschirmschoner und die automatische Sperrung in den Systemeinstellungen unter Helligkeit und Sperren deaktiviert werden. Anschließend sollte im Terminal:
gsettings set org.gnome.desktop.screensaver idle-activation-enabled false
eingeben werden. Im Nutzerordner des Nutzers kiosk wird nun eine Datei mit dem Namen firefox.sh angelegt. Die angelegte Bash-Datei wird mit folgendem Inhalt gefüllt:
#!/bin/bash
setterm -blank 0
sleep 90;
while true;
do
firefox -url http://example.org/
sleep 0.1s;
done
Im Firefox selbst sollte ein Add-On für den Kiosk-Modus installiert werden. Hier stehen mKiosk und R-kiosk zur Auswahl. Mit dem Add-On wird der Firefox in die Möglichkeiten versetzt die Webseite im Vollbild anzuzeigen. Für den automatischen Start des Firefox werden nun folgende Zeilen zur .profile-Datei des Nutzers kiosk hinzugefügt:
# Start firefox ./firefox.sh &
Die 90 Sekunden Verzögerung in dem Skript dienen dazu, dem System genug Zeit für die Initialisierung und die Bildschirmdrehung zu geben. Damit der Mauszeiger nicht zu sehen ist, bietet sich das Paket unclutter an. Mit:
unclutter -idle 0.01 -root
wird der Mauszeiger nach der definierten Zeit ausgeblendet, bis er wieder bewegt wird.