Die Erlaubnis wird für jeden Typ (z.B. Kontakte, Kalendar,…) zur Runtime (während die App läuft) einzeln eingeholt. Es wird jedoch kein automatischer Dialog angezeigt, dieser muss vom Entwickler explizit aufgerufen werden. Alles andere führt zu einem Absturz der App (SecurityException), falls es noch keine Zusage gab. Zusätzlich kann der User, wie bereits erwähnt, jederzeit eine Zusage in den Einstellungen wieder rückgängig machen.

Man muss also als Entwickler darauf gefasst sein jede betreffende Funktion in der App um diese Permission Abfrage zu erweitern. Dabei kann der User für einen Fall einmalig eine Zustimmung geben oder auf Dauer zustimmen, was in den System-Einstellungen gespeichert wird, die aber wiederum jederzeit vom User und außerhalb der eigenen App geändert werden können.

Betreffen tut dieser Mechanismus nur Apps die mit einer targetSDK 23 auf einem Android 6 Gerät gelauncht werden. Ältere Apps die auf einem Android 6 Gerät bereits installiert sind, werden mit dem alten System behandelt. Die Permission-Abfrage wird wie vor Android 6 bei der Installation durchgeführt. Dadurch werden alle Zusagen folglich automatisch in den System-Einstellungen gespeichert. Gefahr besteht dann, wenn der User dennoch seine Zusage in den System-Einstellungen zurücknimmt. Hier warnt das System den User jedoch selbstständig vor der Gefahr, dass die App dann zum Absturz gebracht werden kann. Hat man also seine aktuelle in Entwicklung befindliche App noch nicht Permission-sicher umgestellt, sollte man die tagetSdkVersion vorerst auf 22 belassen.

Nicht alle Permissions fallen in dieses neue Permission-System. Einige werden automatisch bei der Installation der App akzeptiert und scheinen in den System-Einstellungen nicht auf, womit sie auch nie zurückgenommen werden können. Daher braucht man sich um sie nicht kümmern:

android.permission.ACCESS_LOCATION_EXTRA_COMMANDS
android.permission.ACCESS_NETWORK_STATE
android.permission.ACCESS_NOTIFICATION_POLICY
android.permission.ACCESS_WIFI_STATE
android.permission.ACCESS_WIMAX_STATE
android.permission.BLUETOOTH
android.permission.BLUETOOTH_ADMIN
android.permission.BROADCAST_STICKY
android.permission.CHANGE_NETWORK_STATE
android.permission.CHANGE_WIFI_MULTICAST_STATE
android.permission.CHANGE_WIFI_STATE
android.permission.CHANGE_WIMAX_STATE
android.permission.DISABLE_KEYGUARD
android.permission.EXPAND_STATUS_BAR
android.permission.FLASHLIGHT
android.permission.GET_ACCOUNTS
android.permission.GET_PACKAGE_SIZE
android.permission.INTERNET
android.permission.KILL_BACKGROUND_PROCESSES
android.permission.MODIFY_AUDIO_SETTINGS
android.permission.NFC
android.permission.READ_SYNC_SETTINGS
android.permission.READ_SYNC_STATS
android.permission.RECEIVE_BOOT_COMPLETED
android.permission.REORDER_TASKS
android.permission.REQUEST_INSTALL_PACKAGES
android.permission.SET_TIME_ZONE
android.permission.SET_WALLPAPER
android.permission.SET_WALLPAPER_HINTS
android.permission.SUBSCRIBED_FEEDS_READ
android.permission.TRANSMIT_IR
android.permission.USE_FINGERPRINT
android.permission.VIBRATE
android.permission.WAKE_LOCK
android.permission.WRITE_SYNC_SETTINGS
com.android.alarm.permission.SET_ALARM
com.android.launcher.permission.INSTALL_SHORTCUT
com.android.launcher.permission.UNINSTALL_SHORTCUT

Stellen wir uns also vor wir schreiben eine Funktion die alle Kontakte aus dem Adressbuch des Users auslesen soll. Nächster Schritt ist also nach diesem neuen System, dass wir eine zweite Funktion schreiben, die überprüft ob eine Erlaubnis für Kontakte bereits vorhanden ist. Wenn nicht, dann soll ein Dialog angezeigt werden, der den User fragt ob er diese Erlaubnis meiner App geben will. Interessanterweise reicht schon eine Zustimmung das Kontakte gelesen (android.permission.READ_CONTACTS) werden dürfen um auch Kontakte zu ändern/erstellen (android.permission.WRITE_CONTACTS) da dieses Permissions sich in der gleichen Gruppe (android.permission-group.CONTACTS) befinden.

Alle Details zur Implementierung finden sich hier: http://developer.android.com/training/permissions/requesting.html

Funktionen für die Support-Libary sind vorhanden.

Wem die normale Vorgehensweise zu komplex ist, der kann sich auch eine 3rd Party Libary zur Hilfe nehmen. Diese arbeitet z.B. einfach mit dem Annotieren von Funktionen: http://hotchemi.github.io/PermissionsDispatcher/

Abschließender Gedanke: Greift man in seiner App auf mehr externe Resourcen als nur Kontakte zu, sollte man sich überlegen wie die App dennoch nützlich sein kann, wenn der User zwar die Erlaubnis für Kontakte gibt, aber nicht für Telefon.

The post Permission System – Android 6 Marshmallow appeared first on Mobile USTP MKL.

Wichtig für uns im ersten Schritt war es die Daten richtig auszulesen und in der App anzuzeigen. Doch dafür ist sehr viel Logik notwendig, die eher dürftig dokumentiert ist. Auch gibt es selten bis gar nicht Tutorials im Internet dazu zu finden. Eine Art Library die einem solche Dinge überhaupt abnimmt findet sich leider überhaupt nicht.

Grundlegend gibt es verschiedene ContentProvider, man kann auch eigene schreiben. Neben dem CalendarProvider gibt es auch z.B. den ContactsProvider, mit dem man das Telefonbuch des Users auslesen kann. Um nun den CalendarProvider auszulesen braucht es einen sogenannten ContentResolver über den eine Query gemacht wird, nämlich mit der URI der internen Calendar Datenbank am Gerät (speziell hier die URI zu der Tabelle mit den verfügbaren Kalendern) und weiteren SQL Parametern.

Uri uri = Calendars.CONTENT_URI;
private static final String[] calendarsColumns = new String[] {
Calendars._ID,
Calendars.CALENDAR_DISPLAY_NAME,
Calendars.CALENDAR_COLOR,
Calendars.VISIBLE
};
Cursor cursorCalendars = getApplicationContext().getContentResolver.query(uri, calendarsColumns, null, null, null);

Als Rückgabeobjekt bekommt man einen Cursor, den man auch von anderen Programmiersprachen kennt. Mit diesem kann man die Daten Zeile für Zeile durchgehen und die jeweiligen Felder auslesen. Das String Array calendarsColumns enthält die gewünschten Spaltennamen, die weiteren Parameter sind bei diesem Beispiel null, hier könnte man bspsw. Sortierung angeben. Würde man den SQL String ausgeben können, würde er wahrscheinlich so aussehen: “SELECT _ID, CALENDAR_DISPLAY_NAME, CALENDAR_COLOR , VISIBLE FROM CALENDARS”

ArrayList<WTCalendar> arrayList = new ArrayList<>();
while (cursorCalendars.moveToNext()) {
WTCalendar calendar = new WTCalendar(
cursorCalendars.getLong(cursorCalendars.getColumnIndex(Calendars._ID)),
cursorCalendars.getString(cursorCalendars.getColumnIndex(Calendars.CALENDAR_DISPLAY_NAME)),
cursorCalendars.getLong(cursorCalendars.getColumnIndex(Calendars.CALENDAR_COLOR)),
cursorCalendars.getString(cursorCalendars.getColumnIndex(Calendars.VISIBLE)).equals(“1”) //boolean
);
arrayList.add(calendar);
}
cursorCalendars.close();

Als nächstes machen wir uns eine leere ArrayList aus eigenen Calendar Objekten die wir mit den bestimmten Daten aus der Tabelle befüllen wollen. In einer while Schleife die prüft ob es eine (weitere) Zeile (Row) im Ergebnis gibt, erstellen und befüllen wir ein Custom Object (WTCalendar) und fügen es danach der ArrayList hinzu.

Schauen wir uns diesen Codeausdruck aus dem oberen Codesnippet genauer an:

cursorCalendars.getString(cursorCalendars.getColumnIndex(Calendars.CALENDAR_DISPLAY_NAME))

Mit der Methode getString des Cursor Objekts bekommen wir einen String eines Feldes. Wichtig hier ist natürlich das dieses Feld auch einen String beinhaltet, ansonsten würde das zu einem Fehler führen. Dieser Methode getString muss ein Index der Spalte/des Feldes als int übergeben werden. Diesen Index bekommen wir über die Methode getColumnIndex des Cursor Objekts, der wir die Konstante Index Calendars.CALENDAR_DISPLAY_NAME übergeben, diese entält den Index der Spalte/des Feldes. Diese Variante schützt davor einen Fehler zu bekommen, falls Android auf einem anderen Gerät die Spalten-Anordnung in der Tabelle geändert hat.

Besonders wichtig ist noch die Zeile cursorCalendars.close(); , damit wird der Cursor auch wieder freigegeben und bleibt damit nicht im Speicher, was u.a. die Batterielaufzeit des Geräts beeinträchtigen würde.

Wollen wir nun Events (Termine) auslesen wäre das Verfahren dasselbe wie im gerade gezeigten Snippet. Nur die Definition des Cursors unterscheidet sich durch eine andere Uri, andere Spalten und mögliche Parameter.

Uri uri = Events.CONTENT_URI;
private static final String[] eventsColumns = new String[] {
Events._ID,
Events.TITLE,
Events.DESCRIPTION,
Events.EVENT_LOCATION,
Events.DTSTART,
Events.DTEND,
Events.ALL_DAY,
Events.RRULE,
Events.CALENDAR_ID
};
Cursor cursorEvents = WTApplication.contentResolver.query(
uri,
eventsColumns,
Events.CALENDAR_ID + ” = 1″,
null,
Events.DTSTART + ” ASC”);

Die ersten beiden Paramter der query Methode sind ja schon bekannt. Der dritte Parameter ist bei SQL als WHERE zu verstehen, also eine Einschränkung des Suchergebnisses. Hier sollen nur Termine zurückgegeben werden, die zum Kalendar mit der ID “1” gehören. Der nächste Parameter, der hier null gesetzt ist, kann dazu verwendet werden den Ausdruck ” = 1″ in einem Array an Parametern zu übergeben, auf dies wurde hier verzichtet, da es nur einen WHERE Parameter gibt. Der letzte Parameter in der query Methode lässt einen die Ergebnisse vorsortieren. Würde man also den SQL String wieder ausgeben können, würde er wahrscheinlich so aussehen: “SELECT _ID, TITLE, DESCRIPTION, EVENT_LOCATION, DTSTART, DTEND, ALL_DAY, RRULE, CALENDAR_ID FROM EVENTS WHERE _ID=1 ORDER BY DTSTART ASC”

Es gibt natürlich auch Methoden für INSERT und UPDATE/DELETE, doch soweit sind wir in unserer App noch gar nicht gekommen diese zu verwenden.

Die Doku zeigt dass es also eine Tabelle “Calendars” und eine Tabelle “Events” gibt. Nun führt sie aber auch eine Tabelle “Instances” an, dort heißt es:

“This table holds the start and end time for each occurrence of an event. Each row in this table represents a single event occurrence. For one-time events there is a 1:1 mapping of instances to events. For recurring events, multiple rows are automatically generated that correspond to multiple occurrences of that event.”

Nachdem ich mir die Events und Instances mal geloggt habe um zu sehen was überhaupt für Daten in diesen Tabellen vorhanden sind, habe ich entdeckt dass diese Aussage ziemlich gewagt ist. Zu den sich nicht wiederholenden Events gibt es keinerlei 1:1 Instances und zu den sich wiederholenden Events scheint es sehr buggy zu sein. So gibt es teilweise Instances und teilweise einfach nicht, obwohl die Regel (für die Wiederholung des Termins) im Event gespeichert ist. Man kann sich also leider nicht darauf verlassen sich nur die Instances auszulesen, sondern muss eigentlich wie folgt vorgehen:

– Auslesen der Events
– Überprüfen ob das Event sich wiederholt
– Überprüfen ob es eine oder mehrere Instances zum Event gibt
– Wenn nicht -> Regeln für sich wiederholende Events selbst interpretieren und Instanzen anlegen
– Eigene(s) Event Objekt(e) selbstständig befüllen und mit eigenenen Daten erweitern, falls nicht in Tabelle vorhanden
– Darauf achten, dass bei der Erstellung keine ungewünschten Duplikate entstehen

Man sieht also an diesem Punkt ist plötzlich viele manuelle Logik nötig, was das Programmieren einer solchen App ziemlich komplex macht. Vielleicht ist das der Grund warum es nur wenige Kalendar Apps und noch weniger Tutorials oder Dokumentationen gibt.

The post Android – Wie bekomme ich Termine des Users in meine App? appeared first on Mobile USTP MKL.

mfg-Magazin 01/2015

Wer kennt das als Student nicht: Die nächste Abgabe einer Arbeit steht an, für die Prüfung nächste Woche muss noch gelernt werden, die Wohnung könnte auch mal wieder geputzt werden und wer geht eigentlich einkaufen? Also schrieb man sich früher ganz altmodisch Notizzettel. Auch heute tun das wohl noch Menschen, aber Studenten die ein Smartphone besitzen, haben wahrscheinlich auch eine Todo-App oder wollen sich eine anschaffen.

Das Chaos braucht endlich eine Ordnung, doch welche Todo-App soll es sein? Wir haben uns in der Redaktion drei unterschiedlich umfangreiche Todo-Apps gesucht und nach bestimmten Kriterien getestet. Die Übersicht der Testergebnisse findet sich am Ende dieses Artikels. Getestet wurde dabei auf einem HTC One-V mit einer Bildschirm-Diagonale von 3,7 Zoll.

Astrid Tasks

Beim Starten der App fällt schon mal auf, im Vergleich zu den anderen Apps: Man muss sich nicht einloggen um eine einfache Todo-Liste zu erstellen. Die App funktioniert also auch jederzeit offline, nur das man dann natürlich auf die Spracheingabe verzichten muss. Diese bietet nämlich eine Erstellung eines Todos auf Knopfdruck und folgender Spracheingabe. Damit wird jedoch nur der Name des Todos festgesetzt. Danach wird man weitergeleitet auf einen Screen, der eine Menge Einstellungen enthält. So kann man ein Fälligkeitsdatum setzen und was sehr schön ist auch gleich zusätzlich einen Kalendereintrag erstellen. Weiters ist es möglich eine Prioriät auszuwählen und eine Kategorie und eine Beschreibung einzutragen. Auch kann man ein Todo verbergen lassen bis zu einem bestimmten Datum, also z.B. eine Woche vor dem Fälligkeitsdatum. Natürlich gibt es für die Erinnerung an das Todo diverse Erinnerungsfunktionen. Zusätzlich können auch noch Audiovisuelle Dateien angehängt werden und nachträgliche Kommentare hinzugefügt werden.

Astrid zeigt also eine simple Herangehensweise an das Thema Todo-Listen und ist bei der Bedienung möglicherweise doch schon ein wenig zu komplex, so ist z.B. fraglich ob wirklich so viele zusätzliche Einstellungen und hinzufügbare Daten wirklich gebraucht werden. Ansonsten bietet das Design eine schöne Android typische Umgebung in der der geübte Android-User sich schnell mit bekannten Komponenten zurechtfinden wird. Weniger geübte User werden aufgrund der Optionsvielfalt möglicherweise abgeschreckt sein oder einfach Einstellungen nie zu Gesicht bekommen.

Todoist

Todoist nennt sich selbst die “Beste Todo-App”, daher haben wir auf sie ein besonderes Auge geworfen und wollten herausfinden ob das wirklich stimmen kann. Zu einem Massenvergleich führt dieser Artikel nicht und von einem Vergleich mit dem zweiten Platzhirsch “Wunderlist” wurde abgesehen, da sich die Apps zu ähnlich sind.

Das Design gleich zu Beginn des ersten Appstarts kann sich schon mal sehen lassen und zeigt eine sehr professionelle und elegante Herangehensweise an das Thema. Hier muss aber auch gesagt werden, dass diese App schon im Vorfeld bestimmte Erwartungen setzt, so gibt es eine Premium Version mit weiteren Funktionen und eine Business Version für Unternehmen. Die Todo-Daten laufen dabei über eine Cloud, werden dort also gespeichert und können dadurch von überall, also von jedem Gerät und jedem Betriebssystem aus gelesen werden. Dazu steht jeweils eine eigene App auf allen Systemen zur Verfügung.

Jetzt wollen wir uns also mal die Android App genauer ansehen. Doch bevor wir loslegen können unsere Todos anzulegen, müssen wir uns anmelden bzw. registrieren, da wir noch kein Benutzer-Konto haben. Trotz der schönen Optik des animierten Startscreens, fällt uns gleich ein erster Fehler auf, der zur Verwirrung führt: Es gibt zwei Buttons, die beide Anmelden heißen. Erst durch Trail & Error finden wir heraus, dass sich hinter dem zweiten Button die Registrierungsmaske befindet.

Der Startbildschirm nach dem erfolgreichen Anmeldens unterscheidet sich auf den ersten Blick nicht groß von dem der Astrid-App. Mit dem “+”-Button können wir ein neues Todo hinzufügen. Der Einstellungsscreen der jetzt folgt sieht sehr abgespeckt aus. Neben dem Titel, wir sehen enttäuschenderweise keine Möglichkeit für eine Spracheingabe, gibt es eine Kategorieauswahl und die Eingabemaske für das Fälligkeitsdatum. Was jedoch positiv auffällt ist die Kontexthilfe, so scheint bei jedem Eingabefeld ein Sprechblase auf, die beschreibt was hier zu tun ist und beim Fälligkeitsdatum werden vorgefertigte Optionen wie “Heute”, “Morgen”, “In einer Woche” angezeigt, die direkt wählbar sind und scheinbar als fixe Schlüsselwörter dienen, die dem System wissen lassen welches Datum gemeint ist.

Wurde das Todo angelegt werden wir darauf aufmerksam gemacht, dass es nun weitere Optionen gibt, wenn wir das Todo in der Liste antippen. Da sind also die weiteren Einstellungen versteckt worden. Anders als bei Astrid und eindeutig schöner gelöst befinden sich nun die gewohnten Einstellungen nicht in einem Screen sondern versteckt hinter mehreren Toolbar Buttons. So kann das Todo nun mit einer Priorität oder mit weiteren Etiketten und Levels erweitert werden. Notizen können nur in der Premium Version hinzugefügt werden, was uns ein wenig wundert, ist es doch keine wirklich starke Funktion, die wir jetzt unbedingt vermissen würden. Auch Erinnerungen sind eine Premiumfunktion. Angesichts der Astrid-App, die wir im Vorfeld getestet haben und die all diese Funktionen kostenlos enthielt, kommen uns diese Premiumfunktionen nun etwas unverständlich vor und führen für uns persönlich sicher nicht zum Titel “Beste Todo-App”, sie hat noch eher Chancen auf “Best Design”. Da hilft auch keine nett gemeinte Statistik über das Todo-Verhalten des Users, die die Todoist-App weiters bietet. Interessant zu erwähnen für WG-Bewohner ist die “Share”-Funktion, die es zulässt Todo-Listen mit anderen App-Besitzer zu teilen.

Remember the milk

Der Titel der App führt schon mal zum Thema Todos und Einkaufslisten, doch was bietet die App wirklich? Kann sie sich durch spezielle Funktionen oder durch eine intuitive Bedienung hervorheben? Nachdem wir uns auch hier registriert und angemeldet haben kommen wir ohne jegliche Starthilfe auf den Startscreen der App. Hier wird uns aber keine leere Liste präsentiert sondern das Hauptmenü. Hier gibt es die Wahlmöglichkeiten für “Heute”, “Morgen” und weitere folgende Wochentage, dabei zeigt uns eine rote “1”, dass “Heute” bereits ein Todo vorhanden ist. Am rechten Bildschirmrand fällt uns nun auf, dass dort ein anderer Screen ins Bild ragt. Intuitiv ziehen wir den Screen nach links um ihn im Ganzen zu sehen. Da haben wir ja die Liste gefunden und die Ersteller der App haben uns bereits ein Todo erstellt, mit der Bezeichnung “Probieren Sie Remember The Milk”.

Keine weitere Hilfe? Na dann probieren wir die App eben selbstständig aus. Das typische “+” ist auch hier als Button zu finden. Das Design des folgenden Einstellungsscreens ist bescheiden, ähnlich wie in der Astrid-App sehr systemnah gehalten. Der Umfang der Einstellungen eines Todos gleicht dem der Todoist-App. Optional können Felder hinzugefügt werden, jedoch ist der Button dazu zu unscheinbar und erklärt nicht die Funktion dahinter, also ein typischer Fall von zu viel Komplexität für den User. Befindet sich das Todo nun in der Liste, kann es wie in den anderen Apps angewählt werden wodurch Details und Optionen aufscheinen. Hier passiert das über einen eigenen Screen und da fällt uns etwas ungutes auf: Es gibt keinen Back-Button in der Actionbar, wie ihn jeder Android-User automatisch erwarten würde. Das problematische dabei zeigt sich als wir immer wieder statt dem Back-Button den vorhanden “Häkchen”-Button tippen, der das Todo jedes Mal erledigt, was wir ja gar nicht wollen. Immerhin gibt es eine “Rückgängig machen”-Funktion, aber ehrlich gesagt ist das schon ein schwerer Eingriff in die Appgestaltung. Das schreckt wohl auch einige User nach dem ersten Benutzen schon mal ab. Mehr gibt es dazu wohl nicht zu sagen, außer dass man hoffentlich die Milch auch auf einen altmodischen Notizzettel geschrieben hat, falls man das Todo selbst unabsichtlich erledigt bevor man noch einkaufen war.

Testergebnisse

Bitte auf das Vorschaubild klicken um zu vergrößern

Fazit: Mit welcher App bringen Sie Ordnung ins Chaos?

Astrid Tasks, Todoist, Remember the milk. Mit keiner der getesteten Todo-Apps machen Sie als Student etwas falsch, denn die Unterschiede liegen im Detail. Sie legen Wert auf Design und gute Bedienung? Dann sollten Sie einen Blick auf Todoist oder Astrid Tasks werfen. In puncto Funktionalität ist Astrid Tasks dank cloudloser Speicherung und vieler kostenloser Funktionen sicher der unangefochtene Spitzenreiter. Wollen Sie etwas riskieren oder gefällt Ihnen einfach nur der witzige Name, dann probieren Sie Remember the milk aus. Und sollten Sie sich nicht entscheiden können, installieren Sie einfach zwei oder mehr Todo-Apps und vergleichen selbst.

The post Todo-Apps im Test appeared first on Mobile USTP MKL.

Mein erstes Konzept für das Initialprojekt war nämlich eine Art “Augmented Reality Station” in jedem Stockwerk der FH, dass mir eine Art von Interface präsentiert sobald ich auf einen Marker zeige. In diesem Interface kann ich sofort eine Art 3D Karte des Stockwerks mit meiner derzeitigen Position sehen und kann natürlich nach einem Ziel suchen, dass mir dann über eine Führungslinie auf der Karte angezeigt wird.

Das Konzept wäre sogar auf die Raum-/Stundenpläne, die jetzt in Papierform neben jeder Raumtür aufgehängt werden, erweiterbar. Erstens würde man Papier sparen, die Pläne müssten bei Änderungen nicht ausgetauscht werden und man könnte ohne mühsam ins Web-CIS zu gehen direkt sich anzeigen lassen wie es mit dem Raumzeiten aussieht. Natürlich wäre der Zugriff auf den FH-Server von Nöten

Da unser Initialprojekt eine Web-App sein sollte, musste ich also herausfinden ob “Augmented Reality” überhaupt im Web-Browser möglich ist und was es da eigentlich für Möglichkeiten gibt. Wie ihr euch vorstellen könnt, wurde ich nicht fündig, aber was ich gefunden habe, möchte ich hier präsentieren. Dieser Artikel ist aber kein Tutorial zu “Augmented Reality”.

Augmented Reality im Web?

Nach meinem bisherigen Wissen über Augmented Reality, funktioniert das Ganze ja über die Kamera des Smartphones. Erst mal platziert man einen sogenannten “Marker” im Blickfeld der Kamera. Im nativen Code greift man dann auf die Kamera zu und liest sich die Live-Frames aus. Diese werden durch einen Algorithmus gejagt und der Marker wird in den Daten identifiziert. Nun kann man an der Position des Markers ein beliebiges 2D oder 3D Objekt über die Kamera-Frames legen.

Das größte Problem beim Web-Browser liegt natürlich darin, dass man (noch?) keinen direkten Zugriff auf die Kamera aus dem Browser heraus hat. Indirekt kann man ja bereits mit JS in der Hybrid- und Web-App-Entwicklung ein Foto von der Kamera “anfordern” lassen. Das ist also der ausschlaggebende Schritt, der mein Projekt scheitern ließ.

Ich gab mich aber damit nicht zufrieden und wollte mehr recherchieren und zwar in die experimentelle Richtung. Vielleicht gab es dort Information. Was tut man also, wenn man nach experimentellen Geschichten sucht und keine wissenschaftlichen Artikel lesen will? Richtig, man geht auf Youtube

Und nach nur kurzer Zeit fand ich dieses Video hier:

Auf den ersten Blick dachte ich mir: Ja, das ist es doch was ich suche! Und tatsächlich ist es schon nahe dran, aber eben nicht ganz.

Was ist JSARToolkit & Three.js?

Nun, ich zitiere mal direkt aus github wo wir die JSAToolkit Libary finden: “This is a JavaScript port of FLARToolKit, operating on canvas images and video element contents. And hopefully one day on device elements with webcam input.” ( https://github.com/kig/JSARToolKit )

Also zuerst mal: FLARToolKit (was wiederum ein AS3 Port von NyARToolkit (Java) ist, der wiederum ein Port von ARToolkit (das Original, glaube ich) ist) ist eine Libary, die Marker in Bildern findet und deren Position und Ausrichtung im 3D Raum ausgibt. JSAToolkit ist damit der JS Port von FLARToolKit. Jetzt kann aber (wie im Zitat lesbar) das JSAToolkit diese Informationen nur in einem Video- oder einem Canvas-Element herausfinden, nicht in einer Webcam und damit klarerweise auch nicht in einer Kamera eines Smartphones.

Three.js ist eine Libary, die uns auf einfache Weise WebGL-3D Objekte erstellen und zeichnen lässt.

Wie funktioniert nun der Ansatz JSAToolkit & Three.js?

Genauso wie im nativen Ansatz findet uns das JSAToolkit in zum Beispiel Frames einer abspielenden Videodatei (wie man es auch in dem Video sieht) den Marker und gibt uns Informationen darüber aus. Mit diesen können wir dann über Three.js ein Objekt an dessen Position zeichnen lassen.

Doch dass diese Funktion im Browser schon möglich ist und noch dazu mit JavaScript, ist beachtlich.

Fazit

Es war also in diesem Fall doch nur ein kleiner großer Schritt, dann hätte mein Projekt umgesetzt werden können. Ob diese JSAToolkit Libary nur wegen dem fehlendem Zugriff auf Webcam und Smartphone-Kamera nicht weiterentwickelt wird oder sonstige Probleme sie daran hindern, kann ich natürlich nicht beantworten.

Mal sehen was meine weiteren Recherchen ergeben werden.

Quellen:

Video JSARToolKit & Three.js – http://www.youtube.com/watch?v=BIFo1przLY4
Weitere ähnliche Videos – http://www.youtube.com/results?search_query=JSARToolKit+android

JSARToolKit – https://github.com/kig/JSARToolKit
ThreeJS – http://threejs.org/

FLARToolKit – http://www.libspark.org/wiki/saqoosha/FLARToolKit/en
ARToolkit – http://www.hitl.washington.edu/artoolkit/
NyARTookkit – http://nyatla.jp/nyartoolkit/wp/

The post Augmented Reality im Web – Teil 1 appeared first on Mobile USTP MKL.

Bei meiner Ideenfindung für das Initialprojekt in MOBAW fand ich eine mir noch nicht bekannte Vibration API für den Browser. Kurz gesagt man kann auf die Vibrationsfunktion des Smartphones über den Webbrowser zugreifen. Leider nur begrenzt, denn die Funktion bietet nur die Vibration einzuschalten, für beliebige ms vibrieren zu lassen und dann wieder auszuschalten oder eine Pause einzulegen, dazu wird einfach ein Array mit Vibrierzeiten und Pausen übergeben.

Also hier nochmal die API in Codeform:

http://davidwalsh.name/vibration-api

DAS SPIEL

Das Spielprinzip des Games CodeKnacker ist denkbar einfach: Ein Random-Code soll erraten werden. Zusätzlich hast du als Spieler eine besondere Fähigkeit, du kannst durch “scannen” der Tasten herausfinden welche Ziffer/Zeichen im Code an nächster Stelle kommt. Hier kommt die API zur Unterstützung, aber nur wenn dein Smartphone kein iPhone ist und du möglichst im Chrome spielst.
Du tapst also auf eine beliebige Taste und wenn dein Smartphone dabei vibriert weißt du das die Ziffer als nächstes im Code vorkommen muss.

Um aber jetzt diese Ziffer ins “System” einzugeben und damit den ganzen Code nach der Reihe herauszufinden, musst du nochmal auf die gleiche Taste, die vibriert hat, tappen. Du siehst jetzt im Eingabefeld die eingegebene Ziffer und alle weiteren. Gibst du eine falsche Ziffer ein oder läuft die Zeit ab (du wirst vom System beim Hacken entdeckt), wird die Eingabe zurückgesetzt und du musst neu beginnen den gleichen Code einzugeben. Wenn du dir ihn gemerkt hast geht es natürlich leichter.
Mit jedem richtig eingegeben Code, wird die Codelänge vergrößert und die Zeit zum Herausfinden kürzer.

TECHNOLOGIEN

Verwendet habe ich Standard JS, die “normale” jQuery-Libary (Spiel-Logik, Animationen) und zwei jQueryUI Elemente (Progressbar, ModalDialog).

WEBLINK

Wers anspielen will oder sehen will wie weit er kommt (irgendwann läuft einem wohl die Zeit davon ):

http://dm141554.students.fhstp.ac.at/mfg

The post Initialprojekt: codeKnacker appeared first on Mobile USTP MKL.