bishoph.org

Hmm. Ich bin schon ein wenig enttäuscht. Ich dachte GPS in mobilen Endgeräten wäre in den meisten Situationen voll alltagstauglich oder wenigstens bedingt einsetzbar.
Die letzten Tage habe ich beim Fahrrad fahren den kürzlich vorgestellten Sport Track in der Praxis eingesetzt. Hier das ernüchternde Ergebnis:



Nicht das Missverständnisse aufkommen: Ich bin beide Male die selbe Strecke gefahren. Das Handy war beide Male in der selben Seitentasche. Das erste Bild zeigt das Resultat der ersten Fahrt, bei der ich in den ersten paar Minuten kein Signal hatte und schon eine ganze Zeit lang unterwegs war, bevor der Startvorgang eingeleitet werden konnte. Bei der zweiten Fahrt (zweites Bild) war die Initialisierungsphase sehr kurz. Leider gab es nur recht selten ein GPS Signal, so das die Berechnung der Strecke nicht komplett aufgezeichnet wurde. Ich bin davon ausgegangen das der Anwendungsfall "Zeit und Strecke messen" nichts besonders ist und das diese einfache Anforderung problemlos einsetzbar ist.

Lag es vielleicht an der eingesetzten Technik? Ist das Endgerät für einen solchen Anwendungsfall nicht geeignet? Ich werde weiter testen und schauen ob man das Ergebnis beeinflussen und verbessern können. Was ist eure Erfahrung mit GPS und Handys? Was kann man optimieren? Was funktioniert? Freue mich über eure Resultate, Kommentare und Meinungen.

PS: Meine sportlichen "Leistungen" stehen nicht zur Diskussion ;-)

Im ersten Teil von "Mobile Web WRT" waren die Widgets noch optimierungsbedürftig. Um es direkt vorweg zu nehmen: sind sie immer noch. Aber es gibt neue Erkenntnisse und zwar in den folgenden Bereichen:
  * Persistente Objekte
  * Zugriff auf Standort Informationen (GPS)
  * Netzwerkzugriffe
  * Aptana Studio und der Emulator

Persistente Objekte
Nicht selten besteht die Anforderung das ein Programm sich bestimmte Daten speichert und das diese Daten beim erneuten ausführen wieder zur Verfügung stehen. Im Zeitalter der "Cloud" kann man natürlich sämtliche Daten einfach an einen Server schicken und diese einfach von dort aus wieder laden. Wir betrachten hier aber die Möglichkeiten von WRT und es ist zum Glück mehr als einfach Daten zu speichern und wieder zu laden. Und das geht so:
   // Save
   widget.setPreferenceForKey("VALUE", "KEY");
   // Load
   var value = widget.preferenceForKey("KEY");
Da wir uns innerhalb eines JavaScript Kontextes bewegen kann man natürlich für den "VALUE" Part auch JSON verwenden und kann so komplexe Objekte auf recht einfache Art und Weise speichern und wieder laden.
Da es ja bei diesem Experiment darum geht möglichst viele Devices zu unterstützen schauen wir schnell ob wir einer proprietären Funktion auf den Leim gegangen sind. Das Resultat ist sehr erfreulich, denn die Funktion finden wir bei:
Opera
Apple/iPhone
Da das "Widget"-Element Bestandteil von WebKit ist, kann es durchaus sein das Android und der Palm Pre diese Funktionen kennen.

Ich habe ja vor einigen Tagen angekündigt, das ich hier über Ansätze schreibe, wie man webbasierte Anwendungen auf einem mobilen Endgerät entwickeln kann. Das Ziel ist es, am Ende eine Anwendung zu haben, die nahezu alle marktrelevanten (neuen) Endgeräte abdeckt. Dabei sollte die verwendete Technologie möglichst identisch und der Aufwand gering sein. Mal schauen wie weit wir damit kommen.

Als ersten Kandidaten habe ich mit die Web Runtime Widgets (WRT) ausgesucht. Die nachfolgenden Beispiele beziehen auf Endgeräte mit Touch Screen, bei denen als Basis die S60 5th Edition dient.

Nach aktuellem Stand basieren die folgenden Endgeräte auf der S60 5th Edition:
  * Nokia 5800 XpressMusic
  * Nokia N97
  * Samsung i8910 Omnia HD
  * Sony Ericsson Satio

Um ein Widgets zu erstellen benötigt man HTML, CSS und JavaScript Kenntnisse. Widgets lassen sich auf den Endgeräten installieren und bieten Zugriff auf bestimmte Systemressourcen.
Es gibt diverse Entwicklungstools und ich habe mich für Aptana Studio entschieden da diese Plattform auch iPhone Entwicklung ermöglicht. Leider wird derzeitig nur Windows und kein Linux unterstützt, eine Linux Version ist angekündigt.
Zu Installation und Basics von Aptana Studio möchte ich eigentlich nichts sagen, denn da gibt es gute Ressourcen im Web.

Einführung
In Aptana Studio kann man einfach ein existierendes Widget importieren oder ein neues erstellen. Widgets enden mit der Dateiendung ".wgz", allerdings sind Widgets einfache Zip-Archive. Man kann diese Archive also selber erzeugen und man benötigt Aptana Studio nicht unbedingt.

Es ist nun knapp ein halbes Jahr her das ich über die mobile Fragmentierung des Marktes geschrieben habe und seither ist recht viel passiert. Der Markt ist noch stärker fragmentiert. Für den Hersteller, respektive den Entwickler, ist es noch aufwendiger eine breite Masse an Anwendern zu erreichen . Schauen wir uns die aktuelle Situation an. Als erstes schauen wir uns aktuelle Marktzahlen an des gesamten Marktes an.

Marktanteile Q1 2009:

Nokia: 40.43 %
Samsung: 19.91 %
LG: 9.83 %
Motorola: 6.39 %
Sony Ericsson: 6.3 %
Blackberry/RIM: 3.39 %
Apple: 1.65 %
Others: 12.09 %

Quelle: http://www.mobileisgood.com/statistics.php?year=2009

Wenn wir uns diese Zahlen anschauen und einmal den Anteil der Java-fähigen Geräte extrahieren kommen wir auf min. 70 % (Nokia + Samsung + Motorola + Blackberry + ein paar % others).

Die gleiche Betrachtung auf den Smartphone Markt angewendet zeigt (leider nur Q4/2008 Zahlen):

Nokia: 40.8 %
Blackbery/RIM: 19.5 %
Apple: 10.7 %
HTC: 4.3 %
Samsung: 4.2 %
Others: 20.5 %

Quelle: http://www.gartner.com/it/page.jsp?id=910112

Alleine Nokia und Blackberry/RIM kommen auf stolze 60.3 % und ich denke das man auch im Smartphone Markt von einer Java-Abdeckung von min. 2/3 ausgehen kann (und nein, den Win Mobile Java Stack zähle ich nicht dazu).

Was aber, wenn man nahezu 100% abdecken möchte? In Zeiten von Cloud computing und immer besser werdenden Browser Unterstützung liegt eine Webanwendung nahe - gemeinhin auch als Webseite bezeichnet. Interessanter Weise zeichnet sich bei den mobilen Geräten ein Trend ab, der eine Konsolidierung aufweist: Der mobile Browser. Schaut man sich den Trend an, dann zeichnet sich ab, das zukünftig die folgenden Browser auf mobilen Geräten zu finden sind:

WebKit basierend (Safari/Android/Nokia)
IE
Fennec/Firefox
Opera

Das ist eine recht positive Entwicklung denn sie birgt die Chance Entwicklungen einer breiten Masse zur Verfügung zu stellen.

Search engines like Google and Yahoo want to understand the web. They want to dive into (microformat/RDFa) formatted data to provide better search results. The BBC article talks about "smarter search". As of today, searching and browsing the web gives me some insight to topics that are not related to a search term at all. Some of them are interesting and let me thinking laterally... Of course, the semantic web will have some major benefits - product search comes in my mind.

 

Personally I'm more exited about the fact that everyone can work/modify/combine the data. In a social world where you trust your peers more than anybody else, think about what does it mean if anybody can re-create raw/processable data - but before we reach this question, I would find it it smart to define a standard for open and structured data beforehand. But we are in an agile world and Google defines the format for us and the Drupal/Wordpress teams are already working on some kind of implementation.

 

Hope that the benefit of all the efforts can be combined and the user gets a benefit. Just read that we got a name for the whole thing: Web 3.0. Here is the article: http://www.readwriteweb.com/archives/understanding_the_new_web_era_web_3...

Der Begriff Smartphone ist ja nicht unbedingt sehr konkret. Ein Smartphone ist ein Telefon welches zusätzlich noch persönliche Informationen verwaltet. Moderne Smartphone sind meiner Meinung nach aber noch nicht smart. Oder anders ausgedrückt: Anhand der zur Verfügung stehenden Daten könnte ein Smartphone wirklich smart werden. Bisher wurde eher versucht existierende Anwendungen auf einen schmalen Prozessor und einen kleinen Bildschirm zu portieren. Nachfolgend ein Schaubild über den mobilen Kontext:



Ein einfaches Beispiel für ein smartes Phone: Ein Benutzer ist im Büro und hat gerade eine Besprechung. Eigentlich eine Information die in einem Smartphone zur Verfügung steht. Ich fände es smart, wenn zu Beginn eines Meetings das Profil in "Besprechung" geändert wird (in fast jedem Meeting hat ein Teilnehmer sein Telefon nicht in diesem Modus und wird prompt angerufen). Das ganze ist noch recht fehleranfällig, denn ein Meeting kann vorzeitig beendet werden, oder es gibt eine Pause. In solchen Fällen wäre es doch nett, wenn das Smartphone wieder das normale Profil übernehmen würde - für den Fall das ein Meeting länger dauert als geplant habe ich übrigens keine Idee, freue mich aber über jede Anregung.

Kling kompliziert? Es ist nicht einfach, aber moderne Smartphones verfügen über leistungsstarke Sensoren und liefern interessante Daten, welche man recht effektiv kombinieren kann. Eine Übersicht über einige Sensoren:

Nachtrag: Die Hauptnavigation kann man hinzufügen indem man die folgenden Zeilen in das "Mobile-Theme-Page-Template" kopiert:

<?php if (isset($primary_links)) : ?>
<?php print theme('links', $primary_links, array('class' => 'links primary-links')) ?>
<?php endif; ?>


Linux einrichten und so zum laufen bringen ist eigentlich recht einfach. Aufwändiger wird es, wenn man spezielle Anforderungen hat. Meine Anforderung war es zum Beispiel zwei Monitore ans laufen zu bekommen und den primären Monitor für Full-Screen Anwendungen anzusteuern. Außerdem sollten sich Fenster von einem zum anderen Monitor schieben lassen. Meine Umgebung ist übrigens ein Kubuntu 8.04.

Die zwei Monitore zu konfigurieren ist recht simpel, sofern man eine NVidia Karte sein Eigen nennt. Dafür gibt es das Tool "nvidia-settings". Einfach die gewünschten Einstellungen durchführen, speichern und schon ist man fertig. Full-Screen Anwendungen breiten sich allerdings gerne über beide Bildschirme aus - was in meinem Falle nicht gewünscht ist.

Hier muss man manuell konfigurieren. Wenn man weiß wie es geht, ist es einfach. Mit einem geeigneten Editor (z.B. vim), öffne man die Datei /etc/X11/xorg.conf und suche die Sektion "Screen". Es sollte sich eine Option darin befinden welche mit "metamodes" anfängt. Diese kann man in eine neue Zeile kopieren und auskommentieren.

Um nun sowohl zwischen den beiden Bildschirmen Fenster hin-/ und herschieben zu können und Full-Screen zu ermöglichen (wie erwähnt auf einem Bildschirm), passt man die neu eingefügt Zeile wie folgt an:

Option "MetaModes" "nvidia-auto-select,nvidia-auto-select;NULL,nvidia-auto-select"

Diese Zeile macht folgendes: Die ersten beiden Parameter (nvidia-auto-select,nvidia-auto-select) spezifizieren den normalen Modus (TwinView), bei dem beide Monitore mit der geeigneten Auflösung angesprochen werden. Nach dem Semikolon erscheint dann (NULL,nvidia-auto-select). Der NULL Parameter schaltet den gewünschten Monitor im Full-Screen Modus aus. Wenn der andere Monitor ausgeschaltet werden soll ist nur die Reihenfolge zu ändern.