DE112010001143T5

DE112010001143T5 - Ereigniserkennung

Info

Publication number: DE112010001143T5
Application number: DE112010001143T
Authority: DE
Inventors: Allen Moore Bradford; Joshua H. Shaffer
Original assignee: Apple Inc
Current assignee: Apple Inc
Priority date: 2009-03-16
Filing date: 2010-03-12
Publication date: 2012-05-16
Also published as: CN104035718B; JP6408085B2; CN104049975A; US20110310047A1; US9965177B2; WO2010107669A2; EP2413237B1; US8285499B2; JP2017215983A; JP5594914B2; CA2817890C; CA2755443C; CA2817648A1; AU2010226120B2; WO2010107669A3; CN104049975B; CN102422264A; CN102422264B; AU2010226120A1; JP5879395B2

Abstract

Ein Verfahren führt Software aus, die eine Ansichtshierarchie mit einer Mehrzahl von Ansichten enthält, die eine oder mehrere Ansichten der Ansichtshite aus, die mit einer bestimmten Ansicht assoziiert sind, wobei jede bestimmte Ansicht Ereigniserkenner enthält. Jeder Ereigniserkenner hat eine Ereignisdefinition, die auf Unterereignissen basiert, und einen Ereignishandler, der eine Aktion für ein Ziel spezifiziert, und ist konfiguriert, um eine Aktion an das Ziel in Antwort auf eine Ereigniserkennung zu senden. Das Verfahren detektiert eine Reihenfolge von Unterereignissen, und identifiziert eine der Ansichten der Ansichtshierarchie als eine Schlagansicht, die festlegt, welche Ansichten in der Hierarchie aktiv involvierte Ansichten sind. Das Verfahren schickt jeweils ein Unterereignis an Ereigniserkenner für jede aktiv involvierte Ansicht, wobei jeder Ereigniserkenner für aktiv involvierte Ansichten in der Ansichtshierarchie das jeweilige Unterereignis vor Bearbeitung eines nächsten Unterereignisses in der Reihenfolge von Unterereignissen bearbeitet.

Description

TECHNISCHES GEBIET
Die offenbarten Ausführungsformen beziehen sich generell auf Benutzerschnittstellen-Verarbeitung. Insbesondere beziehen sich die offenbarten Ausführungsformen auf Vorrichtungen oder Verfahren zum Erkennen von Benutzerschnittstellenereignissen.
HINTERGRUND
Ein Rechengerät enthält typischerweise eine Benutzerschnittstelle, die verwendet werden kann, um mit dem Rechengerät zu interagieren. Die Benutzerschnittstelle kann ein Anzeige- und/oder Eingabegerät wie zum Beispiel eine Tastatur, Mäuse und berührungsempfindliche Oberflächen zum Interagieren mit verschiedenen Aspekten der Benutzerschnittstelle enthalten. Bei einigen Geräten mit einer berührungsempfindlichen Oberfläche als einem Eingabegerät wird ein erster Satz von berührungsbasierten Gesten (zum Beispiel zwei oder mehrere von: Schlag, Doppelschlag, horizontales Streichen, vertikales Streichen, Kneifen, Spreizen, Zwei-Finger-Streichen) erkannt als geeignete Eingabe in einem bestimmten Kontext (zum Beispiel in einem bestimmten Modus einer ersten Anwendung), und andere, unterschiedliche Sätze von berührungsbasierten Gesten werden als geeignete Eingaben in anderen Kontexten (zum Beispiel unterschiedliche Anwendungen und/oder unterschiedliche Modi oder Kontexte innerhalb der ersten Anwendung) erkannt. Als Ergebnis können die Software und Logik, die für die Erkennung von und Antwort auf berührungsbasierte Gesten erforderlich sind, kompliziert werden, und können eine Nachprüfung erfordern, jedes Mal wenn eine Anwendung aktualisiert wird oder eine neue Anwendung zu dem Rechengerät hinzugefügt wird. Diese und ähnliche Angelegenheiten können sich bei Benutzerschnittstellen ergeben, die Eingabequellen benutzen, die anders als berührungsbasierte Gesten sind.
Daher ist es wünschenswert, ein umfangreiches Rahmenwerk oder einen Mechanismus zum Erkennen von berührungsbasierten Gesten und Ereignissen, sowie Gesten und Ereignissen von anderen Eingabequellen zu haben, das für fast alle Kontexte oder Modi anderer Anwendungsprogramme auf einem Rechengerät anpassungsfähiger ist und das weniger oder keine Nachprüfung erfordert, wenn eine Anwendung aktualisiert wird oder eine neue Anwendung zu dem Rechengerät hinzugefügt wird.
ZUSAMMENFASSUNG
Um auf die zuvor erwähnten Nachteile einzugehen, stellen einige Ausführungsformen ein Verfahren bereit, das, bei einem elektronischen Gerät, das konfiguriert ist, um Software auszuführen, die eine Ansichtshierarchie mit einer Mehrzahl von Ansichten enthält: eine oder mehrere Ansichten der Ansichtshierarchie zeigt; eines oder mehrere Softwareelemente ausführt, wobei jedes Softwareelement mit einer bestimmten Ansicht assoziiert ist, wobei jede bestimmte Ansicht einen oder mehrere Ereigniserkenner enthält. Jeder Ereigniserkenner hat eine Ereignisdefinition, die auf einem oder mehreren besonderen Ereignissen basiert, und einen Ereigniserkenner, wobei der Ereigniskenner eine Aktion für ein Ziel spezifiziert, und ist konfiguriert, um die Aktion an das Ziel in Antwort auf das Detektieren eines Ereignisses entsprechend der Ereignisdefinition durch den Ereigniserkenner zu senden. Das Verfahren detektiert auch eine Reihenfolge von einem oder mehreren Unterereignissen, oder identifiziert eine der Ansichten der Ansichtshierarchie als eine Schlagansicht, wobei die Schlagansicht feststellt, welche Ansichten in der Ansichtshierarchie aktiv involvierte Ansichten sind. Das Verfahren liefert auch ein jeweiliges Unterereignis an den Ereigniserkenner für jede aktiv involvierte Ansicht innerhalb der Ansichtshierarchie, wobei jeder Ereigniserkenner für aktiv involvierte Ansichten in der Ansichtshierarchie das jeweilige Unterereignis vor Bearbeitung eines nächsten Unterereignisses in der Reihenfolge von Unterereignissen bearbeitet.
Einige Ausführungsformen stellen ein Verfahren bereit, das bei einem elektronischen Gerät, das konfiguriert ist, um Software auszuführen, die eine Ansichtshierarchie mit einer Mehrzahl von Ansichten enthält: eine oder mehrere Ansichten der Ansichtshierarchie zeigt; eines oder mehrere Softwareelemente ausführt, wobei jedes Softwareelement mit einer bestimmten Ansicht assoziiert ist, wobei jede bestimmte Ansicht einen oder mehrere Ereigniserkenner enthält. Jeder Ereigniserkenner hat eine Ereignisdefinition, die auf einem oder mehreren Unterereignissen basiert, und einen Ereignishandler, wobei der Ereignishandler eine Aktion für ein Ziel spezifiziert, und ist konfiguriert, um die Aktion an das Ziel in Antwort auf das Detektieren eines Ereignisses entsprechend der Ereignisdefinition durch den Ereigniserkenner zu senden. Das Verfahren detektiert auch eine Reihenfolge von einem oder mehreren Unterereignissen, und identifiziert eine der Ansichten der Ansichtshierarchie als eine Schlagansicht, wobei die Schlagansicht feststellt, welche Ansichten in der Ansichtshierarchie aktiv involvierte Ansichten sind. Das Verfahren liefert auch ein jeweiliges Unterereignis an den Ereigniserkenner für jede aktiv involvierte Ansicht innerhalb der Ansichtshierarchie, und trifft eine Unterereigniserkennungsentscheidung während der Bearbeitung des jeweiligen Unterereignisses bei Ereigniserkennern für die aktiv involvierten Ansichten in der Ansichtshierarchie.
Einige Ausführungsformen stellen ein computerlesbares Speichermedium bereit, das eines oder mehrere Programme zum Ausführen durch einen oder mehrere Prozessoren eines Computersystems oder -gerätes speichert, wobei das eine oder mehrere Programme eines oder mehrerer Anwendungsprogramme zum Anzeigen einer oder mehreren Ansichten einer Ansichtshierarchie mit einer Mehrzahl von Ansichten enthalten. Das eine oder mehrere Anwendungsprogramme enthalten eines oder mehrere Softwareelemente, wobei jedes Softwareelement mit einer bestimmten Ansicht assoziiert ist, wobei jede bestimmte Ansicht einen oder mehrere Ereigniserkenner enthält. Jeder Ereigniserkenner hat eine Ereignisdefinition, die auf einem oder mehreren Unterereignissen basiert, und einen Ereignishandler, wobei der Ereignishandler eine Aktion für ein Ziel spezifiziert, und ist konfiguriert, um die Aktion an das Ziel in Antwort auf das Detektieren eines Ereignisses entsprechend der Ereignisdefinition durch den Ereigniserkenner zu senden; Ereignisverwaltungsanweisungen, wenn sie durch einen oder mehrere Prozessoren des Computersystems oder -gerätes ausgeführt werden, veranlassen das Computersystem oder -gerät dazu: eine Reihenfolge von einem oder mehreren Unterereignissen zu detektieren; eine der Ansichten der Ansichtshierarchie als eine Schlagansicht zu identifizieren, wobei die Schlagansicht feststellt, welche Ansichten in der Ansichtshierarchie aktiv involvierte Ansichten sind; und ein jeweiliges Unterereignis an den Ereigniserkenner für jede aktiv involvierte Ansicht innerhalb der Ansichtshierarchie zu liefern, wobei jeder Ereigniserkenner für aktiv involvierte Ansichten in der Ansichtshierarchie das jeweilige Unterereignis vor Bearbeitung eines nächsten Unterereignis in der Reihenfolge von Unterereignissen bearbeitet.
Einige Ausführungsformen stellen eine Vorrichtung bereit, die eine Anzeige, einen oder mehrere Prozessoren, Speicher, und eines oder mehrere in dem Speicher gespeicherte Programme, die konfiguriert ist, eine oder mehrere Ansichten einer Ansichtshierarchie mit einer Mehrzahl von Ansichten anzuzeigen, aufweist. Das eine oder mehrere Programme enthalten eines oder mehrere Softwareelemente, wobei jedes Softwareelement mit einer bestimmten Ansicht assoziiert ist, wobei jede bestimmte Ansicht einen oder mehrere Ereigniserkenner enthält. Die Ereigniserkenner haben eine Ereignisdefinition, die auf einem oder mehreren Unterereignissen basiert, und einen Ereigniserkenner, wobei der Ereignishandler eine Aktion für ein Ziel spezifiziert, und ist konfiguriert, die Aktion an das Ziel in Antwort auf das Detektieren eines Ereignisses entsprechend der Ereignisdefinition durch den Ereigniserkenner zu senden. Die Programme der Vorrichtung enthalten auch ein Ereignislieferprogramm, das, wenn durch den einen oder mehrere Prozessoren die Vorrichtung ausgeführt wird, die Vorrichtung dazu veranlasst, eine Reihenfolge von einem oder mehreren Unterereignissen zu detektieren; eine der Ansichten der Ansichtshierarchie als eine Schlagansicht zu identifizieren, wobei die Schlagansicht feststellt, welche Ansichten in der Ansichtshierarchie aktiv involvierte Ansichten sind; und eine Unterereigniserkennungsentscheidung zu treffen, während der Ereigniserkenner für die aktiv involvierten Ansichten in der Ansichtshierarchie das jeweilige Unterereignis bearbeitet.
In einigen Ausführungsformen wird eine Vorrichtung bereitgestellt, die einen oder mehrere Prozessoren, Speicher, und eines oder mehrere in dem Speicher gespeicherten Programme, die konfiguriert sind, die Ausführung von einer oder mehreren programmatischen Schichten einer programmatischen Hierarchie mit einer Mehrzahl von programmatischen Schichten zu verwalten. Das eine oder mehrere Programme enthalten eines oder mehrere Softwareelemente, wobei jedes Softwareelement mit einer bestimmten programmatischen Schicht assoziiert ist, wobei jede bestimmte programmatische Schicht einen oder mehrere Ereigniserkenner enthält. Die Ereigniserkenner haben eine Ereignisdefinition, die auf einem oder mehreren Unterereignissen basiert, und einen Ereignishandler, wobei der Ereignishandler eine Aktion für ein Ziel spezifiziert und konfiguriert ist, die Aktion an das Ziel in Antwort auf das Detektieren eines Ereignisses entsprechend der Ereignisdefinition durch den Ereigniserkenner zu senden. Die Vorrichtung enthält auch ein Ereignislieferprogramm, das, wenn durch den einen oder mehrere Prozessoren die Vorrichtung ausgeführt wird, die Vorrichtung dazu veranlasst, eine Reihenfolge von einem oder mehreren Unterereignissen zu detektieren; eine der programmatischen Schichten der programmatischen Hierarchie als eine Schlagschicht zu identifizieren, wobei die Schlagschicht feststellt, welche programmatische Schichten in der programmatischen Hierarchie aktiv involvierte programmatische Schichten sind; und ein jeweiliges Unterereignis an den Ereigniserkenner für jede aktiv involvierte programmatische Schicht innerhalb der programmatischen Hierarchie zu liefern, wobei jeder Ereigniserkenner für aktiv involvierte Schichten in der programmatischen Hierarchie das jeweilige Unterereignis vor Bearbeitung eines nächsten Unterereignisses in der Reihenfolge von Unterereignissen bearbeitet.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1A und 1B sind Blockdiagramme, die elektronische Geräte nach einigen Ausführungsformen darstellen.
2 ist ein Diagramm eines Eingabe/Ausgabe-Verarbeitungsstacks eines beispielhaften elektronischen Gerätes nach einigen Ausführungsformen.
3A stellt eine beispielhafte Ansichtshierarchie nach einigen Ausführungsformen dar.
3B und 3C sind Blockdiagramme, die beispielhafte Ereigniserkennungsverfahren und Datenstrukturen nach einigen Ausführungsformen darstellen.
4A und 4B sind Flussdiagramme, die beispielhafte Zustandsmaschinen nach einigen Ausführungsformen darstellen.
4C stellt die beispielhaften Zustandsmaschinen von 4A und 4B zu einem beispielhaften Satz von Unterereignissen nach einigen Ausführungsformen dar.
5A–5C stellen beispielhafte Unterereignisreihenfolgen mit beispielhaften Ereigniserkenner-Zustandsmaschinen nach einigen Ausführungsformen dar.
6A und 6B sind Ereigniserkennungs-Verfahrensflussdiagramme nach einigen Ausführungsformen.
Gleiche Bezugszeichen beziehen sich auf entsprechende Teile in den ganzen Zeichnungen.
BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Der Bezug wird nun ausführlich auf Ausführungsformen genommen, deren Beispiele in den begleitenden Zeichnungen dargestellt werden. In der folgenden ausführlichen Beschreibung werden zahlreiche spezifische Details vorgelegt, um ein gründliches Verständnis der vorliegenden Erfindung bereitzustellen. Es liegt dem Fachmann dennoch auf der Hand, dass die vorliegende Erfindung ohne diese spezifischen Details praktiziert werden kann. In anderen Beispielen sind bekannte Verfahren, Prozeduren, Komponenten, Schaltungen, oder Netzwerke nicht im Detail beschrieben worden, um Aspekte der Ausführungen nicht unnötigerweise zu verdunkeln.
Es wird auch verstanden werden, dass, obwohl die Begriffe erste, zweite usw. hier verwendet werden können, um verschiedene Elemente zu beschreiben, diese Elemente nicht auf diese Begriffe beschränkt werden sollen. Diese Begriffe werden nur verwendet, um ein Element von dem anderen zu unterscheiden. Zum Beispiel kann ein erster Kontakt als ein zweiter Kontakt bezeichnet, und ebenso ein zweiter Kontakt als ein erster Kontakt bezeichnet werden, ohne den Umfang der vorliegenden Erfindung zu verlassen. Der erste Kontakt und der zweite Kontakt sind beide Kontakte, aber sie sind nicht derselbe Kontakt.
Die in der Beschreibung der Erfindung verwendete Terminologie ist nur zum Zweck der Beschreibung von bestimmten Ausführungsformen gedacht und ist nicht dazu gedacht, die Erfindung zu beschränken. Wie in der Beschreibung der Erfindung und den beigefügten Ansprüchen verwendet, sind die Singularformen „ein” usw. und „der” usw. beabsichtigt, auch die Pluralformen zu enthalten, sofern der Kontext nichts anderes deutlich angibt. Es wird auch verstanden werden, dass der Begriff „und/oder”, wie hier verwendet, alle möglichen Kombinationen des einen oder der mehreren assoziierten aufgelisteten Elemente betrifft und einschließt. Weiterhin wird es verstanden werden, dass die Begriffe „aufweist” und/oder „aufweisende”, wenn in dieser Spezifikation verwendet, das Vorliegen von angegebenen Merkmalen, Ganzzahlen, Schritten, Operationen, Elementen, und/oder Komponenten spezifizieren, aber das Vorliegen oder die Hinzufügung von einem oder mehreren anderen Merkmalen, Ganzzahlen, Schritten, Operationen, Elementen, Komponenten, und/oder Gruppen davon nicht ausschließen.
Wie hier verwendet, kann der Begriff „wenn” so ausgelegt werden, dass es, abhängig vom Kontext, „falls” oder „bei” oder „in Antwort auf Entscheiden” oder „in Antwort auf Detektieren” bedeutet. Ebenso kann der Ausdruck „wenn es entschieden wird” oder „wenn [eine angegebene Bedingung oder Ereignis] detektiert wird”, so ausgelegt werden, dass er, abhängig vom Kontext, „beim Entscheiden” oder „Im Antwort auf Entscheiden” oder „bei Detektieren (der angegebenen Bedingung oder des Ereignisses)” oder „in Antwort auf Detektieren (der angegebenen Bedingung oder des Ereignisses) bedeutet.
Wie oben erwähnt werden bei einigen Geräten mit einer berührungsempfindlichen Oberfläche eines Eingabegerätes ein erster Satz von berührungsbasierten Gesten (z. B. zwei oder mehr von: Schlag, Doppelschlag, horizontales Streichen, vertikales Streichen) als geeignete Eingabe in einem bestimmten Kontext (z. B. in einem bestimmtne Modus einer ersten Anwendung) erkannt, und andere, unterschiedliche Sätze von berührungsbasierten Gesten werden als geeignete Eingabe in anderen Kontexten (z. B. unterschiedliche Anwendungen und/oder unterschiedliche Modi oder Kontexte innerhalb der ersten Anwendung) erkannt. Als Ergebnis können die Software und Logik, die für die Erkennung von und die Antwort auf berührungsbasierte Gesten erforderlich sind, komplex werden, und können Nachprüfung erfordern jedes Mal, wenn eine Anwendung aktualisiert wird oder eine neue Anwendung zu dem Rechengerät hinzugefügt wird.
In den unten beschriebenen Ausführungsformen sind berührungsbasierte Gesten Ereignisse. Bei Erkennen eines vorbestimmten Ereignisses, z. B. eines Ereignisses, das einer vorherigen Eingabe im gegenwärtigen Kontext einer Anwendung entspricht, wird Information bezüglich des Ereignisses an die Anwendung geliefert. Im Kontext des Dokuments entsprechen alle berührungsbasierten Gesten Ereignissen. Ferner wird jedes jeweilige Ereignis als eine Reihenfolge von Unterereignissen definiert. Bei Geräten, die ein Multitouch-Anzeigegerät (oft hier als „Bildschirme” bezeichnet) oder andere multitouch-empfindliche Oberflächen aufweisen, und die multitouch-basierte Gesten annehmen, können die Unterereignisse, die ein multitouch-basiertes Ereignis definieren, Multitouch-Unterereignisse (zwei oder mehrere Finger sind erforderlich, um gleichzeitig in Kontakt mit der berührungsempfindlichen Oberfläche des Gerätes zu sein) enthalten. Zum Beispiel bei einem Gerät mit einer multitouch-empfindlichen Anzeige kann eine jeweilige Multitouch-Reihenfolge von Unterereignissen beginnen, wenn ein Finger des Benutzers den Bildschirm zuerst berührt. Zusätzliche Unterereignisse können geschehen, wenn ein oder mehrere zusätzliche Finger nacheinander folgend oder gleichzeitig den Bildschirm berühren, und andere Unterereignisse können jedoch geschehen, wenn alle diese Finger, die den Bildschirm berühren, sich quer durch den Bildschirm bewegen. Die Reihenfolge wird beendet, wenn der letzte der Finger des Benutzers von dem Bildschirm abgehoben wird.
Wenn berührungsbasierten Gesten verwendet werden, um eine Anwendung zu steuern, die auf einem Gerät mit einer berührungsempfindlichen Oberfläche läuft, haben Berührungen sowohl zeitliche als auch räumliche Aspekte. Der zeitliche Aspekt, als eine Phase genannt, weist darauf hin, wann eine Berührung gerade begonnen hat, ob es sich bewegt oder stehend ist, und wann es beendet wird – d. h. wann der Finger von dem Bildschirm abgehoben wird. Ein räumlicher Aspekt einer Berührung ist der Satz von Ansichten oder Benutzerschnittstellen-Fenstern, in denen die Berührung geschieht. Die Ansichten oder Fenster, in denen eine Berührung detektiert wird, können programmatischen Niveaus innerhalb einer programmatischen oder Ansichtenhierarchie entsprechen. Zum Beispiel kann die niedrigste Niveauansicht, in der eine Berührung detektiert wird, als die Schlagansicht genannt, und der Satz von Ereignissen, die als geeignete Eingabe erkannt werden, können basierend, mindestens zum Teil, auf der Schlagansicht der Anfangsberührung, die eine berührungsbasierte Geste beginnt, entschieden.
Die 1A und 1B sind Blockdiagramme, die elektronische Geräte 102 und 104 nach einigen Ausführungsformen darstellen. Die elektronischen Geräte 102 und 104 können jedes elektronische Gerät sein, das ein Desktop Computersystem, ein Laptop-Computersystem, Mobiltelefon, ein Smartphone, ein PDA oder ein Navigationssystem einschließt, aber sind nicht auf diese beschränkt. Das elektronische Gerät kann auch ein tragbares elektronisches Gerät mit einer Berührungsbildschirmanzeige (z. B. Anzeige 156, 1B), die konfiguriert ist, eine Benutzerschnittstelle darzustellen, ein Computer mit einer Berührungsbildschirmanzeige, die konfiguriert ist, eine Benutzerschnittstelle darzustellen, ein Computer mit einer berührungsempfindlichen Oberfläche und einer Anzeige, die konfiguriert ist, eine Benutzerschnittstelle darzustellen, oder jede andere Form von Rechengerät sein, einschließlich unterhaltungselektronischer Geräte, Mobiltelefone, Videospielsysteme, elektronischer Musikabspieler, Tablet-PCs, elektronischem Buchlesesystem, E-Büchern, PDAs, elektronischer Organizer, Email-Geräte, Laptops oder anderen Computern, Kiosk-Computern, Verkaufsautomaten, intelligenten Geräten usw., ohne darauf beschränkt zu werden. Die elektronischen Geräte 102 und 104 können jeweils Benutzerschnittstellen 113-A und 113-B enthalten.
In einigen Ausführungsformen enthalten die elektronischen Geräte 102 und 104 eine Berührungsbildschirmanzeige. In diesen Ausführungsformen kann die Benutzerschnittstelle 113 (z. B. 113-A oder 113-B) eine Bildschirmtastatur (nicht dargestellt) enthalten, die von einem Benutzer verwendet wird, um mit den elektronischen Geräten 102 und 104 zu interagieren. Alternativ kann eine Tastatur von den elektronischen Geräten 102 und 104 getrennt und unterschieden werden. Zum Beispiel kann eine Tastatur eine verdrahtete oder drahtlose Tastatur sein, die an die elektronischen Geräte gekoppelt ist.
In einigen Ausführungsformen enthält ein elektronisches Gerät 102 eine Anzeige 126 und eines oder mehrere Eingabegeräte 128-A (z. B. Tastatur, Maus, Track-Ball, Mikrofon, physikalische Taste(n), Berührungsfeld, usw.), die an das elektronische Gerät 102 gekoppelt sind. In diesen Ausführungsformen können eine oder mehrere der Eingabegeräte 128-A wahlweise von dem elektronischen Gerät 102 getrennt oder unterschieden werden. Zum Beispiel können das eine oder die mehreren Eingabegeräte ein oder mehrere enthalten von: eine Tastatur, eine Maus, ein Track-Feld, ein Track-Ball, einen elektronischen Stift, jeder von denen wahlweise von dem elektronischen Gerät getrennt werden kann. Wahlweise kann das Gerät 102 oder 104 einen oder mehrere Sensoren 130 enthalten, z. B. einen oder mehrere Beschleunigungsmesser, Gyroskope, GPS-Systeme, Lautsprecher, Infrarot(IR)-Sensoren, biometrische Sensoren, Kameras, usw. Es wird darauf hingewiesen, dass die obige Beschreibung von verschiedenen beispielhaften Geräten als Eingabegeräte 128 oder als Sensoren 130 für die Operationen der hier beschriebenen Ausführungsformen von keiner Bedeutung ist, und dass jedes Eingabe- oder Sensorgerät, das hier als Eingabegerät beschrieben wird, ebenso als ein Sensor beschrieben werden kann, und umgekehrt. In einigen Ausführungsformen werden Signale, die durch einen oder mehrere Sensoren 130 erzeugt werden, als Eingabequellen zum Detektieren von Ereignissen verwendet.
In einigen Ausführungsformen enthält das elektronische Gerät 104 eine berührungsempfindliche Anzeige 156 (z. B. eine Anzeige mit einer berührungsempfindlichen Oberfläche) und ein oder mehrere Eingabegeräte 128-B, die zu dem elektronischen Gerät 104 gekoppelt sind. In einigen Ausführungsformen ist die berührungsempfindliche Anzeige 156 in der Lage, zwei oder mehrere unterschiedliche, gleichzeitige (oder zum Teil gleichzeitige) Berührungen zu detektieren, und in diesen Ausführungsformen wird die Anzeige 156 manchmal als eine Multitouch-Anzeige oder Multitouch-empfindliche Anzeige genannt.
In einigen Ausführungsformen des hier diskutierten elektronischen Gerätes 102 oder 104, werden die Eingabegeräte 128 in dem elektronischen Gerät 102 oder 104 eingerichtet. In einigen Ausführungsformen ist eines oder mehrere der Eingabegeräte 128 von dem elektronischen Gerät 102 oder 104 getrennt und unterschieden; z. B. ein oder mehrere Eingabegeräte 128 können zu den elektronischen Geräten 102 oder 104 durch ein Kabel (z. B. USB-Kabel) oder drahtlose Verbindung (z. B. Bluetooth-Verbindung) gekoppelt werden.
Wenn die Eingabegeräte 128 verwendet werden, oder wenn eine berührungsbasierte Geste auf der berührungsempfindlichen Anzeige 156 eines elektronischen Gerätes 102 oder 104 durchgeführt wird, erzeugt der Benutzer jeweils eine Reihenfolge von Unterereignissen, die durch einen oder mehrere CPUs 110 des elektronischen Gerätes 102 oder 104 bearbeitet werden. In einigen Ausführungsformen bearbeiten der eine oder die mehreren CPUs 110 des elektronischen Gerätes 102 oder 104 die Reihenfolge von Unterereignissen, um Ereignisse zu erkennen.
Das elektronische Gerät 102 oder 104 enthält typischerweise jeweils eine oder mehrere Einzel- oder Multikernverarbeitungseinheiten („CPU” oder „CPUs”) 110 sowie eines oder mehrere Netzwerke oder andere Kommunikationsschnittstellen 112. Das elektronische Gerät 102 oder 104 enthält jeweils Speicher 111 und einen oder mehrere Kommunikationsbusse 115 zum Miteinander-Verbinden von diesen Komponenten. Die Kommunikationsbusse 115 können Schaltungen (manchmal als ein Chip-Satz genannt) enthalten, die die Kommunikation zwischen Systemkomponenten (hier nicht dargestellt) miteinander verbindet und steuert. Wie oben kurz diskutiert, enthalten die elektronischen Geräte 102 oder 104 wahlweise Benutzerschnittstelle 113, die jeweils eine Anzeige 126 und Multitouch-Anzeige 156 enthalten. Ferner enthalten die elektronischen Geräte 102 und 104 typischerweise Eingabegeräte 128 (z. B. Tastatur, Maus, Berührungsbildschirme, berührungsempfindliche Oberfläche, Multiberührungsbildschirme, Tastenfelder, usw.). In einigen Ausführungsformen enthalten die Eingabegeräte ein Bildschirmeingabegerät (z. B. eine berührungsempfindliche Oberfläche eines Anzeigegerätes). Speicher 111 kann Hochgeschwindigkeits-RAM enthalten, z. B. D-RAM, S-RAM, DDR-RAM oder andere Festkörper RAM-Geräte; und können nichtflüchtige Speicher enthalten, wie zum Beispiel ein oder mehrere Magnetplattenspeichergeräte, optische Plattenspeichergeräte, Flash-Speichergeräte oder andere nichtflüchtige Festkörperspeichergeräte. Speicher 111 kann wahlweise ein oder mehrere Speichergeräte, die von den CPU(s) 110 entfernt gelegen sind, enthalten. Speicher 111 oder alternativ das nichtflüchtige Speichergeräte) innerhalb des Speichers 111, weisen ein computerlesbares Speichermedium auf. In einigen Ausführungsformen speichert der Speicher 111 die folgenden Programme, Module und Datenstrukturen, oder einen Untersatz davon:

• ein Betriebssystem 118, das Prozeduren zum Handhaben von verschiedenen grundlegenden Systemdienstleistungen und zum Durchführen von Hardware-abhängigen Aufgaben enthält;
• ein Kommunikationsmodul 120 (jeweils in elektronischen Geräten 102 und 104), das verwendet wird, um das elektronische Gerät 102 oder 104 jeweils mit anderen Geräten über ihre eine oder mehrere jeweilige Kommunikationsschnittstelle 112 (verdrahtet oder drahtlos) und eines oder mehrere Kommunikationsnetzwerke, wie zum Beispiel das Internet, andere Wide Area Networks, Local Area Networks, Metropolitan Area Networks, usw. zu verbinden;
• ein Ereignisliefersystem 122 (jeweils in den elektronischen Geräten 102 und 104) das in verschiedenen alternativen Ausführungsformen innerhalb des Betriebssystems 118 oder in der Anwendungs-Software 124 implementiert werden kann;
• in einigen Ausführungsformen werden dennoch einige Aspekte des Ereignisliefersystems 122 in dem Betriebssystem 118 implementiert, während andere Aspekte in Anwendungs-Software 124 implementiert werden;
• eine oder mehrere Anwendungen jeweils in Anwendungs-Software 124 (z. B. eine Email-Anwendung, eine Webbrowser-Anwendung, eine Textnachrichtenanwendung, usw.).

Jedes der oben identifizierten Elemente kann in einem oder mehreren der zuvor erwähnten Speichergeräte gespeichert werden, und entspricht einem Satz von Anweisungen zum Durchführen von hier beschriebenen Funktionen. Der Satz von Anweisungen kann durch einen oder mehreren Prozessoren (z. B. den einen oder die mehreren CPUs 110) durchgeführt werden. Die oben identifizierten Module oder Programme (d. h. Sätze von Anweisungen) brauchen nicht als separate Software-Programme, Prozeduren oder Module implementiert zu werden und daher können verschiedene Untersätze von diesen Modulen kombiniert oder anderenfalls in verschiedenen Ausführungsformen neu arrangiert werden. In einigen Ausführungsformen kann Speicher 111 einen Untersatz der oben identifizierten Module und Datenstrukturen speichern. Ferner kann Speicher 111 zusätzliche Module und Datenstrukturen, die oben nicht beschrieben sind, speichern.
2 ist ein Diagramm eines Eingabe-/Ausgabeverarbeitungsstacks 200 eines beispielhaften Gerätes oder Vorrichtung (z. B. Gerät 102 oder 104) nach einigen Ausführungsformen der Erfindung. Die Hardware (z. B. elektronische Schaltung) 212 des Gerätes befindet sich auf dem Basisniveau des Eingabe-/Ausgabeverarbeitungsstacks 200. Hardware 212 kann verschiedene Hardwareschnittstellenkomponenten, wie z. B. die in 1A und/oder 1B dargestellten Komponenten enthalten. Hardware 212 kann auch einen oder mehrere der oben erwähnten Sensoren 130 enthalten. Alle diese anderen Elemente (202–210) des Eingabe-/Ausgabeverarbeitungsstacks 200 sind Softwareprozeduren, oder Teile von Softwareprozeduren, die die von der Hardware 212 empfangene Eingabe bearbeiten und verschiedene Ausgaben erzeugen, die durch eine Hardwarebenutzerschnittstelle (z. B. eine oder mehrere von einer Anzeige, Lautsprechern, Geräteschwingungsauslöser) dargestellt werden.
Ein Treiber oder ein Satz von Treibern 210 kommuniziert mit der Hardware 212. Die Treiber 210 können die von der Hardware 212 empfangenen Eingabedaten empfangen und bearbeiten. Ein Kernbetriebssystem („OS”) 208 kann mit dem Treiber (den Treibern) 210 kommunizieren. Das Kern-OS 208 kann die von dem Treiber (den Treibern) 210 empfangenen Roheingabedaten verarbeiten. In einigen Ausführungsformen können die Treiber 210 als ein Teil des Kern-OS 208 gedacht werden.
Ein Satz von OS-Anwendungsprogrammierschnittstellen („OS APIs”) 206 sind Softwareprozeduren, die mit dem Kern-OS 208 kommunizieren. In einigen Ausführungsformen sind die APIs 206 in dem Betriebssystem des Gerätes enthalten, aber auf einem Niveau oberhalb des Kern-OS 208. Die APIs 206 werden für die Verwendung durch Anwendungen, die auf den hier diskutierten elektronischen Geräten oder Vorrichtungen laufen, entworfen. Benutzerschnittstelle (UI) APIs 204 können die OS APIs 206 benutzen. Anwendungssoftware („Anwendungen”) 202, die auf dem Gerät läuft, kann die UI APIs 204 benutzen, um mit dem Benutzer zu kommunizieren. Die UI APIs 204 können wiederum mit Niedrigniveauelementen kommunizieren, schließlich mit verschiedener Benutzerschnittstellenhardware z. B. Multitouch-Anzeige 156.
Während jede Schicht des Eingabe-/Ausgabeverarbeitungsstacks 200 die darunterliegende Schicht benutzen kann, ist dies nicht immer erforderlich. Z. B. in einigen Ausführungsformen können Anwendungen 202 gelegentlich mit OS APIs 206 kommunizieren. Im Allgemeinen können Schichten bei oder oberhalb der OS-API-Schicht 206 nicht direkt auf das Kern-OS 208, Treiber 210, oder Hardware 212 zugreifen, weil diese Schichten als privat gedacht werden. Anwendungen in Schicht 202 und der UI API 204 rufen normalerweise die OS API 206 direkt auf, welche wiederum auf die Schichten Kern-OS 208, Treiber 210, und Hardware 212 zugreift.
Auf andere Weise erläutert, detektieren ein oder mehrere Hardwareelemente 212 des elektronischen Gerätes 102 oder 104, und Software, die auf dem Gerät läuft, wie z. B. Treiber 212 (in 2 dargestellt), Kern-OS (Betriebssystem) 208 (in 2 dargestellt, Betriebssystem API Software 206 (in 2 dargestellt), Anwendung und Benutzerschnittstellen API Software 204 (in 2 dargestellt) Eingabeereignisse (die Unterereignissen in einer Geste entsprechen können) bei einem oder mehreren des Eingabegerätes (der Eingabegeräte) 128 und/oder einer berührungsempfindlichen Anzeige 156, und erzeugen oder aktualisieren verschiedene Datenstrukturen (im Speicher des Gerätes 102 oder 104 gespeichert), die durch einen Satz von gegenwärtig aktiven Ereigniserkennern verwendet werden, um festzustellen, ob und wann die Eingabeereignisse einem Ereignis entsprechen, das an Anwendung 202 zu liefern ist. Ausführungsformen von Ereigniserkennungsmethodologien, Vorrichtungen und Computerprogrammprodukten sind unten ausführlicher beschrieben.
3A stellt eine beispielhafte Ansichtshierarchie 300 dar, die in diesem Beispiel ein Suchprogramm ist, das in äußerster Ansicht 302 angezeigt wird. Äußerste Ansicht 302 schließt normalerweise die Gesamtbenutzerschnittstelle ein, mit der ein Benutzer direkt interagieren kann, und enthält untergeordnete Ansichten, z. B.

• Suchergebnisfeld 304, das Suchergebnisse gruppiert und vertikal gescrollt werden kann;
• Suchfeld 306, das Texteingabe entfernt;
• eine Homezeile 310, die Anwendungen für Schnellzugriff gruppiert.

In diesem Beispiel enthält jede untergeordnete Ansicht Niedrigniveau untergeordnete Ansichten. In anderen Beispielen kann die Anzahl der Ansichtenniveaus in der Hierarchie 300 in unterschiedlichen Abzweigen der Hierarchie unterscheiden, wobei eine oder mehrere untergeordnete Ansichten Niedrigniveau untergeordnete Ansichten haben, und eine oder mehrere andere untergeordnete Ansichten haben keine solchen Niedrigniveau untergeordnete Ansichten. Mit diesem in 3A dargestellten Beispiel fortgesetzt, enthält das Suchergebnisfeld 304 getrennt untergeordnete Ansichten 305 (dem Feld 304 untergeordnet) für jedes Suchergebnis. Hier zeigt das Beispiel ein Suchergebnis in einer untergeordneten Ansicht, die die Kartenansicht 305 genannt wird. Suchfeld 306 enthält eine untergeordnete Ansicht, die hier die Läsche-Inhalte-Icon Ansicht 307 genannt wird, die die Inhalte des Suchfelds löscht, während der Benutzer eine bestimmte Aktion (z. B. eine Einzelberührung oder Schlaggeste) auf dem Lösche-Inhalte-Icon in der Ansicht 307 durchführt. Homezeile 310 enthält untergeordnete Ansichten 310-1, 310-2, 310-3, und 310-4, die jeweils einer Kontaktanwendung, einer Emailanwendung, einem Webbrowser, und einer iPod-Musikschnittstelle entsprechen.
Ein Berührungsunterereignis 301-1 wird in der äußersten Ansicht 302 dargestellt. Ist die Position des Berührungsunterereignisses 301-1 über sowohl dem Suchergebnisfeld 304, als auch Kartenansicht 305 gegeben, wird das Berührungsunterereignis auch über diesen Ansichten jeweils als 301-2 und 301-3 dargestellt. Aktiv involvierte Ansichten des Berührungsunterereignisses enthalten die Ansichten-Suchergebnis-Felder 304, Kartenansicht 305 und äußerste Ansichten 302. Zusätzliche Informationen bezüglich Unterereignislieferung und aktiv involvierter Ansichten werden unten bezugnehmend auf 3B und 3C bereitgestellt.
Ansichten (und entsprechende programmatische Niveaus) können verschachtelt werden. Mit anderen Worten können Ansichten andere Ansichten enthalten. Folglich kann das Softwareelement (die Softwareelemente) (z. B. Ereigniserkenner), die mit einer ersten Ansicht assoziiert ist, ein oder mehrere Softwareelemente, die mit Ansichten innerhalb der ersten Ansicht assoziiert sind, enthalten oder mit diesen verbunden werden. Während einige Ansichten mit Anwendungen assoziiert werden können, können andere mit Hochniveau-OS-Elementen, wie z. B. graphischen Benutzerschnittstellen, Fenstermanagern, usw. assoziiert werden.
Um folgende Diskussion zu vereinfachen, wird Bezug allgemein nur auf Ansichten und die Ansichtshierarchie genommen, aber es muss verstanden werden, dass in einigen Ausführungsformen das Verfahren mit einer programmatischen Hierarchie mit einer Mehrzahl von programmatischen Schichten, und/oder einer Ansichtshierarchie funktionieren kann.
3B und 3C stellen beispielhafte Verfahren und Strukturen dar, die zu Ereigniserkennern relevant sind. 3B stellt Verfahren und Datenstrukturen für Ereignishandhabung dar, wenn Ereignishandler mit bestimmten Ansichten innerhalb einer Hierarchie von Ansichten assoziiert sind. 3C stellt Verfahren und Datenstrukturen für Ereignishandhabung dar, wenn Ereignishandler mit bestimmten Niveaus innerhalb einer Hierarchie von programmatischen Niveaus assoziiert sind. Ereigniserkenner-Globalverfahren 312 und 350 enthalten jeweils Schlagansichten und Schlagniveauentscheidungsmodule 314 und 352, aktive Ereigniserkenner-Entscheidungsmodule 316 und 354, und Unterereignisliefermodule 318 und 356.
Schlagansicht und Schlagniveauentscheidungsmodule 314 und 352 stellen jeweils Softwareprozeduren bereit, um festzustellen, wo ein Unterereignis innerhalb einer oder mehrerer Ansichten, z. B. der in 3A dargestellten beispielhaften Ansichtshierarchie 300, die drei Hauptabzweige hat, geschehen ist.
Das Schlagansicht-Entscheidungsmodul 314 der 3B empfängt Information bezüglich eines Unterereignisses, z. B. einer Benutzerberührung, die als 301-1 auf der äußersten Ansicht 302, auf einem Suchergebnis (Kartenansicht 305) und der Suchergebnisfeldansicht 304 dargestellt wird. Das Schlagansicht-Entscheidungsmodul 314 identifiziert eine Schlagansicht als die niedrigste Ansicht in der Hierarchie, die das Unterereignis handhaben soll. In meisten Umständen ist die Schlagansicht die niedrigste Niveauansicht, in der ein beginnendes Unterereignis (z. B. das erste Unterereignis in der Reihenfolge von Unterereignissen, die ein Ereignis oder potenzielles Ereignis bilden) geschieht. Sobald Die Schlagansicht identifiziert wird, wird es alle untergeordneten Ereignisse bezüglich der gleichen Berührung oder Eingabequelle empfangen, für die die Schlagansicht identifiziert wird.
In einigen Ausführungsformen kann das Schlagniveauentscheidungsmodul 352 der 3C einen ähnlichen Prozess benutzen.
Aktive Ereigniserkenner-Entscheidungsmodule 316 und 354 der Ereigniserkenner-Globalverfahren 312 und 350 entscheiden jeweils, welche Ansicht oder Ansichten innerhalb einer Ansichtshierarchie eine bestimmte Reihenfolge von Unterereignissen empfangen sollen. 3A stellt einen beispielhaften Satz von aktiven Ansichten 302, 304, und 305 dar, die das Unterereignis 301 empfangen. In dem Beispiel von 3A wird das aktive Ereigniserkenner-Entscheidungsmodul 304 entscheiden, dass die höchste Niveauansicht 302, Suchergebnisfelder 304 und Kartenansicht 305 aktiv involvierte Ansichten sind, weil diese Ansichten die physikalische Position der Berührung enthalten, die durch Unterereignis 301 dargestellt wird. Es wird darauf hingewiesen, dass selbst wenn Berührungsunterereignis 301 insgesamt auf das Gebiet eingeschränkt wird, das mit Kartenansicht 305 assoziiert ist, Suchergebnisfelder 304 und höchste Niveauansicht 302 noch in den aktiv involvierten Ansichten bleiben werden, weil das Suchergebnisfeld 304 und die höchste Niveauansicht 302 Vorläufer der Kartenansicht 305 sind.
In einigen Ausführungsformen benutzen aktive Ereigniserkenner-Entscheidungsmodule 316 und 354 ähnliche Prozesse.
Unterereignisliefermodul 318 liefert Unterereignisse an Ereigniserkenner für aktiv involvierte Ansichten. Benutzen wir das Beispiel von 3A, wird eine Berührung des Benutzers in unterschiedlichen Ansichten der Hierarchie durch Berührungsmarken 301-1, 301-2, und 301-3 repräsentiert. In einigen Ausführungsformen werden Unterereignisdaten, die diese Berührung des Benutzers repräsentieren, durch das Unterereignisliefermodul 318 an Ereigniserkenner bei den aktiv involvierten Ansichten, d. h. höchste Niveauansicht 302, Suchergebnisfeld 304, und Kartenansicht 305 geliefert. Ferner können Ereigniserkenner einer Ansicht nachfolgende Unterereignisse eines Ereignisses empfangen, das mit der Ansicht (z. B. wenn ein Anfangsunterereignis innerhalb der Ansicht geschieht) beginnt. Auf andere Weise erläutert, kann eine Ansicht Unterereignisse empfangen, die mit Benutzerinteraktionen assoziiert sind, die in der Ansicht beginnen, selbst wenn es außerhalb der Ansicht fortgesetzt wird.
In einigen Ausführungsformen liefert Unterereignisliefermodul 356 Unterereignisse an Ereigniserkenner für aktiv involvierte programmatische Niveaus in einem Prozess, der ähnlich zu dem ist, der durch Unterereignisliefermodul 318 verwendet wird.
In einigen Ausführungsformen wird eine getrennte Ereigniserkennerstruktur 320 oder 360 für jeden aktiv involvierten Ereigniserkenner erzeugt und im Speicher des Gerätes gespeichert. Ereigniserkennerstrukturen 320 und 360 enthalten typischerweise jeweils einen Ereigniserkennerzustand 334, 374 (wird unten ausführlicher diskutiert, wenn Bezug auf 4A und 4B genommen wird), und jeweils ereigniserkennerspezifische Codes 338, 378, die jeweils Zustandsmaschinen 340, 380 aufweisen. Ereigniserkennerstruktur 320 enthält auch einen Ansichtshierarchieverweis 336, während Ereigniserkennerstruktur 360 einen programmatischen Hierarchieverweis 376 enthält. Jedes Beispiel eines bestimmten Ereigniserkenners bezieht sich exakt auf eine Ansicht oder ein programmatisches Niveau. Ansichtshierarchieverweis 336 oder programmatischer Hierarchieverweis 376 (für einen bestimmten Ereigniserkenner) werden verwendet, um festzulegen, welche Ansicht oder welches programmatische Niveau logisch an den jeweiligen Ereigniserkenner gekoppelt ist.
Ansichts-Metadaten 341 und Niveau-Metadaten 381 können jeweils Daten bezüglich einer Ansicht oder eines Niveaus enthalten. Ansichts- oder Niveau-Metadaten können mindestens die folgenden Eigenschaften erhalten, die die Unterereignislieferung an Ereigniserkenner beeinflussen können:

• Eine Stopeigenschaft 342, 382, die, wenn für eine Ansicht oder programmatisches Niveau eingestellt, Unterereignislieferung an Ereigniskenner verhindert, die mit der Ansicht oder programmatischem Niveau sowie ihren Vorläufern in der Ansicht oder programmatischen Hierarchie assoziiert sind.
• Eine Sprungeigenschaft 343, 383, die, wenn für eine Ansicht oder programmatisches Niveau eingestellt, Unterereignislieferung an Ereigniserkenner verhindert, die mit dieser Ansicht oder diesem programmatischen Niveau assoziiert sind, aber Unterereignislieferung an ihre Vorläufer in der Ansicht oder programmatischen Hierarchie erlaubte.
• Eine Kein-Schlag-Sprungeigenschaft 344, 384, die, wenn für eine Ansicht eingestellt, Lieferung von Unterereignissen an Ereigniserkenner verhindert, die mit der Ansicht assoziiert sind, sofern die Ansicht keine Schlagansicht ist. Wie oben diskutiert, identifizierte das Schlagansicht-Entscheidungsmodul eine Schlagansicht (oder Schlagniveau im Fall des Schlag-Niveau-Entscheidungsmoduls 352) als die niedrigste Ansicht in der Hierarchie, die das untere Ereignis handhaben soll.

Ereigniserkennungsstrukturen 320 und 360 können Metadaten 322, 362, jeweils enthalten. In einigen Ausführungsformen enthalten die Metadaten 322, 362 konfigurierbare Eigenschaften, Flags, und Listen, die angeben, wie das Ereignisliefersystem Unterereignislieferer an aktiv involvierte Ereigniserkenner durchführen soll. In einigen Ausführungsformen können Metadaten 322, 362 konfigurierbare Eigenschaften, Flags, und Listen enthalten, die angeben, wie Ereigniserkenner miteinander interagieren können. In einigen Ausführungsformen können Metadaten 322, 362 konfigurierbare Eigenschaften, Flags, und Listen enthalten, die angeben, ob Unterereignisse an verschiedenen Niveaus in der Ansicht oder programmatischen Hierarchie geliefert werden. In einigen Ausführungsformen werden die Kombination von Ereigniserkenner-Metadaten 322, 362 als auch Ansichts- oder Niveau-Metadaten (341, 381 jeweils) verwendet, um das Ereignisliefersystem zu konfigurieren: a) Unterereignislieferung an aktiv involvierte Ereigniserkenner durchzuführen, b) anzugeben, wie Ereigniserkenner miteinander interagieren können und c) anzugeben, ob und wann Unterereignisse an verschiedenen Niveaus in der Ansicht oder programmatischen Hierarchie geliefert werden.
Es wird darauf hingewiesen, dass in einigen Ausführungsformen ein jeweiliger Ereigniserkenner eine Ereigniserkennungsaktion 333, 373 an sein jeweiliges Ziel 335, 375 sendet, wie durch Felder der Ereigniserkennerstruktur 320, 360 spezifiziert wird. Das Senden einer Aktion an ein Ziel unterscheidet sich von dem Senden (und verzögertem Senden) von Unterereignissen an eine jeweilige Schlagansicht oder – Niveau.
Die Metadaten-Eigenschaften, die in einer jeweiligen Ereigniserkennerstruktur 320, 360 eines entsprechenden Ereigniserkenners gespeichert sind, enthalten mindestens:

• ein Ausschließlichkeits-Flag 324, 364, das, wenn für einen Ereigniserkenner eingestellt, angibt, dass beim Erkennen eines Ereignisses durch den Ereigniserkenner das Ereignisliefersystem die Lieferung von Unterereignissen an irgendwelche Ereigniserkenner der aktiv involvierten Ansichten oder programmatischen Niveaus (mit der Ausnahme von irgendwelchen Ereigniserkennern, die in einer Ausnahmeliste 326, 366 aufgelistet sind) stoppen soll. Wenn der Empfang eines Unterereignisses einen bestimmten Ereigniserkenner dazu veranlasst, in den ausschließlichen Zustand einzutreten, wie durch sein entsprechendes Ausschließlichkeits-Flag 324 oder 364 angegeben wird, werden dann nachfolgende Unterereignisse nur an den Ereigniserkenner in den ausschließlichen Zustand (sowie irgendwelche andere Ereigniserkenner, die in einer Ausnahmeliste 326, 366 aufgelistet sind) geliefert.
• einige Ereigniserkennerstrukturen 320, 360 können eine Ausschließlichkeits-Ausnahmeliste 326, 366 aufweisen. Wenn in der Ereigniserkennerstruktur 320, 360 für einen jeweiligen Ereigniserkenner enthalten wird, gibt diese Liste 326, 366 den Satz von Ereigniserkennern an, wenn irgendwelche, die mit dem Empfang von Unterereignissen fortzusetzen sind, selbst wenn der jeweilige Ereigniserkenner in den Ausschließlichkeitszustand eingetreten ist. Zum Beispiel, wenn der Ereigniserkenner für ein Einzelschlagereignis in den ausschließlichen Zustand eintritt, und die gegenwärtig involvierten Ansichten einen Ereigniserkenner für ein Doppelschlagereignis enthalten, würde die Liste 320, 360 dann den Doppelschlag Ereigniserkenner auflisten, sodass ein Doppelschlagereignis erkannt werden kann, selbst wenn ein Einzelschlagereignis detektiert worden ist. Daher erlaubt die Ausschließlichkeits-Ausnahmeliste 326, 366 es den Ereigniserkennern, unterschiedliche Ereignisse zu erkennen, die gleiche Reihenfolgen von Unterereignissen teilen, zum Beispiel eine Einzelschlagereigniserkennung schließt nachfolgende Erkennung eines Doppel- bzw. Triple-Schlagereignisses durch andere Ereigniserkenner nicht aus.
• einige Ereigniserkennerstrukturen 320, 360 können eine Warteliste 327, 367 enthalten. Wenn in der Ereigniserkennerstruktur 320, 360 für einen jeweiligen Ereigniserkenner enthalten wird, gibt diese Liste 327, 367 den Satz von Ereigniserkennern an, wenn irgendwelche, die in den Ereignis-unmöglich- oder Ereignis-gelöscht-Zustand eintreten müssen, bevor der jeweilige Ereigniserkenner ein jeweiliges Ereignis erkenne kann. In der Tat haben die aufgelisteten Ereigniserkenner höhere Priorität für die Erkennung eines Ereignisses als die Ereigniserkenner mit der Warteliste 327, 367.
• ein Verzögerungsberührung-beginnt-Flag 328, 368, das, wenn für einen Ereigniserkenner eingestellt, den Ereigniserkenner dazu veranlasst, das Senden von Unterereignissen (einschließlich eines Berührung-beginnt oder Finger-nach-unten Unterereignisses, und nachfolgender Ereignisse) an die jeweilige Schlagansicht oder -Niveau des Ereigniserkenners zu verzögern, bis es festgestellt worden ist, dass die Reihenfolge von Unterereignissen der Ereignisart dieses Ereigniserkenners nicht entspricht. Dieses Flag kann verwendet werden, um zu verhindern, dass die Schlagansicht oder -Niveau jemals irgendwelche der Unterereignisse im Fall, dass die Liste erkannt wird, sieht. Wenn es dem Ereigniserkenner nicht gelungen ist, ein Ereignis zu erkennen, kann das Berührungsbeginn-Unterereignis (und nachfolgende Berührungsende-Unterereignis) an die Schlagansicht oder -Niveau geliefert werden. In einem Beispiel veranlasst die Lieferung solcher Unterereignisse an die Schlagansicht oder -Niveau die Benutzerschnittstelle dazu, ein Objekt kurz hervorzuheben, ohne die mit diesem Objekt assoziierte Aktion auszulösen.
• ein Verzögerungsberührungs-Endflag 330, 370, das, wenn für einen Ereigniserkenner eingestellt, den Ereigniserkenner dazu veranlasst, das Senden eines Unterereignisses (zum Beispiel eines Berührungsende-Unterereignisses) an die jeweilige Schlagansicht oder -Niveau des Ereigniserkenners zu verzögern, bis festgestellt worden ist, dass die Reihenfolge von Unterereignissen dieser Ereignisart des Ereigniserkenners nicht entspricht. Dies kann verwendet werden, um zu verhindern, dass die Schlagansicht oder -Niveau bei einem Berührungsende-Unterereignis, im Fall, dass die Liste später erkannt wird, agiert. Solange das Berührungsende-Unterereignis nicht gesendet wird, kann eine gelöschte Berührung an die Schlagansicht- oder Niveau gesendet werden. Wenn ein Ereignis erkannt wird, wird die entsprechende Aktion durch eine Anwendung durchgeführt, und das Berührungsende-Unterereignis wird an die Schlagansicht oder -Niveau geliefert.
• ein Berührungslöschungs-Flag 332, 372, das, wenn für einen Ereigniserkenner eingestellt, den Ereigniserkenner dazu veranlasst, Berührung- oder Eingabelöschung an die jeweilige Schlagansicht oder Schlagniveau des Ereigniserkenners zu senden, wenn es festgestellt worden ist, dass die Reihenfolge von Unterereignissen der Ereignisart dieses Ereigniserkenners nicht entspricht. Die Berührungs- und Eingabelöschung, die an die Schlagansicht oder -niveau gesendet wird, zeigt, dass ein vorhergehendes Unterereignis (zum Beispiel ein Berührungsbeginn-Unterereignis) gelöscht worden ist. Die Berührungs- oder Eingabelöschung kann den Eingabequelle-Handlerzustand (siehe 4b) dazu veranlassen, in den Eingabereihenfolge-gelöscht-Zustand 460 (wird unten diskutiert) einzutreten.

In einigen Ausführungsformen kann die Ausnahmeliste 326, 366 auch durch nicht ausschließliche Ereigniserkenner verwendet werden. Insbesondere, wenn ein nicht ausschließlicher Ereigniserkenner ein Ereignis erkennt, werden nachfolgende Unterereignisse nicht an die ausschließlichen Ereigniserkenner, die mit den gegenwärtigen aktiven Ansichten assoziiert sind, geliefert, bis auf diese ausschließlichen Ereigniserkenner, die in der Ausnahmeliste 326, 366 des Ereigniserkenners aufgelistet sind, der das Ereignis erkennt.
In einigen Ausführungsformen können Ereigniserkenner konfiguriert werden, um das Berührungslöschungs-Flag in Verbindung mit dem Verzögerungsberührungs-Endflag zu benutzen, um zu verhindern, dass unerwünschte nachfolgende Ereignisse an die Schlagansicht geliefert werden. Zum Beispiel sind die Definition einer Einzelschlaggeste und die erste Hälfte einer Doppelschlaggeste identisch. Sobald ein Ereigniserkenner einen Einzelschlag erfolgreich erkennt, kann eine unerwünschte Aktion geschehen. Wenn das Verzögerungsberührungs-Endflag eingestellt wird, wird verhindert, dass der Einzelschlag-Ereigniserkenner Unterereignisse an die Schlagansicht sendet, bis ein Einzelschlagereignis erkannt wird. Zusätzlich kann die Warteliste eines Einzelschlagereigniserkenners den Doppelschlagereigniserkenner identifizieren, wobei es folglich verhindert wird, dass der Einzelschlag-Ereigniserkenner einen Einzelschlag erkennt, bis der Doppelschlag-Ereigniserkenner in den Ereignis-unmöglich-Zustand eingetreten ist. Die Verwendung der Warteliste vermeidet die Ausführung von Aktionen, die mit einem Einzelschlag assoziiert sind, wenn eine Doppelschlaggeste durchgeführt wird. Stattdessen werden nur Aktionen, die mit einem Doppelschlag assoziiert werden, in Antwort auf Erkennung des Doppelschlagereignisses ausgeführt.
Wenden wir uns insbesondere an Formen der Benutzerberührungen auf berührungsempfindlichen Oberflächen, wie oben erläutert, Berührungen und Benutzergesten können eine Aktion enthalten, die nicht sofort sein muss, zum Beispiel kann eine Berührung einen Akt von Bewegung oder Halten eines Fingers gegen eine Anzeige für eine Zeitdauer enthalten. Eine Berührungsdatenstruktur definiert dennoch den Zustand einer Berührung (oder allgemeiner den Zustand jeder Eingabequelle) zu einer bestimmten Zeit. Daher können sich die in einer Berührungsdatenstruktur gespeicherten Felder über den Ablauf einer Einzelberührung ändern, wobei es ermöglicht wird, dass der Zustand der Einzelberührung zu unterschiedlichen Zeitpunkten an eine Anwendung zu übermitteln ist.
Jede Berührungsdatenstruktur kann verschiedene Felder aufweisen. In einigen Ausführungsformen können Berührungsdatenstrukturen Daten enthalten, die mindestens den Berührungs-spezifischen Feldern 339 in 3b oder den Eingabequelle-spezifischen Feldern 379 in 3c entsprechen.
Zum Beispiel kann ein „erste Berührung für Ansicht” Feld 345 in 3b (385 für „erste Berührung für Niveau” in 3c) zeigen, ob die Berührungsdatenstruktur die erste Berührung für die bestimmte Ansicht definiert (weil das Softwareelement, das die Ansicht implementiert, instantiiert wird). Ein „Zeitstempel” Feld 346, 386 kann die besondere Zeit zeigen, auf die sich die Berührungsdatenstruktur bezieht.
Wahlweise kann ein „Info”-Feld 347, 387 verwendet werden, um zu zeigen, ob eine Berührung eine rudimentäre Geste ist. Zum Beispiel kann das „Info”-Feld 347, 387 zeigen, ob die Berührung ein Streichen ist, und, wenn ja, in welche Richtung das Streichen ausgerichtet ist. Ein Streichen ist ein schnelles Schleppen eines oder mehrerer Finger in eine geradlinige Richtung. API-Implementationen (werden unten diskutiert) können bestimmen, ob eine Berührung ein Streichen ist, und diese Information an die Anwendung durch das „Info”-Feld 347, 387 übermitteln, daher wird der Einsatz einiger Datenverarbeitungen verringert, die notwendig gewesen wären, wenn die Berührung ein Streichen wäre.
Wahlweise kann ein „Schlagzähler”-Feld 348 in 3B („Ereigniszähler”-Feld 388 in 3C) zeigen, wie viele Schläge nacheinander folgend bei der Position der Anfangsberührung durchgeführt worden sind. Ein Schlag kann als ein schnelles Drücken und Abheben eines Fingers gegen ein berührungsempfindliches Feld bei einer bestimmten Position definiert werden. Mehrere nacheinander folgende Schläge können geschehen, wenn der Finger in schneller Folge bei der gleichen Position des Feldes wieder gedrückt und freigegeben wird. Ein Ereignisliefersystem 124 kann Schläge zählen und diese Information an eine Anwendung durch das „Schlagzähler”-Feld 348 übermitteln. Mehrere Schläge bei der gleichen Position werden manchmal als ein nützlicher und einfach zu merkender Befehl für Berührungsfelderschnittstellen gedacht. Daher kann durch Zählen von Schlägen das Ereignisliefersystem wieder einige Datenverarbeitung von der Anwendung verringern.
Ein „Phase”-Feld 349, 389 kann eine bestimmte Phase zeigen, in der sich die berührungsbasierte Geste gegenwärtig befindet. Das „Phase”-Feld 349, 389 kann verschiedene Werte haben, wie zum Beispiel „Berührungsphase begann”, die zeigen kann, dass die Berührungsdatenstruktur eine neue Berührung definiert, auf die kein Bezug durch vorherige Berührungsdatenstrukturen genommen worden ist. Ein „Berührungsphase bewegt”-Wert kann zeigen, dass die definierte Berührung von einer vorherigen Position sich bewegt hat. Ein „Berührungsphase stehend”-Wert kann zeigen, dass die Berührung in der gleichen Position geblieben ist. Ein „Berührungsphase beendet”-Wert kann zeigen, dass die Berührung beendet wird (z. B. der Benutzer hat seinen bzw. ihren Finger von der Oberfläche einer Multiberührungsanzeige abgehoben). Ein „Berührungsphase gelöscht”-Wert kann zeigen, dass die Berührung durch das Gerät gelöscht worden ist. Eine gelöschte Berührung kann eine Berührung sein, die nicht durch einen Benutzer beendet werden muss, aber die das Gerät entschieden hat zu ignorieren. Zum Beispiel kann das Gerät bestimmen, dass die Berührung unabsichtlich erzeugt wird (d. h. als Ergebnis vom Legen eines tragbaren multiberührungsfähigen Gerätes in jemandes Tasche) und die Berührung für diesen Grund ignorieren. Jeder Wert des „Phase”-Feldes 349, 389 kann eine ganze Zahl sein.
Daher kann jede Berührungsdatenstruktur definieren, was mit einer Berührung (oder anderen Eingabequelle) zu einer bestimmten Zeit geschieht (z. B. ob die Berührung stehend ist, bewegt wird, usw.) sowie andere Information, die mit der Berührung (wie z. B. Position) assoziiert ist. Folglich kann jede Berührungsdatenstruktur den Zustand einer bestimmten Berührung zu einem bestimmten Zeitpunkt definieren. Eine oder mehrere Berührungsdatenstruktur, die sich auf die gleiche Zeile beziehen, können in eine Berührungsereignisdatenstruktur hinzugefügt werden, die die Zustände aller Berührungen definiert, die eine bestimmte Ansicht zu einem bestimmten Zeitpunkt empfängt (wie oben bemerkt, können sich einige Berührungsdatenstrukturen auch auf Berührungen beziehen, die beendet sind und nicht mehr empfangen werden). Multitouch-Ereignisstrukturen können im Laufe der Zeit an die Software gesendet werden, die eine Ansicht implementiert, um die Software mit kontinuierlichen Informationen auszustatten, die die Berührungen beschreiben, die in der Ansicht geschehen.
Die Fähigkeit, komplexe berührungsbasierte Gesten handzuhaben, wahlweise Multi-Touch-Gesten aufweisende, können Komplexität zu den verschiedenen Software-Elementen hinzufügen. In einigen Fällen kann solche zusätzliche Komplexität notwendig sein, um fortgeschrittene und gewünschte Schnittstellenmerkmale zu implementieren. Zum Beispiel kann ein Spiel die Fähigkeit erfordern, mehrere gleichzeitige Berührungen handzuhaben, die in unterschiedlichen Ansichten geschehen, weil Spiele oft das Drücken von mehreren Tasten zur gleichen Zeit oder das Kombinieren von Beschleunigungsmessdaten mit Berührungen auf einer berührungsempfindlichen Oberfläche erfordern. Einige einfacheren Anwendungen und/oder Ansichten (und ihre assoziierten Software-Elemente) brauchen dennoch keinen fortgeschrittenen Schnittstellenmerkmale. Zum Beispiel kann eine einfache Soft-Taste (d. h. eine Taste, die auf einer berührungsempfindlichen Anzeige angezeigt wird) in zufriedenstellender Weise mit Einzelberührungen funktionieren, statt Multi-Touch-Funktionalität. In diesen Fällen kann das unten liegende OS unnötige oder exzessive Berührungsdaten (z. B. Multi-Touch-Daten) an ein Software-Element senden, das mit einer Ansicht assoziiert ist, die beabsichtigt wird, nur durch Einzelberührungen (z. B. eine Einzelberührung oder Schlag auf eine Soft-Taste) zu funktionieren. Weil das Software-Element die Verarbeitung dieser Daten brauchen kann, kann es an Komplexität eines Software-Elements brauchen, das mehrere Berührungen handhabt, obwohl es mit einer Ansicht assoziiert ist, für die nur Einzelberührungen relevant sind. Dies kann die Kosten der Entwicklung von Software für dieses Gerät erhöhen, weil Software-Elemente, die traditionell in einer Mausschnittstellenumgebung (z. B. verschiedene Tasten usw.) einfach zu programmieren gewesen sind, in einer Multi-Touch-Umgebung viel komplizierter sind.
Es sollte noch verstanden werden, dass die vorherige Diskussion bezüglich der Komplexität von Evaluierung und Verarbeitung von Benutzerberührungen auf berührungsempfindlichen Oberflächen auch auf alle Formen von Benutzereingaben angewandt werden kann, um elektronische Geräte 102 und 104 mit Eingabegeräten, jeweils 128 und 158 zu bedienen, nicht alle von denen auf Berührungsbildschirmen initiiert werden, z. B. koordinierende Mausbewegungen oder Maustaste drücken mit oder ohne einzelne oder mehrere Tastaturdrücken oder Anhalten, Benutzerbewegungsschläge, Schleppen, Scrollen, usw. auf Berührungsfeldern, Stifteingabe, mündliche Anweisungen, detektierte Augenbewegungen, biometrische Eingabe, detektierte physiologische Änderung in einem Benutzer, und/oder irgendeine Kombination davon, die als Eingabe benutzt werden können, die Unterereignissen entsprechen, die ein zu erkennendes Ereignis definieren.
4A stellt eine Ereigniserkennerzustandsmaschine 400 dar, die vier Zustände enthält. Durch Verwaltung von Zustandsübergängen in Ergniserkennerzustandsmaschine 400 basierend auf empfangenen Unterereignissen, drückt ein Ereigniserkenner effektiv eine Ereignisdefinition aus. Zum Beispiel kann eine Schlaggeste effektiv durch eine Reihenfolge von zwei, oder wahlweise drei Unterereignisse definiert werden. Zuerst soll eine Berührung detektiert werden, und das wird Unterereignis 1. Zum Beispiel das Berührungsunterereignis kann die Berührung einer berührungsempfindlichen Oberfläche durch einen Finger des Benutzers in einer Ansicht sein, die den Ereigniserkenner mit Zustandsmaschine 400 enthält. Zweitens wird eine wahlweise gemessene Verzögerung, wobei die Berührung nicht wesentlich in irgendwelche gegebenen Richtungen bewegt wird (z. B. irgendeine Bewegung der Berührungsposition ist kleiner als eine vorbestimmte Schwelle, die aus einer Entfernung (z. B. 5 mm) oder als eine Anzahl von Pixeln (z. B. 5 Pixel) auf der Anzeige gemessen werden kann), und die Verzögerung genügend kurz ist, als Unterereignis 2 dienen. Letztendlich wird die Beendigung der Berührung (z. B. Abheben des Fingers des Benutzers von der berührungsempfindlichen Oberfläche) als Unterereignis 3 dienen. Durch Kodierung der Ereigniserkennerzustandsmaschine 400 zum Übergehen zwischen Zuständen basierend auf Empfangen von diesen Unterereignissen, drückt die Ereigniserkennerzustandsmaschine 400 effektiv eine Schlaggesten-Ereignisdefinition aus.
Ungeachtet der Ereignisart beginnt die Ereigniserkennerzustandsmaschine 400 in einem Ereigniserkennung-beginnt-Zustand 405, und kann zu irgendeinem der gebliebenen Zustände, abhängig davon, was für ein Unterereignis empfangen wird, fortschreiten. Um die Diskussion der Ereigniserkennerzustandsmaschine 400 zu vereinfachen, werden die direkten Wege von dem Ereigniserkennung-beginnt-Zustand 405 zu dem Ereignis-erkannt-Zustand 415, dem Ereignis-möglich-Zustand 410 und Ereignis-unmöglich-Zustand 420 diskutiert, gefolgt durch eine Beschreibung der Wege, die von dem Ereignis-möglich-Zustand 410 führen.
Von Ereigniserkennung-beginnt-Zustand 405 ausgehend, wenn ein Unterereignis empfangen wird, das selbst die Ereignisdefinition für ein Ereignis aufweist, wird die Ereigniserkennerzustandsmaschine 400 auf Ereignis-erkannt-Zustand 415 übergehen.
Vom Zustand Ereigniserkennung beginnt 405 ausgehend, wenn ein Unterereignis empfangen wird, das nicht das erste Unterereignis in einer Ereignisdefinition ist, wird die Ereigniserkenner-zustandsmaschine 400 auf Ereignis-unmöglich-Zustand 420 übergehen.
Vom Ereigniserkennung-beginnt-Zustand 405 ausgehend, wenn ein Unterereignis empfangen wird, das das erste und nicht das letzte Unterereignis in einer gegebenen Ereignisdefinition ist, wird die Ereigniserkennerzustandsmaschine 400 auf Ereignismöglich-Zustand 410 übergehen. Wenn das nächste empfange Unterereignis ein zweites Unterereignis, aber nicht das letzte Unterereignis in der gegebenen Ereignisdefinition ist, wird die Ereigniserkennerzustandsmaschine 400 im Zustand Ereignis möglich 410 bleiben. Die Ereigniserkennerzustandsmaschine 400 kann im Zustand Ereignis möglich 410 solang bleiben, wie die Reihenfolge von empfangenen Unterereignissen weiter Teil der Ereignisdefinition ist. Wenn zu irgendeiner Zeit die Ereigniserkennerzustandsmaschine 400 im Ereignis-möglich-Zustand 410 ist, und die Ereigniserkennerzustandsmaschine 400 ein Unterereignis empfängt, das nicht Teil der Ereignisdefinition ist, wird es auf Zustand Ereignis unmöglich 420 übergehen, wobei es bestimmt wird, dass das gegenwärtige Ereignis (wenn irgendwelche) nicht die Art des Ereignisses ist, das diesem Ereigniserkenner entspricht (d. h. der Ereigniserkenner Zustand 400 entspricht). Wenn auf der anderen Seite die Ereigniserkennerzustandsmaschine 400 in den Ereignis-möglich-Zustand 410 ist, und die Ereigniserkennerzustandsmaschine 400 das letzte Unterereignis in einer Ereignisdefinition empfängt, wird es auf den Ereignis-erkannt-Zustand 415 übergehen, wobei eine erfolgreiche Ereigniserkennung folglich fertiggestellt wird.
4B stellt eine Ausführungsform eines Eingabequelle-Handhabungsprozesses 440 dar, der eine finite Zustandsmaschine hat, die repräsentiert, wie Ansichten Informationen über eine jeweilige Eingabe empfangen. Es wird darauf hingewiesen, dass, wenn es mehrere Berührungen auf der berührungsempfindlichen Oberfläche eines Gerätes gibt, ist jede dieser Berührungen eine getrennte Eingabequelle mit ihrer eigenen finiten Zustandsmaschine. In dieser Ausführungsform enthält der Eingabequelle-Handhabungsprozess 440 vier Zustände: Eingabereihenfolge beginnt 445, Eingabereihenfolge dauert fort 450, Eingabereihenfolge beendet 455, und Eingabereihenfolge gelöscht 460. Eingabequelle-Handhabungsprozess 440 kann durch einen jeweiligen Ereigniserkenner verwendet werden, zum Beispiel wenn eine Eingabe an eine Anwendung zu liefern ist, aber nur nachdem die Fertigstellung einer Eingabereihenfolge detektiert wird. Eingabequellen-Handhabungsprozess 440 kann mit einer Anwendung verwendet werden, die nicht in der Lage ist, Änderungen zu löschen oder annullieren, die in Antwort auf eine an die Anwendung gelieferte Eingabereihenfolge gemacht werden.
Von Eingabereihenfolge beginnt 445 ausgehend, wenn eine Eingabe empfangen wird, die sich selbst eine Eingabereihenfolge fertigstellt, wird der Eingabequelle-Handhabungsprozess 440 auf Eingabereihenfolge beendet 455 übergehen.
Von Eingabereihenfolge beginnt 445 ausgehend, wenn eine Eingabe empfangen wird, die die beendete Eingabereihenfolge zeigt, wird Eingabequelle-Handhabungsprozess 440 auf Eingabereihenfolge gelöscht 460 übergehen.
Von Eingabereihenfolge beginnt 445 ausgehend, wenn eine Eingabe empfangen wird, die die erste und nicht die letzte Eingabe in einer Eingabereihenfolge ist, wird die Eingabequelle-Handhabungsprozess 440 auf Zustand Eingabereihenfolge dauert fort 450 übergehen. Wenn die nächste empfangene Eingabe die zweite Eingabe in einer Eingabereihenfolge ist, wird der Eingabe-Handhabungsprozess 440 in Zustand Eingabereihenfolge dauert fort 450 bleiben. Eingabequelle-Handhabungsprozess 440 kann in Zustand Eingabereihenfolge dauert fort 450 so lange bleiben, wie die Reihenfolge von Unterereignissen, die geliefert werden, weiter Teil einer gegebenen Eingabereihenfolge ist. Wenn zu irgendeiner Zeit Eingabequelle-Handhabungsprozess 440 in Zustand Eingabereihenfolge dauert fort 450 ist, und Eingabequelle-Handhabungsprozess 440 eine Eingabe empfängt, die nicht Teil der Reihenfolge ist, wird er auf Zustand Eingabequelle gelöscht 460 übergehen. Wenn auf der anderen Seite Eingabequelle-Handhabungsprozess 440 in Eingabereihenfolge dauert fort 450 ist und der Eingabe-Handhabungsprozess 440 die letzte Eingabe in einer gegebenen Eingabedefinition empfängt, wird er auf Eingabereihenfolge beendet 455 übergehen, wobei eine Gruppe von Unterereignissen folglich erfolgreich empfangen wird.
In einigen Ausführungsformen kann Eingabequelle-Handhabungsprozess 440 für bestimmte Ansichten oder programmatische Niveaus implementiert werden. In diesem Fall können bestimmte Reihenfolgen von Unterereignissen zu Übergang auf Zustand Eingabe gelöscht 460 führen.
Als ein Beispiel betrachten wir 4C, die eine aktiv involvierte Ansicht annimmt, repräsentiert nur durch aktiv-involvierte-Ansicht-Eingabequellen-Handler 480 (nachfolgend ”Ansicht 480”). Ansicht 480 enthält einen vertikal-Streichen-Ereigniserkenner, repräsentiert nur durch vertikal-Streichen-Ereigniserkenner 468 (nachfolgend ”Erkenner 468”) als einem seiner Ereigniserkenner. In diesem Fall kann der Erkenner 468 als Teil seiner Definition detektieren erfordern: 1) ein Finger nach unten 465-1; 2) eine optionale kurze Verzögerung 465-2; 3), vertikales Streichen von mindestens N Pixeln 465-3; und 4) ein Finger-Abheben 465-4.
Für dieses Beispiel hat der Erkenner 468 auch seinen Verzögerung-Berührung-beginnt-Flag 328 und Berührung-gelöscht Flag 332 gesetzt. Nun betrachten wir die Lieferung der folgenden Reihenfolge von Unterereignissen an Erkenner 468, sowie die Ansicht 480:

• Unterereignis Reihenfolge 465-1: detektiere Finger nach unten, was der Ereignisdefinition des Erkenners 468 entspricht.
• Unterereignisreihenfolge 465-2: Messe Verzögerung, was der Ereignisdefinition des Erkenners 468 entspricht.
• Unterereignisreihenfolge 465-3: Finger führt eine vertikale Streichbewegung durch, die mit dem vertikalen Scrollen kompatibel ist, aber weniger als N Pixel ist und daher der Ereignisdefinition des Erkenners 468 nicht entspricht.
• Unterereignisreihenfolge 465-4: Detektiere Fingerabheben, was der Ereignisdefinition des Erkenners 468 entspricht.

Hier wird Erkenner 468 Unterereignisse 1 und 2 als Teil seiner Ereignisdefinition erfolgreich erkennen, und folglich wird im Zustand Ereignis möglich 472 sein unmittelbar vor der Lieferung des Unterereignisses 3. Da Erkenner 468 seinen Verspätung-Berührung-beginnt-Flag 328 eingerichtet hat, würde das Anfangs-Berührungsereignis nicht an die Schlagansicht gesendet. Dementsprechend wird der Eingabequelle-Handhabungsprozess 440 der Ansicht 480 noch im Zustand Eingabequelle beginnt unmittelbar vor der Lieferung des Unterereignisses 3 sein.
Sobald die Lieferung des Unterereignisses 3 an Erkenner 468 fertiggestellt wird, geht der Zustand des Erkenners 468 auf Ereignis unmöglich 476 über, und, was wichtig ist, der Erkenner 468 stellt nun fest, dass die Reihenfolge von Unterereignissen seiner spezifischen vertikal-Streichen-Geste-Ereignisart nicht entspricht (d. h., es hat entschieden, dass das Ereignis kein vertikales Streichen ist). Mit anderen Worten geschieht Erkennung 474 als ein vertikales Streichen nicht in diesem Beispiel). Das Eingabequelle-Handhabungssystem 440 für Ansicht-Eingabequelle-Handler 480 wird auch seinen Zustand aktualisieren. In einigen Ausführungsformen wird der Zustand des Ansicht-Eingabequelle-Handlers 480 vorn Eingabereihenfolge-beginnt-Zustand 482 zu dem Eingabereihenfolge-dauert-fort-Zustand 484 fortschreiten, wenn der Ereigniserkenner Statusinformation sendet, die zeigt, dass es begonnen hat, ein Ereignis zu erkennen. Der Ansicht-Eingabequelle-Handler 480 schreitet zu dem Eingabereihenfolge-gelöscht-Zustand 488 fort, wenn die Berührung oder Eingabe beendet wird ohne dass ein Ereignis erkannt wird, da das Berührung-gelöscht-Flag 322 des Ereigniserkenners eingerichtet worden ist. Alternativ, wenn das Berührungs-Löschungs-Flag 322 des Ereigniserkenners nicht eingerichtet worden war, schreitet der Ansicht-Eingabequelle-Handler 480 zu dem Eingabereihenfolge-beendet-Zustand 486 fort, wenn die Berührung von Eingabe beendet wird.
Da das Berührungs-Löschungs-Flag 332 des Ereigniserkenners 468 eingerichtet wird, wenn der Ereigniserkenner 468 auf den Ereignis-unmöglich-Zustand 476 übergeht, wird der Erkenner ein Berührungs-Löschungs-Unterereignis oder Nachricht an die Schlagansicht entsprechend dem Ereigniserkenner senden. Als Ergebnis wird der Ansicht-Eingabequellen-Handler 480 auf den Zustand Eingabereihenfolge gelöscht übergehen.
In einigen Ausführungsformen ist die Lieferung von Unterereignis 465-4 unrelevant zu irgendwelchen Ereigniserkennungsentscheidungen, die durch Erkenner 468 gemacht werden, obwohl die anderen Ereigniserkenner des Ansicht-Eingabequelle-Handlers 480, wenn irgendwelche, weiter die Reihenfolge von Unterereignissen analysieren können.

Die folgende Tabelle stellt in zusammenfassendem tabellarischen Format die Bearbeitung dieser beispielhaften Unterereignis-Reihenfolge 465 dar als relevant zu dem oben beschriebenen Zustand des Ereigniserkenners 468, zusammen mit dem Zustand des Ansicht-Eingabequelle-Handlers 480. In diesem Beispiel schreitet der Zustand des Ansicht-Eingabequelle-Handlers 480 von Eingabereihenfolge beginnt 445 zu Eingabereihenfolge gelöscht 488 fort, weil das Berührungs-Löschungs-Flag 332 des Erkenners 468 eingerichtet wurde:

Unterereignisreihenfolge 465	Zustand: Erkenner 468	Zustand: Ansicht 480
Vor Lieferungsbeginn	Ereigniserkennung beginnt 470
Detektiere Finger nach unten 465-1	Ereignis möglich 472	Eingabereihenfolge beginnt 482
Messe Verzögerung 465-2	Ereignis möglich 472	Eingabereihenfolge dauert fort 484
Detektiere Finger vertikales Streichen 465-3	Ereignis unmöglich 476	Eingabereihenfolge dauert fort 484
Detektiere Finger abheben 465-4	Ereignis unmöglich 476	Eingabereihenfolge gelöscht 488

Wenden wir uns an 5A, Aufmerksamkeit ist auf ein Beispiel einer Unterereignisreihenfolge 520 gerichtet, die durch eine Ansicht empfangen wird, die eine Mehrzahl von Ereigniserkennern enthält. Für dieses Beispiel werden zwei Ereigniserkenner in 5A dargestellt, Scrollen-Ereigniserkenner 580 und Schlag-Ereigniserkenner 590. Zum Zweck der Darstellung wird das Ansicht-Suchergebnis-Feld 304 in 3A den Empfang der Unterereignis-Reihenfolge 520, und die Zustandsübergänge im Scrollen-Ereigniserkenner 580 und Schlag-Ereigniserkenner 590 betreffen. Es ist in diesem Beispiel zu bemerken, dass die Reihenfolge von Unterereignissen 520 eine Schlag-Finger-Geste auf einer berührungsempfindlichen Anzeige oder Trackfeld definiert, aber die gleiche Ereigniserkennungstechnik in unzähligen Kontexten verwendet werden kann, z. B. detektieren eines Maustasten-Drückens und/oder in Ausführungsformen, die programmatische Hierarchien von programmatischen Niveaus benützen.
Bevor das erste Unterereignis an Ansicht-Suchergebnis-Feld 304 geliefert wird, sind Ereigniserkenner 580 und 590 jeweils in den Ereigniserkennung-beginnt-Zuständen 582 und 592. Der Berührung 301 folgend, die als Unterereignis Finger-nach-unten 520-1 an aktiv involvierte Ereigniserkenner für Ansicht-Suchergebnis-Feld 304 als Berührungs-Unterereignis 301-2 (sowie an aktiv involvierte Ereigniserkenner für Kartenansicht 305 als Berührungsunterereignis 301-3) geliefert wird, geht Scrollen-Ereigniserkenner auf Zustand Ereignis möglich 584 über, und in ähnlicher Weise geht Schlag-Ereigniserkenner 590 auf Zustand Ereignis möglich 594 über. Der Grund liegt darin, dass die Ereignisdefinition eines Schlags und eines Scrollens beide mit einer Berührung wie Finger nach unten auf einer berührungsempfindlichen Oberfläche beginnt.
Einige Definitionen von Schlag- und Scroll-Gesten können wahlweise eine Verzögerung zwischen einer Anfangsberührung und irgendeinem nächsten Schritt in der Ereignisdefinition enthalten. In allen hier diskutierten Beispielen erkennen die beispielhaften Ereignisdefinitionen für sowohl Schlag- als auch Scroll-Gesten eine Verzögerungs-Unterereignis, das dem ersten Unterereignis (Detektiere Finger nach unten) folgt.
Folglich, weil Unterereignis-Messungs-Verzögerung 521-2 an Ereigniserkenner 580 und 590 geliefert wird, bleiben beide jeweils in Ereignis-möglich-Zuständen 584 und 594.
Am Ende wird Unterereignis Detektiere Finger abheben 521-3 an Ereigniserkenner 580 und 590 geliefert. In diesem Fall sind die Zustandsübergänge für Ereigniserkenner 580 und 590 unterschiedlich, weil die Ereignisdefinitionen für Schlag und Scrollen unterschiedlich sind. Im Fall des Scrollen-Ereigniserkenners 580, das nächste Unterereignis zum Verbleiben im Zustand Ereignis möglich wird das Detektieren von Bewegung sein. Weil das gelieferte Unterereignis Detektiere Finger abheben 521-3 ist, geht der Scroll-Ereigniserkenner dennoch auf Zustand Ereignis unmöglich 588 über. Obwohl eine Schlag-Ereignisdefinition mit einem Finger-abheben-Unterereignis zum Schluss kommt. Folglich geht der Schlag-Ereigniserkenner 590 auf Zustand Ereignis erkannt 596 über, nachdem Ereignis Detektiere Finger abheben 521-3 geliefert wird.

Es ist in einigen Ausführungsformen zu bemerken, wie bezugnehmend auf 4B und 4C oben diskutiert, der in 4B diskutierte Eingabequellen-Handhabungsprozess 440 zu verschiedenen Zwecken auf dem Ansichten-Niveau verwendet werden kann. Die folgende Tabelle stellt in zusammenfassendem tabellarischen Format die Lieferung von Unterereignisreihenfolge 520 als relevant zu Ereigniserkennern 580, 590 und Eingabequelle-Handhabungsprozess 440 dar:

Unterereignis-Reihenfolge 520	Zustand: Scroll-Ereigniserkerner 580	Zustand: Schlag-Ereigniserkenner 590	Zustand: Eingabequelle-Handhabungsprozess 440
Vor Lieferungsst art	Ereigniserkennung beginnt 582	Ereigniserkern ung beginnt 592
Detektiere Finger nach unten 521-1	Ereignis möglich 584	Ereignis möglich 594	Eingabereihenfolge beginnt 445
Messe Verzögerung 521-2	Ereignis möglich 584	Ereignis möglich 594	Eingabereihenfolge dauert fort 450
Detektiere Finger abheben 521-3	Ereignis unmöglich 588	Ereignis erkannt 596	Eingabereihenfolge beendet 455

Bei 5B ist die Aufmerksamkeit auf ein anderes Beispiel einer Unterereignisreihenfolge 530 gerichtet, die durch eine Ansicht empfangen wird, die eine Mehrzahl von Ereigniserkennern enthält. Für dieses Beispiel werden 2 Ereigniserkenner in 5B dargestellt, Scroll-Ereigniserkenner 580 und Schlag-Ereigniserkenner 590. Zum Zwecke der Darstellung wird das Ansicht-Such-Ergebnisfeld 304 in 3A den Empfang der Unterereignisreihenfolge 530, und die Zustandsübergänge in Scroll-Ereigniserkenner 580 und Schlag-Ereigniserkenner 590 betreffen. Es ist in diesem Beispiel zu bemerken, dass die Reihenfolge von Unterereignissen 530 eine Scroll-Fingergeste auf einer berührungsempfindlichen Anzeige definiert, aber die gleiche Ereigniserkennungstechnik in unzähligen Kontexten verwendet werden kann, zum Beispiel Detektieren eines Maustaste-Drückens, Maus-Bewegen und Maustaste-Freigeben, und/oder in Ausführungsformen, die programmatische Hierarchien von programmatischen Niveaus benutzen.
Vor der Lieferung des ersten Unterereignisses an aktiv involvierte Ereigniserkenner für Ansichtssuchergebnisfeld 304 sind Ereigniserkenner 580 und 590 jeweils in den Ereigniserkennungsbeginn-Zuständen 582 und 592. Der Lieferung von Unterereignissen entsprechend und der Berührung 301 (wie oben diskutiert) folgend, geht der Scroll-Ereigniserkenner 580 auf Zustand Ereignis möglich 584 über, und auf ähnliche Weise geht der Schlag-Ereigniserkenner 590 auf Zustand Ereignis möglich 594 über.
Da die Unterereignis-Messungsverzögerung 531-1 an Ereigniserkenner 580 und 590 geliefert wird, gehen die beiden jeweils auf die Ereignis-möglich-Zustände 584 und 594 über.
Als nächstes wird Unterereignis detektiere Fingerbewegung 531-3 an Ereigniserkenner 580 und 590 geliefert. In diesem Fall sind die Zustandsübergänge für Ereigniserzeuger 580 und 590 unterschiedlich, weil die Ereignisdefinitionen für Schlag und Scroll unterschiedlich sind.
Im Fall von Scroll-Ereigniserkenner 580 ist das nächste Unterereignis, das im Zustandsereignis bleiben kann, das Detektieren von Bewegung, daher bleibt der Scroll-Ereigniserkenner 580 in dem Ereignis-möglich-Zustand 584, wenn es die Unterereignis detektiere Fingerbewegung 513-3 empfängt. Wie oben diskutiert, kommt dennoch die Definition für eine Schlag mit einem Finger-abheben-Ereignis zum Schluss, sodass der Schlag-Ereigniserkenner 590 auf den Zustand Ereignis möglich 598 übergeht.
Letztendlich wird Unterereignis detektiere Finger abheben 531-4 an Ereigniserkenner 580 und 590 geliefert. Der Schlag-Ereigniserkenner ist bereits im Ereignis-unmöglich-Zustand 598, und kein Zustandsübergang geschieht. Die Ereignisdefinition des Scroll-Ereigniserkenners 580 kommt mit dem Detektieren eines Fingerabhebens zum Schluss. Weil das gelieferte Unterereignis Detektiere Finger abheben 531-4 ist, geht der Scroll-Ereigniserkenner 580 auf den Zustandsereigniserkenner 586 über. Es wird bemerkt, dass eine Fingerbewegung auf einer berührungsempfindlichen Oberfläche mehrere Bewegungsunterereignisse erzeugen kann, daher kann ein Scroll vor Abheben erkannt werden und bis Abheben fortdauern.

Die folgende Tabelle stellt in zusammenfassenden tabellarischem Format die Lieferung von Unterereignisreihenfolge 530 dar als relevant zu Ereigniserkennern 580, 590 und Eingabequelle-Handlerprozess 440:

Unterereignisreihenfolge 530	Zustand: Scroll-Ereigniserkenner 580	Zustand: Schlag-Ereigniserkenner 590	Zustand: Eingabequelle Handhabungsprozess 540
Vor Lieferungsstart	Ereigniserkennung beginnt 582	Ereigniserkennung beginnt 592
Detektiere Finger nach unten 531-1	Ereignis möglich 584	Ereignis möglich 594	Eingabereihenfolge beginnt 445
Messungsverzögerung 531-2	Ereignis möglich 584	Ereignis möglich 594	Eingabereihenfolge dauert fort 450
Detektiere Fingerbewegung 531-3	Ereignis möglich 584	Ereignis unmöglich 598	Eingabereihenfolge dauert fort 450
Detektiere Finger abheben 531-4	Ereignis erkannt 586	Ereignis unmöglich 598	Eingabe Reihenfolge beendet 455

Bei 5C ist die Aufmerksamkeit auf ein anderes Beispiel einer Unterereignisreihenfolge 540 gerichtet, die durch eine Ansicht empfangen wird, die eine Mehrzahl von Ereigniserkennern enthält. Für dieses Beispiel werden zwei Ereigniserkenner in 5C dargestellt, Doppelschlagereigniserkenner 570 oder Schlag-Ereigniserkenner 590. Zu Zwecken der Darstellung wird die Kartenansicht 305 in 3A den Empfang der Unterereignisreihenfolge 540, und die Zustandsübergange in Doppelschlagereigniserkenner 580 und Schlag-Ereigniserkenner 590 betreffen. Es ist in diesem Beispiel zu bemerken, dass die Reihenfolge von Unterereignis 540 eine Doppelschlaggeste auf einer berührungsempfindlichen Anzeige definiert, aber die gleiche Ereigniserkennungstechnik in unzähligen Kontexten verwendet werden kann, zum Beispiel Detektieren eines Mausdoppelklicks und/oder in Ausführungsformen, die programmatische Hierarchien von programmatischen Niveaus benutzen.
Vor der Lieferung des ersten Unterereignisses an aktiv involvierte Ereigniserkenner für die Kartenansicht 305, sind Ereigniserkenner 570 und 590 jeweils in den Ereigniserkennungs-Beginnzuständen 572 und 592. Nach der Lieferung von Berührungsunterereignissen 301 relevanten Unterereignissen an Kartenansicht 304 (wie oben beschrieben) gehen Doppelschlagereigniserkenner 570 und Schlag-Ereigniserkenner 590 auf den Zustand Ereignis möglich 574 und 594 jeweils über. Der Grund liegt darin, dass die Ereignisdefinitionen des Schlags und eines Doppelschlags beide mit einer Berührung wie dem Detektieren eines Fingers nach unten auf einer berührungsempfindlichen Oberfläche beginnen.
Da die Unterereignismessungsverzögerung 541-2 an die Ereigniserkenner 570 und 590 geliefert wird, bleiben die beiden jeweils in den Zuständen Ereignis möglich 574 und 594.
Als nächstes wird Unterereignis detektiere Finger abheben 541-3 an Ereigniserkenner 570 und 590 geliefert. In diesem Fall sind die Zustandsübergange für Ereigniserkenner 580 und 590 unterschiedlich, weil die beispielhaften Ereignisdefinitionen für Schlag oder Doppelschlag unterschiedlich sind. In dem Fall von Schlag-Ereigniserkenner 590 ist das letzte Unterereignis in der Ereignisdefinition Detektieren von Fingerabheben, sodass der Schlag-Ereigniserkenner 590 auf den Ereignis-erkannt Zustand 596 übergeht.
Doppelschlagerkenner 570 bleibt dennoch in dem Zustand Ereignis möglich 574, weil eine Verzögerung begonnen hat, ungeachtet dessen, was der Benutzer letztendlich machen kann. Die Gesamtereigniserkennungsdefinition für einen Doppelschlag erfordert eine andere Verzögerung, obwohl gefolgt durch eine vollständige Schlagunterereignisreihenfolge. Das erzeugt eine unklare Situation zwischen dem Schlag-Ereigniserkenner 590, der bereits in Zustand Ereignis-erkannt 576 ist, und dem Doppelschlagerkenner 580, der noch im Zustand Ereignis möglich 574 ist.
Folglich können in einigen Ausführungsformen Ereigniserkenner Ausschließlichkeits-Flags und Ausschließlichkeits-Ausnahmelisten wie oben mit Bezug auf 3B und 3C diskutiert, implementieren. Hier wird das Ausschließlichkeits-Flag 324 für den Schlag-Ereigniserkenner 590 eingerichtet, und zusätzlich wird die Ausschließlichkeits-Ausnahmeliste 326 für den Schlag-Ereigniserkenner 590 konfiguriert, um die Lieferung von Unterereignissen an einige Ereigniserkenner (wie zum Beispiel Doppelschlagereigniserkenner 570) weiterhin zu erlauben, nachdem der Schlag-Ereigniserkenner 590 in den Zustand Ereignis-erkannt 596 eintritt.
Während der Schlag-Ereigniserkenner 590 im Zustand Ereignis-erkannt 596 bleibt, wird die Unterereignisreihenfolge 540 weiter an den Doppelschlagereigniserkenner 570 geliefert, wobei die Unterereignis-Messen-Verzögerung 541-4, detektiere Finger nach unten 541-5, und Messen-Verzögerung 541-6 den Doppelschlagereigniserkenner 570 im Zustand Ereignis möglich 574 beibehalten; Lieferung des letzten Unterereignisses der Reihenfolge 540, detektiere Finger abheben 541-7 verschiebt Doppelschlagereigniserkenner 570 in den Zustand Ereignis erkannt 576.
Zu diesem Punkt betrachtet die Kartenansicht 305 das Ereignis Doppelschlag durch den Ereigniserkenner als erkannt, statt des Einzelschlagereignisses durch den Schlag-Ereigniserkenner 590 erkannt. Die Entscheidung, das Doppelschlagereignis zu nehmen, wird getroffen im Hinblick auf die Kombination des eingerichteten Ausschließlichkeits-Flag 324 des Schlag-Ereigniserkenners 590, der Ausschließlichkeits-Ausnahmeliste 326 des Schlag-Ereigniserkenners 590 einschließlich eines Doppelschlagereignisses, und der Tatsache, dass sowohl der Schlag-Ereigniserkenner 590 als auch der Doppelschlagereigniserkenner 570 ihre jeweilige Ereignisarten erfolgreich erkannt haben.

Die folgende Tabelle stellt in zusammenfassendem tabellarischen Format die Lieferung der Unterereignisreihenfolge 540 dar, als relevant für Ereigniserkenner 570 und 590, und den Unterereignis-Handhabungsprozess 440.

Unterereignisreihenfolge 540	Zustand: Doppelschlag-Ereigniserkenner 570	Zustand: Schlag-Ereigniserkenner 590	Zustand: Eingabequelle-Handhabungs-Prozess 440
Vor Lieferungsstart	Ereigniserkennung beginnt 572	Ereigniserkennung beginnt 592	Eingabereihenfolge beginnt 445
Detektiere Finger nach unten 541-1	Ereignis möglich 574	Ereignis möglich 594	Eingabereihenfolge dauert fort 450
Messungsverzögerung 541-2	Ereignis möglich 574	Ereignis möglich 594	Eingabereihenfolge dauert fort 450
Detektiere Finger abheben 541-3	Ereignis möglich 574	Ereignis erkannt 596	Eingabereihenfolge dauert fort 450
Messungsverzögerung 541-4	Ereignis möglich 574	Ereignis erkannt 596	Eingabereihenfolge dauert fort 450
Detektiere Finger nach unten 541-5	Ereignis möglich 574	Ereignis erkannt 596	Eingabereihenfolge dauert fort 450
Messungsverzögerung 541-6	Ereignis erkannt 596	Ereignis erkannt 596	Eingabereihenfolge dauert fort 450
Detektiere Finger abheben 541	Ereignis erkannt 576	Ereignis erkannt 596	Eingabereihenfolge beendet 455

In einer anderen Ausführungsform, in dem Ereignisszenario von 5C, wird die Einzelschlaggeste nicht erkannt, weil der Einzelschlagereigniserkenner eine Warteliste hat, die den Doppelschlagereigniserkenner identifiziert. Als Ergebnis wird eine Einzelschlaggeste nicht erkannt, bis (wenn überhaupt) der Doppelschlagereigniserkenner in den Ereignis-unmöglich-Zustand eintritt. In diesem Beispiel, in dem eine Doppelschlaggeste erkannt wird, wird der Einzelschlagerkenner im Ereignis-möglich-Zustand bleiben, bis die Doppelschlaggeste erkannt wird; zu diesem Punkt wird der Einzelschlagereigniserkenner auf den Ereignis-unmöglich-Zustand übergehen.
Die Aufmerksamkeit wird nun auf 6A–6B gerichtet, die Flussdiagramme enthält, die eigenes Erkennungsverfahren nach einigen Ausführungsformen darstellen. Das Verfahren 600 wird bei einem elektronischen Gerät durchgeführt, das in einigen Ausführungsformen ein elektronisches Gerät 102 oder 104, wie oben diskutiert, sein kann. In einigen Ausführungsformen kann das elektronische Gerät eine berührungsempfindliche Oberfläche enthalten, die konfiguriert ist, um Multi-Touch-Gesten zu detektieren.
Alternativ kann das elektronische Gerät einen Berührungsbildschirm enthalten, der konfiguriert ist, um Multi-Touch-Gesten zu detektieren.
Das Verfahren 600 ist konfiguriert, Software auszuführen, die e4ine Ansicht der Hierarchie mit einer Vielzahl von Ansichten der Hierarchien und führt 610 ein oder mehrere Softwareelemente aus. Jedes Softwareelement ist mit einer bestimmten Ansicht assoziiert, und jede bestimmte Ansicht enthält einen oder mehrere Ereigniserkenner, wie z. B. diejenigen, die jeweils in 3B und 3c als Ereigniserkennerstrukturen 320 und 360 beschrieben werden.
Jeder Ereigniserkenner enthält im Allgemeinen eine Ereignisdefinition basierend auf einem oder mehreren Unterereignissen, wobei die Ereignisdefinition als eine Zustandsmaschine implementiert werden kann, siehe z. B. 3B Zustandsmaschine 340. Ereigniserkenner enthalten auch im Allgemeinen einen Ereignishandler, der eine Aktion für ein Ziel spezifiziert und konfiguriert ist, der Aktion das Ziel in Antwort auf das Detektieren eines Ereignisses entsprechend der Ereignisdefinition durch den Ereigniserkenner zu senden.
In einigen Ausführungsformen ist mindestens einer der Mehrzahl von Ereigniserkennern ein Gestenerkenner, der eine Gestendefinition einem Gestenhandler, wie in Schritt 612 der 6A angegeben wird, aufweist.
In einigen Ausführungsformen definiert die Ereignisdefinition eine Benutzergeste, wie im Schritt 614 der 6A angegeben wird.
Alternativ haben Ereigniserkenner einen Satz von Ereigniserkennungszuständen 616. Diese Ereigniserkennungszustände können mindestens einen Ereignis-Möglich-Zustand, einen Ereignis-Unmöglich-Zustand und einen Ereignis-Erkannt-Zustand enthalten.
In einigen Ausführungsform initiiert der Ereignishandler Vorbereitung 618 seiner entsprechenden Aktion für Lieferung an das Ziel, wenn der Ereigniserkenner in den Ereignismoduszustand eintritt. Wie oben Bezug nehmend auf 4A und die Beispiele in 5A–5C diskutiert wird, enthalten die Zustandsmaschinen, die für jeden Ereigniserkenner implementiert werden, im Allgemeinen einen Anfangszustand, z. B. Zustandereigniserkennung beginnt 405. Der Empfang eines Unterereignisses, dass den Anfangsteil einer Ereignisdefinition bildet, löst eine Zustandsänderung zum Ereignis-Möglich-Zustand 410 aus. Folglich, in einigen Ausführungsformen, als er Ereigniserkenner vom Zustandsereigniserkennung 405 auf den Zustandereignis-Möglich-410 übergeht, kann der Ereignishandler des Ereigniserkenners die Vorbereitung seiner Sonderaktion zur Lieferung an das Ziel des Ereigniserkenners erkennen, nachdem ein Ereignis erfolgreich erkannt wird.
Auf der anderen Seite kann der Ereignishandler in einigen Ausführungsformen Vorbereitung 620 seiner entsprechenden Aktion beenden, wenn der Ereigniserkenner in den Zustand Ereignis-Unmöglich 420 eintritt. In einigen Ausführungsformen enthält die Beendigung der entsprechenden Aktion das Löschen irgendwelcher Vorbereitung der entsprechenden Aktion des Ereignishandlers.
Das Beispiel der 5B ist informativ für diese Ausführungsform, da Schlagereigniserkenner 590 die Vorbereitung 618 dieser Aktion initiiert haben kann, aber dann, sobald das Unterereignisdetektierfingerbewegung 531-3 an den Schlagereigniserkenner 590 geliefert wird, wird der Erkenner 590 auf dem Ereignis-Unmöglich-Zustand 598, 578 übergehen. In diesem Moment kann der Schlagereigniserkenner 590 die Vorbereitung 620 dieser Aktion beenden, für den er die Vorbereitung 618 initiiert hat.
In einigen Ausführungsformen stellt der Ereignishandler die Vorbereitung 622 seine entsprechende Aktion für Lieferung an das Ziel fertig, wenn der Ereigniserkenner in den Ereignis-Erkannt-Zustand eintritt. Das Beispiel von 5C stellt diese Ausführungsform dar, weil ein Doppelschlag durch Aktivinvolviertansichterkenner für die Kartenansicht 305 erkannt wird, der in einigen Implementationen das Ereignis sein wird, das mit Auswahl und/oder Ausführung des Suchergebnisses, das durch die Kartenansicht 305 dargestellt wird, verbunden ist. Hier, nachdem der Doppelschlagereigniserkenner 570 das Doppelschlagereignis erfolgreich erkennt, das in der Unterereignisreihenfolge 540 enthalten ist, der Ereignishandler der Kartenansicht 305 stellt die Vorbereitung 620 seiner Aktion fertig, es wird nämlich angegeben, dass es einen Aktivierungsbefehl empfangen hat.
In einigen Ausführungsformen liefert der Ereignishandler 624 seine entsprechende Aktion an das Ziel, das mit dem Ereigniserkenner assoziiert ist. Fortfahrend mit dem Beispiel von 5C, der Vorbereitungsaktion, d. h. der Aktivierungsbefehl der Kartenansicht 305, wird an das spezifische Ziel geliefert werden, das mit der Kartenansicht 305 assoziiert ist, das jedes geeignete programmatische Verfahren oder Objekt sein kann.
Alternativ kann die Mehrzahl der Ereignisserkennungen die Reihenfolge eines oder mehreren Unterereignissen parallel unabhängig bearbeiten 626.
In einigen Ausführungsformen können eine oder mehrere Ereigniserkenner als ausschließliche Ereigniserkenner 628 konfiguriert werden, wie oben jeweils mit Bezug auf Ausschließlichkeitsflags 324 oder 364 der 3B und 3C diskutiert wird. Wenn ein Ereigniserkenner als ein Auschließlichereigniserkenner konfiguriert ist, verhindert das Ereignisliefersystem, dass irgendwelche andere Ereigniserkenner für aktiv involvierte Ansichten (bis auf diejenigen, die in der Ausnahmeliste 326, 366 des Ereigniserkenners, der das Ereignis erkennt, aufgelistet sind) in der Ansichthierarchie nachfolgende Ereignisse (von der gleichen Reihenfolge von Unterereignissen) empfangen, nachdem der ausschließliche Ereigniserkenner ein Ereignis erkennt. Weiterhin, wenn ein nicht ausschließlicher Ereigniserkenner ein Ereignis erkennt, verhindert das Ereignisliefersystem, dass irgendwelche ausschließliche Ereigniserkenner für aktuell involvierte Ansichten in der Ansichthierarchie nachfolgende Unterereignisse empfangen, bis auf diejenigen (falls überhaupt), die in der Ausnahmeliste 326, 366 des Ereigniserkenners, der das Ereignis erkennt, aufgelistet sind.
In einigen Ausführungsformen können ausschließliche Ereigniserkenner eine Ereignisausnahmeliste enthalten 630, wie oben jeweils mit Bezug auf die Ausschließlichkeitsausnahmelisten 326 und 366 der 3B und 3C diskutiert wird. Wie oben in der Diskussion von 5C angemerkt, kann die Ausschließlichkeitsausnahmeliste eines Ereigniserkenners verwendet werden, um dem Ereigniserkenner zu erlauben, mit der Ereigniserkennung fortzufahren, selbst wenn die Reihenfolge von Unterereignissen, die ihre jeweiligen Ereignisdefinitionen bilden, sich teilweise decken. Folglich enthält die Ereignisausnahmeliste in einigen Ausführungsformen Ereignisse, deren entsprechende Ereignisdefinitionen wiederholt und Ereignisse 632 haben, wie z. B. das Einzelschlag/Doppelschlagereignisbeispiel von 5C.
Alternativ kann die Ereignisdefinition eine Benutzereingabeoperation 634 definieren.
In einigen Ausführungsformen können ein oder mehrere Ereigniserkenner so angepasst werden, die Lieferung jedes Unterereignisses der Reihenfolge von Unterereignissen zu verzögern, bis das Ereignis erkannt wird.
Das Verfahren 600 detektiert 636 eine Reihenfolge eines oder mehrerer Unterereignisse, und in einigen Ausführungsformen kann die Reihenfolge eines oder mehrerer Unterereignisse alternativ Berührungsereignisse 638 enthalten. Primitive Berührungsereignisse können Basiskomponenten einer berührungsbasierten Geste auf einer berührungsempfindlichen Oberfläche, wie z. B. Daten bezüglich eines Anfangsfinger- oder Stiftberührung-nach-unten, Daten bezüglich der Initiierung von Mittelfinger- oder Stiftbewegungen quer durch eine berührungsempfindliche Oberfläche, Doppelfingerbewegungen in entgegengesetzte Richtungen, Stiftabrieb in Form einer berührungsempfindlichen Oberfläche usw. enthalten, ohne darauf beschränkt zu werden.
Unterereignisse in der Reihenfolge eines oder mehrerer Untereignisse können viele Formen enthalten, die Tastendrücken, Tastendrückenhalten, Tastendrückenfreigeben, Knopfdrücken, Knopfdrückenhalten, Knopfdrückenfreigeben, Joystickbewegungen, Mausbewegungen, Mausknopfdrücken, Mausknopffreigeben, Stiftbewegungen, Stiftberührungen, Stiftfreigeben, mündliche Anweisungen, detektierte Augenbewegungen, biometrische Eingaben und detektierte physiologische Änderungen eines Benutzers, unter anderem, enthalten, ohne darauf beschränkt zu werden.
Das Verfahren identifiziert 640 eine der Ansichten der Ansichtenhierarchie als eine Schlagansicht. Die Schlagansicht stellt fest, welche Ansichten der Ansichtenhierarchie aktiv involvierte Ansichten sind. Ein Beispiel wird in 3A dargestellt, wo die aktiv involvierten Ansichten 306 Suchergebnissfeld 304 und Kartenansichten 305 enthalten, weil das Unterereignis 301 das mit der Kartenansicht 305 assoziierte Gebiet kontaktiert.
In einigen Ausführungsformen kann eine erste aktiv involvierte Ansicht innerhalb der Ansichtenhierarchie konfiguriert werden 642, um die Lieferung des jeweiligen Unterereignisses an Ereigniserkenner zu verhindern, die mit der ersten aktiv involvierten Ansicht assoziiert sind. Dieses Verhalten kann den Sprungeigenschaft implementieren, die oben mit Bezug auf 3B und 3C (330 bzw. 370) diskutiert wird. Wenn die Sprungeigenschaft für einen Ereigniserkenner eingerichtet wird, wird die Lieferung des jeweiligen Unterereignisses noch für Ereigniserkenner durchgeführt, die mit anderen aktiv involvierten Ansichten der Ansichtenhierarchie assoziiert sind.
Alternativ kann eine erste aktiv involvierte Ansicht innerhalb der Ansichtenhierarchie konfiguriert werden 644, um die Lieferung des jeweiligen Ereignisses an Ereigniserkenner zu verhindern, die mit dieser ersten aktiv involvierten Ansicht assoziiert sind, sofern die erste aktiv involvierte Ansicht keine Schlagansicht ist. Das Verhaken kann die Bedingtsprungeigenschaft implementieren, die oben mit Bezug auf 3B und 3C diskutiert wird (332 bzw. 370).
In einigen Ausführungsformen ist eine zweite aktiv involvierte Ansicht innerhalb der Ansichtenhierarchie konfiguriert 646, um die Lieferung des jeweiligen Unterereignisses an Ereigniserkenner, die mit der zweiten aktiv involvierten Ansicht assoziiert sind, und an Ereigniserkenner, die mit Vorläufern der zweiten aktiv involvierten Ansicht assoziiert sind, zu verhindern. Das Verhalten kann die Stoppeigenschaft implementieren, die oben mit Bezug auf 3B und 3C (328 bzw. 368) diskutiert wird.
Das Verfahren 600 liefert 648 ein jeweiliges Unterereignis an Ereigniserkenner für jede aktiv involvierte Ansicht innerhalb der Ansichtenhierarchie. In einigen Ausführungsformen bearbeiten Ereigniserkenner für aktiv involvierte Ansichten in der Ansichtenhierarchie das jeweilige Unterereignis vor der Bearbeitung eines möglichen Unterereignisses in der Reihenfolge von Unterereignissen. Alternativ treffen Ereigniserkenner für die aktiv involvierten Ansichten in der Ansichtenhierarchie ihre Unterereigniserkennungsentscheidungen während der Bearbeitung des jeweiligen Unterereignisses.
In einigen Ausführungsformen können Ereigniserkenner für aktiv involvierte Ansichten in der Ansichtenhierarchie die Reihenfolge eines oder mehrerer Unterereignissen gleichzeitig bearbeiten 650; alternativ können Ereigniserkenner für aktiv involvierte Ansichten in der Ansichtenhierarchie die Reihenfolge eines oder mehrerer Unterereignisse parallel bearbeiten.
In einigen Ausführungsformen können ein oder mehrere Ereigniserkenner dazu geeignet sein, die Lieferung 652 eines oder mehrerer Unterereignisse der Reihenfolge von Unterereignissen zu verzögern, bis der Ereigniserkenner das Ereignis erkennt. Das Verhalten reflektiert ein verzögertes Ereignis. Zum Beispiel denken wir an eine Einzelschlaggeste in einer Ansicht, für die mehrere Schlaggesten möglich sind. In diesem Fall wird ein Schlagereignis ein ”Schlag + Verzögerung” Erkenner. Im Grunde, wenn ein Ereigniserkenner dieses Verhalten implementiert, wird der Ereigniserkenner die Ereigniserkennung verzögern, bis es sicher ist, dass die Reihenfolge von Unterereignissen in der Tat ihre Ereignisdefinition nicht entspricht. Das Verhalten kann geeignet sein, wenn eine Empfangsansicht nicht in der Lage ist, gelöschte Ereignisse in geeigneter Weise zu beantworten. In einigen Ausführungsformen wird ein Ereigniserkenner die Aktualisierung seines Ereigniserkennungsstatus an seine jeweilige aktiv involvierte Ansicht verzögern, bis der Ereigniserkenner sicher ist, dass die Reihenfolge von Unterereignissen seiner Ereignisdefinition nicht entspricht. Wie oben mit Bezug auf 3B und 3C diskutiert wird, werden Verzögerung-Berührung-Beginnt-Flag 328, 368, Verzögerung-Berührung-End-Flag 330, 370, und Berühungslöschungsflag 332, 372 bereitgestellt, um Unterereignislieferungtechniken sowie Ereigniserkennung und Ansichtstatusinformationaktualisierungen auf spezifische Wünsche maßzuschneidern.
Die vorhergehende Beschreibung zum Zweck der Erklärung ist mit Bezug auf spezifische Ausführungsformen beschrieben worden. Die oben dargestellten Diskussionen sind jedoch nicht beabsichtigt, erschöpfend zu sein oder die Erfindung auf die offenbarten präzisen Formen zu beschränken. Viele Modifikationen und Änderungen sind im Hinblick auf die obigen Lehren möglich. Die Ausführungsformen wurden ausgewählt und beschrieben, um die Prinzipien der Erfindung und ihre praktischen Anwendungen bestmöglich zu erklären und daher ist den Fachleuten zu erlauben, die Erfindung und verschiedene Ausführungsformen mit verschiedenen Modifikationen, wie sie für die besondere nachgedachte Benutzung geeignet sind, bestmöglich zu benutzen.

Claims

Verfahren, aufweisend: Bei einem elektronischen Gerät, das konfiguriert ist, Software auszuführen, die eine Ansichtshierarchie mit einer Mehrzahl von Ansichten enthält: Anzeigen einer oder mehrerer Ansichten der Ansichtshierarchie; Ausführen eines oder mehrerer Software-Elemente, wobei jedes Software-Element mit einer bestimmten Ansicht assoziiert ist, wobei jede bestimmte Ansicht einen oder mehrere Ereigniserkenner enthält, wobei jeder Ereigniserkenner aufweist: eine auf einem oder mehreren Unterereignissen basierende Ereignisdefinition, und einen Ereignishandler, wobei der Ereignishandler: eine Aktion für ein Ziel spezifiziert, und konfiguriert ist, in Antwort auf das Detektieren eines der Ereignisdefinition entsprechenden Ereignisses durch den Ereigniserkenner die Aktion an das Ziel zu senden Detektieren einer Abfolge von einem oder mehreren Unterereignissen; und Identifizieren einer der Ansichten der Ansichtshierarchie als eine Trefferansicht, wobei die Trefferansicht festlegt, welche Ansichten in der Ansichtshierarchie aktiv involvierte Ansichten sind; für jede aktiv involvierte Ansicht Liefern eines entsprechenden Unterereignisses an einen oder mehrere Ereigniserkenner innerhalb der Ansichtshierarchie; und wobei jeder Ereigniserkenner für aktiv involvierte Ansichten in der Ansichtshierarchie das jeweilige Unterereignis vor Bearbeitung eines nächsten Unterereignisses in der Abfolge von Unterereignissen bearbeitet.
Verfahren nach Anspruch 1, wobei jeder Ereigniserkenner für aktiv involvierte Ansichten in der Ansichtshierarchie die Abfolge von einem oder mehreren Unterereignissen simultan bearbeitet.
Verfahren nach irgendeinem der Ansprüche 1 bis 2, wobei eine erste aktiv involvierte Ansicht innerhalb der Ansichtshierarchie konfiguriert ist, um die Lieferung des jeweiligen Unterereignisses an Ereigniserkenner, die mit der ersten aktiv involvierten Ansicht assoziiert sind, zu verhindern.
Verfahren nach irgendeinem der Ansprüche 1 bis 2, wobei eine erste aktiv involvierte Ansicht innerhalb der Ansichtshierarchie konfiguriert ist, um die Lieferung des jeweiligen Unterereignisses an Ereigniserkenner, die mit der ersten aktiv involvierten Ansicht assoziiert sind, zu verhindern, außer wenn die erste aktiv involvierte Ansicht die Trefferansicht ist.
Verfahren nach irgendeinem der Ansprüche 1 bis 4, wobei eine zweite aktiv involvierte Ansicht innerhalb der Ansichtshierarchie konfiguriert ist, um die Lieferung des jeweiligen Unterereignisses an Ereigniserkenner, die mit der zweiten aktiv involvierten Ansicht assoziiert sind, und an Ereigniserkenner, die mit Vorlgängern der zweiten aktiv involvierten Ansicht assoziiert sind, zu verhindern.
Verfahren nach irgendeinem der Ansprüche 1 bis 5, wobei mindestens einer der Mehrzahl von Ereigniserkennern ein Gesten-Erkenner ist, der eine Gestendefinition und einen Gestenhandler aufweist.
Verfahren nach irgendeinem der Ansprüche 1 bis 6, wobei die Ereignisdefinition eine Benutzergeste definiert.
Verfahren nach irgendeinem der Ansprüche 1 bis 7, wobei das elektronische Gerät weiterhin eine berührungsempfindliche Oberfläche aufweist, die konfiguriert ist, um Multi-Touch-Gesten zu detektieren.
Verfahren nach irgendeinem der Ansprüche 1 bis 7, wobei das elektronische Gerät weiterhin einen Berührungsbildschirm aufweist, der konfiguriert ist, um Multi-Touch-Gesten zu detektieren.
Verfahren nach irgendeinem der Ansprüche 1 bis 9, wobei die Abfolge von einem oder mehreren Unterereignissen primitive Berührungsereignisse enthält.
Verfahren nach irgendeinem der Ansprüche 1 bis 10, wobei jeder Ereigniserkenner eine Satz von Ereigniserkennungszuständen aufweist, die mindestens einen Ereignis-möglich-Zustand, einen Ereignis-unmöglich-Zustand und einen Ereignis-erkannt-Zustand enthalten.
Verfahren nach Anspruch 11, weiterhin aufweisend das Initiieren der Vorbereitung einer entsprechenden Aktion zur Lieferung an das Ziel durch den Ereignishandler, wenn der Ereigniserkenner in den Ereignis-möglich-Zustand eintritt.
Verfahren nach Anspruch 12, weiterhin aufweisend das Fertigstellen der Vorbereitung einer entsprechenden Aktion zur Lieferung an das Ziel durch den Ereignishandler, wenn der Ereigniserkenner in den Ereignis-erkannt-Zustand eintritt.
Verfahren nach Anspruch 13, weiterhin aufweisend die Lieferung seiner entsprechenden Aktion an das Ziel durch den Ereignishandler.
Verfahren nach irgendeinem der Ansprüche 1 bis 14, wobei die Mehrzahl von Ereigniserkennern unabhängig voneinander die Abfolge von einem oder mehreren Unterereignissen parallel bearbeiten.
Verfahren nach irgendeinem der Ansprüche 1 bis 15, wobei einer oder mehrere der Mehrzahl von Ereigniserkennern angepasst sind, die Lieferung eines oder mehrerer Unterereignisse der Abfolge von Unterereignissen zu verzögern, bis der jeweilige Ereigniserkenner das Ereignis erkennt.
Verfahren nach irgendeinem der Ansprüche 1 bis 16, wobei ein oder mehrere der Mehrzahl von Ereigniserkennern, aufweisend ausschließliche Ereigniserkenner, konfiguriert sind, ausschließliche Ereigniserkennung durchzuführen, und das Ereignis-Liefersystem verhindert, dass irgendwelche nicht-ausschließlichen Ereigniserkenner für aktiv involvierte Ansichten in der Ansichtshierarchie jeweilige Ereignisse erkennen, nachdem irgendeiner der ausschließlichen Ereigniserkenner ein Ereignis erkennt.
Verfahren nach Anspruch 17, wobei der eine oder die mehreren ausschließlichen Ereigniserkenner eine Ereignis-Ausnahmeliste enthalten.
Verfahren nach Anspruch 18, wobei die Ereignis-Ausnahmeliste Ereignisse enthält, deren korrespondierende Ereignisdefinitionen sich wiederholende Unterereignisse aufweisen.
Verfahren nach irgendeinem der Ansprüche 1 bis 19, wobei die Ereignisdefinition eine Benutzereingabe-Operation definiert.
Verfahren nach irgendeinem der Ansprüche 1 bis 20, wobei ein jeweiliges Unterereignis der Abfolge von einem oder mehreren Unterereignissen aus der Gruppe ausgewählt wird, die aus einem Taste-Drücken, einem Taste-Drücken-Anhalten, einem Taste-Drücken-Freigeben, einem Knopf-Drücken, einem Knopf-Drücken-Anhalten, einem Knopf-Drücken-Freigeben, einer Joystick-Bewegung, einer Mausbewegung, einem Mausknopf-drücken, einem Mausknopf-Freigeben, einer Stiftberührung, einer Stiftbewegung, einem Stift-Freigeben, einer mündlichen Anweisung, einer detektierten Augenbewegung, einer biometrischen Eingabe, und einer detektierten physiologischen Änderung bei einem Benutzer besteht.
Ein Verfahren, aufweisend: bei einem elektronischen Gerät, das konfiguriert ist, Software auszuführen, die eine Ansichtshierarchie mit einer Mehrzahl von Ansichten enthält: Anzeigen einer oder mehrere Ansichten der Ansichtshierarchie; Ausführen eines oder mehrerer Software-Elemente, wobei jedes Software-Element mit einer bestimmten Ansicht assoziiert ist, wobei jede bestimmte Ansicht einen oder mehrere Ereigniserkenner enthält, wobei jeder Ereigniserkenner aufweist: eine Ereignisdefinition basierend auf einem oder mehreren Unterereignissen, und einen Ereignishandler, wobei der Ereignishandler: eine Aktion für ein Ziel spezifiziert, und konfiguriert ist, in Antwort auf das Detektieren eines der Ereignisdefinition entsprechenden Ereignisses durch den Ereigniserkenner die Aktion an das Ziel zu senden; Detektieren einer Abfolge von einem oder mehreren Unterereignissen; und Identifizieren einer der Ansichten der Ansichtshierarchie als eine Trefferansicht, wobei die Trefferansicht festlegt, welche Ansichten in der Ansichtshierarchie aktiv involvierte Ansichten sind; für jede aktiv involvierte Ansicht Liefern eines entsprechenden Unterereignisses an einen oder mehrere Ereigniserkenner innerhalb der Ansichtshierarchie; und bei Ereigniserkennern für die aktiv involvierten Ansichten in der Ansichtshierarchie, Treffen einer Unterereigniserkennungs-Entscheidung während der Bearbeitung des jeweiligen Unterereignisses.
Verfahren nach Anspruch 22, wobei jeder Ereigniskenner für aktiv involvierte Ansichten in der Ansichtshierarchie die Abfolge von einem oder mehreren Unterereignissen parallel bearbeitet.
Computerlesbares Speichermedium, dass ein oder mehrere Programme zum Ausführen durch einen oder mehrere Prozessoren eines Computersystems oder -gerätes speichert, wobei das eine oder die mehreren Programme aufweisen: ein oder mehrere Anwendungsprogramme zum Anzeigen einer oder mehrerer Ansichten einer Ansichtshierarchie mit einer Mehrzahl von Ansichten; das eine oder die mehreren Anwendungsprogramme, die ein oder mehrere Software-Elemente aufweisen, wobei jedes Software-Element mit einer bestimmten Ansicht assoziiert ist, wobei jede bestimmte Ansicht eine oder mehrere Ereigniserkenner enthält, wobei jeder Ereigniserkenner aufweist: eine Ereignisdefinition basierend auf einem oder mehreren Unterereignissen, und einem Ereignishandler, wobei der Ereignishandler: eine Aktion für ein Ziel spezifiziert, und konfiguriert ist, in Antwort auf das Detektieren eines der Ereignisdefinition entsprechenden Ereignisses durch den Ereigniserkenner die Aktion an das Ziel zu senden; Ereignisverarbeitungsanweisungen, die, wenn durch den einen oder die mehreren Prozessoren des Computersystems oder -Gerätes ausgeführt, das Computersystem oder Gerät dazu veranlassen: eine Abfolge von einem oder mehreren Unterereignissen zu detektieren; eine der Ansichten der Ansichtshierarchie als eine Trefferansicht zu identifizieren, wobei die Trefferansicht festlegt, welche Ansichten in der Ansichtshierarchie aktiv involvierte Ansichten sind; für jede aktiv involvierte Ansicht eine entsprechendes Unterereignis an einen oder mehrere Ereigniserkenner innerhalb der Ansichtshierarchie zu liefern; wobei jeder Ereigniserkenner für aktiv involvierte Ansichten in der Ansichtshierarchie das jeweilige Unterereignis vor Bearbeitung eines nächsten Unterereignisses in der Abfolge von Unterereignissen bearbeitet.
Computerlesbares Speichermedium nach Absatz 24, wobei das eine oder die mehreren Programme Anweisungen enthalten, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, das Computersystem oder -gerät zur Durchführung des Verfahrens nach irgendeinem der Ansprüche 1 bis 23 veranlassen.
Vorrichtung, aufweisend: eine Anzeige; einen oder mehrere Prozessoren; Speicher; ein oder mehrere Programme, die in dem Speicher gespeichert sind, die konfiguriert sind, eine oder mehrere Ansichten einer Ansichtshierarchie mit einer Mehrzahl von Ansichten anzuzeigen; das eine oder die mehreren Programme, die ein oder mehrere Software-Elemente enthalten, wobei jedes Software-Element mit einer bestimmten Ansicht assoziiert ist, wobei jede bestimmte Ansicht einen oder mehrere Ereigniserkenner enthält, wobei jeder Ereigniserkenner aufweist: eine Ereignisdefinition basierend auf einem oder mehreren Unterereignissen; einen Ereignishandler, wobei der Ereignishandler: eine Aktion für ein Ziel spezifiziert, und konfiguriert ist, in Antwort auf das Detektieren eines der Ereignisdefinition entsprechenden Ereignisses durch den Ereigniserkenner die Aktion an das Ziel zu senden; das eine oder die mehreren Programme, die ein Ereignis-Lieferprogramm enthalten, die, wenn sie durch den einen oder die mehreren Prozessoren der Vorrichtung ausgeführt werden, die Vorrichtung dazu veranlassen: eine Abfolge von einem oder mehreren Unterereignissen zu detektieren; eine der Ansichten der Ansichtshierarchie als eine Trefferansicht zu identifizieren, wobei die Trefferansicht festlegt, welche Ansichten in der Ansichtshierarchie aktiv involvierte Ansichten sind; ein jeweiliges Unterereignis an Ereigniserkenner für jede aktiv involvierte Ansicht innerhalb der Ansichtshierarchie zu liefern; und eine Unterereignis-Erkennungs-Entscheidung zu treffen, während Ereigniserkenner für die aktiv involvierten Ansichten in der Ansichtshierarchie das jeweilige Unterereignis bearbeiten.
Vorrichtung nach Anspruch 26, wobei das eine oder die mehreren Programme, die in dem Speicher gespeichert sind, Anweisungen enthalten, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, das Computersystem oder Gerät zur Durchführung des Verfahrens nach irgendeinem der Ansprüche 1 bis 23 veranlassen.