-
HINTERGRUND DER ERFINDUNG
-
Die
vorliegende Erfindung betrifft persönliche mobile Rechenvorrichtungen,
welche im Allgemeinen als Mobilvorrichtungen bekannt sind. Insbesondere
betrifft die vorliegende Erfindung ein System und ein Verfahren
zur Lieferung und zum Empfang von Informationen auf einer Mobilvorrichtung.
-
Mobilvorrichtungen
sind kleine elektronische Rechenvorrichtungen, welche oft als persönliche digitale Assistenten
bezeichnet werden. Viele derartige Mobilvorrichtungen sind tragbare
Vorrichtungen oder handtellergroße Vorrichtungen, welche bequem
in die Hand passen. Eine kommerziell erhältliche Mobilvorrichtung wird
unter dem Markennamen HandHeld PC. (oder H/PC) mit Software vertrieben,
welche durch die Microsoft Corporation aus Redmond, Washington bereitgestellt
wird.
-
Im
Allgemeinen umfasst die Mobilvorrichtung einen Prozessor, einen
Direktzugriffspeicher (RAM) und eine Eingabevorrichtung, wie beispielsweise
eine Tastatur und eine Anzeige. Die Tastatur kann in die Anzeige integriert
sein, wie beispielsweise wenn die Tastatur als berührungsempfindliche
Anzeige integriert ist. Eine Kommunikationsschnittstelle wird optional
bereitgestellt und im Allgemeinen zur Kommunikation mit einem Desktop-Computer
verwendet. Eine ersetzbare oder wiederaufladbare Batterie treibt
die Mobilvorrichtung an. Optional kann die Mobilvorrichtung Energie
von einer externen Energiequelle empfangen, welche die eingebaute
Batterie übergeht
oder wiederauflädt.
-
In
einigen vorherigen Anmeldungen wird die Mobilvorrichtung in Verbindung
mit einem Desktop-Computer verwendet. Beispielsweise muss der Benutzer
der Mobilvorrichtung möglicherweise
auf einen Desktop-Computer in der Arbeit oder zu Hause, oder beides,
zugreifen und diesen verwenden. Der Benutzer betreibt typischerweise
dieselben Arten von Anwendungen sowohl auf dem Desktop-Computer als auch
auf der Mobilvorrichtung. Somit ist es recht vorteilhaft, wenn die
Mobilvorrichtung so konstruiert ist, dass sie mit dem Desktop-Computer
gekoppelt werden kann, um Informationen mit dem Desktop-Computer
auszutauschen und zu teilen.
-
Ein
weiteres Verfahren zur Bereitstellung von Informationen für derartige
Mobilvorrichtungen besteht über
eine drahtlose Übertragungsleitung.
Derartige Informationen können
elektronische Mails oder Nachrichten, Wetter, Sport, Verkehr und
Informationen über
lokale Ereignisse umfassen. Die Informationen werden typischerweise
von einem Desktop-Computer erhalten, welcher mit dem Internet verbunden
ist, und über
eine Drahtverbindung übertragen.
Jedoch kann es erwünscht
sein, derartige Informationen auch über eine drahtlose Verbindung
zu liefern. Ein drahtloser Empfänger
an der Mobilvorrichtung kann zum Empfang der Informationen betrieben
werden, wenn diese an die Mobilvorrichtung gesendet werden.
-
Gegenwärtig existiert
keine vernünftige
Art der Lieferung von Schubinhalt (wie beispielsweise hypertext
markup language- oder HTML-Inhalt, welcher auf einem globalen Netz,
wie beispielsweise dem Internet und dem World Wide Web, bereitgestellt
wird) an derartige Vorrichtungen auf drahtlose Weise und in einer
offenen und verfügbaren
Architektur. Die Bitgeschwindigkeit von herkömmlichen drahtlosen Kanälen ist
sehr niedrig. Somit ist die Lie ferung von sehr großem Inhalt
(wie beispielsweise HDML-Inhalt) höchst unpraktisch.
-
Ein
herkömmliche
Art der Herangehensweise an die Lieferung derartiger Informationen
besteht darin, den Inhalt in einem vorrichtungsfreundlichen Format,
wie beispielsweise HTML, neu zu verfassen. Der Inhalt wird dann über ein
Zugmodell erhalten. Eine weitere Herangehensweise, welche gegenwärtig zur
Lieferung von Informationen über
ein drahtloses Medium verwendet wird, ist ein geschlossenes Modell.
In einem geschlossenen Modell kann ein Bereitsteller von Inhalt
nur Inhalt bereitstellen, welcher in einem Format verfasst ist,
das zum Empfang durch eine bestimmte Vorrichtung geeignet ist, welche
eine bestimmte Art von Software implementiert. Dies bedeutet, dass
die große
Mehrheit von Web-Inhalt
für die
Sichtung auf derartigen Vorrichtungen nicht verfügbar ist.
-
KAASHOEK
M F ET AL: "DYNAMIC
DOCUMENTS: MOBILE WIRELESS ACCESS TO THE WWW" PROCEEDINGS, WORKSHOP ON MOBILE COMPUTING
SYSTEMS AND APPLICATIONS, 8. Dezember 1994 (1994-12-09), Seiten
179 bis 184, offenbart dynamische Dokumentenprogramme für die Ausführung auf einer
Mobilvorrichtung zur Erzeugung eines Dokuments.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Bereitgestellt
wird ein System zur Bereitstellung von Informationsinhalt von einem
Bereitsteller von Inhalt für
eine Mobilvorrichtung wie in Anspruch 1 ausgeführt. Bereitgestellt wird auch
ein computerlesbarer Datenträger,
welcher Anweisungen enthält,
die von einer Mobilvorrichtung lesbar sind, wie in Anspruch 17 ausgeführt, einer
Mobilvorrichtung wie in Anspruch 29 ausgeführt, sowie ein Verfahren der
Wiedergabe von Informationen auf einer Mobilvorrichtung, wie in
Anspruch 30 ausgeführt.
-
Die
vorliegende Erfindung stellt ein System bereit, durch welches Informationsinhalt
an eine Mobilvorrichtung geliefert wird.
-
Der
Web-Inhalt wird in Daten- und Skriptinformationen aufgeteilt. Die
Skriptinformationen werden zur Operation der Daten zur Wiedergabe
der Daten in einem vorgegebenen Format verwendet.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 ist
ein vereinfachtes Blockdiagramm, welches eine Ausführungsform
einer Mobilvorrichtung in einem System in Übereinstimmung mit der vorliegenden
Erfindung zeigt;
-
2 ist
ein detaillierteres Blockdiagramm einer Ausführungsform einer in 1 gezeigten
Mobilvorrichtung;
-
3 ist
eine vereinfachte piktographische Darstellung einer Ausführungsform
der in 2 gezeigten Mobilvorrichtung;
-
4 ist
eine vereinfachte piktographische Darstellung einer weiteren Ausführungsform
der in 2 gezeigten Mobilvorrichtung;
-
5 ist
ein Blockdiagramm einer Ausführungsform
eines Desktop-Computers in Übereinstimmung mit
einem Aspekt der vorliegenden Erfindung;
-
6 ist
ein Ablaufdiagramm, welches den Betrieb einer Mobilvorrichtung in Übereinstimmung
mit einem Aspekt der vorliegenden Erfindung zeigt;
-
7 stellt
eine allgemeine Datenstruktur eines Pakets dar, welches an die Mobilvorrichtung
in Übereinstimmung
mit einem Aspekt der vorliegenden Erfindung übertragen wird;
-
8 ist
ein detaillierteres Ablaufdiagramm, welches eine Routing- und Übersetzungsschicht
sowie die Vorbereitung von Paketen für die Übertragung in Übereinstimmung
mit einem Aspekt der vorliegenden Erfindung zeigt.
-
AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN
AUSFÜHRUNGSFORMEN
-
1 stellt
ein System 10 dar, in welchem die vorliegende Erfindung
illustrativ realisiert ist. Das System 10 weist den Inhaltslieferanten 12,
den drahtlosen Träger 14,
den Desktop-Computer 16 und
die Mobilvorrichtung 18 auf. Der Inhaltslieferant 12 stellt
jegliche geeignete Art von Daten aus einer Datenbank oder einer anderen
Datenquelle bereit. Beispielsweise wird der Inhaltslieferant 12 nachfolgend
als Bereitsteller von Inhalten aus dem World Wide Web des Internet
beschrieben. In der bevorzugten Ausführungsform wird der Inhalt in
einem Standardformat, wie beispielsweise HTML, JPEG, GIF, WAV etc.
bereitgestellt. Der Web-Inhalt wird ebenfalls bevorzugt in einer
CDF-Datei (CDF =
channel definition formst oder Kanaldefinitionsformat) beschrieben.
Ein einziger Inhaltsabschnitt (wie beispielsweise eine Webseite
oder eine Website) wird nachfolgend als ein Mobilkanal beschrieben.
-
Ein
Mobilkanal ist eine selbstbeschreibende Website, welche alle Informationen
enthält,
die zum effizienten Herunterladen von Web-Inhalt auf die Mobilvorrichtung
18 nötig sind.
Drei Komponenten werden in einem bevorzugten Mobilkanal bereitgestellt.
Die Komponenten umfassen eine CDF-Datei, einen Satz von Skript-Dateien zur Wiedergabe
des Kanals und einen Satz wiederzugebender Daten-Dateien. Die CDF-Dateien
werden ausführlicher
im
US-Patent Nr. 6,449,638 mit dem
Titel CHANNEL DEFINITION ARCHITECTURE EXTENSION beschrieben. Kurz
gesagt ist CDF ein Inventar an Inhalt, welcher auf dem Mobilkanal
enthalten ist.
-
Die
Skript-Dateien enthalten Skrip, welches Schablonen definiert, die
das Erscheinungsbild der Daten auf dem Bildschirm der Mobilvorrichtung 18 spezifizieren.
Skripte sind bevorzugt in VBS (visual basic script, visuelles Basisskript)
abgefasst.
-
Die
Daten-Dateien entsprechen einer oder mehreren Skript-Dateien und
weisen Daten auf, welche den substantiven Inhalt des wiederzugebenden
Kanals anzeigen. Die Daten sind in kleinen und ein fachen Textdateien
verpackt. Alle diese Informationen werden zur Definition von Web-Inhalt
verwendet.
-
Der
drahtlose Träger 14 wird
ausführlicher
später
in der Anmeldung beschrieben. Kurz gesagt ist der drahtlose Träger 14 jedoch
zum Empfang von Web-Inhalb von dem Web-Inhaltslieferanten 12 über eine
Einwahl- oder direkte Internetverbindung oder eine Netzwerkverbindung
ausgelegt. Der drahtlose Träger 14 weist auch
einen drahtlosen Schubserver 20 auf. Der Server 20 teilt
den vom Inhaltslieferanten 12 empfangenen Inhalt in Stücke, welche
mit der speziellen Art von Transport kompatibel sind, der durch
den drahtlosen Träger 14 verwendet
wird. Beispielsweise kann der Server 20 die Daten derart
aufteilen, dass sie mit Beschränkungen der
maximalen Paketgröße, mit
Anforderungen an den Zeichensatz etc., für die verwendete Kanalart oder Transportart
konform gehen. Vor der Übertragung
werden die Daten bevorzugt in eine andere Form übersetzt. Wie später in der
Anmeldung ausführlicher
beschrieben, kann eine derartige Übersetzung die Kompression, Verschlüsselung,
Codierung und dann Verpackung umfassen. Wurden die Daten erst einmal
in geeigneter Weise aufgeteilt, so dass sie mit den Transportbeschränkungen
konform gehen, werden die Daten dann für die Übertragung über Luft durch ein drahtloses
Netzwerk konfiguriert (wie beispielsweise über einen Paging-Kanal), um direkt
auf der Mobilvorrichtung 18 empfangen zu werden. Die übertragenen
Daten werden durch einen drahtlosen Empfänger und einer Treiberkomponente 22 auf
der Mobilvorrichtung 18 empfangen, wo die Daten für die Verwendung
durch die Mobilvorrichtung 18 vorbereitet werden.
-
Bevorzugt
weist die Mobilvorrichtung 18 auch ein Modem 24 auf.
Somit kann der Web-Inhalt, statt durch den drahtiosen Träger 14 übertragen
zu werden, direkt vom Web-Inhaltslieferanten 12 durch eine
direkte Einwahl-Modemverbindung an die Mobilvorrichtung 18 übertragen
werden.
-
Der
Desktop-Computer 16 wird ebenfalls später in der Beschreibung ausführlicher
beschrieben. Kurz gesagt wird der Desktop- Computer 16 jedoch mit einem
Standard-Webbrowser, wie beispielsweise dem Internet Explorer 4.0
bereitgestellt, welcher im Handel von der Microsoft Corporation
aus Redmond, Washington erhältlich
ist. Ist dies der Fall, so können
die Benutzer des Desktop 16 bevorzugt Kanäle auf Standardweise abonnieren,
welche dem Benutzer einen bestimmten Kanalinhalt bereitstellen,
der offline oder online gebrowst werden kann. Der Desktop-Computer 16 wird
bevorzugt mit einem ladbaren Transport (in Übereinstimmung mit einem Aspekt
der vorliegenden Erfindung) bereitgestellt, welcher auf die Skriptdateien
zugreift und an den entsprechenden Datendateien (in Übereitstimmung
mit dem Skript) agiert, um den Inhalt dort wiederzugeben, wo der
Desktop-Computer 16 die Daten wiedergibt. Der Desktop-Computer 16 kann
durch den Transport periodisch neue und aktualisierte Skript-, Daten- und CDF-Dateien
entweder zur weiteren Übertragung
an die Mobilvorrichtung 18 oder einfach zur Wiedergabe
der Daten abrufen oder empfangen. Die Skript-, Daten- und CDF-Dateien
können
entweder zusammen oder unabhängig
voneinander übertragen
werden. Da Skriptingdateien typischerweise wesentlich weniger häufig aktualisiert
werden müssen
als die Datendateien, liefert dies dem Benutzer die Fähigkeit,
den Webinhalt auf dem Desktop (offline) zu betrachten, während nur
geringe Mengen an Bandbreite zur inkremetalen Aktualisierung der
Datendateien nötig
sind.
-
Der
Desktop-Computer 16 weist ebenfalls bevorzugt die Synchronisationskomponente 26 auf.
Kurz gesagt, ist die Synchronisationskomponente 16 zur
Interaktion mit einer ähnlichen
Synchronisationskomponente 28 auf der Mobilvorrichtung 18 derart
ausgelegt, dass Dateien, welche der Synchronisation unterliegen, vom
Desktop-Computer 16 aus auf der Mobilvorrichtung 18 aktualisiert
werden können,
oder umgekehrt. Sind sie synchronisiert, so enthalten beide Dateien
(diejenigen auf dem Computer 16 und diejenigen auf der
Mobilvorrichtung 18) aktuelle Informationen.
-
Insbesondere
kann in der bevorzugten Ausführungsform
die Mobilvorrichtung 18 mit entweder dem Desktop-Computer 16 oder
einer anderen Mobilvorrichtung 18 oder beiden synchronisiert
werden.
-
In
diesem Fall ähneln
die Eigenschaften der in einem Objektspreicher auf der Mobilvorrichtung 18 gespeicherten
Objekte den Eigenschaften anderer Fälle desselben in einem Objektspeicher
auf dem Desktop-Computer 16 oder einer anderen Mobilvorrichtung 18 gespeicherten
Objekts. Wenn somit beispielsweise ein Benutzer einen Fall eines
in einem Objektspeicher auf dem Desktop-Computer 16 gespeicherten
Objekts ändert,
wird der zweite Fall dieses Objekts, welcher in dem Objektspeicher
der Mobilvorrichtung 18 gespeichert ist, das nächste Mal,
wenn die Mobilvorrichtung 18 mit dem Desktop-Computer 16 verbunden
wird, aktualisiert, so dass beide Fälle desselben Objekts aktuelle
Daten enthalten. Dies wird als Synchronisation bezeichnet.
-
Zur
Erzielung von Synchronisation laufen Synchronisationskomponenten 26 und 28 sowohl
auf der Mobilvorrichtung 18 als auch auf dem Desktop-Computer 18 (oder
einer anderen Mobilvorrichtung 18). Die Synchronisationskomponenten
kommunizieren miteinander durch wohldefinierte Schnittstellen, um
eine Kommunikation und Synchronisation zu erzielen.
-
Die
Mobilvorrichtung 18 ist ebenfalls bevorzugt mit einem Skriptenübersetzer
ausgestatten, welcher in einer bevorzugten Ausführungsform derselbe oder ein ähnlicher
ist wie der ladbare Transport auf dem Desktop-Computer 16.
Ein derartiger Transport kann beispielsweise ein verringerter visueller
Basisübersetzer
sein, welcher das Formatierungsskript empfängt und übersetzt. Das Skript steht
im Zusammenhang mit einer bestimmten Datendatei (typischerweise
einer Textdatei), welche die Rohdaten für den Webinhalt hält. Somit
operiert der Skriptenübersetzer
an den Daten im Zusammenhang mit einem bestimmten Skript zur Bereitstellung des
Webinhalts für
den Benutzer der Mobilvorrichtung 18.
-
Durch
Trennung des Skripts von den Daten im Webinhalt kann Webinhalt an
die Mobilvorrichtung 18 über Kanäle mit sehr langsamer Bitgeschwindigkeit übertragen
werden. Das Skript muss typischerweise nur sehr selten übertragen
werden. Da eine einzelne Datei typischerweise auch viel kleiner
ist als die Skriptdateien, können
die Daten recht häufig
aktualisiert werden, wodurch dem Benutzer der Mobilvorrichtung 18 aktuelle Webinhalts-Informationen
geliefert werden, ohne das neue Skript zu übertragen. Somit erlaubt die
Teilung von Skript und Daten die Übertragung von Webinhalts-Informationen
auf sehr effiziente Weise über
Kanäle
mit geringer Bitgeschwindigkeit.
-
Es
sollte sich verstehen, dass in der bevorzugten Ausführungsform,
während
die Mobilvorrichtung 18 ebenfalls an den Desktop-Computer 16 gekoppelt
werden kann, sie ebenfalls an eine andere Mobilvorrichtung 18 gekoppelt
werden kann. Diese Verbindung kann mit Hilfe einer beliebigen geeigneten
und im Handel erhältlichen
Kommunikationsleitung und mit Hilfe eines geeigneten Kommunikationsprotokolls
erfolgen. Beispielsweise kommuniziert in einer bevorzugten Ausführungsform
die Mobilvorrichtung 18 entweder mit dem Desktop-Computer 16 oder
mit einer anderen Mobilvorrichtung 18 mit einem physikalischen
Kabel, welches mit Hilfe eines seriellen Kommunikationsprotokolls
kommuniziert. Andere Kommunikationsmechanismen werden durch die
vorliegende Erfindung ebenfalls unterstützt, so beispielsweise die
Infrarotkommunikation, oder IR-Kommunikation, oder andere geeignete
Kommunikationsmechanismen.
-
2 ist
ein detaillierteres Blockdiagramm der Mobilvorrichtung 18.
Die Mobilvorrichtung 18 weist bevorzugt den Mikroprozessor 30,
den Speicher 32, Eingabe-/Ausgabe- oder I/O-Komponenten 34,
die Desktop-Kommunikationsschnittstelle 36, den drahtlosen
Empfänger 37 und
die Antenne 39 auf. In einer bevorzugten Ausführungsform
werden diese Komponenten des Mobilteils 10 zur Kommunikation
miteinander über
einen geeigneten Bus 38 gekoppelt.
-
Der
Speicher 32 ist bevorzugt als nichtflüchtiger Elektronikspeicher,
wie beispielsweise ein Direktzugriffs- oder RAM-Speicher mit einem
Batterie-Unterstützungsmodul
(nicht gezeigt) realisiert, so dass Informationen, welche im Speicher 32 gespei chert
sind, nicht verlorengehen, wenn die allgemeine Energieversorgung der
Mobilvorrichtung 18 abgeschaltet wird. Ein Abschnitt des
Speichers 32 ist bevorzugt als adressierbarer Speicher
zur Programmausführung
ausgelegt, während
ein anderer Abschnitt des Speichers 32 bevorzugt zur Speicherung
verwendet wird, wie beispielsweise zur Simulation von Speicherung
auf einem Diskettenlaufwerk.
-
Der
Speicher 32 weist das Betriebssystem 40, ein Anwendungsprogramm 42 (wie
beispielsweise eine persönliche
Informationsverwaltung PIM) sowie einen Objektspeicher 44 auf.
Während
des Betriebs wird das Betriebssystem 40 bevorzugt durch
den Prozessor 30 vom Speicher 32 aus ausgeführt. Das
Betriebssystem 40 ist in einer bevorzugten Ausführungsform
ein Betriebssystem der Marke Windows CE, welches im Handel von der
Microsoft Corporation erhältlich
ist. Das Betriebssystem 40 ist bevorzugt für Mobilvorrichtungen
konstruiert und realisiert Datenbank-Merkmale, welche durch die
PIM 42 durch einen Satz exponierter Anwendungsprogramm-Schnittstellen
und -Verfahren verwendet werden können. Die im Objektspeicher 44 gespeicherten
Objekte werden bevorzugt durch die PIM 42 und das Betriebssystem 40 aufrechterhalten,
und zwar wenigstens teilweise auf Anrufe an die exponierten Anwendungsprogramm-Schnittstellen
und -Verfahren hin.
-
Die
I/O-Komponenten 34 sind in einer bevorzugten Ausführungsform
bereitgestellt, um Eingabe- und Ausgabe-Operationen durch einen
Benutzer der Mobilvorrichtung 18 zu vereinfachen. Die I/O-Komponenten 34 werden
ausführlicher
mit Bezug auf 3 und 4 beschrieben.
-
Die
Desktop-Kommunikationsschnittstelle 36 wird optional als
eine beliebige geeignete Kommunikationsschnittstelle bereitgestellt.
Die Schnittstelle 36 wird bevorzugt zur Kommunikation mit
dem Desktop-Computer 16, dem Inhaltsanbieter 12,
dem drahtlosen Träger 14 und
optional einer weiteren Mobilvorrichtung 18, wie mit Bezug
auf 1 beschrieben, bereitgestellt. Somit weist die
Kommunikationsschnittstelle 36 bevorzugt die Synchro nisationskomponenten 28 zur
Kommunikation mit dem Desktop-Computer 16 und das Modem 24 zur
Kommunikation mit dem Inhaltsanbieter 12 auf. Der drahtlose
Empfänger
und der Treiber 22 werden zur Kommunikation mit dem drahtlosen
Träger 14 verwendet.
-
3 ist
eine vereinfachte piktographische Darstellung einer bevorzugten
Ausführungsform
einer Mobilvorrichtung 10, welche in Übereinstimmung mit der vorliegenden
Erfindung verwendet werden kann. Die Mobilvorrichtung 10,
wie in 3 dargestellt, kann ein Desktop-Assistent sein,
welcher unter der Bezeichnung H/PC mit Software verkauft wird, die
von der Microsoft Corporation bereitgestellt wird. In einer bevorzugten Ausführungsform
weist die Mobilvorrichtung 18 eine Miniatur-Tastatur 43,
die Anzeige 45 und den Griffel 46 auf. In der
in 3 gezeigten Ausführungsform ist die Anzeige 45 eine
Flüssigkristall-
oder LCD-Anzeige,
welche einen kontaktempfindlichen Anzeige-Bildschirm in Verbindung
mit einem Griffel 46 verwendet. Der Griffel 46 wird
dazu verwendet, auf die Anzeige 45 an bestimmten Koordinaten
zu drücken
oder sie zu berühren,
um bestimmte Anwender-Eingabefunktionen zu realisieren. Die Miniatur-Tastatur 43 ist
bevorzugt als alpha-numerische Miniatur-Tastatur mit beliebigen
geeigneten und erwünschten
Funktionstasten realisiert, welche auch zur Erzielung bestimmter
Anwender-Eingabefunktionen bereitgestellt sind.
-
4 ist
eine weitere vereinfachte piktographische Darstellung der Mobilvorrichtung 18 in Übereinstimmung
mit einer weiteren bevorzugten Ausführungsform der vorliegenden
Erfindung. Die Mobilvorrichtung 18, wie in 4 dargestellt,
weist einige Komponenten auf, welche denjenigen mit Bezug auf 3 beschriebenen ähneln und
mit ähnlichen
Bezugszeichen bezeichnet sind. Beispielsweise weist die Mobilvorrichtung 18, wie
in 4 gezeigt, ebenfalls den berührungsempfindlichen Bildschirm 45 auf,
welcher in Verbindung mit dem Griffel 46 verwendet werden
kann, um bestimmte Benutzer-Eingabefunktionen zu erzielen. Es sollte
sich verstehen, dass die Anzeige 45 für die Mobilvorrichtung wie
in 3 und 4 gezeigt dieselbe Größe aufweisen kann oder
unterschiedliche Größen aufweisen
kann, jedoch typischerweise sehr viel kleiner ist als eine herkömmliche
Anzeige, welche bei einem Desktop-Computer verwendet wird. Beispielsweise
können
die in 3 und 4 gezeigten Anzeigen 45 durch
eine Matrix von lediglich 240 × 320
Koordinaten, oder 160 × 160
Koordinaten, oder eine beliebige andere geeignete Größe, definiert
sein.
-
Die
in 4 gezeigte Mobilvorrichtung 18 weist
auch eine Reihe von Benutzer-Eingabetasten oder -knöpfen wie
beispielsweise die Rollknöpfe 47)
auf, welche dem Benutzer ein Rollen durch Menüoptionen oder andere Anzeigeoptionen
erlauben, die auf der Anzeige 45 angezeigt werden, oder
welche dem Benutzer einen Wechsel der Anwendungen erlauben, ohne
die Anzeige 45 zu berühren.
Zusätzlich
weist die in 4 ebenfalls gezeigte Mobilvorrichtung 18 auch
bevorzugt einen Energieknopf 49 auf, welcher zum Ein- und
Ausschalten der allgemeinen Energieversorgung der Mobilvorrichtung 18 verwendet
werden kann.
-
Es
sollte sich auch verstehen, dass in der in 4 gezeigten
Ausführungsform
die Mobilvorrichtung 18 ein Handschriftgebiet 51 aufweist.
Das Handschriftgebiet 51 kann in Verbindung mit dem Griffel 46 derart verwendet
werden, dass der Benutzer Nachrichten verfassen kann, welche im
Speicher 42 für
eine spätere Verwendung
durch die Mobilvorrichtung 18 gespeichert werden. In einer
beispielhaften Ausführungsform
werden die handschriftlichen Nachrichten einfach in handschriftlicher
Form gespeichert und können
durch den Benutzer abgerufen und auf dem Anzeigebildschirm 45 angezeigt
werden, so dass der Benutzer die in die Mobilvorrichtung 18 eingegebenen
handschriftlichen Nachrichten erneut betrachten kann. In einer weiteren
bevorzugten Ausführungsform
verfügt
die Mobilvorrichtung 18 über ein Zeichenerkennungsmodul,
so dass der Benutzer alphanumerische Informationen in die Mobilvorrichtung 18 durch
Schreiben dieser alphanumerischen Informationen auf das Gebiet 51 mit
dem Griffel 46 eingeben kann. In diesem Fall erkennt das
Zeichenerkennungsmodul in der Mobilvorrichtung 18 die alphanumerischen
Zeichen und wandelt die Zeichen in computererkennbare alphanumerische
Zeichen um, welche durch die Anwendungsprogramme 42 in
der Mobilvorrichtung 18 verwendet werden können.
-
5 und
die zugehörige
Beschreibung sollen eine kurze, allgemeine Beschreibung eines geeigneten Desktop-Computers 16 liefern,
in welchem Abschnitte der Erfindung realisiert sein können. Obgleich
dies nicht erforderlich ist, wird die Erfindung mindestens teilweise
in dem allgemeinen Kontext computerausführbarer Befehle, wie beispielsweise
Programmmodulen, beschrieben, welche durch einen Personalcomputer 16 oder eine
Mobilvorrichtung 18 ausgeführt werden. Im Allgemeinen
schließen
Programmmodule Routineprogramme, Objekte, Komponenten, Datenstrukturen
etc. ein, welche bestimmte Aufgaben durchführen oder bestimmte abstrakte
Datentypen implementieren. Darüber
hinaus wird sich für
Fachleute auf dem Gebiet verstehen, dass der Desktop-Computer 16 mit
anderen Computersystem-Konfigurationen realisiert werden kann, einschließlich Multiprozessorsystemen,
mikroprozessorbasierter oder programmierbarer Verbraucherelektronik,
Netzwerk-PCs, Minicomputern, Mainframe-Computern und ähnlichem.
Die Erfindung kann auch in verteilten Rechenumgebungen realisiert
werden, wo Aufgaben durch entfernte Verarbeitungsvorrichtungen durchgeführt werden,
welche durch ein Kommunikationsnetzwerk verbunden sind. In einer
verteilten Rechenumgebung können
Programmmodule sowohl in lokalen als auch in entfernten Speichervorrichtungen
angeordnet sein.
-
Mit
Bezug auf 5 weist ein beispielhaftes System
zur Realisierung eines Desktop-Computers eine Rechenvorrichtung
für allgemeine
Zwecke in Form eines herkömmlichen
Personalcomputers 16 auf, welcher die Verarbeitungseinheit 48,
einen Systemspeicher 50 und einen Systembus 52 einschließt, der
verschiedene Systemkomponenten einschließlich des Systemspeichers 50 an
die Verarbeitungseinheit 48 koppelt. Der Systembus 52 kann
ein beliebiger aus mehreren Arten von Busstrukturen sein, einschließlich eines
Speicherbusses oder einer Speicherregelung, eines Peripheriebusses
und eines lokalen Busses, welcher eine aus einer Vielzahl von Busarchitekturen
verwendet. Der Systemspei cher 50 weist den Nur-Lese-Speicher
(ROM) 54 und einen Direktzugriffspeicher (RAM) 55 auf.
Ein grundlegendes Eingabe-Ausgabe-System (BIOS) 46, welches die
Basisroutine enthält,
die die Informationsübertragung
zwischen Elementen innerhalb des Desktop-Computers 16 unterstütz, wie
beispielsweise während
des Hochfahrens, ist im ROM 54 gespeichert. Der Desktop-Computer 16 weist
weiter ein Festplattenlaufwerk 57 zum Lesen von und Schreiben
auf eine Festplatte (nicht gezeigt), ein Magnetplattenlaufwerk 58 zum
Lesen von oder Schreiben auf eine entnehmbare Magnetplatte 59,
sowie ein optisches Plattenlaufwerk 60 zum Lesen von oder
Schreiben auf eine entnehmbare optische Platte 61, wie
beispielsweise eine CD-ROM oder ein anderes optisches Medium, auf.
Das Festplattenlaufwerk 57, das Magnetplattenlaufwerk 58 und
das optische Plattenlaufwerk 60 sind mit dem Systembus 52 durch
eine Festplattenlaufwerks-Schnittstelle 62, eine Magnetplattenlaufwerks-Schnittstelle 63 bzw.
eine optische Platten-Schnittstelle 64 verbunden. Die Laufwerke
und die zugehörigen
computerlesbaren Medien stellen eine nichtflüchtige Speicherung von computerlesbaren
Befehlen, Datenstrukturen, Programmmodulen und anderen Daten für den Desktopcomputer 16 bereit.
-
Obgleich
die hierin beschriebene beispielhafte Umgebung eine Festplatte,
eine entnehmbare Magnetplatte 59 und eine entnehmbare optische
Platte 61 verwendet, sollte sich für Fachleute verstehen, dass
andere Arten von computerlesbaren Medien, welche Daten speichern
können,
auf die ein Computer zugreifen kann, wie beispielsweise Magnetband-Kassetten,
Fiash-Memory-Karten, digitale Videoplatten (DVDs), Bernoulli-Kassetten,
Direktzugriffspeicher (RAMs), Nur-Lese-Speicher (ROMs) und ähnliches
in der beispielhaften Betriebsumgebung ebenfalls verwendet werden
können.
-
Eine
Reihe von Programmmodulen kann auf der Festplatte, der Magnetplatte 59,
der optischen Platte 61, dem ROM 54 oder dem RAM 55 gespeichert
werden, einschließlich
eines Betriebssystems 65, eines oder mehrerer Anwendungsprogramme 66 (welche
PIMs ein schließen
können),
anderer Programmmodule 67 (welche die Synchronisationskomponente 26 einschließen können) und
Programmdaten 68. Ein Benutzer kann Befehle und Informationen
in den Desktop-Computer 16 durch Eingabevorrichtungen,
wie beispielsweise eine Tastatur 70, eine Zeigevorrichtung 72 und
ein Mikrophon 74 eingeben. Andere Eingabevorrichtungen
(nicht gezeigt) können
einen Joystick, ein Game-Pad, eine Satellitenschüssel, einen Scanner oder ähnliches
einschließen.
Diese und andere Eingabevorrichtungen sind häufig mit der Verarbeitungseinheit 48 durch
eine serielle Schnittstelle 76 verbunden, welche mit dem
Systembus 52 gekoppelt ist, können jedoch durch andere Schnittstellen
verbunden sein, wie beispielsweise eine Soundkarte, einen parallelen
Anschluss, eine Game-Port oder einen universellen Seriellbus (USB).
Ein Monitor 77 oder eine andere Art von Anzeigevorrichtung
ist ebenfalls mit dem Systembus 52 über eine Schnittstelle verbunden,
wie beispielsweise ein Video-Adapter 78.
-
Zusätzlich zu
dem Monitor 77 können
Desktop-Computer typischerweise über
andere periphere Ausgabevorrichtungen verfügen, wie beispielsweise den
Lautsprecher 75 und Drucker.
-
Der
Desktop-Computer 16 kann in einer vernetzten Umgebung unter
Verwendung von logischen Verbindungen mit einem oder mehreren entfernten
Computern (mit Ausnahme der Mobilvorrichtung 18), wie beispielsweise
einem entfernten Computer 79, arbeiten. Der entfernte Computer 79 kann
ein weiterer Personal-Computer sein, weiter ein Server, ein Router,
ein Netzwerk-PC, eine gleichwertige Vorrichtung oder ein anderer
Netzwerkknoten, und weist typischerweise viele oder alle der vorstehend
mit Bezug auf den Desktop-Computer 16 beschriebenen Elemente
auf, obgleich nur eine Speicherungsvorrichtung 80 in 4 dargestellt
ist. Die in 4 aufgezeigten logischen Verbindungen
umfassen ein lokales Netzwerk (LAN) 81 und ein globales
Netzwerk (WAN) 82. Derartige Netzwerkverbindungen sind
in Büros,
unternehmensweiten Computernetzwerk-Intranetzen sowie dem Internet
allgemein üblich.
-
Bei
der Verwendung in einer LAN-vernetzen Umgebung ist der Desktop-Computer 16 mit
dem lokalen Netzwerk 81 durch eine Netzwerkschnittstelle
oder einen Adapter 83 verbunden. Bei der Verwendung in
einer WAN-vernetzten Umgebung weist der Desktop-Computer 16 typischerweise
ein Modem 84 oder eine andere Einrichtung zur Herstellung
von Kommunikationen über
das globale Netzwerk 82, wie beispielsweise das Internet,
auf. Das Modem 84, welches intern oder extern sein kann,
ist mit dem Systembus 52 über die serielle Anschlussschnittstelle 76 verbunden.
In einer Netzwerkumgebung können
Programmmodule, welche mit Bezug zum Desktop-Computer 16 dargestellt sind,
oder Abschnitte davon, in den entfernten Speicherungsvorrichtungen
gespeichert sein. Es sollte sich verstehen, dass die gezeigten Netzwerkverbindungen
beispielhaft sind und andere Einrichtungen zur Herstellung einer
Kommunikationsverbindung zwischen den Computern verwendet werden
können.
-
Auf
dem Desktop-Computer 16 läuft das Betriebssystem 65,
welches typischerweise in dem nichtflüchtigen Speicher 54 gespeichert
ist und auf dem Prozessor 48 ausgeführt wird. Ein geeignetes Betriebssystem
ist ein Betriebssystem der Marke Windows, welches durch die Microsoft
Corporation vertrieben wird, wie beispielsweise ein Windows95- oder
WindowsNT-Betriebssystem, andere abgeleitete Versionen von Betriebssystemen
der Marke Windows, oder ein beliebiges anderes geeignetes Betriebssystem.
Andere geeignete Betriebssysteme umfassen Systeme wie beispielsweise
Macintosh OS, welches durch die Apple Corporation vertrieben wird,
und den OS/2 Presentation Manager, welcher durch International Business
Machines (IBM) aus Armonk, New York, vertrieben wird. Anwendungsprogramme
sind bevorzugt im Programmmodul 67, in einem flüchtigen
oder nicht flüchtigen
Speicher, gespeichert, oder können
in eine beliebige der in 5 gezeigten Komponenten von
einer Floppy-Diskette 59, einem CD-ROM-Laufwerk 61 geladen,
aus einem Netzwerk über den
Netzwerkadapter 83 heruntergeladen oder mit Hilfe eines
anderen geeigneten Mechanismus geladen werden.
-
Eine
dynamisch verbundene Bibliothek (dynamically linked library, DLL),
welche eine Vielzahl ausführbarer
Funktionen aufweist, steht mit PIMs in dem Speicher zur Ausführung durch
den Prozessor 48 in Zusammenhang. Interprozessor- und Interkomponentenrufe
werden durch Verwendung des Komponenten-Objekt-Modells (component
object model, COM) vereinfacht, wie es in Programmen allgemein üblich ist,
welche für
Betriebssysteme der Marke Microsoft Windows verfasst wurden. Bei
Verwendung des COM weist kurz gesagt eine Software-Komponente, wie
beispielsweise eine DLL, eine Vielzahl derartiger Schnittstellen
auf. Jede Schnittstelle legt eine Vielzahl von Verfahren offen,
welche einzeln aufgerufen werden können, um unterschiedliche Dienste
zu verwenden, welche durch die Software-Komponente angeboten werden.
Zusätzlich werden
Schnittstellen bereitgestellt, so dass Verfahren oder Funktionen
von anderen Software-Komponenten abgerufen werden können, welche
optional eines oder mehrere Parameterargumente empfangen und zurücksenden.
-
Im
allgemeinen ist die mit dem bestimmten PIM in Zusammenhang sthende
DLL speziell darauf ausgelegt, in Verbindung mit diesem PIM zu arbeiten
und Desktop-Synchronisationsschnittstellen freizulegen, welche wie
vorstehend beschrieben funktionieren, und zwar gemäß einem
Synchronisationsprotokoll. Die DLL ruft wiederum Schnittstellen
auf, welche durch den PIM freigelegt werden, um auf Daten zuzugreifen,
welche individuelle Eigenschaften von Objekten darstellen, die in
einem Objektspeicher gehalten werden. Der Objektspeicher 6 kann
selbstverständlich
in einer beliebigen der geeigneten Speicherkomponenten angeordnet
sein, welche mit Bezug auf 4 beschrieben
sind.
-
ARCHITEKTUR-BLOCKDIAGRAMM
-
6 ist
ein Blockdiagramm, welches die funktionale Architektur der Mobilvorrichtung 18 darstellt. 6 zeigt ähnliche
Punkte wie diejenigen, die vorab in der Beschreibung gezeigt wurden. Ähnliche
Komponenten sind ähnlich
bezeichnet. 6 veranschaulicht, dass die
Mobilvorrichtung 18 Webinhaltsinforma tionen entweder über die
Synchronisationskomponente 26, den drahtlosen Empfänger (Funkempfänger und
Treiber) 22 oder das Modem 24 empfängt. In
jedem dieser Fälle
werden die CDF-Dateien sowie die Skriptenmuster und Datendateien,
welche durch die Blöcke 202 und 204 dargestellt
sind, schließlich
an den Cache-Speicher 206 geliefert.
An der Stelle, an welcher die Webinhaltsinformationen durch die
Synchronisationskomponente 26 empfangen werden, werden
die Skriptenmuster und Datendatein möglicherweise nicht verschlüsselt oder codiert
oder anderweitig auf dieselbe Weise formatiert wie es für die Übertragung über einen
drahtlosen Kanal oder Modemkanal der Fall ist. Daher werden die
Skriptenmuster 204 und Datendateien 202 direkt
an die Cache-Verwaltung 208 geliefert. Die Cache-Verwaltung 208 empfängt die
Skriptenmuster und Datendateien und liefert sie an den Cache-Speicher 206.
Die Cache-Verwaltung 208 weist Speicherhandhabung und Zeitgebungskomponenten
sowie Datenübertragungskomponenten
auf, welche zur Übertragung
der Skriptenmuster und Datendateien an eine bestimmte Position im
Cache-Speicher 206 und zur Nachspürung dieser Position geeignet
sind.
-
Wenn
andererseits der Webinhalt über
den drahtlosen Empfänger
und Treiber 22 oder das Modem 24 empfangen wird,
müssen
zusätzliche
Verarbeitungsschritte unternommen werden, ehe die Daten in den Cache-Speicher
gelangen. Der drahtlose Empfänger
und Treiber 22 ist eine physikalische Schicht, welche Nachrichten
empfängt
und filtert und Aufweck-Ereignisse an die Mobilvorrichtung 18 erzeugt.
In einer bevorzugten Ausführungsform
wird, wie später
mit Bezug auf 8 beschrieben, die übertragene
Information zunächst übersetzt
(wie beispielsweise komprimiert, verschlüsselt, codiert und verpackt),
ehe sie übertragen
wird. Somit müssen
die Daten zurück
in ihre ursprüngliche
Form übersetzt
werden, ehe sie durch die Mobilvorrichtung 18 weiter verwendet
werden. Daher werden die Daten zunächst an den Nachrichten-Router 210 geliefert.
Der Nachrichten-Router 210 fungiert zur Speicherung der
Nachricht und zum Routing der empfangenen Nachricht an eine Übersetzungsschicht 209.
In 6 weist die Übersetzungsschicht 209 die
Auspack- und Füge-Komponente 212,
eine Gruppe zusätzlicher Übersetzter,
welche kollektiv mit 214 bezeichnet sind, und eine weitere Routing-Komponente 216 auf.
-
Der
Auspack- und Fügeblock 212 fungiert
zum Empfang, Auspacken und Ordnen einer übertragenen Gruppe von Paketen.
Der Auspacker fügt
Pakete einer beliebigen langen Nachricht wieder zusammen, welche durch
den drahtlosen Träger 15 aufgespalten
wurden. Die geordneten Daten werden an die Übersetzungskomponenten 214 geliefert.
-
Die Übersetzungskomponenten 214 fungieren
zur Neuformatierung oder Übersetzung
der Daten in eine geeignete Form zur Handhabung durch den Inhaltshandhaber 216.
Beispielsweise können,
wenn die Pakete, welche eine Nachricht aufweisen, ausgepackt und
durch den Auspacker und Füger 212 erneut
zusammengefügt
wurde, die Übersetzungskomponenten 214 typischerweise
diese Pakete dekomprimieren, entschlüsseln und decodieren.
-
Der
Inhaltshandhaber 216 liefert die ausgepackte, zusammengefügte und übersetzte
Nachricht an das geeignete registrierte Ziel (d.h. an die geeignete
Anwendung oder einen anderen funktionalen Block) auf der Mobilvorrichtung 18.
In der in 5 dargestellten Ausführungsform
liefert der Inhaltshandhaber 216 die Informationen an die
Cache-Verwaltung 208, welche sie im Cache 206 speichert.
-
Wenn
der Anwender Off-Line den im Cache 206 gespeicherten Webinhalt
browsen möchte,
startet der Anwender ein geeignetes Anwendungsprogramm, welches
durch den Kanal-Browser-Block 218 in 5 angezeigt
wird. Der Kanal-Browser 218 erzeugt bevorzugt geeignete
Anwenderschnittstellen auf der Anzeige 45, welche dem Anwender
die Fähigkeit
liefern, einen bestimmten zu betrachtenden Kanal zu wählen.
-
Der
Kanal-Browser 218 ist darauf ausgelegt, mit einem ladbaren
Transport 220 zu interagieren, welcher wiederum mit der
Cache-Verwaltung 208 gekoppelt
ist. Auf die Anfrage des Anwenders hin, die über den gewählten Kanal bereitgestellten
Informationen zu sichten, fordert der ladbare Transport 220 die
Cache-Verwaltung 208 auf, die entsprechenden Webinhaltsinformationen
(in Form von Skriptenmustern und Datendateien) aus dem Cache 206 abzurufen.
Die erwünschten
Skriptenmuster 204 und Datendateien 202 werden
von der Cache-Verwaltung 208 an den ladbaren Transport 220 bereitgestellt.
-
Der
Skriptenübersetzer
im Transport 220 ist bevorzugt ein visueller Basisskriptenübersetzer,
welcher Skriptenmuster 204 übersetzt und die Datendateien 204 manipuliert,
um eine erwünschte
Wiedergabe des Webinhalts bereitzustellen. In der in 5 dargestellten
Ausführungsform
wird der Webinhalt als herkömmliche
Hypertext-Markup-Language-Seite (HTML-Seite) 224 wiedergegeben.
Der ladbare Transport 220 liefert dann die HTML-Seiten-Wiedergabe
an den Kanal-Browser 218 für die Sichtung durch den Anwender
der Mobilvorrichtung 18 auf der Anzeige 45.
-
INFORMATIONS-LOGGING
-
Ein
Aspekt der vorliegenden Erfindung ermöglicht das Logging der erwünschten
Informationen zur Verwendung durch den Inhaltslieferanten 12.
Anders gesagt, können
die Inhaltslieferanten durch Bereitstellung eines Eintrags in der
CDF-Datei bestimmte Punkte markieren, welche sie nachspüren möchten (d.h.
sie können
bestimmte Punkte markieren, für
welche sie wissen möchten,
wann und für
wie lange diese Punkte durch irgend einen bestimmten Anwender gesichtet
wurden). Die vorliegende Erfindung realisiert diese Funktion.
-
Wenn
der Anwender beispielsweise den Kanalbrowser 218 startet
und Informationen von dem ladbaren Transport 220 anfordert,
bestimmt der ladbare Transport 220, ob die angeforderten
Informationen das entsprechende CDF-Tag einschließen, welches
anzeigt, dass der Inhaltslieferant die Informationen bezüglich der Zeit
und Dauer loggen möchte,
für welche
die Informationen gesichtet wurden. Ist dies der Fall, so loggt
der ladbare Trans- Port 220 Informationen,
welche die Zeit und Dauer darstellen, für welche die Informationen durch
den Anwender gesichtet wurden. Diese Informationen werden im Cache 206 in
einer Position gespeichert, welche dieser bestimmten Webinhaltsinformation
entspricht.
-
Das
nächste
Mal, wenn die Mobilvorrichtung 18 mit dem Desktop-Computer 16 synchronisiert
wird, wird nicht nur die Mobilvorrichtung 18 mit dem aktuellen
durch den Desktop-Computer 16 empfangenen Webinhalt aktualisiert,
sondern der Desktop-Computer 16 wird mit den aktuellen
durch die Mobilvorrichtung 18 gehaltenen Logging-Informationen
aktualisiert. Auf ähnliche
Weise werden das nächste
Mal, wenn der Browser auf dem Desktop-Computer 16 auf den
entsprechenden Webinhalt vom Inhaltslieferanten 12 zugreift,
die Logging-Informationen vom Desktop-Computer 16 zum Inhaltslieferanten 12 übertragen.
In einer bevorzugten Ausführungsform
werden, da der Browser auf dem Desktop-Computer 16 der
Internet Explorer 4.0 ist, Logging-Informationen, welche auf den
Desktop-Computer 16 synchronisiert wurden, zum Inhaltslieferanten 12 übertragen,
wenn der Zeitgeber des Internet Explorer 4.0 das nächste Mal
auf dem Desktop-Computer 16 aufgerufen wird.
-
DATENSTRUKTUR UND FILTERUNG
-
7 stellt
eine Ausführungsform
eines Pakets von Webinhaltsdaten an, welche durch den Funkempfänger und
Treiber 10 empfangen wurden. Der Funkempfänger kann
bevorzugt Nachrichten in im Wesentlichen jedem beliebigen Format
empfangen. Zahlreiche unterschiedliche Arten von Anfangsblock-Formaten können für den Empfang
durch Funk definiert sein. 7 zeigt
nur eine beispielhafte Art von Paketformat an.
-
Das
Paket 230 weist bevorzugt eine Vielzahl von Abschnitten
auf, wie beispielsweise den Funktransport-Anfangsblock 232,
die Gruppen- und Themen-Filterungs-Bytes 234, den Routing-Anfangsblock 236 und die
Daten 238. Der Funktransport-Anfangsblock 232 weist
bevorzugt Adresseninformationen auf. Die Adresseninformationen stellen
eine Identifikation dar, welche verwendet wird, um eine Funknachricht
an den Funkempfänger 22 (oder
eine beliebige andere Art von Funkkarte) zu senden. Beispielsweise
weist in einem handelsüblich
erhältlichen
Paging-Übertragungsprotokoll
die Adresseninformation im Funktransport-Anfangsblock 232 einen
Capcode auf. Der Capcode bezieht sich auf eine Speicherposition
auf der physikalischen Hardware-Funkkartenvorrichtung 22,
welche Addressierungsinformationen speichert. Der Funktransport-Anfangsblock 232 unterstützt in einer
bevorzugten Ausführungsform
sechzehn unterschiedliche Adressen. Der Funkempfänger und Treiber 22 filtert
und verwirft jegliche Nachrichten, welche nicht zu irgend einer
der Adressen passen. Wird eine Übereinstimmung
beobachtet, so hat der Funkempfänger 22 eine
Nachricht erfasst, welche potentiell an ihn adressiert ist, und
muss die Nachricht empfangen und weiter verarbeiten. Die Nachricht
wird dann an den Nachrichten-Router 210 weitergeleitet,
welcher in Verbindung mit der Übersetzungsschicht 209 bestimmt,
welche Komponenten auf der Mobilvorrichtung 18 zur Verarbeitung
der Nachricht nötig
sind.
-
Gruppen-
und Themen-Filterbytes 234 sind ebenfalls bevorzugt bereitgestelt.
Eine Gruppe gemäß Bezeichnung
hierin ist eine Unterklasse einer Adresse, welche in Übereinstimmung
mit der vorliegenden Erfindung verwendet wird, um die Filterungskapazität einer
Adresse auszuweiten. Weiter ist ein Thema eine Unterklasse einer
Gruppe, welche ebenfalls bereitgestellt ist um die Filterungskapazität der Adressen-
und Gruppeninformation auszuweiten.
-
Es
sollte sich verstehen, dass Nachrichten, welche am Funkempfänger und
Treiber 22 mit einer entsprechenden Adresse eintreffen,
möglicherweise
keine Gruppen- und Themen-Filterungsbytes 234 aufweisen, welche
hieran im Voraus angehängt
wurden. Falls diese Bytes jedoch vorhanden sind, fungiert der Funkempfänger und
Treiber 22 zur Filterung der Nachricht basierend auf den
Gruppen- und Themen-Filterungsbytes.
-
Der
Treiber im Funkempfänger
und Treiber 22 realisiert eine Logik, welche zunächst das
Paket 230 überprüft, um zu
bestimmen, ob irgendwelche Gruppen- und Themen-Filterungsbytes 234 im
Paket 230 eingeschlossen sind. In einer bevorzugten Ausführungsform
unterstützt
der Treiber im Funkempfänger
und Treiber 22 eine Bibliothek, welche eine Funktion AnalyzeMessage()
umfasst. Die AnalyzeMessage-Funktion isoliert Dienstgruppen-Codes
und andere Informationen in der eingehenden Nachricht. Falls Gruppen-
und Themen-Filterungsbytes vorhanden sind, müssen die Gruppen- und Themen-Filterungsfunktionen
durchgeführt werden.
-
In
der bevorzugten Ausführungsform
weist die Mobilvorrichtung 18 einen Speicher auf, welcher
eine Gruppentabelle enthält,
wie sie ausführlicher
in den vorstehenden Anwendungen beschrieben ist. Kurz gesagt, enthält die Gruppentabelle
Einträge
von Dienstgruppen, von welchen jede mit jeder beliebigen geeigneten Adresse
in Zusammenhang gebracht werden kann. Auch kann bevorzugt jede beliebige
geeignete Anzahl von Dienstgruppen vorhanden sein, welche mit einer
Adresse im Zusammenhang stehen. Somit werden in der bevorzugten
Ausführungsform
Gruppeneinträge
in der Gruppentabelle durch Adressennummern sortiert, dann durch
Dienstgruppen-Codes. Der Inhalt einer bevorzugten Ausführungsform
der Gruppentabelle ist ausführlicher
in der vorstehend angeführten
Anwendung dargelegt.
-
Falls
Gruppen- oder Themen-Filterungsbytes erfasst werden, durchsucht
der Treiber im Funkempfänger
und Treiber 22 die Gruppentabelle, um zu bestimmen, ob
der im Paket 230 erfasste Dienstgruppencode in der Gruppentabelle
aufgelistet ist, und ob er aktiv oder inaktiv ist. Falls der Dienstgruppencode
in der Tabelle nicht gefunden wird, oder falls er gefunden wird,
aber deaktiviert (oder ausgeschaltet) wurde, verwirft der Treiber 22 die
Nachricht, und keine weitere Verarbeitung erfolgt mit Bezug auf
diese Nachricht. Falls der Treiber 22 jedoch bestimmt,
dass die Gruppen- und Themen-Filterungsbytes 234 in der
Gruppentabelle eingeschlossen sind, so wird bestimmt, dass die Nachricht
für diese
bestimmte Mobilvorrichtung 18 gedacht war, und die weitere
Verarbeitung fährt
fort.
-
Da
die gesamte Gruppen- und Themen-Filterung auf dem Niveau des Treibers 22 erfolgt,
erscheint. sie relativ weit unten im Protokollstapel, oder der Systemarchitektur,
der Mobilvorrichtung 18. Somit findet die Filterung früh in dem
Prozess statt, und der für
die Adresse und Nachricht erforderliche Speicherplatz ist relativ gering.
Zusätzlich
erlauben es, da der Treiber selbst viel von dieser Filterung vornimmt,
die Gruppen- und Themen-Filterungsbytes 234 jeder beliebigen
auf der Mobilvorrichtung 18 laufenden Anwendung, korrekte
Filterungsinformationen nach unten an die Gruppen- und Thementabellen
für eine
Filterung auf dem Niveau des Treibers 22 weiterzuleiten.
Dies verbessert den Energieverbrauch gegenüber früheren Konstruktionen signifikant,
da die Nachrichten nicht empfangen, verarbeitet und den ganzen Weg
hinauf zum Anwendungsniveau im Protokollstapel, oder der Architektur,
der Mobilvorrichtung 18 weitergeleitet werden müssen, ehe
sie gefiltert werden.
-
UBERTRAGUNGS- UND UBERSETZUNGS-ARCHITEKTUR
-
8 ist
ein ausführlicheres
Blockdiagramm, welches die Übertragung
von Datenpaketen von der drahtlosen Schubserverkomponente (WPS-Komponente) 20 an
die Mobilvorrichtung 18 darstellt. Der drahtlose Schubserver 20 weist
bevorzugt den Webinhalts-Cache 250,
den Zeitgeber 252, die Übersetzungsschicht 254,
die Verpackungsvorrichtung 256 und den Funksender 258 auf.
Die Übersetzungsschicht 254 weist
bevorzugt eine beliebige geeignete und erwünschte Anzahl von Übersetzern
auf. Die Übersetzer
werden bevorzugt verwendet, um an dem Webinhalt zu arbeiten (z.B.
an den Datendateien, den Skriptendateien und den CDF-Dateien) und
den Inhalt in einer erwünschten
Form der Verpackungsvorrichtung 256 des Funksenders 258 zur Übertragung
an die Mobilvorrichtung 18 zu liefern. In der in 8 gezeigten
Ausführungsform
weist die Übersetzungsschicht 254 die
Komprimierungsvorrichtung 260, die Verschlüsselungsvorrichtung 262 und die
Codierungsvorrichtung 264 auf.
-
8 zeigt
ebenfalls einen Abschnitt der Mobilvorrichtung 18 detaillierter. Ähnliche
Elemente sind ähnlich
den in 6 gezeigten bezeichnet. Jedoch stellt 8 eine Übersetzungsschicht 209 detaillierter
dar. Die Übersetzungsschicht 209 weist
bevorzugt eine erwünschte
Anzahl und Art von Übersetzern
auf, welche zur Umkehrung der in der Übersetzungsschicht 254 auf
dem WPS 20 durchgeführten Übersetzung
fungieren. Somit weist die in 8 gezeigte
Ausführungsform
die Auspackvorrichtung 212, die Decodiervorrichtung 266, die
Verschlüsselungsvorrichtung 268 und
die Dekomprimierungsvorrichtung 270 auf.
-
Im
Betrieb greift die Zeitgebungsvorrichtung 252 periodisch
auf den Webinhalts-Cache 250 zu, um Aktualisierungen oder
zusätzlichen
Webinhalt an die Mobilvorrichtung 18 zu liefern. Diese
Informationen werden zunächst
an die Übersetzungsschicht 254 geliefert.
Jede Übersetzungsvorrichtung
in der Übersetzungsschicht 254 führt bevorzugt
die Übersetzungsoperation
an den eingehenden Daten durch und stellt einen Identifikator an
die Datenausgabe ab, wie beispielsweise einen Anfangsblock oder
ein Tag, um dadurch die Art der durchgeführten Übersetzung anzuzeigen. Zum
Beispiel wird in der bevorzugten Ausführungsform ein Abschnitt des Webi nhalts,
welcher aus dem Webinhalts-Cache 250 durch die Zeitgebungsvorrichtung 252 extrahiert
(und für die Übersetzungsschicht 254 durch
die Zeitgebungsvorrichtung 252 vorbereitet) wurde, zunächst an
die Kompressionsvorrichtung 260 geliefert. Die Kompressionsvorrichtung 260 komprimiert
den dadurch empfangenen Informationsblock und stellt einen Anfangsblock
von vier Byte ab, um das Kompressionsschema zu identifizieren, welches
zur Komprimierung der Daten verwendet wurde. Die Kompression erfolgt
bevorzugt vor der Verschlüsselung,
da reiner Text typischerweise eine bessere Komprimierung liefert
als verschlüsselter
Text.
-
Die
Verschlüsselungsvorrichtung 262 empfängt die
komprimierten Daten von der Kompressionsvorrichtung 260 und
verschlüsselt
die Ausgabe der Kompressionsvorrichtung 260 und stellt
ebenfalls einen Anfangsblock von vier Byte ab, um das Verschlüsselungsschema
zu identifizieren, welches zur Verschlüsselung der Daten verwendet
wurde. Die Verschlüsselungsvorrichtung 262 liefert
dann verschlüsselte
Daten an die Codierungsvorrichtung 264.
-
Die
Codierungsvorrichtung 264 codiert die Ausgabe der Verschlüsselungsvorrichtung 262,
um den Datenstrom in einen Strom umzuwandeln, welcher aus Zeichen
besteht, die für
die Übertragung über das
gewählte
drahtlose Medium geeignet sind. Dort, wo beispielsweise das drahtlose
Medium ein herkömmlicher
Paging-Kanal ist, codiert die Codierungsvorrichtung 264 die
Daten in einen Strom, welcher lediglich aus druckbaren ASCII-Zeichen
besteht, so dass er über
die drahtlose Leitung übertragen
werden kann. Die Codierunsvorrichtung 264 fügt ebenfalls
einen Anfangsblock von vier Byte an die Daten an, um das spezielle
Codierungsschema zu identifizieren, welches zur Codierung der Daten
verwendet wurde.
-
Wie
vorstehend ausführlicher
beschrieben, spaltet die Packvorrichtung 256 die Ausgabe
der Codierungsvorrichtung 264 in kleinere Pakete auf, welche
für die Übertragung über die
drahtlose Leitung geeignet sind. Die Packvorrichtung 256 fügt einen
Anfangsblock vor das Datenpaket an, so dass die Pakete eindeutig durch
den Empfänger
der Information identifiziert werden können. Wenn die Daten, welche
in die Übersetzungsschicht 254 eingegeben
werden, beispielsweise zunächst
komprimiert, dann verschlüsselt,
dann codiert werden, kann die Ausgabe der Codierungsvorrichtung
264 dargestellt werden durch:
(Codierungsschema, [CodierungsID
{KompressionsID, Daten}]).
-
Somit
verwendet die Packvorrichtung die vorstehenden Daten und erzeugt
Pakete im Allgemeinen in der in 7 gezeigten
Form, welche dargestellt wird durch:
{Hdr, Daten}, {Hdr, Daten}...[Hdr,
Daten]
-
Die
Packvorrichtung 256 (welche auch als Übersetzungsvorrichtung betrachtet
werden kann) liefert die Daten und Anfangsblöcke an den Funksender 258,
welcher die Daten an den Funkempfänger und Treiber 22 liefert.
Insbesondere bricht die Packvorrichtung 256 Eingangsdaten
vom Inhaltslieferanten 12 in eine Reihe von Paketen mit
einer Größe von zwischen
ca. 128 bis 500 Bytes in Abhängigkeit
von dem bestimmten Träger auf.
Jedes Paket wird an einen Paging-Gateway (z.B. den Funksender 258),
beispielsweise über
das Internet, E-Mail, einen drahtlosen Träger oder über ein Modem gesendet. Pakete
können
in einer beliebigen Reihenfolge den Pager-Kanal hinunter gesendet
werden.
-
In
einer bevorzugten Ausführungsform
enthält
jeder Speicher oder jedes Paket 11 bis 23 Byte von Paket-Anfangsblockinformationen
und N Byte an Paket-Dateninformationen, im Allgemeinen in Form des
in 7 dargestellten Pakets 230. Der Funktransport-Anfangsblock in den
Paket-Anfangsblockinformationen weist bevorzugt eine IP-Adresse,
eine Reihenfolgenummer, eine Paketnummer und eine Reihe optionaler
Anfangsblöcke
(z.B. Gruppen- und Themen-Filterungsbytes 234 und den Routing-Anfangsblock 236)
auf.
-
Die
IP-Adresse ist die Adresse des Dienstanbieters. Die Reihenfolgenummer
liefert eine bestimmte Reihenfolgenummer für einen übertragenen Paketstrom. Die
IP-Adresse und die Reihenfolgenummer (in Kombination) liefern eine
eindeutige Identifikation an den Paketstrom und erlauben es einem
Empfänger,
wie beispielsweise der Mobilvorrichtung 18, eine Vielzahl
von Paketströmen
zusammenzusetzen, welche in Multiplexweise eintreffen.
-
Der
Funkempfänger
und Treiber 22 filtert die Daten, wie vorstehend beschrieben,
und liefert zu empfangende Daten an den Router 210. Der
Router 210 überprüft die Anfangsblockinformationen
an jedem Paket. Die Anfangsblockinformationen liefern dem Router 210 eine
Anzeige darüber,
welche Übersetzungsvorrichtung
auf gerufen werden muss, um an den Daten zu arbeiten. In der in 8 gezeigten
Ausführungsform
sind die Übersetzungsvorrichtungen 212, 266, 268 und 270 einfach
in umgekehrter Reihenfolge als Übersetzungsvorrichtungen 256, 260, 262 und 264 bereitgestellt.
Der Router hält
eine Tabelle aller verfügbaren Übersetzungsvorrichtungen
mit Bezug auf die dynamisch verbundenen Bibliotheken DLL dieser Übersetzungsvorrichtungen
aufrecht. Der Anfangsblock oder Tag mit vier Byte wird zur Lokalisierung
der geeigneten Übersetzungsvorrichtung
verwendet. Die Übersetzungsvorrichtung
ist verantwortlich für
die Entfernung dieses Tag und die Versendung oder Rücksendung
der übersetzten
Daten.
-
Die
meisten der Übersetzungsvorrichtungen
sind Teil einer Kette von Übersetzungsvorrichtungen,
in welcher die Ausgabe der Übersetzungsvorrichtung
in eine weitere Übersetzungsvorrichtung
eingegeben werden kann. Dies liefert Flexibilität an den Inhaltslieferanten,
da sie die Reihenfolge der Übersetzungsvorrichtungen
an ihre Bedürfnisse
und bestimmte Daten anpassen können.
Jedoch können
auch Übersetzungsvorrichtungen
bereitgestellt werden, welche die Eingabe in dem Sinn konsumieren,
dass sie die Ausgaben anderswo in dem System platzieren und dadurch
die Übersetzungskette
anhalten.
-
Der
Router fährt
mit der Anwendung von Übersetzungsvorrichtungen
fort, bis der Artikel durch eine der Terminations-Übersetzungsvorrichtungen
konsumiert wird. In einer bevorzugten Ausführungsform werden, wenn keine
verbleibenden Tags oder Anfangsblöcke gefunden werden und der
Artikel noch immer nicht konsumiert wird, die Daten an die E-Mail-Eingangsbox 272 weitergeleitet.
-
Somit
erhält
der Router 210 ein erstes Datenpaket, liefert es an die
Auspackvorrichtung 212 und empfängt die ausgepackten und zusammengefügten Daten
von der Auspackvorrichtung 212 zurück. Die Auspack- und Fügevorrichtung 212 speichert
alle empfangenen Pakete und fügt
sie zusammen. Sie kann Pakete ohne Rücksicht auf die Reihenfolge
empfangen, kann eine Vielzahl von Strömen (von unterschiedlichen
Inhaltslieferanten oder demselben Inhaltslie feranten) empfangen.
Zusammenfassend lässt
sich sagen, dass die Auspackvorrichtung 212 ein einfaches
Dateisystem realisiert, in welchem eine Datei die vollständigen Daten
enthält,
welche gesendet wurden, ehe die Paketisierung erfolgt.
-
Der
Dateiname wird aus der IP-Adresse gebildet, welche diejenige des
Dienstanbieters ist, und zwar zusammen mit der Reihenfolgenummer,
welche zusätzlich
zur Anzeige eines Paketstrom-Reihenfolgemitglieds anzeigt, ob dieses
bestimmte Paket das letzte Paket in einer übertragenen Sequenz ist. Die
Pakete werden empfangen und in einer geordneten, verlinkten Liste
durch die Auspack- und Fügevorrichtung 212 gespeichert.
-
Der
Funkempfänger
und Treiber 22 empfängt
und puffert eine vollständige
Seite von Informationen. Er leitet diese Seite dann an den Nachrichtenrouter 210,
welcher die Seite in eine Datei schreibt. Der Router 210 ruft
dann die Auspack- und Fügevorrichtung 212 an.
Das Paket wird an eine Datei angehängt, deren Name aus der IP-Adresse
und Reihenfolgenummern-Kombination abgeleitet ist, welche in dem
bestimmten Paket enthalten ist. Falls die Datei noch nicht existiert,
wird sie durch die Auspackvorrichtung 212 neu erzeugt.
-
Wenn
das Paket, welches als letztes Paket markiert ist, empfangen wird,
weiß die
Auspackvorrichtung 212, wie viele Pakete sie zu erwarten
hat. Es versteht sich, dass das letzte Paket nicht zeitlich als
letztes eintreffen muss. Die Auspackvorrichtung 212 zählt die
Anzahl der bereits empfangenen Pakete und speichert die Anzahl der
Pakete, welche sie erwartet, in einem Zähler. Jedes Mal, wenn ein nicht
doppeltes Paket angefügt wird,
wird der Zähler
um eins herabgesetzt. Fällt
er auf null, so wurden alle Pakete empfangen. Die Auspackvorrichtung 212 durchläuft dann
die Indexdatei, welche sie erzeugt hat, und welche einen Zeitstempel
enthält, der
die Reihenfolge der empfangenen Pakete anzeigt. Die Auspackvorrichtung
erzeugt eine Datendatei in der korrekten Reihenfolge und leitet
die Datendatei zur weiteren Verarbeitung weiter.
-
Sobald
alle Pakete eingetroffen sind, wird die Datendatei, welche die geordnete
verlinkte Liste enthält, aus
dem Dateisystem in der Auspackvorrichtung 212 entfernt
und wird entweder an zusätzliche Übersetzungsvorrichtungen
in der Übersetzungsschicht 209 oder
zurück
an den Router 210 geleitet.
-
Um
mit verlorenen, doppelten und falschen Paketen zurechtzukommen,
wird ein Prüfummen-Fehlererfassungs-Verfahren,
welches das zyklische Zufallscode-32-Verfahren (CRC-32-Verfahren)
verwendet, über die
gesamte Datei von Datenbytes implementiert (d.h. es schließt alle
Anfangsblock-Bytes aus).
-
Zur
Erfassung verlorener Pakete wird der Zeitstempel des letzten in
der Indexdatei empfangenen Pakets gespeichert. Die Auspackvorrichtung 212 überprüft diesen
Zeitstempel jedes Mal dann, wenn sie ein Paket für die momentane Datendatei
oder für
eine beliebige andere Datendatei verarbeitet. Falls der Zeitunterschied
zwischen einer momentanen Zeit und der Zeit des letzten empfangenen
Pakets über
einer erwünschten Anzahl
von Minuten (oder einem beliebigen anderen geeigneten Zeitintervall)
liegt, wird angenommen, dass jegliche verbleibenden Pakete für die. Datendatei
verloren sind, und die Datendatei wird gelöscht.
-
Doppelte
Pakete werden durch Bezugnahme auf die Indexdatei erfasst, welche
bereits einen initialisierten Eintrag für dieses Paket enthalten wird.
Zwei Optionen können
bei der Handhabung doppelter Pakete realisiert werden. Erstens kann
das neue Paket verworfen werden, und das alte kann erhalten werden.
Zweitens kann das neue Paket an die Datendatei durch Überschreibendes
Indexeintrags für
das erste (oder alte) Paket angehängt werden. Dies wird die Auswirkung
der Verwerfung des alten Pakets haben.
-
In
jedem Fall überprüft zum Abschluss
des in 8 bereitgestellten Beispiels der Router 210,
wenn die Pakete ausgepackt und zusammengefügt wurden, die Anfangsblöcke an den
Daten, um herauszufinden, dass die Daten zunächst an die Decodiervorrich tung 266 geliefert
werden müssen.
Die Decodiervorrichtung 266 decodiert die Daten und liefert
sie zurück
an den Router 210. Der nächste Anfangsblock an den Daten
wird durch den Router 210 überprüft und zeigt an, dass die Daten
an die Entschlüsselungsvorrichtung 268 geliefert werden
müssen.
Die Entschlüsselungvorrichtung 268 entschlüsselt die
Daten und sendet sie dann zum Router 210 zurück. Der
Router 210 liefert die Daten dann an die Dekompressionsvorrichtung 270,
und zwar basierend auf den Anfangsblockinformationen, welche bei
den entschlüsselten
Daten verbleiben. Die Dekompressionsvorrichtung 270 dekomprimiert
die Daten und sendet sie entweder zum Router 210 zurück oder
liefert sie an die Routerkomponente 216, welche das bestimmte
Ziel für
die Daten identifiziert. In der bevorzugten Ausführungsform ist die Routingkomponente 216 mit
dem Webinhalts-Cache 208 und der E-Mail-Eingangsbox 272 gekoppelt.
Natürlich
können
auch andere Ziele bereitgestellt sein.
-
Eine
bestimmte Implementierung einer Übersetzungsvorrichtung
ist zusammen mit einer ausführlicheren
Beschreibung beispielhafter Komprimierungs-, Verschlüsselungs-
und Codierungs-Übersetzungsvorrichtungen
in den vorstehend angeführten
ebenfalls anhängigen
US-Patentanmeldungen bereitgestellt, sowie ebenfalls in Anhang A.
-
Somit
liefert die vorliegende Erfindung durch Aufteilung des Inhalts in
separate Skriptenmuster und Datendateien die Fähigkeit, Inhalt an eine Mobilvorrichtung über einen
Kanal mit geringer Bitgeschwindigkeit in ökonomischer und effizienter
Weise zu liefern. Kleine Segmente von Daten können anstelle vollständiger HTML-Seiten
geliefert werden. Die vorliegende Erfindung stellt ebenfalls einen
Mechanismus bereit, durch welchen das Logging und Filtern in effizienter
Weise erzielt werden können.
-
Obgleich
die vorliegende Erfindung mit Bezug auf bevorzugten Ausführungsformen
beschrieben wurde, werden Fachleute erkennen, dass Änderungen
in Form und Detail vorgenommen werden können, ohne vom Schutzumfang
der Erfindung abzuweichen.
-
Anhang
-
Mobile Channels Skripting-Umgebung
-
Das
Mobile Channels Skriptingmodell basiert auf den aktiven Serverseiten
(Active Server Pages, ASP), gemäß Definition
in IIS. Der ASP-Code ist in VBS verfasst. In Mobile Channels werden
sowohl ASP als auch VBS herabgestuft, um den Beschränkungen
von Vorrichtungen mit Windows CE gerecht zu werden. Das vereinheitlichte
ASP ist auch als Taschen-ASP (pocket ASP, pASP) bekannt. Zusammen
werden pASP und VBS als Mobile Channels Skriptingumgebung bezeichnet.
Die hier vorgestellten Besprechungen konzentrieren sich auf die
Unterschiede zwischen pASP/VBS für
Mobile Channels und ASP/VBS für
Active Channels.
-
Arten
-
Es
existieren drei legale Datenarten für das Mobile Channels Skripting:
STRING, NUMERISCH und BOOLEAN. Jedoch wird nur STRING intern unterstützt. Die
beiden anderen werden aus STRING abgeleitet. String-Zeichen können mit
Hilfe des doppelten Anführungszeichens
(") zur Einklammerung
des Ausdrucks spezifiziert werden. Numerische Zeichen können ohne
Anführungszeichen
spezifiziert werden. Zahlen können nur
aus Integern bestehen, und ihre Werte reichen von –32.768
bis 32.767. Boolean-Ausdrücke
belaufen sich auf 1 für
wahr und 0 für
falsch. Sie können
nicht WAHR und FALSCH zugewiesen werden, wie in Visual Basic. Beispielsweise
Datenart | Wert | Beschreibung |
STRING | "Beispiel Stringzeichen" | |
NUMERISCH | Ergebnis
= 3 + 4 | Das
Ergebnis beläuft
sich auf 7. Doch Ergebnis wird als Stringwert gespeichert. |
BOOLEAN | (a)
3 = 3, (b) 3 = 5 | (a)
beläuft
sich auf 1 und (b) auf 0. |
-
Datenstrukturen
-
Mobile
Channels unterstützt
die folgenden Datenstrukturen.
Datenstruktur | Beschreibung |
Variable | Elementare
Datenstruktur einfacher Datentypen wie vorstehend dargestellt. Variablennamen
sind alphanumerisch und müssen
mit einem Alphazeichen beginnen. Das Unterstreichungs-Zeichen kann mit Ausnahme
des führenden
Zeichens verwendet werden. Variablennamen sollten kurz sein, um
Speicher zu sparen und können
in jedem Fall nicht länger
als 255 Zeichen sein. |
Feld | Eine
geordnete Sammlung mit numerischen Tasten. Der Index zählt von
Null (0). Beispielsweise Ergebnis = a(0) + a(1). Das Verfahren Array.Count setzt
die Gesamtanzahl von Elementen in dem Feld zurück. |
-
Schlüsselwörter
-
Die
folgenden Schlüsselwörter sind
reserviert und kennen nicht als Variablennamen verwendet werden:
If,
Then, Else, ElseIf, End If
For, Next, Do While, Loop, Exit
For, Exit While
Set, Response, Request, MobileChannels
Now
LocDate, Len, Mid, Split, Asc, Chr, StrComp, Random
-
Kommentare
-
Kommentare
werden mit dem einfachen Anführungszeichen
(') begonnen und
können überall auf
einer Zeile erscheinen. REM aus VBS wird für das Mobile Channels Skripting
nicht unterstützt.
Folgendes ist ein Beispiel eines Kommentars
- ' dies ist ein beispielhafter
Kommentar.
Operatoren und Präzedenz Operator | Art | Präzedenz | Beschreibung |
* | Numerisch | 1 | Multiplikation |
/ | Numerisch | 1 | Division |
Mod | Numerisch | 1 | Modulo-Division |
+ | Numerisch | 2 | Addition |
- | Numerisch | 2 | Subtraktion |
& | String | 2 | Konkatenation |
< | Boolean | 3 | Weniger
als |
<= | Boolean | 3 | Weniger
als oder gleich |
> | Boolean | 3 | Größer als |
>= | Boolean | 3 | Größer als
oder gleich |
= | Boolean | 3 | Gleich |
<> | Boolean | 6 | Nicht
gleich |
And | Boolean | 4 | Logisches
UND |
Or | Boolean | 4 | Logisches
ODER |
Not | Boolean | 5 | Logisches
NICHT |
-
Ausdrücke werden
gemäß Operatoren-Präzedenz evaluiert.
Operatoren von höherer
Präzedenz
(wobei 1 die höchste
ist) werden zuerst evlauiert. Operatoren desselben Niveaus werden
von links nach rechts evaluiert. Die Präzedenz kann mit Hilfe einer
Klammer übergangen
werden, welche verschachtelt. sein kann. Die innerste Klammer wird
zuerst evaluiert.
-
Anders
als in VBS werden alle Ausdrücke
innerhalb einer Aussage immer evaluiert. In dem nachstehenden Beispiel
werden, falls arr.count nicht größer als
null ist, arr(1) und arr(2) evaluiert, und die Referenzen zu arr(j)
führen
zu einem Fehler.
-
-
Falls
der erste logische Ausdruck falsch ist, sind die nachfolgenden.
Ausdrücke
ungültig.
Die korrekte Implementierung sollte wie folgt lauten.
-
-
Vermeidung von Spezialzeichen
-
Spezialzeichen,
wie beispielsweise das doppelte Anführungszeichen, können innerhalb
eines String-Ausdrucks "vermieden" werden, indem ihnen
ein Back-Slash-Zeichen (\) vorangestellt wird. Das Back-Slash-Zeichen
kann in einem String eingeschlossen sein, indem es ebenfalls vermieden
wird. Beispielsweise:
"Dies
ist ein String, welcher \" doppelte
Anführungszeichen\" enthält."
"Dies ist ein String,
welcher Back-Slashes wie in einem Dateipfad enthält: \\c:\\windows."
-
Aussagen
-
In
der Mobile-Channels-Skriptingumgebung existieren fünf Klassen
von Aussagen:
-
Zuordnung
-
Die
Zuordnungs-Aussage weist folgende Form auf:
<Variable> = <Ausdruck>
-
Konditional
-
Die
If-Aussage liefert einen konditionalen Regelfluss. Der Teil End
If ist erforderlich. Die Aussagen nach einem logischen Ausdruck
werden nicht evaluiert, außer
der logische Ausdruck wird als wahr (1) evaluiert. Die konditionale
Aussage kann eine der nachstehenden Formen aufweisen:
-
Schleife
-
Es
existieren zwei Arten von Schleifen-Aussagen: For/Next und Do/While:
Die For-Schleife steuert durch die Schleife, indem sie die Variable
anfänglich
auf den numerischen Ausdruck1 setzt und diesen Wert um die Menge
Step (Ausdruck 3) mit jedem Durchgang durch die Schleife erhöht. Wenn
der optionale Step-Satz weggelassen wird, wird der Standardsatz
von Step 1 aufgerufen. Die Schleife endet, wenn die Variable einen
Wert erreicht, der größer ist
als Ausdruck2.
-
-
Die
Do While-Schleife fährt
fort, bis der logische Ausdruck logExpression falsch (0) wird. Die
Exit-Aussagen liefern einen Weg, eine Schleife zu beenden, ohne
die normalen Beendigungs-Kriterien
zu erfüllen. Wenn
auf Exit getroffen wird, bricht die Schleife ab, und die Ausführung wird
bei der Aussage wieder aufgenommen, welche unmittelbar auf die Schleife
folgt. Exit wird gewöhnlich
in Verbindung mit einer konditionalen Aussage verwendet.
-
-
Aktivserver
-
Aktivserver-Aussagen
beziehen sich auf die Verfahren von pASP-Objekten wie beispielsweise Response
und Request. Die Response.Write-Aussage führt ein Ausgangssignal zum
HTML-Strom zurück.
Beispielsweise:
Response.write("<A
Href=MCTP://MSNBC/ch2> Hier
klicken, um zu Sport zu springen </A>").
-
Die
Mobile Channels-Skriptingumgebung zeigt bestimmte Server-Variablen an. Die
Request.ServerVariables-Aussage kann verwendet werden, um die Server-Variablen
anzufordern. Sie nimmt einen Sting-Namensausdruck an und führt einen
String-Wertausdruck zurück,
welcher mit dem Namen im Zusammenhang steht. So erhält
newURL=Request.ServerVariables("URL")
die Wurzel-URL
für den
Kanal der Seite. Und
platStr=Request.ServerVariables("Platform")
führt den
Platform-String als eines der folgenden zurück:
String | Plattform |
"WIN32 CE" | Windows
CE |
"WIN32 WINDOWS" | Windows
95/Windows 98 |
"WIN32 NT" | Windows
NT |
-
Auf ähnliche
Weise führt
die Request.QueryString-Aussage den Wert eines bestimmten Arguments zurück, welches
als Teil der URL an die Seite geschickt wurde. Falls die URL für eine Seite
beispielsweise als "MCTP://msnbc/ch2
? city=seattle" benannt
wurde, weist die Aussage
theCity = Request.QueryString("city")
Seattle der
Variable theCity zu.
-
Set
-
Die
Set-Aussage weist eine Variable einem Fall eines Objekts zu. Jedoch
unterstützt
die Mobile Channels-Skriptingumgebung lediglich das MobileChannels.Utilities-Pseudo-Objekt.
Die einzige Verwendung der Set-Aussage die Erzeugung eines MobileChannels.Utilities-Objekts
und seine Zuweisung zu einer Fall-Variablen:
Set mc variable = Server.Create("MobileChannels.Utilities")
Zeilenumbrüche werden
bei der Evaluierung einer Aussage ignoriert. Somit können Aussagen
mehr als eine Zeile umfassen. Das Aussagen-Fortsetzungszeichen("_") wird empfohlen, ist jedoch nicht verpflichtend.
Beispielsweise:
MyVar = "Dies
ist ein Beispiel für " &
"eine Aussage, welche auf " &
"mehreren Zeilen auftaucht." & MyVar
-
Funktionen
-
Die
folgenden Funktionen erscheinen in der Mobile Channels-Skriptingumgebung.
-
Now
-
Führt das
aktuelle Datum zurück
und nimmt kein Argument an. Beispielsweise Response.Write("Heute haben wir den " & Now).
-
LocDate
-
Führt das
Datum mit Hilfe der aktuellen regionalen Einstellungen zur Formatierung
des Datums zurück.
Beispielsweise
Response.Write( "Date: " & LocDate
)
-
Len (<string>)
-
Führt die
Länge eines
Strings zurück.
Beispielsweise führt
Len
("Hello?")
6 zurück.
-
Mid(aStringExpression, startNumExpression,(length))
-
Führt einen
Sub-String eines existierenden String zurück. Der resultierende Sub-String
ist length Zeichen lang und beginnt bei der Start-Zeichennummer
(ab eins zählend,
nicht ab null) in dem ursprünglichen String-Ausdruck.
Beispielsweise
Foo = Mid("Das
ist mein String",
9, 4).
Foo wird nun auf "mein" gesetzt.
-
Split(aStringExpression, delimiterStringExpression)
-
Teilt
einen String in Sub-Strings basierend auf einer bestimmten Abgrenzung
auf. Das Ergebnis wird als ein Feld von Strings zurückgeführt. Beispielsweise
ergibt
Names = Split ("Bob;
Fred; Joe;",";")
die folgenden Sub-Strings:
Names(0)="Bob"
Names(1)="Fred"
Names(2)="Joe"
Names(3)=""
-
Asc (aStringExpression)
-
Wandelt
einen Zeichen-String in seinen numerischen ASCII-Wert um und führt einen
numerischen Ausdruck zurück.
Falls aStringExpression länger
als ein Zeichen ist, führt
die Funktion nur den ASCII-Wert des ersten Zeichens zurück.
-
Chr (numericExpression)
-
Wandelt
einen numerischen ASCII-Wert in das zugehörige Zeichen um und führt einen
1 Zeichen langen String-Ausdruck zurück. Um beispielsweise einen
String zu erzeugen, welcher ein Neuzeilen-Zeichen enthält, verwendet man
str
= Chr(10)
-
StrComp (S1, S2 [, Compare])
-
Diese
Funktion. vergleicht zwei Strings, S1 und S2, wobei optional der
Vergleichsmodus Compare spezifiziert wird. Das Compare-Argument kann 0 oder
1 sein. Falls Compare weggelassen wird, wird ein binärer Vergleich
durchgeführt.
-
Diese
Funktion führt
einen der folgenden Werte zurück:
Bedingung | Rückführwert |
S1
ist kleiner als S2 | –1 |
S1
ist gleich S2 | 0 |
51
ist großer
als S1 | 1 |
-
Raudom (range)
-
Die
Funktion erzeugt eine Zufallszahl im Bereich 0 bis eins weniger
als range. Beispielsweise erzeugt
num = Random (10)
Zufallszahlen
von 0 bis 9 einschließlich.
-
Mobile Channels Scripting-Objekt
-
MobileChannels.Utilities
ist ein Pseudo-Objekt in der Mobile Channels-Skriptingumgebung,
welches Unterstützung
für die
Navigation und Handhabung von Objekten innerhalb einer CDF-Datei
liefert. Das Utilities-Objekt stellt eine Reihe von Verfahren für das Mobile
Channels-Scripting bereit. Diese Verfahren sind in der nachstehenden
Tabelle zusammengefasst.
Verfahren | Beschreibung |
Data | Liest
einen Datenblock aus einem Datenpunkt |
Debug | Gibt
ein Debug-Ausgangssignal aus, um der Skriptenentwicklung zu helfen |
Href | Führt ein
Element HREF zurück |
HrefExists | Führt wahr
zurück,
falls ein Punkt im Cache existiert |
IsSubscribed | Führt einen
abonnierten Zustand eines Kanals/Subkanals zurück. |
IsUnread | Führt einen
gelesen/nicht gelesen-Zustand eines Punktes oder Kanals/Unterkanals
zurück |
LibraryCall | Greift
auf eine spezielle DLL-Funktion zu |
Locate | Springt
zu einer bestimmten ID innerhalb der CDF |
Navigate | Quert
eine CDF-Datei |
Tag | Führt das
Tag eines Elements in einer CDF-Datei zurück |
Title | Führt den
Titel eines Elements zurück |
Value | Führt den
Wert eines Elements in einer CDF-Datei zurück |
-
Zur
Verwendung dieser Dienste muss das Utilities-Objekt zunächst mit
Hilfe der Set-Objekts wie folgt vorbereitet werden:
Set MC
= Server.Create("MobileChannels.Utilities")
MC wird nachstehend
als Abkürzung
für das
MobileChamiels.Utilities-Scripting-Objekt verwendet, jedoch kann das
Objekt jedem beliebigen Variablennamen zugeordnet werden.
-
Navigate-Verfahren der Utilities-Objekte
-
Der
MC.Navigate()-Befehl ist ein starkes, häufig verwendetes und bei weitem
das wichtigste Verfahren in pASP. Er ist darauf ausgelegt, die Untersuchung
der Struktur eines Mobilkanals, wie in CDF dargestellt, beim Laufen
zu unterstützen.
Zum Verstandnis des Verhaltens dieses Befehls ist eine kurze Erläuterung
des Hintergrundes und der Terminologie hilfreich.
-
Der
Grund-Operand des Navigate-Befehls ist ein Element, welches die
kleinste Informationseinheit in einer CDF-Datei ist. Jedes Element
weist ein Tag auf sowie optional einen Wert (value). Das MC.Tag()-
und MC.Value()-Verfahren von pASP kann zur Abholung dieser Strings
für jedes
beliebige Element verwendet werden. Die Elemente werden in einer
Baumstruktur organisiert, wie durch XML spezifiziert, wenn die CDF-Datei aufgeteilt
wird. Der Navigate-Befehl
erlaubt eine Bewegung zu bestimmten Elementen innerhalb des Baumes sowie
eine Bewegung zwischen Elementen mit bestimmten Beziehungen. Diese
Information kann sehr hilfreich für die Kanal-Skripten sein,
welche CDF zur dynamischen Erzeugung der HTML-Seiten für den Kanal beim
Laufen verwenden.
-
Die
nachstehenden Erläuterungen
beziehen sich häufig
auf die Beispiel-CDF-Datei und ihren zugehörigen Baum, welche am Ende
dieses Dokuments bereitgestellt sind. Der Baum zeigt die interne
Vertretung der Beispiel-CDF-Datei. Jede Zeile des Baumes entspricht
einem Element, und alle beginnen mit dem Tag für das Element. Die eingerückteren
Elemente sind Kinder ihrer weniger eingerückten Eltern. Elemente auf
demselben Einrückungsniveau
sind Geschwister. In der CDF-Datei ist beispielsweise das BASE-Element ein Kind
des CHANNEL-Elements auf höherem
Niveau. Das erste HREF-Element ist ein Geschwister des BASE-Elements. Das
INTERVALTIME-Element ist ein Kind des SCHEDULE-Elements.
-
Viele
Elemente werden als mit einem Standardwert behaftet betrachtet.
Diese sind in dem Baum durch einen "=[string]"-Ausdruck angezeigt, welcher auf das
Tag des Elements folgt. Der Standardwert wird in folgendem Schema
bestimmt. Zunächst
ist, falls das betrachtete Element einen direkt damit zusammenhängenden String
aufweist, der String der Standardwert. Als nächstes wird, falls ein Kind-VALUE-Wert
existiert, der Wert des Kindes zum Standard. Falls kein VALUE-Element
bereitgestellt ist, doch ein Kind-HREF-Element gefunden wird, wird
sein Wert zum Standardwert. Falls keiner davon gefunden werden kann,
ist VALUE leer. Beispielsweise ist der Wert des ersten ID-Tag ein
direkter String, das TITLE-Tag weist ein explizites VALUE-Element
auf, also wird dieses verwendet, und der Wert des ersten LOGO-Tag
ist sein HREF. Das SCHEDULE-Tag weist keinen direkten String, VALUE- oder HREF-Kinder
auf, also ist sein Wert leer.
-
Die
Navigate-Funktion weist die folgende Syntax auf:
NewElem =
MCNavigate( StartElem, NavAction, [,Match] )
-
Die
Funktion führt
ein neues Element zurück,
oder aber 0, falls der Befehl das bestimmte Element nicht finden
konnte. Diese Rückführung lässt sich
mit Hilfe von Standard-VBS-Vergleichen überprüfen, wie beispielsweise
-
Der
StartElem-Parameter ist das Startelement, von welchem Relativbewegungs-Befehle
zu basieren sind. Falls der Absolutbewegungs-Befehl "Jump" verwendet wird,
muss "" als StartElem-Parameter
verwendet werden. Doch in allen anderen Fällen muss er ein gültiges Element
sein, welches von einem vorherigen Navigate()-Befehl zurückgeführt wird.
-
Der
NavAction-Parameter muss einer der folgenden Strings sein:
-
"Jump"
-
Die "Jump"-Aktion ist der erste
Befehl, welcher zum Erhalt eines Startelements verwendet wird. Er
entspricht dem MC.Locate()-Befehl
(s.u.). Der StartElem-Parameter muss ein leerer String sein. Die "Jump"-Aktion navigiert
direkt zu einem bestimmten Element in der CDF gemäß Identifikation
durch die gelieferte ID. Beispielsweise springt die folgende Aussage
NewElem
= MC.Navigate( "", "Jump", "D1" )
zum ersten
Datenpunkt-Element in der Beispiel-CDF-Datei. NewElem wird zum ITEM-Elternelement
für das ID-Element
("D1", ca. auf halber
Höhe der
Beispiel-CDF-Datei).
-
"First"
-
Die "First"-Aktion bewegt sich
zum ersten Element auf einem bestimmten Niveau. Von dem ID-Element
des ersten LOGO-Elements in der Beispiel-CDF-Datei bewegt sich eine "First"-Aktion beipsielsweise zum
STYLE-Tag dieses LOGO. Praktischere Szenarien bestehen darin, diese
Aktion zu verwenden, um sich zurück
zum Anfang der Liste von ITEMs unter einem Subkanal zu bewegen.
NewElem
= MC.Navigate( StartElem, "First" )
-
"Out"
-
Die "Out"-Aktion bewegt sich
zum Elternelement des gegenwärtigen
Elements, oder zur linken Einrückung
in dem Baumdiagramm. Vom TITLE-Element der Beispiel-CDF führt die "Out"-Aktion beispielsweise
zur Bewegung zum Channel-Element des höchsten Niveaus.
NewElem
= MC.Navigate( StartElqem, "Out" )
-
"In"
-
Die "In"-Aktion bewegt sich
zum ersten Kindelement unterhalb des aktuellen Elements. Von dem
ersten USAGE-Element in der Beispiel-CDF-Datei führt die "In"-Aktion
beispielsweise zu einer Bewegung zum VALUE-Element.
NewElem
= MC.Navigate( StartElem, "In" )
-
"Prev"
-
Die "Prev"-Aktion bewegt sich
zu dem Element auf gleichem Niveau, welches unmittelbar vor dem
aktuellen Element liegt. Falls es kein vorangehendes Element auf
demselben Niveau findet, kehrt es zu 0 zurück; es rückt nicht zum Elternelement
aus. Falls sie beispielsweise von dem BASE-Element in der Beispiel-CDF-Datei ausgeht,
führt die "Prev"-Aktion zu einer
Bewegung zum HREF-Element rechts davor. Ein erneuter Aufruf von "Prev" führt 0 zurück, da keine
Geschwister mehr auf diesem Niveau existieren.
NewElem = MC.Navigate(
StartElem, "Prev" )
-
"Next"
-
Die "Next"-Aktion bewegt sich
zum nächsten
Element auf demselben Niveau. Wie bei der "Prev"-Aktion
führt sie
Null zurück,
falls sie kein derartiges Geschwisterelement findet. Von dem ersten
LOGO-Tag in der Beispiel-CDF-Datei aus führt die "Next"-Aktion
beispielsweise zu einer Bewegung zum zweiten LOGO-Element.
NewElem
= MC.Navigate( StartElem, "Next" )
-
"Match"
-
Die "Match"-Aktion versucht
ein Geschwisterelement mit einem Tag zu finden, welches mit dem
spezifizierten Match-String übereinstimmt.
Sie überquert
so viele Geschwister wie nötig,
bis sie entweder eine Übereinstimmung
findet oder keine weiteren Geschwister finden kann. Falls die "Match"-Aktion von einem übereinstimmenden
Element aus startet, führt
sie einfach das aktuelle Element zurück. Um über das aktuelle Element hinaus übereinzustimmen,
muss die "Match"-Aktion auf eine "Next"-Aktion. folgen.
NewElem
= MC.Navigate( StartElem, "Match", "TagToMatch" )
-
"InMatch"
-
Die "InMatch"-Aktion entspricht
dem vorstehenden "Match", mit der Ausnahme,
dass sie ihre Suche beim ersten Kind des aktuellen Elements beginnt.
Dies kann nützlich
für die
Suche nach bestimmten Sub-Tags sein, welche das einschließende Element
modifizieren. So suchen beispielsweise die folgenden Aussagen
nach
dem USAGE-Tag für
ein bestimmtes Element.
-
Die
einzigen Aktionen, welche den optionalen dritten Parameter verwenden,
sind "Match" und "InMatch".
-
Andere Verfahren des Utilities
Object
-
Tag
-
Dieses
Verfahren führt
den Tag-Namen eines Elements zurück:
tagString=MC.Tag(elementID)
-
Value
-
Dieses
Verfahren führt
den Wert eines Elements zurück:
valString=MC.Value(elementID)
-
Data
-
Dieses
Verfahren erhält
Daten aus einer Mobile Channels-Datendatei und führt ein Feld von Namen-Wert-Paarungen
basierend auf der aktuellen Position und der spezifizierten Blocknummer
zurück.
-
Die
Namen sind die Feldnamen wie in einer ITEMFORMAT-Aussage spezifiziert,
und die Werte sind die Datenelemente (Zeilen) wie aus der Datendatei
abgeholt. In dem nachfolgenden Beispiel ist dataItems ein Feld zum
Halten der Datenelemente:
DataItems=MC.Data(elementID, blockNum)
wobei
elementID die aktuelle Position innerhalb der CDF-Datei ist, beispielsweise
das ID-Element für
die MCD-Datei, und block-Num
die Blocknummer innerhalb der Datei ist. Blöcke beginnen mit Null. So ist
der erste Wiederholungsblock, falls vorhanden, immer Block Nummer
eins (selbst wenn kein Anfangsblock existiert). Das resultierende
Feld, dataItems, enthält
ein Element für
jeden Punkt (Zeile) innerhalb des Blocks. Die Punkte in einem Block
zählen
ab Null.
-
Jedes
Datenelement ist tatsächlich
ein Objekt, welches das Tag-, Type- und Value-Verfahren zur Ausstellung
seiner eigenen Eigenschaften unterstützt.
-
Tag
-
dataItems(index).Tag
führt den
Feldnamen für
die angegebene Feldposition zurück,
wie im <ITBMFORMAT>-Element erklärt.
-
Value
-
dataItems
(index).Value führt
den Wert des Feldes für
die angegebene Feldposition zurück.
-
Type
-
dataItems
(index).Type führt
den Typ gemäß Spezifikation
in der <ITEMFORMAT>-Aussage zurück. Falls
kein Typ aufgelistet ist oder falls das <ITBMFORMAT>-Tag fehlt, führt das Type-Verfahren "HTML" zurück. Andere
Typen sind unter anderem "TEXT", "IMG" und "HREF".
Typ | Beschreibung |
HTML | Das
Zeilenelement ist von HTML-formatiertem Inhalt. Dies ist der Standard-Typ. |
HREF | Die
Zeile ist eine URL, (entweder http:// oder mctp://) |
IMG | Die
Zeile enthält
die ID eines Bildelements in der CDF-Datei |
TEXT | ebenso
wie HTML |
-
Locate
-
Die
Funktion weist folgende Form auf:
newElem = MC.Locate("ID")
und ist eine
Abkürzung
für die "Jump"-Aktion des Navigate-Verfahrens:
newElem
= MC.Navigate( "", "Jump", "ID" )
-
LibraryCall
-
Diese
Funktion erlaubt den Zugriff eines Skripts auf eine Custom-DLL zur
Durchführung
von Funktionen, welche durch Standard-Skripting nicht verfügbar sind.
Das Verfahren weist die folgende Form auf:
Result = MC.LibraryCall(
LibName, FuncName [,param]* )
-
Zunächst prüft das Verfahren
die Sicherheit, um zu garantieren, dass die DLL korrekt für Zugriff über pASP-Skripting
registriert wurde. Eine zugängliche
DLL muss einen Registrierungseintrag in \HKLM\Software\Microsoft\Mobile
Channels\Components aufweisen, welcher mit dem Namen der DLL übereinstimmt.
-
Dann
lädt das
LibraryCall-Verfahren dynamisch die spezifizierte DLL durch Aufrufen
der GetProcAddress-Funktion zur Suche nach der spezifizierten Funktion.
Jegliche zusätzliche
Parameter werden dann vor der Weiterleitung an die DLL-Funktion
beseitigt. Bis zu 8 optionale Parameter können weitergeleitet werden.
-
Die
DLL-Funktion muss einen LPWSTR-Wert zurückführen. Falls der Rückführwert NULL
ist, kehrt LibraryCall zu null (0) zurück. Andernfalls führt sie
den String selbst als Standard-pVBS-Stringwert zurück.
-
Debug (Mesg)
-
Das
Debug-Verfahren erlaubt das Ausschreiben eines Debug-String während der
Ausführung
des Skripts. Dies kann während
der Entwicklung zur Unterstützung
der Untersuchung des Programmflusses nützlich sein. Die Debug-Nachrichten
erscheinen im Konsolenfenster jegliches angehängten Debuggers, ähnlich dem
OutputDebug-String
API.
-
Die
Funktion führt
keinerlei Wert zurück.
-
HrefExists (Href)
-
Dieses
Verfahren prüft
zur Bestimmung, ob die spezifizierte URL im Cache gefunden werden
kann. Dies erlaubt einem Skript die behutsame Handhabung fehlender
Bilder, Datenelmente oder anderer Komponenten, welche durch das
Skript benötigt
werden. Die URL muss eine voll qualifizierte http-Art URL sein.
-
Dieses
Verfahren führt
1 zurück,
falls im Cache gefunden, sonst 0.
-
Href(Elem)
-
Dieses
Verfahren führt
die volle URL für
das spezifizierte Element zurück,
falls es in der CDF-Datei spezifiziert ist. Es führt 0 zurück, falls keine URL gefunden
werden kann.
-
IsSubscribed(ChanElem)
-
Dies
prüft,
um zu sehen ob der spezifizierte Kanal oder Subkanal momentan durch
den Anwender abonniert ist. Es führt
1 zurück,
falls der Kanal abonniert ist, oder 0, falls er nicht gefunden wird
oder nicht abonniert ist.
-
N.B.:
dies funktioniert nicht mit Elementen, nur mit Kanälen. Weiterhin
führt es
stets 1 zurück,
wenn es auf dem Desktop (in IE4) läuft.
-
Title
-
Dieses
Verfahren weist die folgende Form auf:
titleString = MC.Title(
ElemString )
und versucht, den Titel eines bestimmten Elements
wie folgt zu entziffern:
Falls ein ausdrückliches TITLE-Tag für dieses
Element vorliegt, wird dessen Wert zurückgeführt;
Falls es ein .mcd-Datenelement
mit einem ITEMFORMAT ist, welches ein TITLE-Feld spezifiziert, wird
das Datenelement geöffnet
und der Titel daraus extrahiert;
Falls ein ID-Element bereitgestellt
ist, wird sein Wert zurückgeführt;
In
jedem anderen Fall wird NULL zurückgeführt.
-
Es
sollte sich verstehen, dass dieses Verfahren das Datenelement beim
Abholen des Titels nicht als "Read" oder "gelesen" markiert. Dies unterscheidet
sich von der Verwendung von Navigate zum Erhalt des Titels. Letzteres
Verfahren markiert das Element als "Read",
selbst dann, wenn der Anwender es nicht tatsächlich gesehen hat.
-
IsUnread
-
Dieses
Verfahren führt
ein Boolean zurück,
welches anzeigt, ob das zugehörige
Element oder der zugehörige
Kanal gelesen wurde.
newContent = MC.IsUnread( Elem )
-
Die
Funktion führt
einen nicht-null-Wert zurück,
falls sie direkt an einem ungelesenen Element aufgerufen wird. Wenn
sie an einem Subkanal aufgerufen wird, führt sie nicht-null zurück, falls
irgendwelche Elemente oder anderen Subkanäle innerhalb des Subkanals
nicht gelesen wurden.
-
SetUnread
-
Dieses
Verfahren setzt den gelesen/ungelesen-Status für ein Element und führt keinen
Wert zurück. Und
es weist das folgende Format auf:
SetUnread(Elem [,Flag])
-
Der
Elem-Parameter sollte ein gültiges
Element aus einem vorhergehenden Navigate()- oder Locate()-Ruf sein.
Der optionale Flag-Parameter
ist ein Boolean, welcher zur Markierung des Status von Elem verwendet
wird: 0 für "unread" oder "ungelesen", und 1 für "read" oder "gelesen". Der Standardwert
von Flag ist "unread".
N.B.
Aufgrund einer Beschränkung
der Realisierung der Version 1.0 von Mobile Channels werden Bildelemente
nicht automatisch als "gelesen" markiert (wie es
bei MDC-Elementen der Fall ist). Dies führt dazu, dass das Bild weiterhin
als "ungelesen" markiert ist, obgleich
es gelesen wurde. Weiter zeigen sich alle Eltern-Subkanäle ebenfalls
als "ungelesen", solange irgendwelche
Bilder darin ungelesen sind. Um in dieser Situation Abhilfe zu schaffen,
sollte der Skriptenautor manuell jedes Bild jedes Mal dann, wenn
es angezeigt wird, als "ungelesen" markieren. Die SetUnread()-Anwendung
ist die richtige Art und Weise, um dies zu erzielen. |
-
Channel Browser und Active Desktop-HTML-Extensionen
-
Eine
Reihe von HTML-Extensionen stellen eine zusätzliche Funktionalität zum Schreiben
fortgeschrittenerer Skripten für
Active Desktop und zur Regelung von Seitenaktualisierungen in Channel
Browser bereit.
-
Anwendungs-Links
-
Windows
CE Active Desktop unterstützt
eine spezielle HTML-Href zum Start einer Anwendung von einem Hyperlink
aus. Das Format ist folgendes:
<A HREF="mcexe://[appname]">Launch
Text</A>
appname ist der
Name der Anwendung, welche gestartet werden soll, wenn der Link
angeklickt wird.
-
Die
Anwendung muss registriert worden sein, indem ein Wert desselben
Namens wie der .exe in das Register bei \HKLM\Software\Microsoft\Mobile
Channels\Components platziert wurde.
-
MBTA-Tags
-
Channel
Browser und Active Desktop erkennen die nachfolgenden speziellen
META-Tags. Die Einbettung dieser META-Tags in den Anfangsblock einer
Seite, entweder direkt oder über
Skripting, kann bewirken, dass die Seite automatisch gehandhabt
oder auf eine bestimmte Weise aktualisiert wird. Es sollte sich
verstehen, dass diese META-Tags (mit der Ausnahme von Refresh) durch
IE4 ignoriert werden.
-
Die
META-Tags sind in der nachfolgenden Tabelle zusammengefasst.
Http_Equiv | Beschreibung | Unterstützung |
Notify | Abholung
von Cache- oder Datenbank-Aktualisierung | Aktive
Desktop und Channel Browser |
Refresh | Neuladen
nach Zeitintervall | Active
Desktop |
LaunchApp | Ausführen der
Anwendung für Desktop-Komponente | Active
Desktop |
Autosize | Regelung
Bildskalierung | Channel
Browser |
-
Nachfolgend
einige detaillierte Beschreibungen jedes Tag.
-
Notify
-
Dieses
META-Tag ermöglicht
die automatische Aktualisierung einer Seite, wenn eine Aktualisierung auf
eine bestimmte Datenbank exisitert, oder dann, wenn ein bestimmtes
Element im Cache aktualisiert wird. Dies kann zur automatischen
Regeneration einer Seite verwendet werden, wenn eine neue Version
davon (oder von einer ihrer Komponenten) über Sync oder andere Mechanismen
hereinkommt. Die beiden Formen dieses META-Tag sind:
-
DBname
ist der Name der Datenbank, die nach Aktualisierungen überwacht
werden soll.
-
WatchUrl
ist die URL eines Elements, welches beobachtet werden soll, ob es
Cache-Aktualisierungen aufweist.
-
RefreshUrl
ist die URL, welche geladen werden soll, falls eine Aktualisierung
detektiert wird.
-
Refresh
-
Dieses
META-Tag veranlasst das automatische Neuladen einer Seite nach einem
bestimmten Zeitintervall. Die Form ist folgende:
<META HTTP-EQUIV="Refresh" CONTENT="[secs];URL=[RefreshUrl]">
secs setzt die Anzahl von Sekunden,
bis die Seite neu geladen wird.
-
RefreshUrl
ist die URL, welche nach dem bestimmten Zeitintervall geladen werden
soll.
-
LaunchApp
-
Dieses
META-Tag ermöglicht
den Start einer Anwendung durch Klicken auf den Anfangsblock einer Active
Desktop-Komponente auf der Vorrichtung. Die Form ist folgende:
<META HTTP-EQUIV="LaunchApp" CONTENT=[appname][?params]">
appname ist der Name der zu startenden
Ausführung.
params
ist eine optionale, durch Kommas getrennte Liste von params, welche
nach der Aufrufung an die Anwendung weitergeleitet werden sollen.
-
Die
Anwendung muss registriert worden sein, indem ein Wert desselben
Namens wie die .exe in das Register in \HRLM\Software\Microsoft\Mobile
Channels\Components platziert wurde.
-
Autosize
-
Dieses
META-Tag erlaubt die Sperrung des Standard-Bildskalierungs-Verhaltens
für eine
bestimmte Seite. Die HTML-Regelung versucht standardmäßig, Bilder
zur Anzeige auf dem Bildschirm mit kleinerem Formfaktor zu skalieren.
Falls dieses META jedoch im Anfangsblock der Seite spezifiziert
ist, werden die Bilder in voller Größe angezeigt, wodurch Scroll-Leisten
erscheinen, falls dies nötig
ist. Die Form ist folgende:
<META
HTTP-EQUIV="Autosize" CONTENT="Off">
-
Es
sollte sich verstehen, dass, da der Standardwert immer "Ein" ist, keine Notwendigkeit
für einen
anderen Wert im CONTENT-Feld besteht. Parse-Baum
der Beispiel-CDF-Datei
Beispiel
einer CDF-Datei