Nachdem vor Kurzem pingeb.org auch in Graz an den Start ging und dort in sehr kurzer Zeit bereits unglaublich viele Downloads erzeugt hat, finde ich ist es wiedermal an der Zeit uns den Zahlen zu widmen.

Wie ihr ja wisst “zählt” pingeb.org und zwar nicht nur wie oft welcher Sticker genutzt wurde sondern auch welche mobilen Betriebsysteme und Technologie (NFC oder QR) genutzt wird um an den Content zu kommen.

Das wird hier nun sicher keine vollständige Marktstudie, aber es zeichnet ein grobes Bild der Nutzung und Akzeptanz mobiler Technologien in Graz und Klagenfurt.

Die nackten Zahlen

Klagenfurt

Einwohner 94.796 (Stand 1.1.2012 – Quelle Wikipedia/Klagenfurt)

Projektstart 2.7.2012

In Betrieb seit 289 Tagen

Downloads via pingeb.org 2852 (Stand 16.04.2013)

Graz

Einwohner 265.318 (Stand 1.1.2012 – Quelle Wikipedia Graz)

Projektstart 30.03.2013 (Pilotphase) – offizieller Start 9.4.2013

In Betrieb seit 18 Tagen

Downloads via graz.pingeb.org 426 (Stand 16.04.2013)

Downloads zu Einwohner und Zeit

Basierend auf den genannten Zahlen gibt es also in Klagenfurt ca. einen Download pro 33 Einwohner und in Graz ca. einen pro 622 Einwohner.

Nimmt man nun beide Städte zusammen kommt auf ca.  einen Download pro 109 Einwohner. Eine Zahl die ich angesichts des möglichen Zielpublikums sehr beeindruckend finde.

Wie man sieht ist Graz ja erst seit sehr kurzer Zeit in Betrieb und deshalb mit den Downloads pro Einwohner noch etwas hinterher, aber das wird sich, wenn es so weiter geht mit der Nutzung, wohl schnell ändern.

Denn in Klagenfurt stehen wir bei ca. 10 Downloads pro Tag, wohin gegen es Graz auf beeindruckende 23 Downloads pro Tag schafft. Bricht man das nun wieder auf die Einwohner herunter bedeutet das, dass es in Klagenfurt jeden Tag einen Download pro 9.479 Einwohner gibt. In Graz ist es ca. ein Download pro 11.535 Einwohner. Hier liegen die beiden Städte also schon sehr nahe an einander und das obwohl Graz erst seit 18 Tagen in Betrieb ist. Man kann also davon ausgehen, dass sich dieses Verhältnis in Graz noch deutlich verbessert und somit die Downloadzahlen recht bald Klagenfurt überholen werden und dann sieht es auch mit “Gesamt Downloads zu Einwohner” bald ganz anders aus.

Mobile Betriebsysteme

Jeder Download speichert neben dem genutzten Tag auch welches Betriebsystem genutzt wurde. Hier dominieren in beiden Städten ganz klar Android und iOS. Andere Betriebsysteme wie Windows Phone und das ältere Symbian schaffen es gemeinsam kaum auf 2%, wohin gegen iOS und Android in beiden Städten über 90% ausmachen.

Genau gesagt sind es 77% Android und 20% iOS in Graz und 56% Android und 42% iOS in Kalgenfurt. Macht man daraus nun absolute zahlen sind das in Klagenfurt 1597 Android und 1197 iOS Downloads. In Graz wären es dann 328 Android und 85 iOS Downloads. Naürlich erwarte ich in Graz noch einen deutlichen Anstieg von iOS, aber wie deutlich dieser wird, wird sich erst zeigen.

Rechnet man nun beide Städte zusammen ergibt das 1925 Android und 1282 iOS Downloads. In Prozent sind das dann ca. 59% Android und ca. 39% iOS. Ich bin sehr gespannt wie diese Statistik in einem Jahr aussieht und ob es ein drittes Betriebsystem über 5% schafft.

NFC und QR

Jeder Tag ermöglicht es auf zwei Arten zum Inhalt zu kommen. Entweder durch einfaches auflegen des Geräts auf den NFC Tag oder durch scannen des QR Codes. NFC ist noch recht neu und in Geräten mit iOS noch gar nicht enthalten und somit rechnete ich letztes Jahr im Juli mit einem NFC Anteil von unter 7%. Ich wurde eines Besseren belehrt.

Trotz der Tatsache, dass nicht jedes Smartphone einen NFC-Leser hat und die Technologie sicher nicht jedem Nutzer überhaupt bekannt ist, wird sie sehr gut angenommen und genutzt.

In Klagenfurt sind ca. 28% der Downloads über den NFC erfolgt und in Graz waren es sogar 34%. Man kann also sagen, dass ca. jeder dritte Download mittels NFC erfolgt und das ist meines Erachtens nach richtig viel und richtig erfreulich!

Es werden immer mehr NFC-fähige Geräte am Markt angeboten und der Nutzen der Technologie geht weit über pingeb.org und berührungsloses Zahlen hinaus. Wenn die Technologie jetzt schon so gut angenommen wird bin ich sehr gespannt wie es in einem Jahr aussieht und ob wir dann schon mehr kontaktlose Anwendungsfälle in unserem Alltag sehen.

Soviel also zu den aktuell durch Projekt Ingeborg erhobenen Zahlen. Wenn Graz 2000 Downloads erreicht hat werde ich dieses Zahlenspiel erneut machen und sehen sich das Ganze entwickelt. Bis dahin überlasse ich euch nun euren Interpretationen und Erwartungen dazu, würde mich aber freuen wenn ihr sie mir hier mitteilen würdet.

Wie ihr ja wisst baue ich neben dem pingeb.org Wordpress Plugin auch die pingeb.org Android App. In einer der nächsten Versionen der App will ich das Webview, welches aktuell die Blogs anzeigt, durch einen schönen Newsstream ersetzen.

Dazu muss ich aber die RSS Feeds der einzelnen Seiten lesen und wie wir wissen kann RSS Parsen auch recht anstrengend sein. Deshalb habe ich mir ein kleines Library gebaut, welches es ermöglicht unter Android einen RSS 2.0 Feed asynchron zu lesen und dann den UI Thread mittels Callback aktualisiert.

Ich dachte mir so ein Library kann nicht schaden, da man sowas ja immer wieder braucht. Außerdem kann man es auch als Basis für andere Feedtypen hernehmen und bei Bedarf erweitern.

Wie alle meine Basteleien ist natürlich auch diese frei und für euch zu haben.

Das Library gibt es hier zum Download -> Simple-Rss2-Android.jar und natürlich gibt es auch den ganzen Sourcecode dazu auf Github als Sample Android App mit DemoActivity. Dort findet ihr auch ein kurzes Sourcecode Sample im Readme.

In diesem Sinne viel Spaß damit und lasst es mich wissen wenn ihr damit was cooles gebaut habt oder es verbessern wollt!

Wer sich etwas mit Softwareentwicklung beschäftigt kommt am Thema “Versionskontrolle” nicht vorbei und landet in Zeiten wie diesen sicher irgendwann mal bei Git.

Am bekanntesten ist hier wohl der Dienst GitHub auf dem auch ich viele meiner OpenSource Projekte hoste.

Was aber wenn ich ein privates Git brauche? Also einen “Git-Server” nur für mich und mein Team ganz privat?

*Ich weiß der Begriff “Git-Server” ist nicht ganz korrekt, erfüllt hier aber mal seinen Zweck.

Also eine Servermaschine welche alle meine Repositories verwaltet und als Master für alle an den Projekten beteiligten Mitarbeitern dient? Kein Problem! Wir setzen uns einen auf!

Systemumgebung

Ich verwende hierfür einen Ubuntu 12.04 LTS Server. Diese Anleitung solte aber auch mit nachfolgenden Versionen und auch mit Debian Servern funktionieren.

Installation

Als erstes müssen wir uns einmal git an sich installieren und wo wir schon dabei sind auch die Python Setuptools. Also verbinden wir uns per ssh auf den server unserer Wahl und beginnen wir folgt.

sudo apt-get update
sudo apt-get install git-core
sudo apt-get install python-setuptools

Anschließend clonen wir uns die aktuelle Version von gitosis in ein Verzeichnis unserer Wahl und installieren es.

git clone https://github.com/tv42/gitosis.git
cd gitosis
sudo python setup.py install

Als letzten Schritt der Installation brauchen wir noch einen git-user. Dieser heißt dann sinnigerweise auch git. Wichtig bei diesem User ist nur, dass er ein Home und eine Shell hat.

sudo adduser --system --shell /bin/sh --gecos 'git version control' -group  --home /home/git git

Damit wäre die Basisinstallation dann auch schon erledigt.

Konfiguration

Nun wechseln wir auf unsere lokale Maschine, also weg vom Git-Server um uns einen RSA Key zu generieren sofern wir nicht schon einen haben.

ssh-keygen -t rsa

Das RSA Keyfile, welches wir benötigen, befindet sich typischerweise in eurem Home-Verzeichnis unter .ssh und endet auf .pub. Diese Datei kopieren wir nun auf den Git-Server nach /tmp.

scp <your-key>.pub <your-user>@<your-server>:/tmp

Nun gehen wir wieder zurück auf den Server und initialisieren Gitosis und fügen dabei gleich unseren Key zu den autorisierten Keys hinzu.

sudo -H -u git gitosis-init < /tmp/<your-key>.pub

Bevor es nun endlich richtig losgeht noch eine kleiner Hinweis. Es kommt immer wieder vor, dass der Post-Update Hook nicht ausführbar ist. Um dem zuvorzukommen führen wir schnell noch folgenden Befehl am Server aus.

sudo chmod 755 /home/git/repositories/gitosis-admin.git/hooks/post-update

Einrichten eines Repositories

Jetzt kommt der richtige coole Teil der ganzen Geschichte, denn wir klonen uns lokal einfach mal das Repository ‘gitosis-admin’ aus. Dazu erstellen wir uns zuerst ein lokales Verzeichnis und klonen es dahinein.

mkdir gitosis-admin
cd gitosis-admin/
git clone git@<your-server>:gitosis-admin.git

In diesem Verzeichnis finden wir nun einen Ordner “keydir”, darin befinden sich alle Keyfiles und eine Datei “gitosis.conf”. Jegliche Konfiguration am Server findet nun über dieses Repository statt. Anlegen eines neuen Repositorie Wir öffnen dazu die Datei gitosis.conf. Darin sollte nun in etwa so aussehen.

[gitosis]

[group gitosis-admin]
members = <your-key-name-without-pub-at-the-end>
writable = gitosis-admin

Um einen neues Repository zu erzeugen müssen wir nur dieses File um  Zeilen wie folgende erweitern. Dieses Beispiel erzeugt ein neues Repository ?testproject? und ich habe darauf Rechte.

[group testproject]
members = <your-key-name-without-pub-at-the-end>
writable = testproject

Nachdme wir diese Änderungen gemacht haben müssen wir noch unsere Änderungen zurück auf den Server spielen.

git add .
git commit -m 'added test project'
git push

Das könnt ihr jetzt testen indem ihr das Repository in einen neuen ORdner lokal abruft eine Testdatei anlegt und das ganze dann wieder pusht.

mkdir /somedir/testproject
cd /somedir/testproject/
git init
git remote add origin git@<your-server>:testproject.git
echo 'mein test dokument' > test.txt
git add .
git commit -m 'erster Testcommit'
git push origin master

Hinzufügen weiterer Benutzer

Das ist  nun wirklich einfach. Ihr  müsst nur von den anderen Teammitgliedern ihre Public-RSA Keys einsammeln und sie in den Ordner “keydir” des Repositorys gitosis-admin kopieren und danach die Namen der Keyfiles ohne .pub unter Member in der entsprechenden Group in dem File gitosis.conf anhängen um sie auf die einzelnen Repositories zu berechtigen. Danach müsst ihr nur noch das Repository commiten und pushen.

Fertig! Schon habt  ihr euer eigenes Git!

In den letzten Wochen wurde viel Neues am Smartphonemarkt präsentiert und ich verfolgte das Ganze mit großer Neugier. Trotzdem werde ich mir keines der neuen Geräte kaufen.

Das hat viele Gründe, der Wichtigste ist aber, dass ich mein aktuelles Smartphone, ein LG Nexus 4, super passend für meine Bedürfnisse finde und für mich einfach kein Weg an Pure-Android vorbeiführt.

Was wäre aber wenn ich das Beste aus den vielen neuen Smartphones nehmen könnte und in einem ultimativem Smartphone vereinigen würde?

Willkommen in Dr. Bruno’s Labor!

Damit das ganze hier nicht zu sehr ausartet schränke ich die Auswahl an Opfern erstmal ein. Zur Auswahl stehen Organe Teile aus folgenden Smartphones:

• Samsung Galaxy S4
• HTC One
• Samsung Galaxy Note 2
• iPhone 5
• LG Nexus 4

Beginnen wir mit den Lebenswichtigen Teilen. So nehmen wir 64GB internen Storage und die 2GB RAM sowie das Exynos 5 Octa 5410 Chipset mit Quad-core 1.6 GHz Cortex-A15 CPU und PowerVR SGX 544MP3 GPU.

Ihr seht also das Herz und die Nieren unserer neuen Kreation kommen von Samsung aus dem S4 und auch ich die Augen nehme ich mir von dort und zwar in Form der 13 MP autofocus Kamera des S4 mit LED flash.

Die Sensoren verstehen sich von selbst und können aus einem beliebigen Smartphone ausgebaut werden. (Accelerometer, gyro, proximity, compass, barometer).

Ich will, dass mein Franken-phone gut aussieht und deshalb kommt es in das Gehäuse des HTC One von dem wir uns auch die Lautsprecher unter den Nagel reisen.

Ganz wichtig ist natürlich auch noch NFC und damit auch Qi zum Laden des Gerät. Beides holen wir uns aus dem LG Nexus 4.

Damit wir es aber nicht ständig laden müssen verbauen wir noch den Akku aus dem Galaxy Note 2 und um das ultimative Display zu haben (und das muss ich neidlos zugeben) holen wir uns das Display des iPhone 5 aber in 4,6”.

Nun müssen wir unserer unnatürlichen Kreation noch Leben einhauchen und das geschieht mittels Pure-Android 4.2.2 wie es am Nexus 4 vorkommt und mit der Sicherheit der erste zu sein der Updates bekommt und auch der, der sie am längsten bekommt.

So würde es aussehen meine Kreation des “perfekten” Smartphones. Wie sieht eure aus?

Als ich heute morgen aufwachte war mir noch nicht bewusst welch großen Verlust ich heute ertragen muss. Ein ständiger Begleiter in meinem Leben wurde zum Tode verurteilt und seine Hinrichtung auch gleich mit einem Datum versehen! Jeden morgen war er meine Quelle der Information, ersetzte seine Vorgänger aus toten Bäumen vollständig und hielt mich immer auf dem Laufenden. Nichts konnte ihn ersetzen.

Welch Grausamkeit! Welch Unrecht! Er hatt doch nichts unrechtes getan!

R.I.P. Google Reader

2005 – 01.07.2013

So durchlebte ich heute in vielen kleinen, über den Tag verteilten Gedanken mehrere Phasen der Trauer:

• Verleumdung: Nein, Google macht so was nicht. “Don’t be evil” und so. Es gibt so viele Nutzer, warum sollte sie denn das tun?
• Wut: Geht’s euch noch gut ihr realitätsfernen Entscheidungsträger da in Mountain View? Wie soll ich den jetzt den Überblick behalten! (gefolgt von nicht blogtauglichen Flüchen)
• Einsicht: Ok, ganz ruhig. Du kannst nichts mehr ändern und hast jetzt Zeit nach Alternativen zu suchen, die das Gleiche können. Bis Juli ist noch lang hin.

…und dann plötzlich: Zweifel

“…, die das Gleiche können…” Dieser Satzfetzen brachte mich zum Nachdenken. Will ich wieder “das Gleiche”? Es ist nicht mehr 2005 und wenn man ehrlich ist hat sich am Reader seit 2005 nichts Großes getan. Keine Innovation und das in 8(!!!) Jahren.

Der Google Reader ist heute voll mit Meldungen darüber, dass eben jener eingestellt wird und möglichen Alternativen, aber will ich “eine Alternative”?

Nein. Ich will etwas, dass meinen Anforderungen entspricht und die haben sich bei genauerer Betrachtung in den letzten Jahren stark verändert, nur hat mich das eben nie gekümmert, denn der Google Reader war ja da und funktionierte und das auch noch richtig gut!

Ich könnte jetzt einfach schnell zu Feedly migrieren (gefällt mir echt ganz gut), oder…

Mauern einreißen!

Beginnen wir also auf dem Haufen Schutt der letzten Jahre. Was ist übrig, wenn wir aus diesem Haufen nur noch das mitnehmen, was uns hier und jetzt sinnvoll erscheint? Wenn ich alle Artikel entferne die ich nur als Überschriften gesehen und meist gar nicht gelesen habe. Alles doppelte entferne und das ganze Spektrum betrachte, nicht nur RSS.

Wünsche, Anforderungen

Everything everywhere und synchronisiert. Der wichtigste Punkt ist wohl, dass diese neue Quelle der Information – wie auch immer diese Aussehen mag – das kann was der Reader am Besten konnte: Synchronisieren und überall bereitstehen. Im Klartext will ich am Tablet genauso komfortabel mit Information versorgt werden wie am Phone oder am Desktop und wenn ich etwas gelesen habe, dann sollen die anderen Geräte es mir nicht noch einmal zeigen!

Alles aus einer Hand. Ich will Aggregation. Ich will nicht 5 Apps besuchen müssen um “alles” zu erfahren. Alle Quellen müssen sich an einem zentralen Punkt zusammenfinden.

Qualität vor Qunatität. Muss ich wirklich von 5 Medien die selbe Rubrik lesen und damit alles doppelt? Nein. Ich muss gut auswählen können was ich von wem sehe. Lieber 5 gute Artikel gelesen, als sie in 100 schlechten zu übersehen.

Social. Ich will lesen was euch bewegt was ihr mit mir teilt! Denn wenn ich jemandem auf Twitter oder Google+ folgen dann tue ich das aus gutem Grund: Es interessiert mich was schreibst und/oder teilst. Deshalb gefällt mir Google+ auch so viel besser als Facebook. Mir folgen über 2800 Personen und ich kann kontrollieren was ich mit ihnen teile! Ich muss nicht ihr “Freund” sein. Genau so verhält es sich auch umgekehrt. Ich folge vielen Menschen die sicher nicht mein Freund sein wollen, aber gerne etwas mit mir teilen ohne dafür jeden Satz von mir lesen zu müssen. google+ entwickelt sich neben Twitter so zu einem wichtigen Netzwerk für mich wenn es um Information geht. Dabei gibt es noch einen “sozialen” Wunsch an was auch immer es sein wird: Ich will aus diesem Single-Point-Of-Information heraus Inhalte teilen können und damit meine ich nicht einen Link in diese App/Website/etc sondern einen Verweis mit Kommentar zu originalen Inhalt!

Usability und Optik. Ich gebe es offen zu: Ich will eine schöne Lösung! Flipboard gefällt mir ganz gut. Am Tablet super zum Blättern, Lesen, Teilen, etc.. Aber leider keine Webapp und auch kein “show only unread items”. Das fehlt hier eben.

Die Eierlegende-Woll-Milch-Sau

Die hab ich noch nicht. Alles was ich jetzt habe ist eine Vorstellung, ein Ziel. Vielleicht wird es wirklich Feedly (wenn sich Google+ Circles und Communities und Twitter Listen integrieren lassen). Vielleicht, aber auch etwas ganz anderes.

Wie bereits gesagt, ich habe noch Zeit und die werde ich nutzen um das zu finden was heute meinen Bedarf an Information deckt.

Ja ich gestehe: Sehr reißerischer Titel damit ihr alle drauf klickt!

Aber Spaß bei Seite, eigentlich meine ich das schon so wie ich es schreibe, nur eben nicht so wie das Google meint wenn sie Videos mit dem Titel “How It Feels [through Glass]“ veröffentlichen.

Ich meine wie sich Google Glass für mich anfühlt, als jemand der es noch nie in echt gesehen hat, sondern es nur aus Videos, Beschreibungen, der Google+ Glass Page und Blogs kennt.

Glass im Wandel

Als ich zum ersten Mal von Google Glass hörte und einen der ersten Spots sah dachte ich eigentlich nur eins: Wozu?

Dann sah ich auf der Google IO diesen überaus gelungenen Skydive-PR-Stunt / Live-Demo und dachte nur so: Sehr coole Aktion! Grandios gemacht! – Anwendungsfall für Google Glass? Fehlanzeige, aber cool!

Immer wieder sagte ich: “Da muss wohl noch viel in die Usability inversitert werden bis DAS alltagstauglich wird!”

Nun verging etwas Zeit und ich las immer wieder über neue Entwicklungen, sah weitere Videos und langsam begann ein Gedanke in mir zu wachsen.

Es ist echt! Ich begann mir vorzustellen in wie vielen Lebenslagen es plötzlich für mich Sinn machen würde.

Wow, jetzt wäre Glass super!

Vor allem der “wish you could see that!”-Gedanke wurde immer stärker.

• Mit den Ski die Piste unter perfekt blauem Himmel runter -> Ok Glass, take a Video! -> Ok Glass, send Video to friends at work! (Mauhaha)
• Auf der GameCity in Wien -> Ok Glass, hang out with “the gamer friends” -> Wow, seht ihr das?!! Yeah!

Außerdem, aber das wundert jetzt vermutlich keinen von euch, bin ich ein Informations-Junky und dauernd verpeilt.

• Auf Urlaub in einer Fremden Stadt -> Ok Glass, where is my Hotel? (Google Now weiß natürlich schon wo mein Hotel ist) -> Route wird eingeblendet, beide Hände frei zum Kofferschleppen.

In der Arbeit Google ich viel. Man kann ja schlichtweg nicht alles wissen, aber man muss wissen wie man schnell findet was man sucht.

• Ok Glass, Objective-C Singleton Pattern -> Search Results, ohne in den Browser wechseln zu müssen. Zugegeben, das Grenzt fast schon an Faulheit, kann aber auch zum Erhalt der Konzentration beitragen.

Nun sind das noch nicht sehr viele Fälle die einen Kauf durch mich rechtfertigen würde und noch weniger Gründe warum soetwas am Massenmarkt Anklang finden sollte und damit kommen wir zum nächsten Punkt der gerade für so eine Plattform essentiell ist.

Apps

Gerade heute las ich, neben der für mich sehr wichtigen Information, dass Google Glass auch für Brillenträger funktionieren wird, dass Evernote und vermutlich auch andere bereits an Apps für Glass arbeiten. Damit sind die Möglichkeiten plötzlich unendlich und unvorstellbar.

Ab jetzt Antworte ich wenn mich jemand fragt was ich von Glass halte: Ich freue mich darauf!

Aber ich denke die Vorfreude wird nicht mehr lange halten, denn so schnell wie die Entwicklung voranschreitet, dass wenn ich in drei bis vier Jahren wieder diesen Artikel lese mir nur noch denke: Och alter Hut, ist eh nur noch alltäglich.

Vor Kurzem habe ich die pingeb.org Android Sticker Finde App für Android im Google Play Store veröffentlicht. Projekt Ingeborg ist offen und frei und so soll es auch die App sein.

Deshalb gibt es den SourceCode der App ab jetzt für jeden von euch verfügbar auf Github!

pingeb.org Finder Android auf Github

Die App befindet sich natürlich weiterhin in Entwicklung. Im  Moment baue ich an der Integration von Geofences und das ist noch lange nicht das Ende.

Wenn ihr also sehen wollt wie die App im Detail funktioniert oder etwas zu verbessern habt, tut euch keinen Zwang an und holt euch den SourceCode!

Endlich ist es soweit! Ich hatte endlich mal genug Wochenenden und Abende Zeit um die pingeb.org Android App vorzeigbar zu machen. Solltet ihr pingeb.org noch nicht kennen hier eine kleine Zusammenfassung zum Projekt:

Im Juli 2012 verwandelte sich Klagenfurt durch eine Idee von Georg Holzer (http://www.georgholzer.at/) und Bruno Hautzenberger (http://the-engine.at/) in eine virtuelle Bibliothek. 70 knallgelbe Sticker von Projekt Ingeborg mit NFC-Tags und QR-Codes wurden in und um Klagenfurt verteilt. Jeder davon enthielt ein E-Book vom Projekt Gutenberg, das zum jeweiligen Ort passte. Im August wuchs die Zahl der Sticker auf 120 an, das Projekt wandelte sich zur kostenlosen Entdeckungsplattform für Kunstschaffende aus Klagenfurt – von Musikern und Bands bis hin zu Autoren und Fotografen.
Mittlerweile gibt es auch schon Teams in Wien, Graz und Villach, welche das Projekt auch in ihren Städten umsetzen wollen.

Noch mehr Informationen zum Projekt findet ihr auf http://pingeb.org.

Die App dient zum leichteren Auffinden der Sticker in deiner Nähe.  Über eine Map kann weltweit nach pingeb.org Stickern gesucht werden und ein Augmented Reality Viewer (ein recht experimentelles Feature, basierend auf dem Metaio SDK) ermöglicht das Finden durch das Kamera-Livebild deines Geräts in einem Radius von 300 Metern.

Klickt man auf einen “Tag” auf der Karten- oder in der AR-Ansicht öffnet sich ein Detailfenster mit Infos zu diesem Sticker. Durch einen weiteren Klick auf dieses Fenster startet dann, um den Weg zu den Stickern noch einfacher zu machen, eine Routenberechnung und man kann sich sofort zum jeweiligen Sticker navigieren lassen.Weiters sind die jeweiligen Webseiten mit Infos zu aktuellen Inhalten und den lokalen Projektteams über die App aufrufbar. Dank der Google Map V2 Api gibt es obendrauf noch eine kippbare Map mit 3D Gebäuden, sofern es in der Gegend schon welche gibt.

Die App ist ab sofort und natürlich Gratis im Play Store verfügbar!

Der Vorteil daran für mobile Geräte zu entwickeln ist es, dass man eine Fülle an Sensoren nutzen kann und damit auf viele Umstände reagieren kann.
Bei einem meiner aktuellen Projekte muss ich darauf reagieren ob das Gerät flach oder aufrecht gehalten wird.

Konkret soll wenn das Gerät flach gehalten wird eine Map angezeigt werden, aber sobald es aufrecht gehalten wird ein AR Viewer.
Die Anforderung klang sehr einfach und ich war mir sicher mit etwas “Google Magic” ein einfaches Howto zu finden. Leider war dies nicht der Fall und ich landete da wo ich nicht landen wollte: Beim Auslesen und Analysieren von Sensorwerten vieler Sensoren.

Damit ihr das nicht auch machen müsst habe ich eine Klasse implementiert welche auf die Deviceposition reagiert und einen Listener der bei Lageänderung diese mitteilt.

Verwendung

In eurer Activity, welche auf Lageänderung reagieren soll erzeugt ihr ein Instanzmember der Klasse DeviceOrientation.
Dieses Objekt bekommt im Construtor einen OnOrientationListener, den aktuellen Context und die Activity.
Wie bei jedem Listener müsst ihr euch für Updates “registrieren” damit das Ding nicht ständig die Events auslöst. Vor allem wollen wir das nicht wenn die Activity garnicht angezeigt wird.
Hierzu callen wir in onResume der Activity “subscribe” und in onPause “unsubscribe” des DeviceOrientation-Objects.
Den Listener müsst ihr selbst implementieren (implements OnOrientationListener). Das ist ganz einfach, denn der Listener hat nur eine Methode “onOrientationChanged“. In dieser Methode reagiert ihr dann einfach auf die übergebene Lage.
Die sehr einfach gehaltenen Sourcen gibt es wie immer auf Github:
DeviceOrientation.java
OnOrientationListener.java

Wie man diese in einer Activity verwendet seht hier -> ViewerActivity.java

Ich hoffe das erspart euch einiges an Zeit und Frust.

Wie ihr ja vielleicht schon bemerkt habt baue ich seit einiger Zeit an einem offenen Media Service namens Snakeberry. Ziel dieses Projekts ist eine einfache Lösung um einen Raspberry Pi in einen über das Netzwerk  steuerbaren Audioplayer zu machen.

https://github.com/salendron/Snakeberry/wiki

Wer jetzt spontan an Sonos denkt liegt nicht ganz falsch, denn im Moment kann das System “nur” Radiostreams wiedergeben, aber wohin das gehen soll ist klar:

• Automatisches erkennen von Musik im Heimnetzwerk (DLNA)
• Abspielen von Medien am mobilen Gerät am Snakeberry (So wie zB. Airplay)
• Podcasts und und und…

Der Unterschied zu Sonos ist aber, dass dieses System pro Raum nur ca. 70€ kostet und das wird sogar noch weniger wenn ihr bereits bestehende Boxen in einem Raum habt. Ich zum Beispiel nutze im Schlafzimmer eine 2.1 Anlage und im Wohnzimmer die große 5.1 Anlage. Beide Systeme waren schon vorhanden und der Raspberry Pi musste nur noch angeschlossen werden.

Das System

Das System besteht aus einem Raspberry Pi – pro Raum – mit angeschlossenen Boxen. Auf jedem Raspberry läuft ein Snakeberry Service und dieser wiederum erlaubt es zu steuern was in diesem Raum gespielt wird.

Eine Android App, welche automatisch Snakeberries im Netz findet und ganz ohne Konfiguration auskommt, dient aktuell als “Fernbedienung”.

Update: Spotify

Ich bin zufällig über ein Python Library gestolpert, welches es scheinbar ermöglicht Spotify aus Python herraus zu verwenden und wenn das so stimmt wird die nächste Erweiterung wohl ein Spotify Player!
Gute Idee, oder?
Mehr Info -> https://github.com/mopidy/pyspotify

Die API

Die Android App ist aber nur ein Beispiel für eine Remote. Der Service ist so gestaltet, dass er von praktisch jeder Plattform aus angesteuert werden kann und somit steht einer iOS oder Windows Phone App nichts im Wege, sofern sich jemand findet der sie baut!

Bau es dir selbst!

Von der ersten Zeile Code an ist der Service dafür ausgelegt weitere Services zu integrieren und Apps dafür kann und soll auch jeder bauen der will.

Wenn ihr dies lest hoffe ich ihr gehört zu einer der nun folgenden Gruppen von Menschen (wenn nicht ist das auch nicht so schlimm).

Der Interessierte Nutzer

Ihr wollt so etwas selbst haben und traut euch zu einen Raspberry Pi nach Anleitung in Betrieb zu nehmen und anschließend mittels ein paar genau beschriebener Kommandos den Snakeberry Service zu installieren.

Dann macht das! Es geht wirklich ganz einfach, auch wenn minimale Linuxkenntnisse von Vorteil wären.

Der Entwickler

Ihr findet das System ist eine gute Idee und wollt eine App bauen oder den Service um Funktionalität erweitern. Dann geht auf GitHub holt euch den Source Code und legt los! Vergesst nur nicht mich über eure Entwicklungen zu informieren. Ich bin ja so neugierig!

Aber ganz egal zu welcher dieser beiden Gruppen ihr gehört, alle Informationen die ihr sucht gibt es im Wiki des Projekts und dort gibt es auch die Android App.

Keine Grenzen!

Das Projekt bietet natürlich noch einen Vorteil: Der Raspberry Pi ist klein und somit könnt ihr ihn fast überall in Betrieb nehmen. Wie das Aussehen kann seht ihr in folgendem Video. Dort seht ihr meine beiden Snakeberries: Einem in einem kleinen schwarzen Gehäuse und den anderen, etwas cooler, im alten Gameboy.