andforge.net

The android Blog! News, Tutorials and Reports!

Die Live Wallpaper Flut und der Market-Suchalgorithmus

Posted by Mohammed El Batya August - 16 - 2010 - Monday 2 COMMENTS

Wie ihr vielleicht mitgekommen habt, habe ich immer mal wieder eines meiner Live Wallpaper hier im Blog angepriesen. Mittlerweile habe ich 10 davon im Android Market und durfte die ein oder andere Erfahrung machen.

Leider wurde der Market in den letzten Monaten stark mit Live Wallpapern überschwemmt. Sucht man heute im Market nach eben diesen erhält man bereits mehr als 1.000 Suchergebnisse. Besonders unangenehm ist der Sortieralgorithmus, welcher von Google eingesetzt wird. Dieser wirkt recht ‘dumm’ bzw. ist sehr berechenbar. Zum Beispiel werden die ersten Plätze im Suchergebnis von Wallpapern weniger Anbieter dominiert, welche ihre Werke einfach nur ‘Live Wallpaper’ nennen oder eine Mutationen davon wie ‘LiVe WaLlPaPeR’ verwenden. Die Anzahl der Downloads und die Bewertung scheint hierbei nur eine kleine Rolle zu spielen.

Das führt dazu, dass die Benutzer sich extrem schwer tun geeignete Wallpaper zu finden. Auf Grund der langjährigen Google Gehirnwäsche sind sind sie gewohnt, dass die ersten Ergebnisse gut sind und der Rest zu vernachlässigen ist. Das ist bei der Android Market Suchmaschine jedoch ganz und gar nicht der Fall. Für mich als Entwickler ist das besonders ärgerlich, da Google mehr als genug Informationen (Downloadzahlen, Bewertungen, Kommentare, Anzahl der aktiven Installationen, Update-Rate usw.) besitzt um einen sehr guten Suchalgorithmus zu realisieren. Besonders von dem größten Suchmaschienen-Anbieter der Welt hätte ich da mehr erwartet.

Dies ist natürlich auch für alle anderen Apps im Market der Fall und beschränkt sich nicht nur auf Wallpaper. Jedoch eignen sich die Live Wallpaper, als relativ homogene Masse von gleichartigen Apps, besonders gut um die Funktionsweise und Macken des Suchalgorithmus aufzudecken. Momentan ist derjenige oben, wer mit dem Namen seiner App am exaktesten den Suchbegriff trifft. Wenn das so weiter geht wird es bald parallel zur klassichen SEO eine Art von App Market Optimization (AMO) geben …. wahrscheinlich gibt es so etwas sogar schon.

Aus Frust und um zu sehen ob ich damit meine Download-Zahlen über einen parallelen Kanal pushen kann habe ich DroidArts eingerichtet. Ich glaube, dass immer mehr Benutzer anfangen werden im Internet statt direkt im Android Market nach Apps zu suchen, da die Google-Suche einfach besser funktioniert und auf mehr Inhalte (z.B. Testberichte und Videos) zurückgreifen kann. Viele vermuten, dass sich sogar spezialisierte App Markets für verschiedene Nischen etablieren werden … es bleibt abzuwarten wie sich das ganze entwickeln wird, so bleiben kann es aber nicht.

Über den (Miss)Erfolg meines Versuchs mit DroidArts werde ich vermutlich in ein bis zwei Monaten berichten.

Neue App: AL Voice Recorder & AL Voice Recorder Ad Free

Posted by Johannes Borchardt July - 14 - 2010 - Wednesday 3 COMMENTS

Seit einer Woche ist meine neue App, der AL Voice Recorder im Android Market verfügbar.

Die App ist mit dem Anliegen gestartet, ein möglichst einfacher Voice Recorder zu sein der das, was er tun soll so gut wie möglich macht. Zunächst ist die App darum mit zwei Funktionen gesetartet: Tonaufnahme und Tonwiedergabe.

Links sieht man wie das Ganze optisch aussieht: Namen für die Datei eingeben, auf   den großen Button mit dem Kreis drücken und los geht’s.

Die AL Voice Recorder Aufnahme-Activity

Die AL Voice Recorder Aufnahme-Activity

Die Datei wird dann standardmäßig auf der SD-Karte in dem Ordner ‘AL Voice Recorder’ abgelegt. Da ich nicht nur diesen, sondern alle Ordner des jeweiligen Android Handys auf Audiodateien durchsuchbar machen wollte, haben ich auch noch einen Dateibrowser entwickelt (s. Bild unten). Der Browser startet automatisch im Ordner ‘AL Voice Recorder’, es kann aber auch jede andere Directory angesteuert werden.

Die Browser-Activity des AL Voice Recorders

Die Browser-Activity des AL Voice Recorders

Über das Menü gerät man von dort aus, wie man auf dem Bild schon sehen kann, zu dem Fenster in dem neue Tonaufnahmen gemacht werden können.

Ständige Weiterentwicklung, Feedback erwünscht

Der AL Voice Recorder ist minimalistisch gestartet und wird kontinuierlich weiter entwickelt. Jeder Nutzer oder Interessent ist dazu aufgerufen, jederzeit Feedback abzugeben und neue Funktionen vorzuschlagen. Einige User haben das bereits getan und einige dieser Vorschläge wurden bereits umgesetzt.

Daher hier eine Übersichtsliste, welche Features bereits auf Euren Wunsch hin umgesetzt wurden und welche noch umgesetzt werden sollen (auf englisch):

Done:

  • Delete auidiodata by longpress
  • Send audiodata by longpress
  • Rename audiodata by longpress
  • Orientation change
  • Auto-generate record names for faster recording
  • Diverse bug fixes
  • Ad Free Version

Todo:

task, (difficulty),[comment]

  • Implement widget (easy)
  • Implement preferences with
    • Skin Settings
    • Show-date-in-fileexplorer settings

Sollten Ihr irgendwelche Ideen oder Verbesserungswünsche haben, hinterlasst mir einfach eine Nachricht in den Kommentaren :-)

Edit: Werbefreie Version jetzt verfügbar!

Teleporter Prototyp auf der DroidCon 2010

Posted by Mohammed El Batya May - 28 - 2010 - Friday 3 COMMENTS

Froyo für das Nexus One ist hier

Posted by Lukas.Jarosch May - 25 - 2010 - Tuesday 1 COMMENT

Endlich ist es da! Android 2.2!

Wie in der Google I/O Keynote sind alle Features vorhanden und laufen wie angekündigt.

Hier http://forum.xda-developers.com/showthread.php?t=686627 könnt ihr sogar schon eine Root-Version runterladen (wie immer ohne Gewähr)

Erster Eindruck: solide

  • Der Homescreen hat jetzt ein kleines Dock mit Telefon und Browser Shortcut bekommen.
  • Das Gerät lässt sich jetzt in beiden Richtungen im Landscape Modus benutzen, sprich nur noch kopfüber Portrait gibts nicht.
  • Der AppMarket hat jetzt ein Widget bekommen.
  • Wunderschön und einfach ist auch das erstellen eines Accesspoints.
  • Was ein bißchen entäucht ist das kopieren von Apps auf die SD Karte. Zwar ist dieses Feature enthalten, jedoch muss jeder Entwickler explizit angeben das er das erlaubt was wiederum heißt das er erst auf die API 2.2 wechseln muss ….. und das haben bis jetzt die wenigsten gemacht.

Fazit: Stark positiv und ein Update zu Froyo ist auf jeden Fall zu empfehlen!

Postet eure Erfahrungen in den Comments!

Magic Tree – Live Wallpaper

Posted by Mohammed El Batya May - 22 - 2010 - Saturday ADD COMMENTS
Just announcing our new Live Wallpaper called “Magic Tree Live Wallpaper” for Android 2.1!

Live Wallpaper Tutorial für Android 2.1

Posted by Mohammed El Batya January - 26 - 2010 - Tuesday 6 COMMENTS

Wie viele von euch sicherlich bereits mitbekommen haben hat Google vor ein paar Wochen das Nexus One veröffentlicht und damit auch die neue Android-Version 2.1. Eines der tollen neuen Features nennt sich “Live Wallpaper” (auch manchmal “Living Wallpaper” genannt). Das sind coole dynamische Desktop-Hintergründe, welche schicke Animationen darstellen. Oft reagieren diese auch auf Benutzerinteraktionen.

Ich möchte mit diesem Artikel einen grundlegenden Überblick über die Programmierung eines solchen Live Wallpapers vermitteln.
Dieser Artikel enthält keinen voll funktionstüchtigen Code, da bereits ein gutes Beispiel im SDK 2.1 (namens “Cube”) mitgeliefert wird.

Vom Prinzip her ist so ein Live Wallpaper ( ab jetzt LWP abgekürzt ) das selbe wie eine normale Activity, welche auf einem 2D Surface einfache Dinge wie Kreise und und Linien zeichnet. Es ist vergleichbar mit der Programmierung eines kleinen 2D Spiels.

Voraussetzungen für dieses Tutorial:

  • Du hast schon mal eine normale Activity programmiert.
  • Du hast das SDK 2.1 installiert.

0. Grundlagen

Ein LWP besteht im Grunde aus 5 Teilen:

  1. einem WallpaperService
  2. einer “Engine”, welche sich um das Zeichnen kümmert
  3. einer “Einstellungen”-Activity zur Anpassung des Wallpapers durch den User (z.B. Farben)
  4. einer XML-Datei um zu konfigurieren wie das LWP aufgelistet wird (z.B. Icon)
  5. das übliche Android-Manifest

1. Der WallpaperService

Zunächst benötigst du eine Klasse, welche von “WallpaperService” erbt. In dieser Klasse musst du nur die Methode “onCreateEngine()” überschreiben und deine eigene Engine zurückgeben.

public class AndforgeWallpaper extends WallpaperService {
	@Override
	public Engine onCreateEngine() {
		return new AndforgeLWPEngine();
	}
}

2. Die Engine

Die Engine übernimmt das eigentliche Zeichnen und muss innerhalb deines WallpapersServices definiert werden. Also definieren wir als nächstes eine innere Klasse, welche von WallpaperService.Engine erbt.

public class AndforgeWallpaper extends WallpaperService {
	@Override
	public Engine onCreateEngine() {
		return new AndforgeLWPEngine();
	}

	 class AndforgeLWPEngine extends Engine{
		// TODO: ausprogrammieren
 	}
}

Die Engine besitzt einen SurfaceHolder, welcher wiederum ein Canvas besitzt. Auf diesem Canvas kann man letztendlich seine Animationen zeichnen. Mit der Methode getSurfaceHolder() bekommt man in der Engine das Surface. Wendet man auf das Surface die Methode lockCanvas() an bekommt man das Canvas zum zeichnen.

Achtung: Es ist wichtig das Canvas über die Methode lockCanvas() zu erhalten, da es sonst zu seltsamen Fehlern kommen kann. Dies hat unter anderem damit zu tun, dass “DoubleBuffering” eingesetzt wird.

DoubleBuffering?
Kurz gesagt: Es werden zwei Bilder generiert, eines auf dem gerade gezeichnet wird und eines, welches auf dem Bildschirm zu sehen ist. Diese Bilder werden nach jedem Zeichenvorgang ausgetauscht, was bedeutet, dass man immer eine “alte” Version des Bildes zum Zeichnen bekommt. Ruft man nun lockCanvas() auf bekommt man das Canvas, welches gerade nicht angezeigt wird um darauf zu zeichnen. Ist man fertig mit dem Zeichnen kann man mit unlockCanvasAndPost(canvas) das Canvas wieder freigeben und ein Austauschen des angezeigten Canvas mit dem frisch bemalten Canvas anstoßen.

Das Zeichnen sieht dann ungefähr so aus:


Canvas canvas = getSurfaceHolder().lockCanvas();

//TODO: auf dem canvas zeichnen

getSurfaceHolder().unlockCanvasAndPost(canvas);

Wo stecken wir nur unseren Code zum Zeichnen hin? Theoretisch kann man jetzt eine beliebige Methode der Engine überschreiben und dort etwas zeichnen (was nicht immer sinnvoll ist ^^). Es ist wichtig zu verstehen, dass die Engine einen Lifecycle (Lebenszyklus) durchlebt. Das bedeutet, dass es z.B. Momente gibt in denen es gar keinen SufaceHolder gibt ( also der SurfaceHolder null ist). Hier sind die Methoden onSurfaceDestroyed(), onSurfaceCreated(), onSurfaceChanged(), onDestroy(), onCreate(), usw. entsprechend zu beachten.

Aber wo kommt jetzt endlich der Code zum Zeichnen hin?

Eine mögliche (aber nicht besonders sinnvolle) Stelle wäre die onSurfaceCreated() Methode:

@Override
		public void onSurfaceCreated(SurfaceHolder arg0) {

			Canvas canvas = getSurfaceHolder().lockCanvas();

			// Zeichne einen Kreis
			canvas.drawCircle(200, 200, 10, color);

			getSurfaceHolder().unlockCanvasAndPost(canvas);
		}

Dies hat zur Folge, dass ein Kreis gezeichnet wird sobald der SurfaceHolder erzeugt wird, also einmal und dann nie wieder.

Was wir aber für bewegte Animationen benötigen ist eine Möglichkeit das Zeichnen regelmäßig anzustoßen. Das Cube Beispiel aus dem SDK verwendet hierfür eine recht elegante Lösung unter Verwendung eines Handlers, welcher sich selbst immer wieder auf die “Queue” schmeißt. Ich möchte hier nicht weiter auf die Implementierung der Engine eingehen und auf das Cube Beispiel verweisen, da dies sonst den Rahmen des Artikels sprengen würde. Ich bin mir aber sicher, dass man mit dem hier gelernten Wissen das Cube Beispiel relativ gut verstehen kann. (Falls jemand Interesse an einem ausführlicheren Artikel zur Implementierung eines Wallpapers hat, kann er/sie gerne einen Kommentar hinterlassen.)

3. Die “Einstellungen”-Activity

Dies ist eine ganz normale Activity, welche dem Nutzer ermöglichen soll das Wallpaper zu personalisieren. Vorstellbar wären z.B. Farbe, Geschwindigkeit und diverse Effekte des Wallpapers. Hierfür sollte man wie im Cube Beispiel auf SharedPreferences zurückgreifen um die Einstellungen auch beim Zeichnen mitzubekommen. Zusammengefasst: Diese SettingsActivity lässt den Nutzer die SharedPreferences editieren, welche wiederum in der Engine beim Zeichnen berücksichtigt werden.

Hier sollte man beachten, dass diese Activity normalerweise nicht im AppMenü von Android auftauchen soll. Daher sollte man das Manifest (siehe Punkt 5) entsprechend anpassen. Diese App wird gestartet wenn der Nutzer in der LWP-Liste neben dem LWP auf Einstellungen klickt.

4. LWP lwp_config.xml

Diese XML Datei dient dazu, zu konfigurieren wie das LWP im LWP-Menü aufgelistet wird. Sie muss sich im Verzeichnis res/xml befinden, wenn dieses Verzeichnis nicht existiert muss man eins erstellen. Eine typische Konfiguration würde folgende Werte enthalten:

  • android:thumbnail = mini Vorschaubild in der LWP-Liste
  • android:description = kurze Beschreibung für die LWP-Liste
  • android:settingsactivity = Packagepfad zu der Settings-Activity


5. Das Manifest

Im Folgenden wird der WallpaperService und die SettingsActivity eingerichtet.
Man beachte, dass kein Menüeintrag erstellt wird.



	

		
			
				
			
			
		

		
		

	
	


Ich hoffe ich konnte einen Überblick und ein Grundverständnis über die Erstellung eines Android Live Wallpapers bieten. Ich habe bewusst ein paar Details vorenthalten und versucht mich auf das Wesentliche zu konzentrieren. Bei offenen Fragen einfach einen Kommentar hinterlassen.

3D Hologramm Effekt auf Android Geräten

Posted by Mohammed El Batya January - 2 - 2010 - Saturday 1 COMMENT

Folgendes Video von TATMobile zeigt sehr schön, wie ein User-Interface der Zukunft mit 3D Hologramm Effekt aussehen könnte und am Ende dieses Artikels gibt es noch eine weitere sehr schöne Demo.

[ad#google_article_mo]

Der Trick hierbei ist, dass das Bild  auf den momentanen Blickwinkel des Benutzers angepasst wird.  Das im Video gezeigte User-Interface ist leider nicht echt und soll nur zeigen wie so etwas theoretisch aussehen könnte.

Das Prinzip ist jedoch seit langem bekannt und wurde bereits durch folgendes Video sehr berühmt. Es zeigt eine beeindruckende Umsetzung dieser optischen Täuschung für die Nintendo Spielekonsole Wii.

3D Hologramm Effekt für Android

Theoretisch ist es technisch möglich solch einen Effekt auch für Android Geräte zu entwickeln. Ich habe mir daher ein paar Gedanken gemacht und möchte nun beschreiben wie man das ganze auf einem Android Gerät realisieren könnte. Für diesen Effekt ist es essentiell, dass die Positionen von Betrachter und Gerät relativ zueinander ermittelt werden können. Daher habe ich die verschiendenen Bewegungsmöglichkeiten im Raum  in die folgende Fälle unterteilt und sie isoliert betrachtet.

1. Handy kann nur kippen

Zunächst möchte ich davon ausgehen, dass sich der Kopf des Benutzers und das Android Gerät fest im Raum befinden. Sie können sich in keinerlei Richtung Bewegen. Das Gerät kann aber in alle möglichen Richtungen gekippt werden.

Möchte man nun unter diesen Umständen einen 3D Effekt erzeugen, muss man nur die Lage des Gerätes anhand der Beschleunigungssensoren (welche momentan so gut wie alle Android Geräte besitzen) ermitteln. Mit den Daten kann man dann das Bild auf dem Gerät so anpassen, dass man einen wunderbaren Effekt erzielt. Wenn man sich hierbei ein Auge zuhält wirkt der Effekt noch besser, da dann jegliches Gefühl für “Tiefenwahrnehmung” verschwindet .

2. Handy kann sich nur Horizontal/Vertikal bewegen

Jetzt kommt der etwas kompliziertere Fall drann. Ich möchte jetzt annehmen, dass sich das Gerät auf einer Art Schiene im Raum nach oben, unten, links und rechts bewegen kann. Es kann sich jedoch in keine Richtung drehen/kippen. Bei diesen Bewegungsabläufen helfen uns die Beschleunigungssensoren leider nicht mehr weiter, da wir die Position des Gerätes relativ zur Position der betrachtenden Augen benötigen. Dies könnte man mit einer Front-Kamera, wie es heutzutage viele Video-Telefonie-Taugliche Geräte haben realisieren. Die Kamera müsste dann anhand eines Augen-Erkennungs-Algorithmusses die Position der Augen des Benutzers ermitteln. Es gibt bereits einige solcher Algorithmen, welche oft in  Digitalkameras eingesetzt werden.

3. Handy kann sich nur auf der Z-Achse bewegen

Dieser Fall ist ähnlich zu lösen wie der vorherige. Hier wird angenommen, dass sich das Gerät nur nach vorne und hinten bewegen kann. Es kann wieder nicht gekippt werden. Wenn sich das Handy exakt auf einer Linie vor dem Betrachter befindet hat diese Bewegung keine Auswirkung auf den Bildschirminhalt.

Befindet sich das Handy, jedoch leicht versetzt neben dem Betrachter und bewegt sich dann auf der Z-Achse muss dies auch erfasst werden um den Effekt  möglichst realistisch wirken zu lassen. Auch hierfür benötigt man einen Augen-Erkennungs-Algorithmus. Um die Länge der Strecke zwischen Handy und Betrachter zu ermitteln muss man diesmal den Abstand zwischen den beiden Augen messen. Liegen die Augen relativ nah zusammen ist der Betrachter etwas weiter entfernt. Vergrößert sich dann der Abstand zwischen den Augen bewegt sich der Betrachter auf das Android Gerät zu. Das selbe funktionier natürlich auch umgekehrt.

Die Mischung machts!

Kombiniert man nun alle drei Fälle kann man mit den ermittelten Daten einen wunderbaren 3D Hologramm Effekte auf Android Geräten erzeugen, welcher den Effekt aus dem TATMobile Video noch weit übertreffen könnte. Ich bin mir sicher, dass in den nächsten Monaten noch viele coole Experimente auf diesem Gebiet passieren werden.

[ad#google_article_mo_2]

4. Das Ultimative 3D Erlebnis !!!

Das Android Gerät besitzt einen weiteren nicht zu unterschätzenden Sensor. Den Kompass! Mit diesem liese sich der 3D Effekt um einen besonders coolen Aspekt erweitern. Man könnte die auf dem Bildschrim dargestellten “Pseudo-3D-Objekte” von allen möglichen Seiten betrachten.

Das folgende Video zeigt diesen Effekt sehr schön. Es ist eine Kombination aus den Punkten 1 und 4. Man beachte, dass sich weder Kamera noch das Gerät von der Stelle bewegen.

Der 3D Hologramm Effekt ist machbar!

Mit den hier vorgestellten technischen Möglichkeiten sind solche Effekte theoretisch nur eine Frage der richtigen Implementierung. Es müssen nämlich aller der 4 Fälle berücksichtigt werden um die perfekte Illusion zu erzeugen. Ein Android Phone mit Front-Kamera wäre natürlich auch recht hilfreich :) .

Ich übersehe unter Umständen ein paar Aspekte oder es geht noch einfacher als ich es hier beschrieben habe. Daher würde ich mich über Feedback und weitere Ideen zu diesem Thema sehr freuen.

Nachtrag:
Ich habe gerade ein weiteres Video zu diesem Thema entdeckt. Wieder ist es eine iPhone App, welche offensichtlich mit Kompass und den Beschleunigungssensoren arbeitet. Wie bei der “Katze” von oben wirkt der Effekt nur solange wie der Betrachter seine relative Position zum Gerät nicht verändert.

Fahrplan NG ist im Market!

Posted by Mohammed El Batya October - 29 - 2009 - Thursday 3 COMMENTS

Ich möchte nur kurz Mitteilen, dass Fahrplan NG nun im Market erhältlich ist. Die Version ist noch recht simpel, erledigt aber Ihre Aufgabe. :)

Für weiter Infos und einen Screenshot einfach den Blogeintrag  http://www.andforge.net/?p=1552 lesen.

Feedback ist natürlich wie immer erwünscht.

Andforge auf der Droidcon

Posted by Johannes Borchardt October - 12 - 2009 - Monday 1 COMMENT

Am 4. November findet im Dahlem Cube in Berlin die erste Android Konferenz in Deutschland, die Droidcon, statt. Am Vortag findet ein dazugehöriges Barcamp statt. Die Teilnahme an der Konferenz kostet 99 Euro, das Barcamp ist natürlich kostenlos.

Anfang September wurden wir von einem der Organisatoren mit der Bitte angesprochen, uns für einen Sprecherplatz zu bewerben. Gesagt, getan: Andforge goes Droidcon!

So werden unsere Teammitglieder Florian Detig und Johannes Borchardt ab 14:00 Uhr mit “Making Money Mobile” den Sinn für das Android-zu-Geld-machen schärfen. Veranlasst dadurch werden wir in den nächsten Wochen eine Reihe über Businesswissen posten, beginnend mit dem “Geschäftsmodell”.

Andforge goes Droidcon

Andforge goes Droidcon

Ankündigung: Fahrplan NG

Posted by Mohammed El Batya August - 26 - 2009 - Wednesday 7 COMMENTS
Fahrplan NG Prototyp

Fahrplan NG Prototyp

Um unsere Beta Applikation “Fahrplan Beta” ist es in den letzten Wochen ziemlich ruhig geworden. Auch ist es so dass wir die App seit einiger Zeit aus dem Android Market entfernt haben.

Was war los?

Das Hauptproblem waren einige technische Hürden, was die Beschaffung der Fahrplan-Informationen betraf. Nach langem hin und her sind wir zu dem Schluss gekommen, dass Fahrplan Beta in  der bestehenden Form keine vernünftige Zukunft hat und haben das Projekt eingestellt.

Fahrplan NG

Unser Ziel, eine effiziente und einfache Fahrplanauskunft aufs Handy zu zaubern haben wir jedoch noch nicht aufgegeben und arbeiten gerade an einem neuen Konzept.

Es geht darum, dass bestehende Verkehrsgesellschaften wie zum Beispiel die Deutsche Bahn bereits sehr schöne mobile Internetseiten anbieten. Diese zeigen nach kurzer Eingabe von Start und Ziel eine für den Handybrowser optimierte Fahrplanauskunft an. Nervig ist jedoch, dass man jedes mal erst den Browser öffnen, die URL ansteuern, die Eingaben tätigen und auf das Ergebnis waren muss.

Um diesen Prozess so stark wie möglich zu vereinfachen haben wir das Projekt “Fahrplan NG” ins Leben gerufen. Mit “Fahrplan NG” soll es nach einer kurzen “Lernphase” möglich sein mit nur 2 Klicks und keinerlei Texteingabe den gewünschten Fahrplan anzuzeigen.

Das ganze soll wie folgt funktionieren:

  1. Click um Fahrplan NG zu starten
  2. Es werden die Felder für Start und Ziel automatisch ausgefüllt
  3. Click um Start und Ziel zu bestätigen
  4. Es wird die Auskunft der Deutschen Bahn im Browser geöffnet

Noch arbeiten wir an einem Prototypen, da das “erraten” der richtigen Start-Ziel Kombination anhand von bisherigen Eingaben nicht immer so einfach ist.

Bei Benutzern, die täglich immer die selben Routen fahren und das “erraten” so gut wie immer funktioniert, könnte man sich sogar vorstellen, dass nur ein einziger Klick notwendig ist. Der Klick zum Bestätigen der Start – Ziel Kombination würde dann nämlich wegfallen.