Memory Spiel in Java

Update:
Da im Projekt Namen erwähnt wurden, die nicht gewollt sind, habe ich das Projekt gelöscht. Ein neues Repository mit dem Source-Code werde ich nachreichen. Leider wird dann nur der neuste Source-Code (also mit Spielern und ohne Bugs) zur Verfügung stehen.
Update 2:
Neues Repository: BitBucket

Im Zuge einer Bewerbung hatte ich die Aufgabe ein Memory Spiel in beliebiger Programmiersprache zu erstellen. Dazu hatte ich 90 Minuten Zeit. Eine Regel war, dass es nur von einer Person gespielt werden soll. Ansonsten die normalen Memory Regeln. Wer diese nicht kennt: (PDF zum Downloaden).

Meine erste Version, die ich auch so abgegeben hatte, hatte leider noch ein paar Fehler. So wurden Karten nicht nur einmal als Paar aufs "Spielfeld" gelegt, sondern ggf. auch öfter. Die Karte "Katzen" konnte womöglich 3 oder mehrfach auf dem Spielfeld liegen.
Aber auch wenn bei einem Zug die zweite Karte aufgedeckt wurde, und im nächsten Zug die erste übereinstimmten, galt das als "richtiges gefundenes Paar". Was natürlich falsch ist.
Dies Version, mit den Fehlern, könnt ihr euch auf meinem BitBucket-Account anschauen.

Aus reiner Interesse habe ich mich heute morgen dann nochmal hingesetzt und die Fehler korrigiert. Außerdem habe ich noch Spieler hinzugefügt. Die fertige Version könnt ihr ebenfalls auf BitBucket anschauen.

Vielleicht kann ich mit dem veröffentlichen des Source-Codes den ein oder anderen Helfen, der in einer ähnlichen Situation ist. Oder der einfach ein bisschen Programmieren lernen will. Oder einfach zum Spielen, wenn ihr Compilieren könnt ;)

Android und Tizen... ähneln sich

Ich will nun wirklich nicht die ganze Leier mit Copycats, Patenten und Geschmacksmuster Verletzung aufrollen. Ich möchte nicht, und habe auch noch nie, Samsung als Kopierer hinstellen. Aber als ich mir die Tizen Dokumentation unter "UX Guide" durchgeschaut habe, ist mir fast die Kinnlade runtergefallen.

Gleich mal vorne weg. Die Quellen bzw. die Screenshots, die ich euch gleich zeige, könnt ihr alle im Developerbereich von Tizen bzw. Android anschauen. Ich habe mir nicht die einzelnen Hilfestellungen unter Tizen durchgelesen. Die von Android allerdings kenne ich. Aber ich denke Bilder sagen dabei mehr als Tausendworte.

Fangen wir an mit Androids ActionBar. Ist seit Ice Cream Sandwich ein fester Bestandteil von Android. Ziert jeweils den Kopfbereich in einer App. Enthalten können/müssen/sollten: Ein Icon, der AppName (oder ein Titel), "Action-Items" und ein Overflow-Menü. 

Kurzer Blick auf die Tizen-Fraktion. Jap, haben wir auch! Einzig und allein der Up-Button im Logo der App ist nicht vorhanden. Auch das Overflow-Menü ist nicht da, dies hat aber einen anderen Grund, den ich später nochmal aufgreifen will.

Kommen wir zum Dialog. Wie oft müssen wir unter Android etwas nochmal bestätigen? Das typische "Bild wirklich löschen?". Selbiges gibt es - natürlich - auch unter Tizen. Das dies auf beiden System bis auf das kleinste Detail Haargenau gleich aussieht, könnte natürlich Zufall sein. Wer sich aber die Doku zu Tizens-Dialogen und Androids-Dialogen anschaut weiß worauf ich hinaus möchte.

Die typische Kontakt-App. Wie sieht die aus? Richtig. Normalerweise wird eine einfache Liste angezeigt. Schönes Bildchen und ein Text. Womöglich der Name. Das so etwas "eigentlich" immer gleich aussieht ist auch klar. Aber... bitte! Selbst die 1 Pixel großen Linien mit Überschrift sind gleich wie unter Android.

Auch das Fast-Scrolling, dasselbe in grün. 

Aber der Hammer kommt jetzt: Tizen bringt auf ihren Geräten, normalerweise, 3 Buttons: Zurück, Home und Menü. Na, erkennt es jemand? Wie dem auch sei, die Navigation wird in beiden Dokumentationen beschrieben. Bei beiden...ich sag mal ähnlich. 

Hier liegt aber auch der Grund warum die ActionBar unter Tizen kein Overflow-Menü hat. Denn das Menü erscheint, wie noch unter Android 2.3 und kleiner, unten am Bildschirmrand. Ob das mal geändert wird?

Zugegeben. Es ist Schwer ein anderes Design bei gleicher Geräteklasse hinzukriegen. Auch Apples IOS und Microsofts WP sehen in etwas so aus. Ich will auch gar nicht sagen, dass Android nicht irgendwo abgeschaut hat. Aber ich finde das die Bilder doch tatsächlich genau gleich sein. Also nicht mal irgendwie ein anderer Ansatz. Sondern... gleich! 

Als Beispiel ein Bild von der WP-Design Dokumentation:

Es ist auch irgendwo nur eine Liste mit Fastscroll. Also dem Alphabet an der Seite. Allerdings wirkt es doch anders. Allein schon, weil kein Highlight Buchstabe groß aufleuchtet. Und auch weil der Header komplett anders aussirht und dementdprechend eine andere Wirkung hat.

Oder wie seht ihr das?
Bin ich da zu kritisch? 

Müssen moderne Handheld-Betriebssysteme so aussehen?

Chromecast - Es wird spannend!

Als das (der?) Chromecast am 24.7.13 vorgestellt wurde, konnte er noch nicht viel. Play Music, YouTube-Videos, Play Movies und auch Netflix (uninteressant für Deutschland) waren von Anfang an im Angebot. Mit einem Unschlagbaren Preis-/Leistungsverhältnis, schlugen dann trotz der vielen einschränken einige zu.

Auch ich war ein Interessierter des Sticks, um Anfangs gleich dafür zu entwickeln. Leider ist das, vor allem durch die Einschränkungen, nicht ganz einfach. Zumindest für mich :). Wie dem auch sei, nach dem ich mich als Entwickler "angemeldet" habe, erhielt ich dann eine Einladung zu einem Chromecast Hackathon am 7-8. Dezember. Leider kann ich aus dem heimischen Deutschland nicht so schnell in die USA reisen, um "mal eben" für den Cast zu entwickeln. Dennoch war mir klar, dass das Wochenende Auswirkungen auf die Zukunft des kleinen Sticks hat.
So wurden nämlich nur zwei Tage später, am 10. Dezember, 10 neue Apps vorgestellt. Doch damit soll es nicht bleiben. Denn einige G+-User konnten schon Anzeichen einer Integration von Google Drive feststellen. In Drive Präsentationen kann man also vielleicht in Zukunft diese einfach auf den TV-Mirrorn.

Auch Interessant ist die Tatsache, dass man im AOSP von Android 4.4.1 erste Hinweise des Screen-Recording in Android gefunden hat. So wurden schon die Display-Einstellungen unter Android etwas aufgebort und mit der Erweiterung "Bildschirmübertragung" ergänzt. Zwar ist dies erst mal für Mircast eingestellt, doch der extra Hacken im Overflow macht mich dann schon etwas skeptisch. Denn wenn es wirklich nur für Miracast dienst, warum dann noch extra Aktivieren? Wie dem auch sei, meine These wurde durch Koushik bestätigt. Er schreibt nämlich, dass Chromecast-Mirroring mit Android "bald" möglich ist.

Zum Schluss dann endlich weg von Gerüchten und hin zum offiziellen Teil. Denn heute Nacht hat Google seine Developer-Seite für den Stick erweitern und "Design Guidelines" hinzugefügt. Der Entwickler-Bereich ist zwar weiterhin unberührt und in Beta, aber ich denke das ist schon mal der Anfang für ein Release der SDK 1.0. Auch der Play Store kündigt an, dass man nun im Browser über Play Musik und Play Movie-Trailer direkt an den Chromecast schicken kann.

So langsam scheint der Stick fahrt aufzunehmen und in immer mehr Google-Diensten integriert zu werden. Die ersten Third-Party-Apps sind auch da und generell ist das System, so scheint es zumindest mir, ausgereift und bereit für die breite Masse. Ich denke es ist nur noch eine Frage der Zeit, bis die SDK veröffentlicht wird und neue Software von dritten den Markt fluten werden....

Quellen: Link, Link, Link, Link, Link

(Android) KitKat Gewinnspiel - Teil 2!?

Bei der Android KitKat Aktion, gab es insgesamt 1.000 neue Nexus 7 Tablets und 25.000 Mal 5,- € Gutscheine für den Play Store zu gewinnen. Doch leider ist diese beendet und kommt so schnell nicht wieder... oder doch?

Wenn man die Homepage von KitKat-Deutschland aufruft, erscheint trotz Ende der Aktion, ein Hinweis, dass man ein Tablet gewinnen kann. "Have a new Tablet", heißt es dort immer noch! Bei einem Klick darauf erfährt man zwar, dass die Aktion zu Ende ist, allerding nur "Pause" hat. Desweiteren wird Informiert, dass es ab Januar weitere Gewinne gibt.

Natürlich weiß ich nicht, ob es wieder mit Android zusammen hängt, allerdings habe ich mal ein bisschen im Source-Code der Seite gewühlt und entdeckt, dass die entsprechenden Seiten "nur" auskommentiert sind. Für Laien: Auskommentierter Code wird vom Programm einfach nicht beachtet. Er ist aber "noch da". Heißt also, wenn man die Zeichen "<!--" bzw. "-->" wieder entfernt, läuft alles wie vorher!
Ein weiteres Indiz dafür ist, dass man auf der damaligen Unterseite des Gewinnspiels lediglich eine "403" Fehlermeldung bekommt. Der 403-Fehlercode ist ähnlich wie das auskommentieren in Code, nur auf einem Webserver. Die Seite existiert noch. Der Webserver weiß auch was er aufzuliefern hat. Allerdings hat der aktueller User, in unserem Fall der Besucher der Webseite, keinen Zugriff!

Auch kann es sein, dass es einfach noch "zu viele" Android-KitKats im Umlauf oder in den Lagern sind. Diese müssen vielleicht noch an den Kunden kommen. Dafür wäre noch eine weitere Aktion Ideal. Alles ist schon vorbereitet. Lediglich neue "Gewinnercodes" müssten in der Datenbank ausgelost werden...

Also wer weiß, vielleicht haben diejenigen, die diesmal Pech hatten, nochmal im Januar die Chance auf ein Nexus 7. Vielleicht diesmal sogar in weiß? ;)

Für Webentickler: Nexus-, iPhone- und mehr Emulatoren für Webseiten

Kennt ihr das Problem, wenn man eine Webseite extra an Smartphones anpasst und trotzdem bei hundert Geräten anders aussieht? Man testet eben nur mal schnell mit seinem eigenem Mobilengerät ob die Seite "gut" aussieht und schwups, ist sie online. Was passiert aber, wenn es auf dem Nexus 10 super aussieht und auf dem iPhone 5S verdammt scheiße? Google bringt die Lösung: Emulatoren im Browser selbst.
Francois Beaufort zeigt in einem Google+ Post wie das ganze funktioniert. Ein passendes YouTube-Video schiebt er auch gleich mit.

Neben vordefinierten Geräten wie der Nexus-Reihe, kann man auch ganz gezielt andere User-Agenten oder Auflösungen eintragen. Benötigt wird nur ein aktueller Chrome-Browser (Chromium) und die Chrome DevTools.

Quelle: Link

Google App Engine - Account Login und Datenbank

In meinem letzten Beitrag habe ich angefangen mit der GAE. Wie versprochen möchte ich den Beitrag weiter führen. Heute geht es darum wie man Daten - in unserem Beispiel Username und "Notiz" - in einer NoSQL-Datenbank speichern kann. Außerdem möchte ich zeigen, wie man mit nur wenigen Codezeilen einen Login mit dem Google-Account realisiert.

Als erstes nehmen wir unseren Code und gucken wie wir eine Datenbank hinzufügen. Dazu müssen wir als erstes die "db" importieren. Das packet gibt es in google.appengine.ext. Weiter im Code brauchen wir eine neue Klasse, die von db.Model erbt. Die Objekte in der Datenbank können wir einfach realisieren.

user = db.StringProperty()

Erstellt ein Objekt mit dem Namen "user" vom Typ String. Weitere Datenbanktypen gibt es hier.

Im Code kann dann einfach ein Objekt "data" von der eben erstellten Klasse erben. Der Username und die Notiz erhalten einfach einen Wert wenn man ihnen einen zuweist. Mit put() übergeben wir das ganze in die Datenbank.

Das wars dann eigentlich auch schon fürs speichern. Das sind die Grundlagen, der Rest ist Spielerei :)

Wir möchten natürlich variable Daten speichern. Hierfür erstellen wir eine einfache HTML-Form. Die Daten, die via POST oder GET übergeben werden, die kann man sich einfach mit

self.request.get('name')

holen. In unserem Code können wir dann dem note-DB-Objekt dem Wert von der textarea geben.

Der Login über Google mit dem G-Account erfolgt ebenfalls in ein paar simplen Schritten.
Importiert wird hierbei "users" von "google.appengine.api". Den Usernamen, der ohne Login "None" ist, bekommt man mit

users.get_current_user()

Zu der Login-Page kommen wir in dem wir eine Weiterleitung zu

users.create_login_url()

aufrufen. Der Paramenter ist dabei die Weiterleitung von der Login-Page. In unserem Fall möchten wir wieder zurück. Deshalb wird unsere "URL" übergeben.

Das war dann auch das ganze Hexenwerk. Die Datenbank ist ein einfaches Model, welche Objekte mit verschiedenen Typen erstellen kann. Das automatische Login-System von Google funktioniert ebenfalls in wenigen Schritten.

Google App Engine - Schnell HTML-Webseiten erstellen

In dem Beitrag möchte ich euch Googles App Engine näher bringen. Was das überhaupt ist? Ein Service wo man Webanwendungen auf Googles Servern und Infrastruktur ausführen kann. Das ganze nennt sich auch PaaS. Wer genaueres darüber wissen möchte, kann sich hier einlesen.
Heute möchte ich erstmal anfangen, wie man ganz einfach HTML-Webseiten darauf ausführen kann. In einem weiteren Artikel binden wir dann noch eine Datenbank, zum Speichern von Notizen, ein und das einloggen mit eurem Google-Account.

Als erstes müssen wir uns eine Application erstellen. Dazu gehen wir auf https://appengine.google.com/ und klicken auf Create Application.

Auf der folgenden Seite müssen wir dem Kind ein Namen und ein "Thema" geben. In unserem Beispiel ist der Name "simpleenginetest" und das Thema "Just Testing".

Der nächste Schritt ist nun, dass wir uns die SDK runterladen. Man kann mit GAE in Python, Java, Go und neuerdings auch in PHP entwickeln. In diesem Beispiel programmieren wir in Pyhton. Deswegen müssen wir uns auch die entsprechende SDK hier runterladen.
Unter Linux reicht ein einfaches entpacken nach dem Download der Datei. Es erstellt sich ein Ordner "google_appengine", welches alles nötige an Board hat. Ob eine Installation unter Windows oder Mac OS X nötig ist weiß ich nicht. Jedenfalls benötigen wir für weitere Schritte die "appcfg.py".

Nachdem wir also den entpackten Ordner vor uns haben, erstellen wir einen neuen Ordner "simpletest". Dort müssen wir nun zwei Datein erstellen. Die "app.yaml" - quasi das Steuerungsskript der Engine - und ein "helloworld.py". Zweiteres wird die eigentliche Webseite.

In der app.yaml benötigen wir mindestens die oben angegeben Informationen, damit sie auf der GAE ordnungsgemäß läuft. Unter application müssen wir den Namen der Application angeben, die wir in unserem ersten Schritt angelegt haben. Unter handlers, was eine wichtige Rolle spielt, hier aber noch nicht drauf eingegangen wird, muss ein Name stehen, der für die entsprechende URL aufgerufen wird. In dem Beispiel zeigen "alle" URLs auf helloworld.application.

In dem helloworld.py-Skript müssen wir erstmal den Namen, wo von ich eben gesprochen habe, deklarieren. Wir haben gesagt helloworld.application. Also muss unser Skript helloworld heißen. Den zweiteren Teil, kann man nennen wie man will. Allerdings muss dieser wieder vorkommen und ein Objekt von webapp2 werden.

Haben wir die Datein erstellt, können wir diese nun ganz einfach mit der SDK uploaden. Dazu rufen wir das script auf und hängen "upload simpletest" [zweiteres ist der Ornder-Name] hinten dran.

Nach einer abfrage nach E-Mail und Passwort, ist das ganze auch schon online und kann mit beliebigem Browser angeschaut werden.

Android Design UI - endlich einheitlich!

Das ist wirklich überraschend, selbst für mich. Die Jungs von Pocket (Read it Later) haben eine sehr interessante Entdeckung gemacht. Diesmal geht es nicht direkt um die App, sondern eher um das von Android in 4.0 eingeführte Holo Design. Eingeführt wurde, dass das Icon in der ActionBar auch als "up" Button fungieren kann.

Für viele immer wieder ein heftiges Streitthema. Denn es nimmt - mehr oder weniger - die Arbeit des "Zurück"-Buttons in der NavigationsBar ab.
Zurück zum "experiement":
Vor einigen Monaten wurde die Pocket App um diesen Up-Button erweitert. Vorher war, dort wo nun der Up-Button sitzt, ein "hacken", der den Artikel als gelesen markiert hat. Außerdem führte dieser zurück zur "Main"-Liste. Genau dieser hacken hat viele User verwirrt. Denn laut Pocket, wurde dort instinktiv drauf geklickt, auch wenn man den Artikel nicht als gelesen markieren wollte. Die User dachten einfach, oder erwarteten(!), dass dort der zurück Button sitzt. Sie hatten also gehoft, dass man damit zurück zu seiner Liste kommt und der Artikel sich immer noch in dieser befindet. Dies war natürlich nicht der Fall. Denn wenn man einen Artikel als gelesen markiert - also auf den hacken klickt - wird dieser automatisch ins Archive geschoben.

Nachdem man die UI an die vorgaben von Android angepasst hatte, also die Elemente in der ActionBar nach rechts verschob und den Up-Button nach links, hat man bei sage und schreibe 23% der User erreicht, weiterhin Pocket zu nutzen. Die User waren also nicht mehr so "frustriert", so schreibt es der Dienst, und wollten weiterhin mit der App arbeiten.

In dem Artikel schreiben sie auch, dass es Android geschafft hat, ein einheitlichen Design für alle
Apps geschaffen zu haben. Nicht wie vor 4.0, wo jede App sein eigenes individuelles hatte.
Dennoch schreiben sie auch, dass man die Design Richtlinien nicht als Gesetzt sehen soll. Jeder Programmierer oder Designer dürfte auch individuelle und innovative Ideen in seine App bringen. Aber man soll das "Richtlinien" immer im Auge behalten und für keine Verwirrung sorgen, an den stellen, wo der Anwender normalerweise was anderes erwartet.

Quelle: Link

GCM zu Mehrdevice

Google stellt auf der I/O ein Feature für Android vor, welches viele User mit mehr als einem Gerät wirklich erfreut hat. Sie haben es so vorgestellt, dass ein User - auf mehreren Geräten - eine Benachrichtigung bekommt. Als er dann auf seinem Nexus 10 diese weg gewischt hat, verschwand sie wie von Zauberhand auch auf dem anderen Gerät. Wie ist es bisher? Man bekommt eine Notification. Alle Geräte bekommen es und man muss sie überall "bestätigen", dass sie gelesen wurde. Außer bei G+ und Gmail. Dort ist dieses Feature nämlich schon eingebaut.

Doch warum besitzen die anderen Apps nicht auch diese Funktion? Dazu schauen wir uns erst mal den technischen Hintergrund an:
Push-Benachrichtigungen kommen, wenn man es "Google-Like" implementiert, über Google Cloud Messaging (GCM). Das Verfahren ist relativ einfach erklärt. Aus Entwickler-Sicht braucht man nur einen "kleinen" Server oder Datenbank, der eine eindeutige ID des Benutzers speichert. Dieser Server muss, wenn er nun etwas an das Gerät senden will, via HTTP-Post oder als JSON-String an den GCM-Server von Google senden. Dank der großen Verzahnung von Google und Android kann der Server relativ Ressourcen schonend eine Nachricht ans Handy schicken und die - wenn erwünscht - Benachrichtigung anzeigen.

Das Problem an der ganzen ist, dass das Handy nicht antworten kann. Wenn der GCM-Server einen Fehler erkennt, dann ist es kein Problem "unserem Server" zu sagen, dass etwas schief gelaufen ist. Wenn der Server aber alles korrekt abschickt und das Device, aus welchen Gründen auch immer, nicht mehr anwesend ist oder einfach ein "ok, habe empfangen" senden will, hat es Pech.

Genau hier setzte Google an und stellt das Protokoll auf XMPP um. Dieses Protokoll sagt vielleicht einigen was. "Erfunden" wurde es ursprünglich um Chat-Nachrichten auszutauschen. Nach dem Senden wird also, in unserem Fall, die Verbindung aufrecht erhalten und das Handy kann noch antworten. Ob ein Simples "Ja, Nachricht empfangen" oder vielleicht einfach dem GCM-Server zu sagen "Nachricht von xxx@gmail.com gelesen. Auf allen anderen Geräten diese Benachrichtigung löschen".

So kommen wir nun wieder auf den Ursprung. Mit zweiterem Verfahren kann man das ganze nämlich ziemlich einfach implemtieren. Aber, und es gibt immer ein großes aber, diese Methode ist schlicht weg nicht verfügbar! Google hat das ganze zwar veröffentlicht und vielen eine Freude gemacht, doch wer es nutzten möchte, der darf sich erst mal bei Google Anmelden. Das da 0-8-15 Developer nicht durch kommen, dürfte klar sein.

Schade, aber typisch Google. Etwas vorstellen und dann nicht veröffentlich. Klar, wenn etwas noch nicht ausgereift oder verbuggt ist, dann bloß nicht für die breite Masse zur Verfügung stellen. Aber wieso dann die große Ankündigung? Groß locken und nichts dahinter. Schade Google. Wieder mal ein Schuss ins eigene Knie...

Die Sache mit dem Stages Rollout

Wie vielleicht der ein oder andere schon erfahren hat, gibt es seit der I/O 2013 im Play Store das sogenannte "Staged Rollout". Das ganze bedetet, einfach gesagt, dass erst ein "paar" User das Update einer App bekommen, bevor der "Rest der Welt" damit beliefert wird. Der Sinn dahinter ist einfach. Wenn mal bei einem Update etwas Schief läuft, dann ist "nur" ein "kleiner" Teil der App-User betroffen. Als Entwickler hat man dann noch die Möglichkeit das Ganze zu Stoppen und erstmal zu fixen.

Doch wie läuft das eigentlich genau ab? Wer bestimmt wer ein Update bekommt? Den wirklichen Mechanismus dahinter kennt wohl nur Google. Aber einen kleinen Einblick kann ich euch dennoch geben.

Aus der Hilfe-Seite von Google wird man nicht wirklich schlauer. Eine bessere Übersicht bekommt man dann schon, wenn man selbst mal Developer spielt und folgendes Bild vorgesetzt bekommt.

Was sehen wir also? Wir können auswählen, ob wir das Update erst mal für 5, 10, 20 oder 50 Prozent der User verteilen möchten. 100 gibt es auch. Aber das hat dann weniger was mit Stufenweise zu tun.
Jedenfalls müssen wir uns hier erst mal festlegen. Wenn das gemacht wurde, wir sagen mal 5 %, dann bekommen wirklich nur 5 % der User das Update. Mehr nicht. Danach ist Schluss! Der nächste Schritt wäre auch nicht die Erhöhung auf 10 %. Denn nur 100 Prozent würde die alte Konfiguration ersetzten.

Selbstverständlich ist es jedem Entwickler selbst überlassen, ob er dieses Verfahren anwenden möchte oder nicht. Google macht es mit seinen Apps jedenfalls grundsätzlich so. Wie lange sie dabei warten um auf 100 Prozent zu schalten und wie viele User sie erstmalig Freischalten ist allerdings weiterhin Unklar.

Für mich persönlich ist dieses Feature nicht zu gebrauchen. Meine Apps sind nicht nur relativ klein sondern auch "User-arm". Daher schenke ich as Entwickler diesem Feature keine Beachtung. Aber bei größeren Apps, wo auch gegebenfalls wichtige Daten verloren gehen können, ist es eine wirklich gute Sache. Obwohl es uns User manchmal zur Weißglut bringt.

Google Patent - Muster zum starten von Apps

Eben erst habe ich über meine Wünsche von der nächsten Android Version gesprochen, folgt schon der nächste Streich. Vorneweg: Wann das wirklich kommen sollte, bin ich begeistert! Ich selbst nutze nämlich ausschließlich das "Muster" um meine Android-Devices zu schützen. Aber kommen wir zu den eigentlichen News.

Das Patent zeigt ein ein Nexus One, welches 2010 auf den Markt kam. Zu sehen ist, dass man mit verschiedenen Mustern verschiedene Anwendungen starten kann. So kann man zum Beispiel zum entsperren ein virtuelles "i" Zeichnen und zum Starten einer bestimmten App ein "L". Das Gerät bzw. Android soll dann erkennen um welches Muster es sich handelt und entsprechend reagieren.

Simple, einfach, geile Idee. Mehr kann ich dazu nicht sagen. Ich bin jetzt schon am überlegen, ob ich den Lockscreen, sollte er Open-Source sein, Forken soll und um die oben genannten Funktionen einzubauen. Denn das Patent bzw. viel mehr die Idee dahinter gefällt mir richtig gut.

Quelle: Link, Link

Outing: Merkel Browser ist keine Malware!

Wie einige vielleicht mitbekommen haben, erfuhr mein eigens programmierter Neuland Browser einiges an Interesse. Nach dem ich ihn in einer Community teilte wurde er auch unabhängig von einem Blog resümiert. Zwar wurde der Browser, der natürlich mehr aus Spaß entstanden ist, nur 6 mal runtergeladen (inklusive zwei mal von mir selbst :)), dennoch sprechen die Kommentar und Bewertungen für sich.

Schade dagegen finde ich, das selbsternannte Profis die App sofort durchleuchtet haben.  So ist die App bzw. der Link dorthin bei Google+ zwar unter "angesagten" Beiträgen gelandet, dennoch sofort als "Malware" abgestempelt.

So schreibt der Urheber schon "[..]wer mit welcher Absicht dahinter steckt. Ich würde sie nicht installieren". Ein anderer schreibt in den Kommentaren "Malware" und bekommt +5. Wirklich schade, dass das Thema Virus unter Android schon so verbreitet ist.

Nichtsdestotrotz möchte ich hiermit ausdrücklich hinweisen, dass diese App allein aus Spaß programmiert wurde. Sie ist weder schädlich noch gefährlich. Ich habe sie einfach erstellt, da das Thema "Neuland" zur Zeit in aller Munde ist und auch entsprechend kritisiert wird. 

Der Code beträgt gerade mal 122 Zeilen und ist wirklich nichts spektakuläres. Also beruhigt euch... ihr Profis!