Kolumne: Dino talks

ASP.NET und Datenbanken für Gerätebeschreibungen
Kommentare

Wenn Sie meinen, dass es eine komplizierte Angelegenheit ist, Websites zu schreiben, die auf unterschiedlichsten Desktopbrowsern gleichermaßen gut funktionieren, wissen Sie wahrscheinlich nicht allzu viel über mobile Browser und mobile Sites. Die Variantenvielfalt von mobilen Browsern ist wesentlich größer als bei Desktopbrowsern. Zudem sind die heutigen Mechanismen zum Erkennen der Browserfunktionen in ASP.NET völlig unzureichend. Doch wie können Sie es besser machen? Und vor allem: Wo finden Sie die richtigen Informationen? Dieser Artikel beschäftigt sich mit den Browserfunktionen in ASP.NET und stellt eine Open-Source-Datenbank für mobile Geräte vor.

Obwohl heutzutage die meisten Desktopbrowser einen gemeinsamen Satz leistungsfähiger Funktionen nutzen, bleibt das gute alte Motto von „write once browse from everywhere“ (einmal Schreiben, von überall browsen) ein Märchen. Dass eine Seite auf verschiedenen Browsern funktioniert, ist kein alter Hut, sondern vielmehr etwas, was Sie gründlich testen müssen. Hierzu kann eine gehörige Portion zusätzlicher Arbeit erforderlich sein. Browserübergreifendes Rendering bezieht sich auf den Satz von Techniken und Technologien, mit denen Sie sicherstellen können, dass Ihre Seiten unabhängig vom verwendeten Browser funktionieren und gleich aussehen. Der Kerngedanke hinter browserübergreifendem Rendering ist, dass der Code innerhalb der Seite in der Lage ist, die ID des Browsers und seinen bekannten Satz von Funktionen und Eigenschaften zu erkennen. Darauf aufbauend arbeitet der Code in der Seite eine Lösung aus, um das bestmögliche Markup für das Gerät zu erhalten. Dieses recht allgemeine Muster wird als Multi-Serving bezeichnet. Als Alternative zum Multi-Serving können Sie Ad-hoc-Seiten für bestimmte Kategorien von Browsern erstellen. Denkbar sind zum Beispiel HTML-5-Seiten für Webkit-fähige Browser, eher klassische Webseiten für andere Browser und vielleicht noch eine abgespeckte Seite für alle mobilen Geräte. Dies kann eine gangbare Option sein, solange es sich um eine Webanwendung handelt, die vorwiegend auf den Desktop ausgerichtet ist. Wenn Ihr Publikum zu einem beträchtlichen Anteil aus mobilen Nutzern besteht, wird das mehrseitige Konzept schlichtweg unpraktisch. Im mobilen Bereich sind die Unterschiede zwischen Geräten und den jeweiligen Browsern wesentlich zahlreicher als im Desktopbereich. Ich würde hier zumindest eine Größenordnung schätzen. Wie differenzieren Sie nun den Inhalt, den Sie bereitstellen, aus ASP.NET-Anwendungen heraus bei einer erheblichen Anzahl von mobilen Benutzern? Um diese Frage richtig beantworten zu können, müssen wir bei den Informationen über die eintreffende Anforderung beginnen, die ASP.NET für uns zusammenstellt und verfügbar macht.

Speicherung von Browsereigenschaften in ASP.NET

ASP.NET speichert die Informationen über die aktuelle Anforderung im HttpRequest-Objekt. Dieses Objekt macht eine Eigenschaft Browser vom Typ HttpBrowserCapabilities verfügbar. Die Browsereigenschaften werden über einige Dutzend Einzelwerte dargestellt, die jeweils ein einzelnes Feature des anfordernden Browsers beschreiben sollen. Hierzu gehören Eigenschaften der HTML-Darstellung, zum Beispiel die Unterstützung von deaktivierten Elementen und mehreren Auswahloptionen, Schriften und CSS sowie komplexere Funktionen wie etwa die Unterstützung von Ajax und JavaScript sowie Bildschirmgröße und Farbtiefe.

Browsereigenschaften sollen dem Servercode möglichst zuverlässige Informationen über die effektiven Funktionen des anfordernden Browsers zur Verfügung stellen. Diese Informationen werden nicht von einem öffentlichen API gelesen, die vom Browser selbst zugänglich gemacht wird. Offen gesagt, neigen Browser zum Lügen, wenn es darum geht, Ihnen etwas über ihre effektiven Funktionen zu verraten. Die Informationen werden von einer externen Komponente zurückgegeben, dem Provider für Browserfunktionen. Diese Komponente ist erst in ASP.NET 4 hinzugekommen. In vorherigen Versionen von ASP.NET gab es lediglich einen Provider – den heutigen Standardprovider – der Informationen aus einer breiten Palette von XML-Dateien liest. ASP.NET bringt eine Liste vordefinierter Beschreibungsdateien mit. Entwickler können jedoch diese Dateien bearbeiten und ersetzen sowie neue Dateien erstellen. (Mangels einer gültigen Dokumentation ist es recht schwierig, .browser-Dateien zu ändern oder von Grund auf neu zu schreiben.) Browserdefinitionsdateien sind aus technischer Sicht Dateien mit der Erweiterung .browser, die unter dem Ordner C:WindowsMicrosoft.NETFrameworkv4.0.30319Config abgelegt sind. Es gibt eine Datei für jede bedeutende Browserfamilie, die Ihre Anwendung erkennen kann.

Es versteht sich von selbst, dass diese Informationen nicht als statische Daten zu betrachten sind, sondern ziemlich variieren können, wenn neue Versionen oder neue Browser auf den Markt kommen und sobald neue Funktionen bekannt gemacht werden. Das Aktualisieren dieser Dateien ist vor allem Sache der Entwickler. Im Allgemeinen ist es nicht trivial, diese Dateien zu aktualisieren, da hierzu ein starkes Engagement und eventuell eine aktive Community von Benutzern erforderlich sind.

Analyse der erkannten Browserfunktionen

Das Feature für die Browserfunktionen von ASP.NET ist zwar gut konzipiert, wahrscheinlich aber schlecht implementiert. In diesem Fall meine ich aber mit Implementierung nicht den Code. Vielmehr geht es um die Relevanz der Informationen, die in XML-Dateien gespeichert sind, und im Weiteren um die Qualität der Multi-Serving-Anwendungen, die Sie schreiben können.

Als Entwickler können Sie eine Reihe von Funktionen testen, die aus heutiger Sicht kaum von Interesse sind. Zum Beispiel ist es unwahrscheinlich, dass Sie wissen müssen, ob ein bestimmter Browser (durch dessen Benutzeragenten identifiziert) JavaScript oder Ajax unterstützt oder HTML-Tabellen rendern kann. Das beherrscht heute nahezu jeder Browser. Eine lange Liste von Funktionen bezieht sich auf WML (die Wireless Markup Language), die vor rund zehn Jahren bei zunehmender Präsenz mobiler Anwendungen recht populär war. Heute ist WML praktisch Geschichte und alle einschlägigen Funktionen, die sich auf einen Browser beziehen, sind einfach nutzlos. Das auf .browser-Dateien basierende Framework ist letztlich unzulänglich; es hilft Ihnen lediglich zu verstehen, ob eine bestimmte Zeichenfolge des Benutzeragenten einem Desktopbrowser oder einem mobilen Gerät entspricht. Darüber hinaus scheint der Trend in ASP.NET dahin zu gehen, dass die Funktionen live im Browser getestet werden. Man liest nicht aus einer vertrauenswürdigen Quelle, ob ein Browser über bestimmte Funktionen verfügt, sondern verwendet sie einfach erst einmal und stellt danach fest, ob alles geklappt hat oder nicht. Für welche Anwendungen ist dieser Ansatz brauchbar? Grundsätzlich für Anwendungen, die von Desktopbrowsern genutzt werden. Wenn die Zielgruppe überwiegend mobile Geräte einsetzt (oder Sie an diesem Segment stark interessiert sind), ist dieser Ansatz weniger geeignet.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -