Kategorie: HTML5

Wikipedia wird mit HTTPS sicherer – Reparaturarbeiten am Pediaphon


Durch eine Anfrage eines Nutzers bin ich auf Probleme mit der Textkodierung der Pediaphon-Funktion „eigene Texte sprechen“ aufmerksam geworden. Nur ist diese Funktion auch in der Lage weiche Trennstriche, wie sie beispielsweise per Cut&Paste aus Word in das Eingabefeld kommen, zu erkennen und nicht mitzusprechen. Eine Stimme hat diese weichen Trennstriche als „bedingter Trennstrich“ oder als „Verneinung“ mitgesprochen. In Word wird das Negationszeichen, also wortwörtlich die “Verneinung” als weiches Trennzeichen verwendet.

Nach der Reparatur fiel mir ein auch einmal zu testen, ob das Sprechen von Wikipedia-Artikeln noch funktioniert, nachdem die Wikipedia, wie viele andere Webseiten nach den Snowden-Enthüllungen auch, nun nur noch per HTTPS abzufragen ist. Und tatsächlich, der Redirect von HTTP auf die entprechende HTTPS-Artikelseite führt in den Pediaphon-Scripten zu einem Problem, so dass bei allen Anfragen nur noch der normalerweise am Endes des Artikels angehängte Erklärungstext gesprochen wurde. Die Ursache war schnell gefunden, die Änderung für alle Sprachen und Stimmen zu realisieren war aber etwas aufwendiger, da alle Sprachvarianten betroffen waren.

Bei den folgenden Tests ist mir sofort ein weiteres kleines Problem aufgefallen. Vor einigen Monaten hatte ich beschlossen, die Audoausgabe defaultmäßig von Flash auf HTML5 umzuschalten, da mittlerweile fast alle mir bekannten Browser den MP3-Codec im HTML5-Audio-Tag unterstützen und Flash deshalb (und wegen der ständigen Sicherheitslücken) als Webtechnik in den Mülleimer der Geschichte gehört. Übrigens unterstütze ich HTML5-Audio für das Pediaphon schon seit Firefox 3.5 ( 2010). Allerdings mussten die Nutzer diese Option bisher aktiv auswählen.

Beim Einsatz HTML5-Audio weigern sich aber Firefox und andere Browser (neuerdings?) trotz “Pragma” „no-cache“ im HTML-Header die vom Pediaphon generierten Audio-Dateien immer neu zu laden. Die Audio-Repräsentation z.B. des Artikels zu Edward Snowden heißt im Pediaphon immer edward_snowden.mp3, auch wenn zwischendurch Parameter wie Stimme und Sprechgeschwindigkeit verändert werden. Flash, Java und Windowsmedia können durch Parameter dazu gebracht werden, die Datei immer frisch nachzuladen. HTML5-Audio weigert sich aber beharrlich und spielt den Inhalt aus dem Cache ab, auch wenn manuell die Datei per Reload in einem neuen Fenster nachgeladen wurde. Abhilfe schafft ein Trick: Den Dateien ist im URL ein Parameter angehängt, der einen Zufallswert mitliefert:

 

edward_snowden.mp3?z=<zufallswert>

 

Der Browser lädt dann die richtige Datei, hält sie aber durch den geänderten URL für eine andere. So wir nun auch HTML5-Audio im Browser dazu bewogen dynamische MP3- oder Ogg-Dateien nachzuladen und nicht die Datei aus dem Cache zu verwenden. So funktioniert das Pediaphon wieder wie gewohnt.

 

The rebirth of the cool – mit webGL kehrt Virtual Reality endlich zurück ins Web


Ende des letzten Jahrtausends wurde die Virtual Reality Modeling Language als ein Austauschformat für 3D-Geometrien standardisiert (VRML97). Interessant wurde es aber erst als VRML im Web eingesetzt wurde.

Zunächst waren leistungsfähige und teure 3D-Grafik-Workstations von Silicon Graphics (SGI) nötig um 3D in Echtzeit auf einem Desktop darzustellen. Aber Ende der neunziger Jahre standen die ersten Grafikkarten mit OpenGL Beschleunigung auch für handelsübliche PCs zu Verfügung und so begann das goldenen Zeitalter der Virtuellen Realität im Netz. Um VRML im Browser darzustellen war ein Browser PlugIn erforderlich, das die Darstellung der 3D-Welten übernahm. Richtig spannend wurde VRML durch das sogenannte External Authoring Interface ( EAI), welches  Java-Applets ermöglichte die 3D-Welten zu beeinflussen also zu programmieren. Zur Erinnerung: Damals waren Java Virtual Machines in den Browsern integriert (Netscape4, IE4).

Da nun die Nutzer der Browser schon damals wenig Lust (und wenig know how) hatten Webbrowser-PlugIns zu installieren, setze ich zu dieser Zeit viel Hoffnung in den Netscape Navigator 4.06 der mit einem VRML-PlugIn (CosmoPlayer) ausgeliefert wurde. Leider beendete der von Microsoft initiierte Browser-Krieg einerseits die Integration von Java in den Browser, andererseits gab Netscape auf und stellte den Quellcode des Navigator unter Open Source. Damit war das EAI verschwunden und es gab keine standardisierten Möglichkeiten mehr im Browser VRML Welten mit externen Schnittstellen zu programmieren. Selbst webbasierte Multiuser Virtual Reality Umgebungen wie VNET und Deepmatix funktionierten nicht mehr. Das viel spätere netzbasierte Second Life lief niemals im Browser und staubte den Hype ab.

Mit WebGL und dem API x3dom sind nun wieder standardisierte (X3D, der Nachfolgestandard zu VRML97) programmierbare (diesmal Javascript) 3D-Modelle im Browser möglich. Und das Ganze funktioniert sogar ohne PlugIn in aktuellen Browsern. Der IE von Microsoft bildet wieder einmal die unrühmliche Ausnahme. Leider hält sich dieser Konzern an keinerlei Standards. Aber x3dom verwendet für nicht unterstützte Browser ein Flash swf als Renderer für X3D, allerdings werden nicht alle folgende Beispiele im IE richtig dargestellt.

Ich erwecke hier den Puma-Robotersimulator wieder zum Leben, den ich im Jahre 2000 für das RichODL-Projekt an der FernUni in Hagen realisiert habe. Mit jquery wird hier das X3D DOM manipuliert um die Roboterachsen zu bewegen:

Ein mehr immersives Beispiel ist das PRT-Roboterlabor, welches ich 2001 in VRML modelliert habe:

Und die „Galerie oben“ der FernUni, die seinerzeit (2002) mit diesen Avataren bevölkert war:

In meiner Diss. habe ich mich im Jahre 2005 ausführlich mit diesen Techniken beschäftigt.

The rebirth of the cool“ ist der Titel einer Acid-Jazz Compilation aus den Neunzigern.

In 80 Zeilen um die Welt – Moving Map mit HTML5 Geolocation für iPhone,iPad und Android ohne Google ;-)


Das HTML5 Geolocation-Feature interessiert mich schon eine ganze Weile. Im Juli 2010 habe ich in meinem Blog eine Lösung basierend auf Openstreetmap, bzw. genauer dem großartigen Openlayers-Projekt, vorgestellt. Weil diese Seite recht viel Traffic über Google erzeugt, nun auch in meinem Blog einen ausführlicheren Artikel dazu.
Ich habe das Beispiel nun um eine Detektion der Screensize und eine live-Aktualisierung erweitert, so dass nun eine rein webbasierte ‘moving map’ a la Google maps plattformübergreifend zur Verfügung steht. Richtig spannend wird diese Seite erst wenn Sie sich bewegen (z.B mit mit einem Smartphone/iPad oder Netbook), der Browser aktualisiert dann Ihre Position!

Also in etwa die Google maps Funtionalität, rein HTML5-webbasiert und ohne Google. Das stimmt leider nicht wirklich, da beispielsweise im Firefox-Browser auch wieder Google als ‘embedded location provider’ eingetragen ist. Glauben Sie nicht? Einfach einmal about:config in die Adresszeile des Browsers eingeben (das ist die Browser-Konfiguration für Erwachsene ;-) ) und nach dem Schlüssel ‘geo.wifi’ suchen. Der Browser holt die Position per JSON bei Google https://www.google.com/loc/json ab. Wie genau Ihre Position bestimmt werden kann hängt vom Location Provider bzw. von der Implementierung Ihres Browsers und der eingeschalteten Quellen für die Lokalisation (WLAN/GSM/GPS) ab. Wenn diese Quellen nicht eingeschaltet sind, z.B. bei einem PC ohne WLAN, versucht Google die Position anhand der IP-Adresse bzw. anhand von Whois Records zu erraten. Das klappt erstaunlich genau.

Das Beispiel ist hier als iframe in mein Blog eingebettet und funktioniert auf allen HTML5 fähigen Browsern auch auf Android-Smartphones (ab 2.3 Gingerbread) und dem iPhone/iPad/iPod touch:

Benutzen Sie diesen Link um die Karte direkt auf Ihrem Android bzw IOS Smartphone anzuzeigen.

Nicht erschrecken, der Browser sollte beim Laden nun artig fragen ob diese Webseite Ihre Position erfahren darf. Dabei handelt es sich um ein HTML5-Geolocation-Feature.

Hier ist der einfache Quellcode zu sehen, ein bisschen Javascript meinerseits plus OpenLayer.js:

 

<html>
  <head>
    
    <style type="text/css">
      html, body, #basicMap {
          width: javascript(screen.width);
          height: javascript(screen.height);
          margin: 10;
      }
    </style>
 <!-- javascript(screen.width); //-->
  <!-- javascript(screen.height); //-->

    <script src="OpenLayers.js"></script>

    <script>
      function init() {
        map = new OpenLayers.Map("basicMap");
        var mapnik = new OpenLayers.Layer.OSM();
        var markers = new OpenLayers.Layer.Markers( "Markers" );
        
        map.addLayer(mapnik);
        //map = new OpenLayers.Map("basicMap");
        //var mapnik = new OpenLayers.Layer.OSM();
        //map.addLayer(mapnik);
        map.setCenter(new
        OpenLayers.LonLat(3,3) // Center of the map
          .transform(
            new OpenLayers.Projection("EPSG:4326"), // transform from WGS 1984
            new OpenLayers.Projection("EPSG:900913") // to Spherical Mercator Projection
          ), 15 // Zoom level
         );
        //var markers = new OpenLayers.Layer.Markers( "Markers" );
        map.addLayer(markers);
        var posss = new OpenLayers.Marker(0,0);
        markers.addMarker(posss);                    
                        

        navigator.geolocation.watchPosition(function(position) {       
            document.getElementById('anzeige').innerHTML="Latitude: " + position.coords.latitude + "   Longitude: " +
            position.coords.longitude + "<p>";
            var lonLat = new OpenLayers.LonLat(position.coords.longitude,
                                    position.coords.latitude)
                      .transform(
                                  new OpenLayers.Projection("EPSG:4326"), //transform from WGS 1984
                                              map.getProjectionObject() //to Spherical Mercator Projection
                                            );
            
            markers.clearMarkers();                                
            markers.addMarker(new OpenLayers.Marker(lonLat));
            //posss.lonlat(lonLat);
            map.setCenter(lonLat, 14 // Zoom level
            );
           
        });
            
      
      }
    </script>
  </head>

  <body onload="init();">
<center>
HTML5 geolocation: 
<br />
    <div id="basicMap"></div>
<br />HTML5 geolocation<br />
<br />with Openstreetmap and OpenLayers<br />

For Android Froyo,iPhone,iPAD,iPod
<br />
Your position estimated by browser geolocation API:<p>
<div id="anzeige">(will be displayed here)<p></div>
<a href="http://www.dr-bischoff.de">Andreas Bischoff</a>

<br />(view source to see how it works, or <a
href="http://blog.robotnet.de/2011/03/30/html5-geolocation-with-openstreetmap-and-openlayers-for-android-iphone-ipad-and-ipod/">read my blog</a> ;-)
</center>
  </body>
</html>


Android Gingerbread 2.3.3 auf dem 99 Euro Androiden Vodafone 845


Nachdem sich mein neues Orange San Francisco (mit 2.3.3 Gingerbread, Cyanogen Mod 7), frisch importiert aus UK, nach nur einer Woche mit einem Sturz verabschiedet hat :-( , konnte ich nun nicht widerstehen als ich gelesen habe, dass eine frühe Cyanogen Mod 7 Beta auch für das Vodafone 845 verfügbar ist. Das kam insofern überraschend, als dass es bisher kein wirklich stabiles ROM mit Froyo für das Gerät gab.

Wer mutig ist kann Gingerbread für das Vodafone 845 hier ausprobieren:

http://forum.xda-developers.com/showthread.php?t=1096075

und hier:

http://www.android-hilfe.de/vodafone-845-forum/115220-cyanogenmod-7-auf-dem-845-a.html

Noch nicht alles läuft perfekt, das größte Manko ist derzeit noch die fehlende Kalibrierung für den Touch Screen. Der verwendetet Kernel unterstützt wohl keine Touch Screen Kalibrierung.
Das Android Keyboard sollte daher durch die HTC_Ime.zip ersetzt werden, die kalibriert werden kann.
Empfehlenswert ist es auch den ADW-Launcher durch den schlankeren Zeam Launcher zu ersetzen.

Damit läuft das Telefon überraschend flüssig!

Um an die notification bar heranzukommen muss im Launcher diese als swipe down Aktion eingestellt werden. Es scheinen auch keine Applikationen zu laufen, welche die Kamera nutzen (die Kamera selber funktioniert), weder das großartige Google Goggles noch einen QR-Code Reader konnte ich erfolgreich benutzen, beides crashed die Kamera, die erst nach einem reboot wieder funktioniert. Layar, eine App welche die Kamera im Videomodus benutzt (Augmented Reality), funktioniert aber prima.

HTML5-Audio (Pediaphon Touch Interface) und Video (http://www.jplayer.org/latest/demo-01-video-supplied-m4v/) funktionieren auch endlich mit gingerbread.

cyanogenmod7 auf dem vodafone 845

gingerbread auf dem vodafone 845

UPDATE:
Es gibt dort mittlerweile Android 2.3.5 – Cyanogen Mod 7.1.0 – Huawei U8120 – RC1 – update 11 – damit funktioniert auch die Kallibrierung des Tochscreens ganz wunderbar. Auch das Update 11 läuft mit dem Zeam-Launcher super flott. Nur das Kamera Problem besteht noch. Ansonsten besser als alle Custom ROMs (und auch besser als das Original ROM) die ich kenne, und nun schon IMHO alltagstauglich.

Das Pediaphon mit neuem Touch-Interface für Android, iPhone, iPad und iPad


Weil die HTML5-Audiounterstützung nun auf Android 2.3 Gingerbread ebenso gut funktioniert wie unter iOS auf den Apple-Mobilgeräten, war ich neugierig ob sich die gemeinsame Basis der beiden Welten (der Android-Webbrowser basiert ebenso wie der Safari-Browser auf der freien Webkit Rendering Engine) für eine HTML-basierte, an die Touch-Bedienung angepasste, eigene Oberfläche eignet. Die Ansicht, die Entwicklung von plattformübergreifenden HTML-basieren Anwendungen gegenüber nativen APPs zu favorisieren, vertrete ich schon seit langem. Besonders für e- und m-learning Anwendungen ist eine Standardisierung nützlich um zu verhindern, dass im Hochschulbereich immer knappe Entwicklungskapazitäten an einzelne Endgeräte verschwendet werden. Wiederverwendbarkeit und langer Lebenszyklus sind bei Web-basierten Anwendungen eher sicherzustellen als bei nativen APPs.

Ich wollte ursprünglich Sencha Touch einsetzen  bin aber durch einen Kollegen auf iWebkit aufmerksam geworden. iWebkit besticht durch seine Einfachheit in der Anwendung, schon rudimentäre HTML-Kenntnisse reichen aus um eine iWebkit-Seite zu erstellen. Auf dem iPhone und iPad sehen iWebkit-Seiten aus wie eine native APP und sie laufen auch ganz fabelhaft  auf Android- Nokia S60- Palm Pre- und Openmocko, basierten Geräten.

Als beispielhafte Anwendung wird hier ein eigenes Pediaphon-User-Interface für Webkit-basierte Mobilbrowser vorgestellt. Die Audioausgabe wird hier mit HTML5 realisiert, für Android 2.2 Froyo basierte Telefone gibt es auch eine Flash Alternative.

Hier einige Screenshots vom GUI (Auf einem Android 2.3 Gingerbread Emulator, aber auch schon live mit einem Orange San Francisco getestet):

Ausprobiert werden kann das Pediaphon iWebkit-Interface hier in Deutsch und in Englisch, Spanisch, Französisch und Italienisch.

Audio-Wiedergabe ohne Plugin mit HTML5 und neue Positionsbestimmung mit Location-API für HTML5


Ein neues Feature für das Pediaphon ist die Plugin-lose Audiowiedergabe mit HTML5. Moderne Browser (Firefox > 3.5, Chrome, Safari) unterstützen die HTML5-Spezifikation und ermöglichen konform dem Standard die Plugin-lose Audiowiedergabe direkt im Browser. Unterstützt wird das OGG-Audioformat für das jetzt auch im neuen Design eine Metadatei generiert wird. Einfach auf der Pediaphon-Seite HTML5 bei ‘Sofort im Browser abspielen mit’ auswählen.

Auch für location based services gibt es eine Neuerung in HTML5. Das Objekt getLocation wird nun in Javascript ähnlich wie in Google-Gears
direkt von allen konformen Browsern unterstützt. Der getestete Browser Firefox 3.6 fragt dazu den geolocation-Dienst von Google im JSON Format ab. Allerdings werden momentan nur IP-Adressen und empfangene WLAN MAC-Adressen ausgewertet. Der Nutzer wird immer vom geolocation-API gefragt ob er für die Seite seine Position preisgeben möchte. Google speichert (bzw. Firefox übergibt keinen Referer) angeblich nicht von welcher Seite die Anfrage stammt. Allerdings kann Google sehr gut seine Datenbanken mit den MAC-Adressen pflegen, die die Nutzer beisteuern.
Mit ‘about:config’ in der Adressleiste kann man (nach der neuen popup-Warnung ;-) den Schlüssel ‘geo.wifi.uri’ finden, der auf
https://www.google.com/loc/json verweist.

Hier kann das Ganze ausprobiert werden. (Allerdings hat der Geonames.org Webservice wohl heute ein
Problem
).

Auch die Linux-Version von Firefox 3.6 soll auch lokale und entfernte GPS-Empfänger unterstützen, wahrscheinlich ganz einfach über diesen Schlüssel, wo doch der GPSd-NG jetzt auch JSON unterstützt. (Da gibt es wohl noch ein kleines Problem).