PATENT DOCUMENT

Publication Number: US-9684521-B2
Application Number: US-78969510-A
Country: US
Kind Code: B2

Title: Systems having discrete and continuous gesture recognizers

Abstract:
A software application includes a plurality of views and an application state. The method includes displaying one or more views, where a respective view includes a respective gesture recognizer having a corresponding delegate to the respective gesture recognizer. The method includes detecting one or more events and processing a respective event of the one or more events using the respective gesture recognizer. The processing of the respective event includes processing the respective event at the respective gesture recognizer in accordance with a respective gesture definition corresponding to the respective gesture recognizer, executing the corresponding delegate to determine one or more values, and conditionally sending information corresponding to the respective event to the software application in accordance with the one or more values determined by the delegate. The method includes executing the software application in accordance with information, received from the respective gesture recognizer.

Claims:
What is claimed is: 
     
       1. A method, comprising:
 at an electronic device having a touch-sensitive surface and configured to execute a software application:
 displaying views of the software application, wherein the displayed views are associated with a plurality of gesture recognizers, the plurality of gesture recognizers including:
 at least one discrete gesture recognizer, the discrete gesture recognizer configured to recognize a respective discrete gesture in accordance with a discrete gesture definition and send to the software application only a single action message that indicates recognition of the respective discrete gesture in response to the respective discrete gesture; and 
 at least one continuous gesture recognizer, the continuous gesture recognizer configured to recognize a respective continuous gesture in accordance with a continuous gesture definition that is distinct from the discrete gesture definition and send to the software application action messages for successive recognized sub-events of the respective continuous gesture, wherein:
 each discrete gesture recognizer is configured to send only a single action message for each gesture recognized by the discrete gesture recognizer, and each continuous gesture recognizer is configured to send a sequence of action messages for each gesture recognized by the continuous gesture recognizer; 
 
 
 detecting one or more touches; 
 processing the one or more touches using one or more of the gesture recognizers, the processing of a respective touch of the one or more touches including:
 processing the respective touch at a respective gesture recognizer in accordance with a respective gesture definition corresponding to the respective gesture recognizer, and 
 conditionally sending one or more respective action messages from the respective gesture recognizer to the software application in accordance with an outcome of the processing of the respective touch at the respective gesture recognizer; and 
 
 executing the software application in accordance with one or more action messages received from one or more of the gesture recognizers corresponding to one or more of the touches. 
 
 
     
     
       2. The method of  claim 1 , wherein each gesture recognizer has a set of gesture recognizer states. 
     
     
       3. The method of  claim 2 , wherein:
 the discrete gesture recognizer has a first set of gesture recognizer states including:
 a gesture possible state, corresponding to an initial state of the discrete gesture recognizer; 
 a gesture recognized state, corresponding to recognition of the respective discrete gesture; and 
 a gesture failed state, corresponding to failure of the discrete gesture recognizer to recognize the one or more touches as the respective discrete gesture; and 
 
 the continuous gesture recognizer has a second set of gesture recognizer states including:
 a gesture possible state; 
 a gesture began state, corresponding to initial recognition of the respective continuous gesture; 
 a gesture changed state, corresponding to a respective change in location of the respective touch; 
 a gesture ended state, corresponding to completion of the respective continuous gesture; 
 a gesture canceled state, corresponding to interruption of the recognition of the respective continuous gesture; and 
 a gesture failed state, corresponding to failure of the continuous gesture recognizer to recognize the one or more touches as the respective continuous gesture. 
 
 
     
     
       4. The method of  claim 3 , wherein the gesture recognized state and the gesture ended state have an identical gesture recognizer state value. 
     
     
       5. The method of  claim 1 , wherein the software application has an application state; and conditionally sending the one or more respective action messages includes conditionally sending the one or more respective action messages further in accordance with the application state of the software application. 
     
     
       6. The method of  claim 1 , further comprising requesting additional information from the respective gesture recognizer, wherein executing the software application includes executing the software application further in accordance with the additional information. 
     
     
       7. The method of  claim 6 , wherein the additional information includes the number and locations of respective touches processed at the respective gesture recognizer. 
     
     
       8. The method of  claim 1 , wherein the at least one discrete gesture recognizer includes: one or more of a tap gesture recognizer, and a swipe gesture recognizer; and the at least one continuous gesture recognizer includes: one or more of a long press gesture recognizer, a pinch gesture recognizer, a pan gesture recognizer, a rotate gesture recognizer, and a transform gesture recognizer. 
     
     
       9. The method of  claim 1 , wherein the at least one discrete gesture recognizer includes: a tap gesture recognizer, and a swipe gesture recognizer; and the at least one continuous gesture recognizer includes: a long press gesture recognizer, a pinch gesture recognizer, a pan gesture recognizer, a rotate gesture recognizer, and a transform gesture recognizer. 
     
     
       10. The method of  claim 1 , wherein each gesture recognizer of the at least one discrete gesture recognizer and the at least one continuous gesture recognizer is an instance of a corresponding event recognizer class, the instance of the event recognizer class having a corresponding event recognizer state. 
     
     
       11. The method of  claim 10 , wherein the plurality of gesture recognizers include two or more instances of a particular event recognizer class, each instance of the particular event recognizer class having a state separate from a state of the other instances of the particular event recognizer class. 
     
     
       12. The method of  claim 1 , wherein the processing of the respective touch includes processing the respective touch with two or more of the gesture recognizers, including the discrete gesture recognizer and the continuous gesture recognizer. 
     
     
       13. The method of  claim 12 , wherein, in response to detecting a change in location of the respective touch:
 the continuous gesture recognizer enters a gesture changed state in accordance with a determination that the change in location of the respective touch corresponds to the gesture definition corresponding to the continuous gesture recognizer; and 
 the discrete gesture recognizer enters a gesture recognized state, that is distinct from the gesture changed state, in accordance with a determination that the change in location of the respective touch corresponds to the gesture definition corresponding to the discrete gesture recognizer. 
 
     
     
       14. The method of  claim 1 , wherein the single action message indicates the recognition of and completion of the respective discrete gesture. 
     
     
       15. An electronic device, comprising:
 a touch-sensitive surface; 
 one or more processors; 
 memory; 
 one or more programs stored in the memory and configured to be executed by the one or more processors, the one or more programs including a software application, the software application including instructions for:
 displaying views of the software application, wherein the displayed views are associated with a plurality of gesture recognizers, the plurality of gesture recognizers including:
 at least one discrete gesture recognizer, the discrete gesture recognizer configured to recognize a respective discrete gesture in accordance with a discrete gesture definition and send to the software application only a single action message that indicates recognition of the respective discrete gesture in response to the respective discrete gesture; and 
 at least one continuous gesture recognizer, the continuous gesture recognizer configured to recognize a respective continuous gesture in accordance with a continuous gesture definition that is distinct from the discrete gesture definition and send to the software application action messages for successive recognized sub-events of the respective continuous gesture, wherein:
 each discrete gesture recognizer is configured to send only a single action message for each gesture recognized by the discrete gesture recognizer, and each continuous gesture recognizer is configured to send a sequence of action messages for each gesture recognized by the continuous gesture recognizer; 
 
 
 detecting one or more touches; 
 processing the one or more touches using one or more of the gesture recognizers, the processing of a respective touch of the one or more touches including:
 processing the respective touch at a respective gesture recognizer in accordance with a respective gesture definition corresponding to the respective gesture recognizer, and 
 conditionally sending one or more respective action messages from the respective gesture recognizer to the software application in accordance with an outcome of the processing of the respective touch at the respective gesture recognizer; and 
 
 executing the software application in accordance with one or more action messages received from one or more of the gesture recognizers corresponding to one or more of the touches. 
 
 
     
     
       16. The electronic device of  claim 15 , wherein each gesture recognizer has a set of gesture recognizer states. 
     
     
       17. The electronic device of  claim 16 , wherein:
 the discrete gesture recognizer has a first set of gesture recognizer states including:
 a gesture possible state, corresponding to an initial state of the discrete gesture recognizer; 
 a gesture recognized state, corresponding to recognition of the respective discrete gesture; and 
 a gesture failed state, corresponding to failure of the discrete gesture recognizer to recognize the one or more touches as the respective discrete gesture; and 
 
 the continuous gesture recognizer has a second set of gesture recognizer states including:
 a gesture possible state; 
 a gesture began state, corresponding to initial recognition of the respective continuous gesture; 
 a gesture changed state, corresponding to a respective change in location of the respective touch; 
 a gesture ended state, corresponding to completion of the respective continuous gesture; 
 a gesture canceled state, corresponding to interruption of the recognition of the respective continuous gesture; and 
 a gesture failed state, corresponding to failure of the continuous gesture recognizer to recognize the one or more touches as the respective continuous gesture. 
 
 
     
     
       18. The electronic device of  claim 16 , wherein the gesture recognized state and the gesture ended state have an identical gesture recognizer state value. 
     
     
       19. The electronic device of  claim 15 , wherein the software application has an application state; and the software application includes instructions for conditionally sending the one or more respective action messages includes conditionally sending the one or more respective action messages further in accordance with the application state of the software application. 
     
     
       20. The electronic device of  claim 15 , the software application further comprising instructions for requesting additional information from the respective gesture recognizer, and instructions for executing the software application further in accordance with the additional information. 
     
     
       21. The electronic device of  claim 20 , wherein the additional information includes the number and locations of respective touches processed at the respective gesture recognizer. 
     
     
       22. The electronic device of  claim 15 , wherein the at least one discrete gesture recognizer includes: one or more of a tap gesture recognizer, and a swipe gesture recognizer; and the at least one continuous gesture recognizer includes: one or more of a long press gesture recognizer, a pinch gesture recognizer, a pan gesture recognizer, a rotate gesture recognizer, and a transform gesture recognizer. 
     
     
       23. The electronic device of  claim 15 , wherein the at least one discrete gesture recognizer includes: a tap gesture recognizer, and a swipe gesture recognizer; and the at least one continuous gesture recognizer includes: a long press gesture recognizer, a pinch gesture recognizer, a pan gesture recognizer, a rotate gesture recognizer, and a transform gesture recognizer. 
     
     
       24. The electronic device of  claim 15 , wherein each gesture recognizer of the at least one discrete gesture recognizer and the at least one continuous gesture recognizer is an instance of a corresponding event recognizer class, the instance of the event recognizer class having a corresponding event recognizer state. 
     
     
       25. The electronic device of  claim 24 , wherein the plurality of gesture recognizers include two or more instances of a particular event recognizer class, each instance of the particular event recognizer class having a state separate from a state of the other instances of the particular event recognizer class. 
     
     
       26. The electronic device of  claim 15 , wherein the processing of the respective touch includes processing the respective touch with two or more of the gesture recognizers, including the discrete gesture recognizer and the continuous gesture recognizer. 
     
     
       27. The electronic device of  claim 26 , wherein:
 the continuous gesture recognizer is configured to, in response to detecting a change in location of a respective touch, enter a gesture changed state in accordance with a determination that the change in location of the respective touch corresponds to the gesture definition corresponding to the continuous gesture recognizer; and 
 the discrete gesture recognizer is configured to, in response to detecting the change in location of the respective touch, enter a gesture recognized state, that is distinct from the gesture changed state, in accordance with a determination that the change in location of the respective touch corresponds to the gesture definition corresponding to the discrete gesture recognizer. 
 
     
     
       28. A non-transitory computer readable storage medium storing one or more programs for execution by one of more processors of an electronic device having a touch-sensitive surface, the one or more programs including a software application, the software application including instructions for:
 displaying views of the software application, wherein the displayed views are associated with a plurality of gesture recognizers, the plurality of gesture recognizers including:
 at least one discrete gesture recognizer, the discrete gesture recognizer configured to recognize a respective discrete gesture in accordance with a discrete gesture definition and send to the software application only a single action message that indicates recognition of the respective discrete gesture in response to the respective discrete gesture; and 
 at least one continuous gesture recognizer, the continuous gesture recognizer configured to recognize a respective continuous gesture in accordance with a continuous gesture definition that is distinct from the discrete gesture definition and send to the software application action messages for successive recognized sub-events of the respective continuous gesture, wherein:
 each discrete gesture recognizer is configured to send only a single action message for each gesture recognized by the discrete gesture recognizer, and each continuous gesture recognizer is configured to send a sequence of action messages for each gesture recognized by the continuous gesture recognizer; 
 
 
 detecting one or more touches; 
 processing the one or more touches using one or more of the gesture recognizers, the processing of a respective touch of the one or more touches including:
 processing the respective touch at a respective gesture recognizer in accordance with a respective gesture definition corresponding to the respective gesture recognizer, and 
 conditionally sending one or more respective action messages from the respective gesture recognizer to the software application in accordance with an outcome of the processing of the respective touch at the respective gesture recognizer; and 
 
 executing the software application in accordance with one or more action messages received from one or more of the gesture recognizers corresponding to one or more of the touches. 
 
     
     
       29. The non-transitory computer readable storage medium of  claim 28 , wherein each gesture recognizer has a set of gesture recognizer states. 
     
     
       30. The non-transitory computer readable storage medium of  claim 29 , wherein:
 the discrete gesture recognizer has a first set of gesture recognizer states including:
 a gesture possible state, corresponding to an initial state of the discrete gesture recognizer; 
 a gesture recognized state, corresponding to recognition of the respective discrete gesture; and 
 a gesture failed state, corresponding to failure of the discrete gesture recognizer to recognize the one or more touches as the respective discrete gesture; and 
 
 the continuous gesture recognizer has a second set of gesture recognizer states including:
 a gesture possible state; 
 a gesture began state, corresponding to initial recognition of the respective continuous gesture; 
 a gesture changed state, corresponding to a respective change in location of the respective touch; 
 a gesture ended state, corresponding to completion of the respective continuous gesture; 
 a gesture canceled state, corresponding to interruption of the recognition of the respective continuous gesture; and 
 a gesture failed state, corresponding to failure of the continuous gesture recognizer to recognize the one or more touches as the respective continuous gesture. 
 
 
     
     
       31. The non-transitory computer readable storage medium of  claim 28 , wherein the software application has an application state; and the software application includes instructions for conditionally sending the one or more respective action messages includes conditionally sending the one or more respective action messages further in accordance with the application state of the software application. 
     
     
       32. The non-transitory computer readable storage medium of  claim 28 , the software application further comprising instructions for requesting additional information from the respective gesture recognizer, and instructions for executing the software application further in accordance with the additional information. 
     
     
       33. The non-transitory computer readable storage medium of  claim 28 , wherein each gesture recognizer of the at least one discrete gesture recognizer and the at least one continuous gesture recognizer is an instance of a corresponding event recognizer class, the instance of the event recognizer class having a corresponding event recognizer state. 
     
     
       34. The non-transitory computer readable storage medium of  claim 33 , wherein the plurality of gesture recognizers include two or more instances of a particular event recognizer class, each instance of the particular event recognizer class having a state separate from a state of the other instances of the particular event recognizer class. 
     
     
       35. The non-transitory computer readable storage medium of  claim 28 , wherein the processing of the respective touch includes processing the respective touch with two or more of the gesture recognizers, including the discrete gesture recognizer and the continuous gesture recognizer. 
     
     
       36. The non-transitory computer readable storage medium of  claim 35 , wherein:
 the continuous gesture recognizer is configured to, in response to detecting a change in location of a respective touch, enter a gesture changed state in accordance with a determination that the change in location of the respective touch corresponds to the gesture definition corresponding to the continuous gesture recognizer; and 
 the discrete gesture recognizer is configured to, in response to detecting the change in location of the respective touch, enter a gesture recognized state, that is distinct from the gesture changed state, in accordance with a determination that the change in location of the respective touch corresponds to the gesture definition corresponding to the discrete gesture recognizer.

Description:
RELATED APPLICATIONS 
     This application claims priority to U.S. Provisional Application Ser. No. 61/298,531, filed Jan. 26, 2010, entitled “Gesture Recognizers with Delegates for Controlling and Modifying Gesture Recognition,” which is incorporated herein by reference in its entirety. 
     This relates to the following application, which is hereby incorporated by reference: U.S. patent application Ser. No. 12/566,660, “Event Recognition,” filed Sep. 24, 2009, which in turn claims priority to U.S. Provisional Patent Application No. 61/210,332, “Event Recognition,” filed on Mar. 16, 2009, which are incorporated herein by reference in their entirety. 
    
    
     TECHNICAL FIELD 
     This relates generally to user interface processing, including but not limited to, apparatuses and methods for recognizing gesture inputs. 
     BACKGROUND 
     An electronic device typically includes a user interface that may be used to interact with the computing device. The user interface may include a display and/or input devices such as a keyboard, mice, and touch-sensitive surfaces for interacting with various aspects of the user interface. In some devices with a touch-sensitive surface as an input device, a first set of touch-based gestures (e.g., two or more of: tap, double tap, horizontal swipe, vertical swipe, pinch, depinch, two finger swipe) are recognized as proper inputs in a particular context (e.g., in a particular mode of a first application), and other, different sets of touch-based gestures are recognized as proper inputs in other contexts (e.g., different applications and/or different modes or contexts within the first application). As a result, the software and logic required for recognizing and responding to touch-based gestures can become complex, and can require revision each time an application is updated or a new application is added to the computing device. These and similar issues may arise in user interfaces that utilize input sources other than touch-based gestures. 
     Thus, it would be desirable to have a comprehensive framework or mechanism for recognizing touch-based gestures and events, as well as gestures and events from other input sources, that is easily adaptable to virtually all contexts or modes of all application programs on a computing device, and that requires little or no revision when an application is updated or a new application is added to the computing device. 
     SUMMARY 
     To address the aforementioned drawbacks, in accordance with some embodiments, a method is performed at an electronic device having one or more event sensors and configured to execute a software application that includes a plurality of views and an application state of the software application. The method includes displaying one or more views of the plurality of views. A respective view of the one or more displayed views includes one or more gesture recognizers, and a respective gesture recognizer has a corresponding delegate. The method includes detecting one or more events, and processing a respective event of the one or more events using the respective gesture recognizer. The processing of the respective event includes: processing the respective event at the respective gesture recognizer in accordance with a respective gesture definition corresponding to the respective gesture recognizer, executing the respective gesture recognizer&#39;s corresponding delegate to determine one or more values in accordance with the application state, and conditionally sending information corresponding to the respective event to the software application in accordance with an outcome of the processing of the respective event by the respective gesture recognizer and in accordance with the one or more values determined by the corresponding delegate. The method furthermore includes executing the software application in accordance with information, received from the respective gesture recognizer, corresponding to the respective event. 
     In accordance with some embodiments, an electronic device includes: one or more event sensors for detecting events, one or more processors, memory, and one or more programs stored in the memory and configured to be executed by the one or more processors. The one or more programs include a software application having a plurality of views and an application state. The software application includes instructions for displaying one or more views of the plurality of views. A respective view of the one or more displayed views includes one or more gesture recognizers, and a respective gesture recognizer has a corresponding delegate. The software application further includes instructions for processing a respective event of the detected events using the respective gesture recognizer. The instructions for processing of the respective event include instructions for: processing the respective event at the respective gesture recognizer in accordance with a respective gesture definition corresponding to the respective gesture recognizer, executing the corresponding delegate to determine one or more values in accordance with the application state, and conditionally sending information corresponding to the respective event to the software application in accordance with an outcome of the processing of the respective event by the respective gesture recognizer and in accordance with the one or more values determined by the corresponding delegate. The software application furthermore includes instructions for executing the software application in accordance with information, received from the respective gesture recognizer, corresponding to the respective event. 
     In accordance with some embodiments, a computer readable storage medium stores one or more programs for execution by one of more processors of an electronic device having one or more event sensors for detecting events. The one or more programs include a software application including a plurality of views and an application state of the software application. The software application includes instructions for displaying one or more views of the plurality of views. A respective view of the one or more displayed views includes one or more respective gesture recognizers, and a respective gesture recognizer has a corresponding delegate. The software application further includes instructions for processing a respective event of the detected events using the respective gesture recognizer. The instructions for processing of the respective event include instructions for: processing the respective event at the respective gesture recognizer in accordance with a respective gesture definition corresponding to the respective gesture recognizer, executing the corresponding delegate to determine one or more values in accordance with the application state, and conditionally sending information corresponding to the respective event to the software application in accordance with an outcome of the processing of the respective event by the respective gesture recognizer and in accordance with the one or more values determined by the corresponding delegate. The software application furthermore includes instructions for executing the software application in accordance with information, received from the respective gesture recognizer, corresponding to the respective event. 
     In accordance with some embodiments, a method is performed at an electronic device having a touch-sensitive surface and configured to execute a software application that includes a plurality of views and an application state of the software application. The method includes displaying one or more views of the plurality of views. A respective view of the one or more displayed views includes a respective gesture recognizer. The respective gesture recognizer has a corresponding delegate. The method also includes detecting one or more touches, on the touch-sensitive surface, having a touch position that falls within one or more of the displayed views. The method further includes processing a respective touch of the one or more touches. Processing the respective touch includes executing the delegate corresponding to the respective gesture recognizer to obtain a receive touch value in accordance with the application state, and when the receive touch value meets predefined criteria, processing the respective touch at the respective gesture recognizer. Processing the respective touch also includes conditionally sending information corresponding to the respective touch to the software application. The method furthermore includes executing the software application in accordance with information, received from the respective gesture recognizer, corresponding to the respective touch. 
     In accordance with some embodiments, an electronic device includes a touch-sensitive surface, one or more processors, memory, and one or more programs stored in the memory and configured to be executed by the one or more processors. The one or more programs include a software application including a plurality of views and an application state of the software application. The software application includes instructions for displaying one or more views of the plurality of views. A respective view of the one or more displayed views includes a respective gesture recognizer. The respective gesture recognizer has a corresponding delegate. The software application also includes instructions for detecting one or more touches, on the touch-sensitive surface, having a touch position that falls within one or more of the displayed views. The software application further includes instructions for processing a respective touch of the one or more touches. The instructions for processing the respective touch include instructions for: executing the delegate corresponding to the respective gesture recognizer to obtain a receive touch value in accordance with the application state, and when the receive touch value meets predefined criteria, processing the respective touch at the respective gesture recognizer. The instructions for processing the respective touch also include instructions for conditionally sending information corresponding to the respective touch to the software application. The software application furthermore includes instructions for executing the software application in accordance with information, received from the respective gesture recognizer, corresponding to the respective touch. 
     In accordance with some embodiments, a computer readable storage medium stores one or more programs for execution by one of more processors of an electronic device having a touch-sensitive surface. The one or more programs include a software application including a plurality of views and an application state of the software application. The software application includes instructions for displaying one or more views of the plurality of views. A respective view of the one or more displayed views includes a respective gesture recognizer. The respective gesture recognizer has a corresponding delegate. The software application also includes instructions for detecting one or more touches, on the touch-sensitive surface, having a touch position that falls within one or more of the displayed views. The software application further includes instructions for processing a respective touch of the one or more touches. The instructions for processing the respective touch include instructions for: executing the delegate corresponding to the respective gesture recognizer to obtain a receive touch value in accordance with the application state, and when the receive touch value meets predefined criteria, processing the respective touch at the respective gesture recognizer. The instructions for processing the respective touch also include instructions for conditionally sending information corresponding to the respective touch to the software application. The software application furthermore includes instructions for executing the software application in accordance with information, received from the respective gesture recognizer, corresponding to the respective touch. 
     In accordance with some embodiments, a method is performed at an electronic device having a touch-sensitive surface and configured to execute a software application. The method includes displaying one or more views of the software application. The one or more displayed views include a plurality of gesture recognizers. The plurality of gesture recognizers includes at least one discrete gesture recognizer and at least one continuous gesture recognizer. The discrete gesture recognizer is configured to send a single action message in response to a respective gesture, and the continuous gesture recognizer is configured to send action messages at successive recognized sub-events of a respective recognized gesture. The method also includes detecting one or more touches, and processing each of the touches using one or more of the gesture recognizers. The processing of a respective touch includes processing the respective touch at a respective gesture recognizer in accordance with a respective gesture definition corresponding to the respective gesture recognizer, and conditionally sending one or more respective action messages to the software application in accordance with an outcome of the processing of the respective touch at the respective gesture recognizer. The method further includes executing the software application in accordance with one or more action messages received from one or more of the gesture recognizers corresponding to one or more of the touches. 
     In accordance with some embodiments, an electronic device includes a touch-sensitive surface, one or more processors, memory, and one or more programs stored in the memory and configured to be executed by the one or more processors. The one or more programs include a software application, and the software application includes instructions for displaying one or more views of the software application. The one or more displayed views include a plurality of gesture recognizers. The plurality of gesture recognizers includes at least one discrete gesture recognizer and at least one continuous gesture recognizer. The discrete gesture recognizer is configured to send a single action message in response to a respective gesture, and the continuous gesture recognizer is configured to send action messages at successive recognized sub-events of a respective recognized gesture. The software application also includes instructions for detecting one or more touches and processing each of the touches using one or more of the gesture recognizers. The instructions for processing of a respective touch include instructions for: processing the respective touch at a respective gesture recognizer in accordance with a respective gesture definition corresponding to the respective gesture recognizer, and conditionally sending one or more respective action messages to the software application in accordance with an outcome of the processing of the respective touch at the respective gesture recognizer. The software application further includes instructions for executing the software application in accordance with one or more action messages received from one or more of the gesture recognizers corresponding to one or more of the touches. 
     In accordance with some embodiments, a computer readable storage medium stores one or more programs for execution by one of more processors of an electronic device having a touch-sensitive surface. The one or more programs include a software application, and the software application includes instructions for displaying one or more views of the software application. The one or more displayed views include a plurality of gesture recognizers. The plurality of gesture recognizers includes at least one discrete gesture recognizer, and at least one continuous gesture recognizer. The discrete gesture recognizer is configured to send a single action message in response to a respective gesture, and the continuous gesture recognizer is configured to send action messages at successive recognized sub-events of a respective recognized gesture. The software application also includes instructions for: detecting one or more touches, and processing each of the touches using one or more of the gesture recognizers. The instructions for the processing of a respective touch includes instructions for processing the respective touch at a respective gesture recognizer in accordance with a respective gesture definition corresponding to the respective gesture recognizer, and conditionally sending one or more respective action messages to the software application in accordance with an outcome of the processing of the respective touch at the respective gesture recognizer. The software application further includes instructions for executing the software application in accordance with one or more action messages received from one or more of the gesture recognizers corresponding to one or more of the touches. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIGS. 1A and 1B  are block diagrams illustrating electronic devices, according to some embodiments. 
         FIG. 2  is a diagram of an input/output processing stack of an exemplary electronic device according to some embodiments. 
         FIG. 3A  illustrates an exemplary view hierarchy, according to some embodiments. 
         FIG. 3B  is a block diagram illustrating exemplary components for event handling in accordance with some embodiments. 
         FIG. 3C  is a block diagram illustrating exemplary classes and instances of gesture recognizers in accordance with some embodiments. 
         FIGS. 4A-4D  are flow charts illustrating exemplary state machines, according to some embodiments. 
         FIG. 5A  is a block diagram illustrating the flow of event information, according to some embodiments. 
         FIGS. 5B and 5C  are high-level flow charts illustrating gesture recognition methods, according to some embodiments. 
         FIGS. 6A-6B  are flow charts illustrating an exemplary method of processing a respective event in accordance with information obtained from a delegate, according to some embodiments. 
         FIGS. 7A-7B  are flow charts illustrating an exemplary method of processing a respective touch in accordance with a receive touch value obtained from a delegate, according to some embodiments. 
         FIGS. 8A-8B  are flow charts illustrating an exemplary method of processing a respective touch in a software application including a discrete gesture recognizer and a continuous gesture recognizer, according to some embodiments. 
     
    
    
     Like reference numerals refer to corresponding parts throughout the drawings. 
     DESCRIPTION OF EMBODIMENTS 
     Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. 
     It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first contact could be termed a second contact, and, similarly, a second contact could be termed a first contact, without departing from the scope of the present invention. The first contact and the second contact are both contacts, but they are not the same contact. 
     The terminology used in the description of the invention herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the description of the invention and the appended claims, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. 
     As used herein, the term “if” may be construed to mean “when” or “upon” or “in response to determining” or “in response to detecting,” depending on the context. Similarly, the phrase “if it is determined” or “if [a stated condition or event] is detected” may be construed to mean “upon determining” or “in response to determining” or “upon detecting (the stated condition or event)” or “in response to detecting (the stated condition or event),” depending on the context. 
     As used herein, the term “event” refers to an input detected by one or more sensors of the device. In particular, the term “event” includes a touch on a touch-sensitive surface. An event comprises one or more sub-events. Sub-events typically refer to changes to an event (e.g., a touch-down, touch-move, and lift-off of the touch can be sub-events). Sub-events in the sequence of one or more sub-events can include many forms, including without limitation, key presses, key press holds, key press releases, button presses, button press holds, button press releases, joystick movements, mouse movements, mouse button presses, mouse button releases, pen stylus touches, pen stylus movements, pen stylus releases, oral instructions, detected eye movements, biometric inputs, and detected physiological changes in a user, among others. Since an event may comprise a single sub-event (e.g., a short lateral motion of the device), the term “sub-event” as used herein also refers to an event. 
     As used herein, the terms “event recognizer” and “gesture recognizer” are used interchangeably to refer to a recognizer that can recognize a gesture or other events (e.g., motion of the device). 
     As noted above, in some devices with a touch-sensitive surface as an input device, a first set of touch-based gestures (e.g., two or more of: tap, double tap, horizontal swipe, vertical swipe) are recognized as proper inputs in a particular context (e.g., in a particular mode of a first application), and other, different sets of touch-based gestures are recognized as proper inputs in other contexts (e.g., different applications and/or different modes or contexts within the first application). Furthermore, two or more proper inputs (or gestures) may interfere with, or conflict with, each other (e.g., after detecting a single tap, it needs to be decided whether to recognize the single tap as a complete single tap gesture, or as part of a double tap gesture). As a result, the software and logic required for recognizing and responding to touch-based gestures can become complex, and can require revision each time an application is updated or a new application is added to the computing device. 
     When using touch-based gestures to control an application running in a device having a touch-sensitive surface, touches have both temporal and spatial aspects. The temporal aspect, called a phase, indicates when a touch has just begun, whether it is moving or stationary, and when it ends—that is, when the finger is lifted from the screen. A spatial aspect of a touch is the set of views or user interface windows in which the touch occurs. The views or windows in which a touch is detected may correspond to programmatic levels within a view hierarchy. For example, the lowest level view in which a touch is detected may be called the hit view, and the set of events that are recognized as proper inputs may be determined based, at least in part, on the hit view of the initial touch that begins a touch-based gesture. 
       FIGS. 1A and 1B  are block diagrams illustrating different embodiments of an electronic device  102 ,  104 , according to some embodiments. The electronic device  102  or  104  may be any electronic device including, but not limited to, a desktop computer system, a laptop computer system, a netbook computer system, mobile phone, a smart phone, a personal digital assistant, or a navigation system. The electronic device may also be a portable electronic device with a touch screen display (e.g., touch-sensitive display  156 ,  FIG. 1B ) configured to present a user interface, a computer with a touch screen display configured to present a user interface, a computer with a touch sensitive surface and a display configured to present a user interface, or any other form of computing device, including without limitation, consumer electronic devices, mobile telephones, video game systems, electronic music players, tablet PCs, electronic book reading systems, e-books, PDAs, electronic organizers, email devices, laptops, netbooks or other computers, kiosk computers, vending machines, smart appliances, etc. The electronic device  102  or  104  includes a user interface  113 . 
     In some embodiments, electronic device  104  includes a touch screen display. In these embodiments, user interface  113  may include an on-screen keyboard (not depicted) that is used by a user to interact with electronic devices  102  and  104 . Alternatively, a keyboard may be separate and distinct from electronic device  104  (or electronic device  102 ). For example, a keyboard may be a wired or wireless keyboard coupled to electronic device  102  or  104 . 
     In some embodiments, electronic device  102  includes display  126  and one or more input devices  128  (e.g., keyboard, mouse, trackball, microphone, physical button(s), touchpad, etc.) that are coupled to electronic device  102 . In these embodiments, one or more of input devices  128  may optionally be separate and distinct from electronic device  102 . For example, the one or more input devices may include one or more of: a keyboard, a mouse, a trackpad, a trackball, and an electronic pen, any of which may optionally be separate from the electronic device. Optionally, device  102  or  104  may include one or more sensors  130 , such as one or more accelerometers, gyroscopes, GPS systems, speakers, infrared (IR) sensors, biometric sensors, cameras, etc. It is noted that the description above of various exemplary devices as input devices  128  or as sensors  130  is of no significance to the operation of the embodiments described herein, and that any input or sensor device herein described as an input device may equally well be described as a sensor, and vice versa. In some embodiments, signals produced by one or more sensors  130  are used as input sources for detecting events. 
     In some embodiments, electronic device  104  includes touch-sensitive display  156  (i.e., a display having a touch-sensitive surface) and one or more input devices  128  that are coupled to electronic device  104 . In some embodiments, touch-sensitive display  156  has the ability to detect two or more distinct, concurrent (or partially concurrent) touches, and in these embodiments, display  156  is sometimes herein called a multitouch display or multitouch-sensitive display. 
     In some embodiments of electronic device  102  or  104  discussed herein, input devices  128  are disposed in electronic device  102  or  104 . In other embodiments, one or more of input devices  128  is separate and distinct from electronic device  102  or  104 ; for example, one or more of input devices  128  may be coupled to electronic device  102  or  104  by a cable (e.g., USB cable) or wireless connection (e.g., Bluetooth connection). 
     When using input devices  128 , or when performing a touch-based gesture on touch-sensitive display  156  of electronic device  104 , the user generates a sequence of sub-events that are processed by one or more CPUs  110  of electronic device  102  or  104 . In some embodiments, one or more CPUs  110  of electronic device  102  or  104  process the sequence of sub-events to recognize events. 
     Electronic device  102  or  104  typically includes one or more single- or multi-core processing units (“CPU” or “CPUs”)  110  as well as one or more network or other communications interfaces  112 , respectively. Electronic device  102  or  104  includes memory  111  and one or more communication buses  115 , respectively, for interconnecting these components. Communication buses  115  may include circuitry (sometimes called a chipset) that interconnects and controls communications between system components (not depicted herein). As discussed briefly above, electronic device  102  or  104  includes a user interface  113 , including a display (e.g., display  126 , or touch-sensitive display  156 ). Further, electronic device  102  or  104  typically includes input devices  128  (e.g., keyboard, mouse, touch sensitive surfaces, keypads, etc.). In some embodiments, the input devices  128  include an on-screen input device (e.g., a touch-sensitive surface of a display device). Memory  111  may include high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices; and may include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices. Memory  111  may optionally include one or more storage devices remotely located from the CPU(s)  110 . Memory  111 , or alternately the non-volatile memory device(s) within memory  111 , comprise a computer readable storage medium. In some embodiments, memory  111  (of electronic device  102  or  104 ) or the computer readable storage medium of memory  111  stores the following programs, modules and data structures, or a subset thereof:
         operating system  118 , which includes procedures for handling various basic system services and for performing hardware dependent tasks;   communication module  120 , which is used for connecting electronic device  102  or  104 , respectively, to other devices via their one or more respective communication interfaces  112  (wired or wireless) and one or more communication networks, such as the Internet, other wide area networks, local area networks, metropolitan area networks, and so on;   user interface module  122 , which is used for displaying user interfaces including user interface objects on display  126  or touch-sensitive display  156 ;   control application  124 , which is used for controlling processes (e.g., hit view determination, thread management, and/or event monitoring, etc.); in some embodiments, control application  124  includes a run-time application; in other embodiments, the run-time application includes control application  124 ;   event delivery system  136 , which may be implemented in various alternate embodiments within operating system  118  or in application software  132 ; in some embodiments, however, some aspects of event delivery system  136  may be implemented in operating system  118  while other aspects (e.g., at least a subset of event handlers) are implemented in application software  132 ;   application software  132 , which may include one or more software applications (e.g., an email application, a web browser application, a text messaging application, etc.); a respective software application typically has, at least when executing, an application state, indicating the state of the software application and its components (e.g., gesture recognizers and delegates); see application internal state  317  ( FIG. 3B ), described below; and   device/global internal state  134 , which includes one or more of: application state, indicating the state of software applications and their components (e.g., gesture recognizers and delegates); display state, indicating what applications, views or other information occupy various regions of touch-sensitive display  156  or display  126 ; sensor state, including information obtained from the device&#39;s various sensors  130 , input devices  128 , and/or touch-sensitive display  156 ; and location information concerning the device&#39;s location and/or attitude.       

     Each of the above identified elements may be stored in one or more of the previously mentioned memory devices, and corresponds to a set of instructions for performing functions described herein. The set of instructions can be executed by one or more processors (e.g., one or more CPUs  110 ). The above identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures or modules, and thus various subsets of these modules may be combined or otherwise rearranged in various embodiments. In some embodiments, memory  111  may store a subset of the modules and data structures identified above. Furthermore, memory  111  may store additional modules and data structures not described above. 
       FIG. 2  is a diagram of input/output processing stack  200  of an exemplary electronic device or apparatus (e.g., device  102  or  104 ) according to some embodiments of the invention. Hardware (e.g., electronic circuitry)  212  of the device is at the base level of the input/output processing stack  200 . Hardware  212  can include various hardware interface components, such as the components depicted in  FIGS. 1A and/or 1B . Hardware  212  can also include one or more of above mentioned sensors  130 . All the other elements ( 132 ,  204 - 210 ) of input/output processing stack  200  are software procedures, or portions of software procedures, that process inputs received from hardware  212  and generate various outputs that are presented through a hardware user interface (e.g., one or more of a display, speakers, device vibration actuator). 
     A driver or a set of drivers  210  communicates with hardware  212 . Drivers  210  can receive and process input data received from hardware  212 . Core Operating System (“OS”)  208  can communicate with driver(s)  210 . Core OS  208  can process raw input data received from driver(s)  210 . In some embodiments, drivers  210  can be considered to be a part of core OS  208 . 
     A set of OS application programming interfaces (“OS APIs”)  206 , are software procedures that communicate with core OS  208 . In some embodiments, APIs  206  are included in the device&#39;s operating system, but at a level above core OS  208 . APIs  206  are designed for use by applications running on the electronic devices or apparatuses discussed herein. User interface (UI) APIs  204  can utilize OS APIs  206 . Application software (“applications”)  132  running on the device can utilize UI APIs  204  in order to communicate with the user. UI APIs  204  can, in turn, communicate with lower level elements, ultimately communicating with various user interface hardware, e.g., multitouch display  156 . 
     While each layer input/output processing stack  200  can utilize the layer underneath it, that is not always required. For example, in some embodiments, applications  132  can occasionally communicate with OS APIs  206 . In general, layers at or above OS API layer  206  may not directly access Core OS  208 , driver(s)  210 , or hardware  212 , as these layers are considered private. Applications in layer  132  and UI API  204  usually direct calls to the OS API  206 , which in turn, accesses the layers Core OS  208 , driver(s)  210 , and hardware  212 . 
     Stated in another way, one or more hardware elements  212  of electronic device  102  or  104 , and software running on the device, such as, for example, drivers  210  (depicted in  FIG. 2 ), core OS (operating system)  208  (depicted in  FIG. 2 ), operating system API software  206  (depicted in  FIG. 2 ), and Application and User Interface API software  204  (depicted in  FIG. 2 ) detect input events (which may correspond to sub-events in a gesture) at one or more of the input device(s)  128  and/or a touch-sensitive display  156  and generate or update various data structures (stored in memory of device  102  or  104 ) used by a set of currently active event recognizers to determine whether and when the input events correspond to an event to be delivered to application  132 . Embodiments of event recognition methodologies, apparatus and computer program products are described in more detail below. 
       FIG. 3A  depicts an exemplary view hierarchy  300 , which in this example is a search program displayed in outermost view  302 . Outermost view  302  generally encompasses the entire user interface a user may directly interact with, and includes subordinate views, e.g.,
         search results panel  304 , which groups search results and can be scrolled vertically;   search field  306 , which accepts text inputs; and   a home row  310 , which groups applications for quick access.       

     In this example, each subordinate view includes lower-level subordinate views. In other examples, the number of view levels in the hierarchy  300  may differ in different branches of the hierarchy, with one or more subordinate views having lower-level subordinate views, and one or more other subordinate views not have any such lower-level subordinate views. Continuing with the example shown in  FIG. 3A , search results panel  304  contains separate subordinate views  305  (subordinate to panel  304 ) for each search result. Here, this example shows one search result in a subordinate view called the maps view  305 . Search field  306  includes a subordinate view herein called clear contents icon view  307 , which clears the contents of the search field when a user performs a particular action (e.g., a single touch or tap gesture) on the clear contents icon in view  307 . Home row  310  includes subordinate views  310 - 1 ,  310 - 2 ,  310 - 3 , and  310 - 4 , which respectively correspond to a contacts application, an email application, a web browser, and an iPod music interface. 
     A touch sub-event  301 - 1  is represented in outermost view  302 . Given the location of touch sub-event  301 - 1  over both the search results panel  304 , and maps view  305 , the touch sub-event is also represented over those views as  301 - 2  and  301 - 3 , respectively. Actively involved views of the touch sub-event include the views search results panel  304 , maps view  305  and outermost view  302 . Additional information regarding sub-event delivery and actively involved views is provided below with reference to  FIGS. 3B and 3C . 
     Views (and corresponding programmatic levels) can be nested. In other words, a view can include other views. Consequently, the software element(s) (e.g., event recognizers) associated with a first view can include or be linked to one or more software elements associated with views within the first view. While some views can be associated with applications, others can be associated with high level OS elements, such as graphical user interfaces, window managers, etc. 
       FIG. 3B  is a block diagram illustrating exemplary components for event handling (e.g., event handling components  390 ) in accordance with some embodiments. In some embodiments, memory  111  (in  FIGS. 1A and 1B ) includes event recognizer global methods  311  (e.g., in operating system  118 ) and a respective application  132 - 1 . 
     In some embodiments, event recognizer global methods  311  include event monitor  312 , hit view determination module  313 , active event recognizer determination module  314 , and event dispatcher module  315 . In some embodiments, event recognizer global methods  311  are located within event delivery system  136 . In some embodiments, event recognizer global methods  311  are implemented in operating system  118 . Alternatively, event recognizer global methods  311  are implemented in application  132 - 1 . In yet other embodiments, event recognizer global methods  311  are implemented as a stand-alone module, or a part of another module stored in memory  111  (e.g., a contact/motion module (not depicted)). 
     Event monitor  312  receives event information from sensors  130 , touch-sensitive display  156 , and/or input devices  128 . Event information includes information about an event (e.g., a user touch on touch-sensitive display  156 , as part of a multi-touch gesture or a motion of device  102  or  104 ) and/or a sub-event (e.g., a movement of a touch across touch-sensitive display  156 ). For example, event information for a touch event includes one or more of: a location and time stamp of a touch. Similarly, event information for a swipe event includes two or more of: a location, time stamp, direction, and speed of a swipe. Sensors  130 , touch-sensitive display  156 , and input devices  128  transmit information event and sub-event information to event monitor  312  either directly or through a peripherals interface, which retrieves and stores event information. Sensors  130  include one or more of: proximity sensor, accelerometer(s), gyroscopes, microphone, and video camera. In some embodiments, sensors  130  also include input devices  128  and/or touch-sensitive display  156 . 
     In some embodiments, event monitor  312  sends requests to sensors  130  and/or the peripherals interface at predetermined intervals. In response, sensors  130  and/or the peripherals interface transmit event information. In other embodiments, sensors  130  and the peripheral interface transmit event information only when there is a significant event (e.g., receiving an input beyond a predetermined noise threshold and/or for more than a predetermined duration). 
     Event monitor  312  receives event information and determines the application  132 - 1  and application view  316 - 2  of application  132 - 1  to which to deliver the event information. 
     In some embodiments, event recognizer global methods  311  also include a hit view determination module  313  and/or an active event recognizer determination module  314 . 
     Hit view determination module  313  provides software procedures for determining where an event or a sub-event has taken place within one or more views, when touch-sensitive display  156  displays more than one view. Views are made up of controls and other elements that a user can see on the display. 
     Another aspect of the user interface associated with an application  132 - 1  is a set views  316 , sometimes herein called application views or user interface windows, in which information is displayed and touch-based gestures occur. The application views (of a respective application) in which a touch is detected may correspond to a particular view within a view hierarchy of the application. For example, the lowest level view in which a touch is detected may be called the hit view, and the set of events that are recognized as proper inputs may be determined based, at least in part, on the hit view of the initial touch that begins a touch-based gesture. 
     Hit view determination module  313  receives information related to events and/or sub-events. When an application has multiple views organized in a hierarchy, hit view determination module  313  identifies a hit view as the lowest view in the hierarchy which should handle the event or sub-event. In most circumstances, the hit view is the lowest level view in which an initiating event or sub-event occurs (i.e., the first event or sub-event in the sequence of events and/or sub-events that form a gesture). Once the hit view is identified by the hit view determination module, the hit view typically receives all events and/or sub-events related to the same touch or input source for which it was identified as the hit view. 
     Active event recognizer determination module  314  determines which view or views within a view hierarchy should receive a particular sequence of events and/or sub-events. In some application contexts, active event recognizer determination module  314  determines that only the hit view should receive a particular sequence of events and/or sub-events. In other application contexts, active event recognizer determination module  314  determines that all views that include the physical location of an event or sub-event are actively involved views, and therefore determines that all actively involved views should receive a particular sequence of events and/or sub-events. In other application contexts, even if touch events and/or sub-events are entirely confined to the area associated with one particular view, views higher in the hierarchy still remain as actively involved views. 
     Event dispatcher module  315  dispatches the event information to an event recognizer (also called herein “gesture recognizer”) (e.g., event recognizer  320 - 1 ). In embodiments including active event recognizer determination module  314 , event dispatcher module  315  delivers the event information to an event recognizer determined by active event recognizer determination module  314 . In some embodiments, event dispatcher module  315  stores in an event queue the event information, which is retrieved by a respective event recognizer  320  (or event receiver  331  in a respective event recognizer  320 ). 
     In some embodiments, application  132 - 1  includes application internal state  317 , which indicates the current application view(s) displayed on touch-sensitive display  156  when the application is active or executing. In some embodiments, device/global internal state  134  is used by event recognizer global methods  311  to determine which application(s) is(are) currently active, and application internal state  317  is used by event recognizer global methods  311  to determine application views  316  to which to deliver event information. 
     In some embodiments, application internal state  317  includes additional information (e.g.,  344 ,  FIG. 3C ), such as one or more of: resume information to be used when application  132 - 1  resumes execution, user interface state information that indicates information being displayed or that is ready for display by application  132 - 1 , a state queue for enabling the user to go back to a prior state or view of application  132 - 1 , and a redo/undo queue of previous actions taken by the user. In some embodiments, application internal state  317  further includes contextual information/text and metadata  318 . 
     In some embodiments, application  132 - 1  includes one or more application views  316 , each of which includes instructions for handling touch events that occur within a respective view of the application&#39;s user interface. At least one application view  316  of the application  132 - 1  includes one or more event recognizers  320  and one or more event handlers  322 . Typically, a respective application view  316  includes a plurality of event recognizers  320  and a plurality of event handlers  322 . In other embodiments, one or more of event recognizers  320  are part of a separate module, such as a user interface kit (not shown) or a higher level object from which application  132 - 1  inherits methods and other properties. In some embodiments, a respective application view  316  also includes one or more of: data updater, object updater, GUI updater, and/or event data received. 
     A respective event recognizer  320 - 1  receives event information from event dispatcher module  315 , and identifies an event from the event information. Event recognizer  320 - 1  includes event receiver  331  and event comparator  332 . 
     The event information includes information about an event (e.g., a touch) or a sub-event (e.g., a touch movement). Depending on the event or sub-event, the event information also includes additional information, such as location of the event or sub-event. When the event or sub-event concerns motion of a touch, the event information may also include speed and direction of the sub-event. In some embodiments, events include rotation of the device from one orientation to another (e.g., from a portrait orientation to a landscape orientation, or vice versa), and the event information includes corresponding information about the current orientation (also called device attitude) of the device. 
     Event comparator  332  compares the event information to one or more predefined gesture definitions (also called herein “event definitions”) and, based on the comparison, determines an event or sub-event, or determines or updates the state of an event or sub-event. In some embodiments, event comparator  332  includes one or more gesture definitions  333  (as described above, also called herein “event definitions”). Gesture definitions  333  contain definitions of gestures (e.g., predefined sequences of events and/or sub-events), for example, gesture  1  ( 334 - 1 ), gesture  2  ( 334 - 2 ), and others. In some embodiments, sub-events in gesture definitions  333  include, for example, touch begin, touch end, touch movement, touch cancellation, and multiple touching. In one example, the definition for gesture  1  ( 334 - 1 ) is a double tap on a displayed object. The double tap, for example, comprises a first touch (touch begin) on the displayed object for a predetermined phase of the gesture, a first lift-off (touch end) for a next predetermined phase of the gesture, a second touch (touch begin) on the displayed object for a subsequent predetermined phase of the gesture, and a second lift-off (touch end) for a final predetermined phase of the gesture. In another example, the definition for gesture  2  ( 334 - 2 ) is a dragging on a displayed object. The dragging, for example, comprises a touch (or contact) on the displayed object, a movement of the touch across touch-sensitive display  156 , and lift-off of the touch (touch end). 
     In some embodiments, event recognizer  320 - 1  also includes information for event delivery  335 . Information for event delivery  335  includes references to corresponding event handlers  322 . Optionally, information for event delivery  335  includes action-target pair(s). In some embodiments, in response to recognizing a gesture (or a part of a gesture), event information (e.g., action message(s)) is sent to one or more targets identified by the action-target pair(s). In other embodiments, in response to recognizing a gesture (or a part of a gesture), the action-target pair(s) are activated. 
     In some embodiments, gesture definitions  333  include a definition of a gesture for a respective user-interface object. In some embodiments, event comparator  332  performs a hit test to determine which user-interface object is associated with a sub-event. For example, in an application view in which three user-interface objects are displayed on touch-sensitive display  156 , when a touch is detected on touch-sensitive display  156 , event comparator  332  performs a hit test to determine which of the three user-interface objects, if any, is associated with the touch (event). If each displayed object is associated with a respective event handler  322 , event comparator  332  uses the result of the hit test to determine which event handler  322  should be activated. For example, event comparator  332  selects an event handler  322  associated with the event and the object triggering the hit test. 
     In some embodiments, the definition for a respective gesture  333  also includes delayed actions that delay delivery of the event information until after it has been determined whether the sequence of events and/or sub-events does or does not correspond to the event recognizer&#39;s event type. 
     When a respective event recognizer  320 - 1  determines that the series of events and/or sub-events do not match any of the events in gesture definitions  333 , the respective event recognizer  320 - 1  enters an event failed state, after which the respective event recognizer  320 - 1  disregards subsequent events and/or sub-events of the touch-based gesture. In this situation, other event recognizers, if any, that remain active for the hit view continue to track and process events and/or sub-events of an ongoing touch-based gesture. 
     In some embodiments, a respective event recognizer  320 - 1  includes event recognizer state  336 . Event recognizer state  336  includes a state of the respective event recognizer  320 - 1 . Examples of event recognizer states are described in more detail below with reference to  FIGS. 4A-4D . 
     In some embodiments, event recognizer state  336  includes recognizer metadata and properties  337 - 1 . In some embodiments, recognizer metadata and properties  337 - 1  include one or more of the following: A) configurable properties, flags, and/or lists that indicate how the event delivery system should perform event and/or sub-event delivery to actively involved event recognizers; B) configurable properties, flags, and/or lists that indicate how event recognizers interact with one another; C) configurable properties, flags, and/or lists that indicate how event recognizers receive event information; D) configurable properties, flags, and/or lists that indicate how event recognizers may recognize a gesture; E) configurable properties, flags, and/or lists that indicate whether events and/or sub-events are delivered to varying levels in the view hierarchy; and F) references to corresponding event handlers  322 . 
     In some embodiments, event recognizer state  336  includes event/touch metadata  337 - 2 . Event/touch metadata  337 - 2  includes event/touch information about a respective event/touch that has been detected and corresponds to gesture definitions  333 . The event/touch information includes one or more of: a location, time stamp, speed, direction, distance, scale (or change in scale), and angle (or change in angle) of the respective event/touch. 
     In some embodiments, a respective application view includes one or more delegates  321 . A respective delegate  321  is assigned to a respective event recognizer  320 . Alternately, a respective event recognizer  320  has a corresponding delegate  321 , but the delegate  321  is not necessarily assigned to the respective recognizer  320  at a runtime, and instead the delegate for an event recognizer may be established prior to execution of the application (e.g., the delegate for an event recognizer may be indicated by the delegate property of an application view, established when the corresponding applicative view  316  is initialized). In some embodiments, some event recognizers do not have an assigned (or corresponding) delegate. Event recognizers lacking corresponding delegates perform in accordance with default rules, such as default rules governing event recognition exclusivity. In some embodiments, some event recognizers have multiple assigned (or corresponding) delegates. Delegates modify the behavior of the corresponding event recognizer, and can also be used to coordinate the behavior of multiple event recognizers. In some embodiments described below, a delegate, when assigned to a respective event recognizer, modifies multiple aspects of the behavior of the respective event recognizer. 
     In some embodiments, a respective event recognizer  320  activates event handler  322  associated with the respective event recognizer  320  when one or more particular events and/or sub-events of a gesture are recognized. In some embodiments, respective event recognizer  320  delivers event information associated with the event to event handler  322 . 
     Event handler  322 , when activated, performs one or more of: creating and/or updating data, creating and updating objects, and preparing display information and sending it for display on display  126  or touch-sensitive display  156 . 
     In some embodiments, a respective application view  316 - 2  includes view metadata  323 . View metadata  323  include data regarding a view. Optionally, view metadata includes the following properties, which influence event and/or sub-event delivery to event recognizers:
         stop property  324 - 1 , which, when set for a view prevents event and/or sub-event delivery to event recognizers associated with the view as well as its ancestors in the view hierarchy;   skip property  324 - 2 , which, when set for a view prevents event and/or sub-event delivery to event recognizers associated with that view, but permits event and/or sub-event delivery to its ancestors in the view hierarchy;   NoHit skip property  324 - 3 , which, when set for a view, prevents delivery of events and/or sub-events to event recognizers associated with the view unless the view is the hit view; as discussed above, the hit view determination module  313  identifies a hit-view as the lowest view in the hierarchy which should handle the sub-event; and   other view metadata  324 - 4 .       

     In some embodiments, a first actively involved view within the view hierarchy may be configured to prevent delivery of a respective sub-event to event recognizers associated with that first actively involved view. This behavior can implement the skip property  324 - 2 . When the skip property is set for an application view, delivery of the respective sub-event is still performed for event recognizers associated with other actively involved views in the view hierarchy. 
     Alternately, a first actively involved view within the view hierarchy may be configured to prevent delivery of a respective sub-event to event recognizers associated with that first actively involved view unless the first actively involved view is the hit view. This behavior can implement the conditional NoHit skip property  324 - 3 . 
     In some embodiments, a second actively involved view within the view hierarchy is configured to prevent delivery of the respective sub-event to event recognizers associated with the second actively involved view and to event recognizers associated with ancestors of the second actively involved view. This behavior can implement the stop property  324 - 1 . 
     It shall be understood that the foregoing discussion regarding event handling of user touches on touch-sensitive displays also applies to other forms of user inputs to operate electronic device  102  or  104  with input-devices, not all of which are initiated on touch screens, e.g., coordinating mouse movement and mouse button presses with or without single or multiple keyboard presses or holds, user movements, taps, drags, scrolls, etc., on touch-pads, pen stylus inputs, movement (e.g., rotation) of the device, oral instructions, detected eye movements, biometric inputs, and/or any combination thereof, which may be utilized as inputs corresponding to events and/or sub-events which define a gesture to be recognized. 
       FIG. 3C  is a block diagram illustrating exemplary classes and instances of gesture recognizers (e.g., event handling components  390 ) in accordance with some embodiments. 
     A software application (e.g., application  132 - 1 ) has one or more event recognizers  340 . In some embodiments, a respective event recognizer (e.g.,  340 - 2 ) is an event recognizer class. The respective event recognizer (e.g.,  340 - 2 ) includes event recognizer specific code  341  (e.g., a set of instructions defining the operation of event recognizers) and state machine  342 . 
     In some embodiments, application state  317  of a software application (e.g., application  132 - 1 ) includes instances of event recognizers. Each instance of an event recognizer is an object having a state (e.g., event recognizer state  336 ). “Execution” of a respective event recognizer instance is implemented by executing corresponding event recognizer specific code (e.g.,  341 ) and updating or maintaining the state  336  of the event recognizer instance  343 . The state  336  of event recognizer instance  343  includes the state  338  of the event recognizer instance&#39;s state machine  342 . 
     In some embodiments, application state  317  includes a plurality of event recognizer instances  343 , each corresponding to an event recognizer that has been bound (also called “attached”) to a view of the application. In some embodiments, application state  317  includes a plurality of instances (e.g.,  343 - 1  to  343 -L) of a respective event recognizer (e.g.,  340 - 2 ). In some embodiments, application state  317  includes instances  343  of a plurality of event recognizers (e.g.,  340 - 1  to  340 -R). 
     In some embodiments, a respective instance  343 - 2  of a gesture recognizer includes event recognizer state  336 . As discussed above, event recognizer state  336  includes recognizer metadata and properties  337 - 1  and event/touch metadata  337 - 2 . Event recognizer state  336  also includes view hierarchy reference(s)  337 - 3 , indicating to which view the respective instance  343 - 2  of the gesture recognizer is attached. 
     In some embodiments, recognizer metadata and properties  337 - 1  include the following, or a subset or superset thereof:
         exclusivity flag  339 , which, when set for an event recognizer, indicates that upon recognition of a gesture by the event recognizer, the event delivery system should stop delivering events and/or sub-events to any other event recognizers of the actively involved views (with the exception of any other event recognizers listed in an exception list  353 ); when receipt of an event or sub-event causes a particular event recognizer to enter the exclusive state, as indicated by its corresponding exclusivity flag  339 , then subsequent events and/or sub-events are delivered only to the event recognizer in the exclusive state (as well as any other event recognizers listed in an exception list  353 );   exclusivity exception list  353 ; when included in the event recognizer state  336  for a respective event recognizer, this list  353  indicates the set of event recognizers, if any, that are to continue receiving events and/or sub-events even after the respective event recognizer has entered the exclusive state; for example, if the event recognizer for a single tap event enters the exclusive state, and the currently involved views include an event recognizer for a double tap event, then the list  353  would list the double tap event recognizer so that a double tap event can be recognized even after a single tap event has been detected. Accordingly, the exclusivity exception list  353  permits event recognizers to recognize different gestures that share common sequences of events and/or sub-events, e.g., a single tap gesture recognition does not preclude subsequent recognition of a double or triple tap gesture by other event recognizers;   wait-for list  351 ; when included in the event recognizer state  336  for a respective event recognizer, this list  351  indicates the set of event recognizers, if any, that must enter the event failed or event canceled state before the respective event recognizer can recognize a respective event; in effect, the listed event recognizers have higher priority for recognizing an event than the event recognizer with the wait-for list  351 ;   delay touch began flag  352 , which, when set for an event recognizer, causes the event recognizer to delay sending events and/or sub-events (including a touch begin or finger down sub-event, and subsequent events) to the event recognizer&#39;s respective hit view until after it has been determined that the sequence of events and/or sub-events does not correspond to this event recognizer&#39;s gesture type; this flag can be used to prevent the hit view from ever seeing any of the events and/or sub-events in the case where the gesture is recognized; when the event recognizer fails to recognize a gesture, the touch began sub-event (and subsequent touch end sub-event) can be delivered to the hit view; in one example, delivering such sub-events to the hit view causes the user interface to briefly highlight an object, without invoking the action associated with that object;   delay touch end flag  363 , which, when set for an event recognizer, causes the event recognizer to delay sending a sub-event (e.g., a touch end sub-event) to the event recognizer&#39;s respective hit view or level until it has been determined that the sequence of sub-events does not correspond to this event recognizer&#39;s event type; this can be used to prevent the hit view from acting upon a touch end sub-event, in case the gesture is recognized late; as long as the touch end sub-event is not sent, a touch canceled can be sent to the hit view or level; if an event is recognized, the corresponding action by an application is preformed, and the touch end sub-event is delivered to the hit view or level; and   touch cancellation flag  364 , which, when set for an event recognizer, causes the event recognizer to send touch or input cancellation to the event recognizer&#39;s respective hit view when it has been determined that the sequence of events and/or sub-events does not correspond to this event recognizer&#39;s gesture type; the touch or input cancellation sent to the hit view indicates that a prior event and/or sub-event (e.g., a touch began sub-event) has been cancelled; the touch or input cancellation may cause the event recognizer&#39;s state to enter the event canceled state  418  (in  FIG. 4B ).       

     In some embodiments, one or more event recognizers may be adapted to delay delivering one or more sub-events of the sequence of sub-events until after the event recognizer recognizes the event. This behavior reflects a delayed event. For example, consider a single tap gesture in a view for which multiple tap gestures are possible. In that case, a tap event becomes a “tap+delay” recognizer. In essence, when an event recognizer implements this behavior, the event recognizer will delay event recognition until it is certain that the sequence of sub-events does in fact correspond to its event definition. This behavior may be appropriate when a recipient view is incapable of appropriately responding to cancelled events. In some embodiments, an event recognizer will delay updating its event recognition status to its respective actively involved view until the event recognizer is certain that the sequence of sub-events does not correspond to its event definition. Delay touch began flag  352 , delay touch end flag  363 , and touch cancellation flag  364  are provided to tailor sub-event delivery techniques, as well as event recognizer and view status information updates to specific needs. 
     In some embodiments, recognizer metadata and properties  337 - 1  include the following, or a subset or superset thereof:
         state machine state/phase  338 , which indicates the state of a state machine (e.g.,  342 ) for the respective event recognizer instance (e.g.,  343 - 2 ); state machine state/phase  338  can have various state values, such as “event possible”, “event recognized”, “event failed”, and others, as described below; alternatively or additionally, state machine state/phase  338  can have various phase values, such as “touch phase began” which can indicate that the touch data structure defines a new touch that has not been referenced by previous touch data structures; a “touch phase moved” value can indicate that the touch being defined has moved from a prior position; a “touch phase stationary” value can indicate that the touch has stayed in the same position; a “touch phase ended” value can indicate that the touch has ended (e.g., the user has lifted his/her finger from the surface of a multi touch display); a “touch phase cancelled” value can indicate that the touch has been cancelled by the device; a cancelled touch can be a touch that is not necessarily ended by a user, but which the device has determined to ignore; for example, the device can determine that the touch is being generated inadvertently (i.e., as a result of placing a portable multi touch enabled device in one&#39;s pocket) and ignore the touch for that reason; each value of state machine state/phase  338  can be an integer number (called herein “gesture recognizer state value”);   action-target pair(s)  345 , where each pair identifies a target to which the respective event recognizer instance send the identified action message in response to recognizing an event or touch as a gesture or a part of a gesture;   delegate  346 , which is a reference to a corresponding delegate when a delegate is assigned to the respective event recognizer instance; when a delegate is not assigned to the respective event recognizer instance, delegate  346  contains a null value; and   enabled property  347 , indicating whether the respective event recognizer instance is enabled; in some embodiments, when the respective event recognizer instance is not enabled (e.g., disabled), the respective event recognizer instance does not process events or touches.       

     In some embodiments, exception list  353  can also be used by non-exclusive event recognizers. In particular, when a non-exclusive event recognizer recognizes an event or sub-event, subsequent events and/or sub-events are not delivered to the exclusive event recognizers associated with the currently active views, except for those exclusive event recognizers listed in exception list  353  of the event recognizer that recognized the event or sub-event. 
     In some embodiments, event recognizers may be configured to utilize the touch cancellation flag  364  in conjunction with the delay touch end flag  363  to prevent unwanted events and/or sub-events from being delivered to the hit view. For example, the definition of a single tap gesture and the first half of a double tap gesture are identical. Once a single tap event recognizer successfully recognizes a single tap, an undesired action could take place. If the delay touch end flag is set, the single tap event recognizer is prevented from sending sub-events to the hit view until a single tap event is recognized. In addition, the wait-for list of the single tap event recognizer may identify the double-tap event recognizer, thereby preventing the single tap event recognizer from recognizing a single tap until the double-tap event recognizer has entered the event impossible state. The use of the wait-for list avoids the execution of actions associated with a single tap when a double tap gesture is performed. Instead, only actions associated with a double tap will be executed, in response to recognition of the double tap event. 
     Turning in particular to forms of user touches on touch-sensitive surfaces, as noted above, touches and user gestures may include an act that need not be instantaneous, e.g., a touch can include an act of moving or holding a finger against a display for a period of time. A touch data structure, however, defines the state of a touch (or, more generally, the state of any input source) at a particular time. Therefore, the values stored in a touch data structure may change over the course of a single touch, enabling the state of the single touch at different points in time to be conveyed to an application. 
     Each touch data structure can comprise various entries. In some embodiments, touch data structures may include data corresponding to at least the touch-specific entries in event/touch metadata  337 - 2  such as the following, or a subset or superset thereof:
         “first touch for view” entry  348 , indicating whether the touch data structure defines the first touch for the particular view (since the view was instantiated);   “per touch info” entry  349 , including “time stamp” information, which indicates the particular time to which the touch data structure relates (e.g., the time of touch); optionally, “per touch info” entry  349  includes other information, such as a location of a corresponding touch; and   optional “tap count” entry  350 , indicating how many taps have been sequentially performed at the position of the initial touch; a tap can be defined as a quick pressing and lifting of a finger against a touch-sensitive panel at a particular position; multiple sequential taps can occur if the finger is again pressed and released in quick succession at the same position of the panel; an event delivery system  136  can count taps and relay this information to an application through “tap count” entry  350 ; multiple taps at the same location are sometimes considered to be a useful and easy to remember command for touch enabled interfaces; thus, by counting taps, event delivery system  136  can again alleviate some data processing from the application.       

     Thus, each touch data structure can define what is happening with a respective touch (or other input source) at a particular time (e.g., whether the touch is stationary, being moved, etc.) as well as other information associated with the touch (such as position). Accordingly, each touch data structure can define the state of a particular touch at a particular moment in time. One or more touch data structures referencing the same time can be added in a touch event data structure that can define the states of all touches a particular view is receiving at a moment in time (as noted above, some touch data structures may also reference touches that have ended and are no longer being received). Multiple touch event data structures can be sent to the software implementing a view as time passes, in order to provide the software with continuous information describing the touches that are happening in the view. 
     The ability to handle complex touch-based gestures, optionally including multi-touch gestures, can add complexity to the various software applications. In some cases, such additional complexity can be necessary to implement advanced and desirable interface features. For example, a game may require the ability to handle multiple simultaneous touches that occur in different views, as games often require the pressing of multiple buttons at the same time, or combining accelerometer data with touches on a touch-sensitive surface. However, some simpler applications and/or views need not require advanced interface features. For example, a simple soft button (i.e., a button that is displayed on a touch-sensitive display) may operate satisfactorily with single touches, rather than multi-touch functionality. In these cases, the underlying OS may send unnecessary or excessive touch data (e.g., multi-touch data) to a software component associated with a view that is intended to be operable by single touches only (e.g., a single touch or tap on a soft button). Because the software component may need to process this data, it may need to feature all the complexity of a software application that handles multiple touches, even though it is associated with a view for which only single touches are relevant. This can increase the cost of development of software for the device, because software components that have been traditionally easy to program in a mouse interface environment (i.e., various buttons, etc.) may be much more complex in a multi-touch environment. 
     In order to reduce the complexity in recognizing complex touch-based gestures, delegates can be used to control the behavior of event recognizers in accordance with some embodiments. As described below, delegates can determine, for example, whether a corresponding event recognizer (or gesture recognizer) can receive the event (e.g., touch) information; whether the corresponding event recognizer (or gesture recognizer) can transition from an initial state (e.g., event possible state) of state machine to another state; and/or whether the corresponding event recognizer (or gesture recognizer) can simultaneously recognize the event (e.g., touch) as a corresponding gesture without blocking other event recognizer(s) (or gesture recognizer(s)) from recognizing the event or getting blocked by other event recognizer(s) (or gesture recognizer(s)) recognizing the event. 
     It shall be understood, however, that the foregoing discussion regarding the complexity of evaluating and processing user touches on touch-sensitive surfaces also applies to all forms of user inputs to operate electronic device  102  or  104 , not all of which are initiated on touch screens, e.g., coordinating mouse movement and mouse button presses with or without single or multiple keyboard presses or holds, device rotations or other movements, user movements such as taps, drags, scrolls, etc., on touch-pads, pen stylus inputs, oral instructions, detected eye movements, biometric inputs, detected physiological change in a user, and/or any combination thereof, which may be utilized as inputs corresponding to events and/or sub-events which define an event to be recognized. 
       FIGS. 4A-4D  are flow charts for exemplary state machines, according to some embodiments. Gesture recognizers may include a discrete gesture recognizer and a continuous gesture recognizer. A discrete gesture recognizer is typically useful in recognizing a brief gesture occurring within a predefined time period (e.g., tap or swipe gesture), but more fundamentally is for recognizing a gesture for which only one action message or one set of action messages needs to be delivered to the application upon recognition of the gesture. A continuous gesture recognizer is useful in recognizing a gesture that includes a movement of a touch (and therefore requires tracking of the touch location) (e.g., pan, pinch, or rotate gesture), and more fundamentally is for recognizing a gesture for which a sequence of action messages need to be delivered to the application over the course of the gesture. In some embodiments, discrete event recognizer state machine  400  and continuous event recognizer state machine  402  have different states. 
       FIG. 4A  depicts discrete event recognizer state machine  400  containing three states in accordance with some embodiments. By managing state transitions in event recognizer state machine  342  based on received events and/or sub-events, an event recognizer effectively expresses an event definition. For example, a tap gesture may be effectively defined by a sequence of two, or optionally, three sub-events. First, a touch should be detected, and this will be sub-event  1 . For example, the touch sub-event may be a user&#39;s finger touching a touch-sensitive surface in a view that includes the event recognizer having event recognizer state machine  342 . Second, an optional measured delay where the touch does not substantially move in any given direction (e.g., any movement of the touch position is less than a predefined threshold, which may be measured as a distance (e.g., 5 mm) or as a number of pixels (e.g.,  5  pixels) on the display), and the delay is sufficiently short, would serve as sub-event  2 . Finally, termination of the touch (e.g., liftoff of the user&#39;s finger from the touch-sensitive surface) will serve as sub-event  3 . By coding the event recognizer state machine  342  to transition between states based upon receiving these sub-events, the event recognizer state machine  342  effectively expresses a tap gesture event definition. Discrete event recognizer state machine  400  is an exemplary implementation of event recognizer state machine  342  configured to recognize a tap gesture, described above. 
     Regardless of event type, event recognizer state machine  342  (including event recognizer state machine implemented as discrete event recognizer state machine  400 ) begins in event possible state  410 , which indicates an initial state of the event recognizer state machine. Event recognizer state machine  342  may progress to any of the remaining states depending on what event and/or sub-event is received. 
     Starting from event possible state  410 , if an event or sub-event is received that is not the first event or sub-event in a gesture definition, discrete event recognizer state machine  400  will transition to event failed state  430 . 
     Starting from event possible state  410 , if an event or sub-event is received that, by itself comprises the gesture definition for a gesture, discrete event recognizer state machine  400  will transition to event recognized state  420 . However, even if the received event or sub-event comprises the gesture definition for the gesture, discrete event recognized state machine  400  may nevertheless transition to event failed state  430  in accordance with metadata (e.g., a property) of the corresponding event recognizer, one or more values determined by a corresponding delegate, and/or the application state. 
     In some embodiments, after transitioning to event recognized state  420 , the corresponding event recognizer checks ( 441 ) a delay flag (e.g., delay touch end flag  363 ). If the delay flag is raised ( 441 —yes), the corresponding event recognizer delays ( 442 ) delivering event information until the delay flag is lowered. 
     In some embodiments, the corresponding event recognizer includes wait-for list  351 , and the corresponding event recognizer waits for the event recognizers listed in wait-for list  351  to reach a certain state. For example, when a view includes a single tap gesture recognizer and a double tap gesture recognizer, a single tap gesture recognizer can be configured to wait for a double tap gesture recognizer to fail. In effect, transition of the single tap gesture recognizer to event recognized state  420  requires (or is conditioned upon) the failure of the double tap gesture recognizer to recognize the event. As a result, when there is a tap event, the single tap gesture recognizer recognizes the tap event as long as the tap event is not part of a multi-tap gesture. 
     After the delay and wait ( 442 ), if any, the corresponding gesture recognizer delivers events to the application ( 443 ). In some embodiments, events are delivered in the form of action messages. In some embodiments, action messages are delivered in accordance with action-target pair(s)  345 . In some embodiments, the corresponding gesture recognizer activates action-target pair(s)  345 . 
       FIG. 4B  depicts continuous event recognizer state machine  402  containing six states in accordance with some embodiments. 
     As discussed above, continuous event recognizer state machines  402  starts from event possible state  410 . 
     Starting from event possible state  410 , if an event or sub-event is received that is not part of a begin sequence of event(s) and/or sub-event(s) in a gesture definition, discrete event recognizer state machine  400  will transition to event failed state  430 . 
     Starting from event possible state  410 , if an event or sub-event is received that is part of a begin sequence of event(s) and/or sub-event(s) in a given gesture definition, continuous event recognizer state machine  402  will transition to event began state  412 . Similar to discrete gesture recognizer  400 , even if the received event or sub-event comprises part of a begin sequence of event(s) and/or sub-event(s) in the gesture definition, continuous event recognized state machine  402  may transition to event failed state  430  in accordance with metadata (e.g., a property) of the corresponding event recognizer, one or more values determined by a corresponding delegate, and/or the application state. 
     From event began state  412 , if the next event or sub-event received is an intermediate event or sub-event, but not the final event or sub-event in the given gesture definition, continuous event recognizer state machine  402  will transition to and remain in event changed state  414 . Continuous event recognizer state machine  402  can remain in event changed state  414  for as long as the sequence of received events and/or sub-events continues to be part of the gesture definition. If, at any time continuous event recognizer state machine  402  is in event changed state  414 , and continuous event recognizer state machine  402  receives an event or sub-event that is not part of the gesture definition, it will transition to event failed state  430 , thereby determining that the current event (if any) is not the type of event that corresponds to this event recognizer (i.e., the event recognizer corresponding to continuous event recognizer state machine  402 ). If, on the other hand, continuous event recognizer state machine  402  is in event began state  412  or event changed state  414 , and continuous event recognizer state machine  402  receives the last event or sub-event in a gesture definition, it will transition to event ended state  416 , thereby completing a successful event recognition. 
     In some embodiments, each gesture recognizer state has a gesture recognizer state value. In some embodiments, event recognized state  420  (for discrete event recognizer state machine  400 ) and event ended state  416  (for continuous event recognizer state machine  402 ) have an identical gesture recognizer state value, such that a software component configured to response a recognition of a gesture by one type of gesture recognizer can also respond to the other type of gesture recognizer. 
     While in event began state  412  or event changed state  414 , when a predefined interruption event (e.g., predefined in operating system  118  or control application  124 , such as an incoming phone call) occurs, continuous event recognizer state machine  402  transitions to event canceled state  418 . 
     Regardless of the gesture recognizer type, each gesture recognizer (e.g.,  343 ) can be reset such that a corresponding event recognizer state machine returns (e.g.,  342 ) to event possible state  410 . 
       FIGS. 4C and 4D  depict the role of delegates in state transitions in accordance with some embodiments. In  FIGS. 4C and 4D , the actions (or decisions made) by one or more delegates is indicated by boxes with shadows (e.g.,  450 - 456 ). 
       FIG. 4C  depicts the role of delegates in state transitions for discrete event recognizer state machine  400  in accordance with some embodiments. In the examples discussed below, state machine  400  corresponds to a particular discrete event recognizer that has a corresponding delegate. 
     Starting from event possible state  410 , if an event or sub-event is detected, the delegate corresponding to an event recognizer decides whether the event recognizer should receive ( 450 ) the event or sub-event. If the delegate returns a value that prevents the corresponding event recognizer from receiving the event or sub-event, the corresponding event recognizer does not receive the event or sub-event (or disregards the event or sub-event). As a result, the corresponding event recognizer remains in event possible state  410 . If there is no delegate preventing the corresponding event recognizer from receiving the event or sub-event, the default behavior for the corresponding event recognizer is to receive the event or sub-event. 
     It is noted that the “should receive” operation  450  by the delegates of a set of event recognizers can be used to determine which event recognizers receive which touches on a touch-sensitive display or surface. For example, in a view that allows a user to use two touches to individually and simultaneously reposition two objects, or to select two different objects, the delegates of two event recognizers can be configured to allow one event recognizer to receive only a first one of the two touches and to allow a second event recognizer to receive only a second one of the two touches. All information about each of the two touches is therefore directed to only the event recognizer allowed, by its corresponding delegate, to receive that touch. Much more complex multi-touch inputs can also be recognized and processed through the use of multiple event recognizers and corresponding delegates that determine which touches are processed by which event recognizers. 
     If the event recognizer is allowed to receive the event or sub-event, the delegate corresponding to the event recognizer (or the control application  124  or operating system  118 ) decides whether the recognition of the event or sub-event by the event recognizer is blocked ( 451 ) by another event recognizer having already recognized the event. This initial level of blocking is based on a default exclusivity rule, and can be overridden by the delegate. If the recognition of the event or sub-event is blocked, the corresponding delegate (or operating system  118  or control application  124 ) also decides whether simultaneous recognition of the event by the event recognizer is allowed ( 452 ) in accordance with one or more values determined by the delegate. For example, if the event recognizer is on the exclusivity exception list  353  of the event recognizer that initially recognized the event, the delegate allows simultaneous recognition by both event recognizers. In another example, if the exclusivity flag  339  of the event recognizer is not set, the delegate allows simultaneous recognition by both event recognizers. If the simultaneous recognition is not allowed, the event recognizer transitions to event failed state  430 . 
     If the corresponding event recognizer is not blocked ( 451 —No) from recognizing the event or sub-event, or if simultaneous recognition is allowed ( 452 —Yes), the corresponding event recognizer determines whether the event or sub-event matches ( 453 ) a corresponding gesture definition. If the event or sub-event does not match ( 453 —No) the corresponding gesture definition, the corresponding gesture recognizer transitions to event failed state  430 . 
     If the event or sub-event matches ( 453 —Yes) the corresponding gesture definition, the corresponding delegate (or operating system  118  or control application  124 ) decides whether it can transition (“should begin”  454 ) out of event possible state  410  in accordance with one or more values determined by the delegate. If the event recognizer is not allowed ( 454 —No) by the delegate to transition out of event possible state  410 , the corresponding event recognizer is put into event failed state  430 . If the event recognizer is allowed ( 454 —Yes) to transition out of event possible state  410 , the corresponding event recognizer transitions into event recognized state  420 . 
     When the corresponding event recognizer transitions into event recognized state  420 , the corresponding event recognizer (or operating system  118  or control application  124 ) also decides whether to allow the recognition of the event or sub-event by the other event recognizers ( 455 ). In some embodiments, the default is to prevent all other event recognizers from recognizing the same event, unless the delegate (or the application) of at least one of the event recognizers sets a property to allow simultaneous recognition. If the delegate corresponding to the event recognizer which has recognized the event or sub-event determined that the delegate will allow ( 455 —Yes) other event recognizers to recognize the event or sub-event, the delegate (or operating system  118  or control application  124 ) sets ( 456 ) a property of the other event recognizers such that they can recognize the event or sub-event simultaneously. If the delegate does not allow other event recognizers to recognize the event or sub-event, the other event recognizers are prevented from recognizing the event or sub-event. 
     In some embodiments, prior to preventing a respective event recognizer from recognizing an event or sub-event, the delegate of that event recognizer is also invoked (see  452 ) to see if it will allow simultaneous recognition of the event or sub-event. In these embodiments, simultaneous recognition can be enabled by either the delegate of the first event recognizer to recognize the event, or the delegate of a second event recognizer. As shown by  452  and  455  in  FIG. 4C , in these embodiments decisions about whether to allow simultaneous recognition are made only when an event matches the event definition of at least one event recognizer. 
     The above described delegate operations, when implemented in the delegates for a set of event recognizers used by an application view (or set of simultaneously displayed views), can be used to customize the interaction of the event recognizers. The delegates can implement exceptions to a default exclusivity rule, which otherwise allows only one event recognizer to recognize a gesture based on the same received event(s). The user of delegates to implement exceptions to the default exclusivity rule, and thereby allow simultaneous event recognition by compatible event recognizers, facilitates the implementation of many useful functions in software applications. The use of delegates to modify and control the behavior of event recognizers allows for a compact representation and implementation of complex relationships, such as mutually exclusive sets of mutually compatible gestures. 
       FIG. 4D  depicts the role of delegates in state transition for continuous event recognizer state machine  402  in accordance with some embodiments. In the examples discussed below, state machine  402  corresponds to a particular continuous event recognizer that has a corresponding delegate. All the delegate operations shown in  FIG. 4C  and discussed above with reference to  FIG. 4C  are equally applicable to a continuous event recognizer that has a corresponding delegate, and therefore the delegate operations shown in  FIG. 4D  have the same reference numbers as those in  FIG. 4C . The only difference is that the name of one state in the state machine has changed, from “event recognized”  420  in state machine  400  to “event began”  412  in state machine  402 . 
     From event began state  412 , the corresponding event recognizer transitions into other states as described above. For brevity, the transition from event changed state  414  to event failed state  416  is not depicted. 
     The following table presents in a tabular format the processing of an exemplary sub-event sequence (e.g., a single tap) as related to the states of event recognizers described above. In this example, the sub-event sequence comprises a single tap, and the view has two tap gesture recognizers: a single tap gesture recognizer and a double tap gesture recognizer. Also in this example, both gesture recognizers are configured to simultaneously receive and recognize the sub-event sequence. Simultaneous recognition can be allowed by a delegate assigned to the single tap gesture recognizer or a delegate assigned to the second tap gesture recognizer. 
     
       
         
           
               
               
               
               
             
               
                   
               
               
                   
                 Sub-Event 
                 Single Tap 
                 Double Tap 
               
               
                 Sequence 
                 Sequence 
                 Gesture 
                 Gesture 
               
               
                 # 
                 (single tap) 
                 Recognizer 
                 Recognizer 
               
               
                   
               
             
            
               
                 0 
                 before delivery starts 
                 Event Possible 
                 Event Possible 
               
               
                 1 
                 detect finger down 
                 Event Possible 
                 Event Possible 
               
               
                 2 
                 measure delay 
                 Event Possible 
                 Event Possible 
               
               
                 3 
                 detect finger liftoff 
                 Event Recognized 
                 Event Possible 
               
               
                 4 
                 measure delay 
                 Event Recognized 
                 Event Failed 
               
               
                   
               
            
           
         
       
     
     Before delivery of sub-event information starts (sequence #0), both gesture recognizers are in event possible state  410 . Even after detecting a finger down sub-event (sequence #1) and measuring a delay (sequence #2), both gesture recognizers remain in event possible state  410 . In response to detecting a finger liftoff (sequence #3), the single tap gesture recognizer transitions into event recognized state  420 . After detecting additional delay, the single tap gesture recognizer remains in event recognized state  420  until it is reset, in which case the single tap gesture recognizer returns to event possible state  410 . On the other hand, the double tap gesture recognizer transitions into event failed state  430  when the measured additional delay exceeds a predefined duration (e.g., during which the double tap gesture recognizer anticipates a second finger down sub-event). 
     The following table presents in a tabular format the processing of the exemplary sub-event sequence when the behavior of one gesture recognizer is modified. In this example, the sub-event sequence comprises a single tap, and the view has two tap gesture recognizers: a single tap gesture recognizer and a double tap gesture recognizer. Also in this example, the single tap gesture recognizer is not allowed by its delegate to receive the sub-events. 
     
       
         
           
               
               
               
               
             
               
                   
               
               
                   
                 Sub-Event 
                 Single Tap 
                 Double Tap 
               
               
                 Sequence 
                 Sequence 
                 Gesture 
                 Gesture 
               
               
                 # 
                 (single tap) 
                 Recognizer 
                 Recognizer 
               
               
                   
               
             
            
               
                 0 
                 before delivery starts 
                 Event Possible 
                 Event Possible 
               
               
                 1 
                 detect finger down 
                 Event Possible 
                 Event Possible 
               
               
                 2 
                 measure delay 
                 Event Possible 
                 Event Possible 
               
               
                 3 
                 detect finger liftoff 
                 Event Possible 
                 Event Possible 
               
               
                 4 
                 measure delay 
                 Event Possible 
                 Event Failed 
               
               
                   
               
            
           
         
       
     
     Because the single tap gesture recognizer is not allowed by its delegate to receive the sub-events, the single tap gesture recognizer remains in event possible state  410 . The double tap gesture recognizer transitions into event failed state  430  when the measured second delay exceeds the predefined threshold (sequence #4). 
     The following table presents in a tabular format the processing of the exemplary sub-event sequence when the behavior of one gesture recognizer is modified. In this example, the sub-event sequence comprises a single tap, and the view has two tap gesture recognizers: a single tap gesture recognizer and a double tap gesture recognizer. Also in this example, both gesture recognizers are not allowed to simultaneously recognize the sub-event sequence. 
     
       
         
           
               
               
               
               
             
               
                   
               
               
                   
                 Sub-Event 
                 Single Tap 
                 Double Tap 
               
               
                 Sequence 
                 Sequence 
                 Gesture 
                 Gesture 
               
               
                 # 
                 (single tap) 
                 Recognizer 
                 Recognizer 
               
               
                   
               
             
            
               
                 0 
                 before delivery starts 
                 Event Possible 
                 Event Possible 
               
               
                 1 
                 detect finger down 
                 Event Possible 
                 Event Possible 
               
               
                 2 
                 measure delay 
                 Event Possible 
                 Event Possible 
               
               
                 3 
                 detect finger liftoff 
                 Event Recognized 
                 Event Failed 
               
               
                 4 
                 measure delay 
                 Event Recognized 
                 Event Failed 
               
               
                   
               
            
           
         
       
     
     Similar to what was described above, after detecting finger liftoff (sequence #3), single tap gesture recognizer transitions from event possible state  410  to event recognized state  420 . In general, a first gesture recognizer that recognizes the sub-event sequence blocks other gesture recognizers that have not yet recognized the sub-event sequence from recognizing the sub-event sequence. Unless a simultaneous recognition is allowed, blocked gesture recognizers transition into event failed state  430 . In this case, because simultaneous recognition is not allowed, when the single tap gesture recognizer recognizes the sub-event sequence (at sequence #3), the double tap gesture recognizer transitions into, and remains in, event failed state  430  until it is reset. 
     The following table presents in a tabular format the processing of the exemplary sub-event sequence when the behavior of one gesture recognizer is modified by its delegate, and operation of the two gesture recognizers is coordinated in accordance with actions taken by the delegate(s) of one or both recognizers. In this example, the sub-event sequence comprises a single tap, and the view has two tap gesture recognizers: a single tap gesture recognizer and a double tap gesture recognizer. Also in this example, the single tap gesture recognizer is not allowed to begin (or transition out of event possible state  410 ). 
     
       
         
           
               
               
               
               
             
               
                   
               
               
                   
                 Sub-Event 
                 Single Tap 
                 Double Tap 
               
               
                 Sequence 
                 Sequence 
                 Gesture 
                 Gesture 
               
               
                 # 
                 (single tap) 
                 Recognizer 
                 Recognizer 
               
               
                   
               
             
            
               
                 0 
                 before delivery starts 
                 Event Possible 
                 Event Possible 
               
               
                 1 
                 detect finger down 
                 Event Possible 
                 Event Possible 
               
               
                 2 
                 measure delay 
                 Event Possible 
                 Event Possible 
               
               
                 3 
                 detect finger liftoff 
                 Event Failed 
                 Event Possible 
               
               
                 4 
                 measure delay 
                 Event Failed 
                 Event Failed 
               
               
                   
               
            
           
         
       
     
     After detecting finger liftoff (sequence #3), single tap gesture recognizer attempts to transition from event possible state  410  to event recognized state  420 . However, the delegate assigned to the single tap gesture recognizer does not allow the state transition into the event recognized state  420 , and as a result, the single tap gesture recognizer transitions into event failed state  430 . The double tap gesture recognizer transitions into event failed state  430  when the measured delay exceeds the predefined threshold (sequence #4). 
     The following table presents in a tabular format the processing of the exemplary sub-event sequence when the behavior of one gesture recognizer is modified, and operation of two gesture recognizers is coordinated in accordance with actions taken by the delegate(s) of one or both recognizers. In this example, the sub-event sequence comprises a single tap, and the view has two tap gesture recognizers: a single tap gesture recognizer and a double tap gesture recognizer. Also in this example, the single tap gesture recognizer waits for (or requires) a failure of the double tan gesture recognizer. 
     
       
         
           
               
               
               
               
             
               
                   
               
               
                   
                 Sub-Event 
                 Single Tap 
                 Double Tap 
               
               
                 Sequence 
                 Sequence 
                 Gesture 
                 Gesture 
               
               
                 # 
                 (single tap) 
                 Recognizer 
                 Recognizer 
               
               
                   
               
             
            
               
                 0 
                 before delivery starts 
                 Event Possible 
                 Event Possible 
               
               
                 1 
                 detect finger down 
                 Event Possible 
                 Event Possible 
               
               
                 2 
                 measure delay 
                 Event Possible 
                 Event Possible 
               
               
                 3 
                 detect finger liftoff 
                 Event Possible 
                 Event Possible 
               
               
                 4 
                 measure delay 
                 Event Recognized 
                 Event Failed 
               
               
                   
               
            
           
         
       
     
     After detecting finger liftoff (sequence #3), single tap gesture recognizer attempts to transition from event possible state  410  to event recognized state  420 . However, due to the “wait-for” requirement or the failure requirement (that the double tap gesture recognizer fail), the single tap gesture recognizer delays transitioning into event recognized state  420 . When the double tap gesture recognizer fails because the measured second delay exceeds the predefined threshold (sequence #4), the single tap gesture recognizer transitions into event recognized state  420 . The “wait-for” requirement and/or the failure requirement may be implemented using delegates or in gesture recognizers. 
     The following table presents in a tabular format the processing of the exemplary sub-event sequence. In this example, the sub-event sequence comprises a pan gesture involving multiple intermediary sub-events, and the view has two gesture recognizers: a single tap gesture recognizer and a pan gesture recognizer. Also in this example, both gesture recognizers are allowed to simultaneously recognize the sub-event sequence. 
     
       
         
           
               
               
               
               
             
               
                   
               
               
                   
                 Sub-Event 
                 Single Tap 
                   
               
               
                 Sequence 
                 Sequence 
                 Gesture 
                 Pan Gesture 
               
               
                 # 
                 (pan gesture) 
                 Recognizer 
                 Recognizer 
               
               
                   
               
             
            
               
                 0 
                 before delivery starts 
                 Event Possible 
                 Event Possible 
               
               
                 1 
                 detect finger down 
                 Event Possible 
                 Event Began 
               
               
                 2 
                 measure delay 
                 Event Possible 
                 Event Began 
               
               
                 3 
                 detect finger movement 
                 Event Failed 
                 Event Changed 
               
               
                 4 
                 detect finger movement 
                 Event Failed 
                 Event Changed 
               
               
                 5 
                 detect finger movement 
                 Event Failed 
                 Event Changed 
               
               
                 6 
                 detect finger liftoff 
                 Event Failed 
                 Event Ended 
               
               
                   
               
            
           
         
       
     
     Before delivery of sub-event information starts (sequence #0), both gesture recognizers are in event possible state  410 . Even after detecting a finger down sub-event (sequence #1) and measuring a delay (sequence #2), the single tap gesture recognizer remains in event possible state  410 , while the pan gesture recognizer transitions into event began state  412 . In response to detecting a finger movement (sequence #3), the single tap gesture recognizer transitions into event failed state  430  as the sub-event does not match with the gesture definition for a single tap. The single tap gesture recognizer remains in event failed state  430  thereafter until it is reset. However, the pan gesture recognizer transitions into event changed state  414  in response to detecting the finger movement (sequence #4), and in some embodiments, sends action message(s) including the new location of the finger contact. After detecting additional finger movements (sequence #4 and 5), the pan gesture recognizer remains in event changed state  414 , while sending action message(s) every time a finger movement is detected. When a finger liftoff is detected (sequence #6), the pan gesture recognizer transitions into event ended state  416 . 
     Turning to the flow of event information and the interaction between event recognizers,  FIG. 5A  is a block diagram illustrating the flow of event information, according to some embodiments. Event dispatcher module  315  (e.g., in operating system  118  or control application  124 ) receives event information, and sends the event information to application (e.g.,  132 - 1 ). In some embodiments, application  132 - 1  includes a plurality of views (e.g.,  508 ,  510 , and  512  corresponding to views  316 ) in view hierarchy  506  and a plurality of gesture recognizers ( 516 - 1  through  516 - 6 ) in the plurality of views. Application  132 - 1  also includes one or more event handlers  520 , which correspond to the target values in target-action pairs (e.g.,  522 - 1 ,  522 - 2 , and  522 - 3 ). Event dispatcher module  315  receives hit view information from hit view determination module  313  and sends event information to the hit view (e.g.,  512 ) or event recognizer(s) attached to the hit view (e.g.,  512 ). In some embodiments, only a subset of gesture recognizers attached to the hit view are allowed to (or configured to) receive the event information (or touch information). Those gesture recognizers allowed to receive the event information are called herein “receiving gesture recognizers”. In  FIG. 5A , gesture recognizers  516 - 1  and  516 - 2  are in a set of receiving gesture recognizers  514 . As a result, event dispatcher module  315  sends event information to both gesture recognizers  516 - 1  and  516 - 2  in the set of receiving gesture recognizers. 
     In some embodiments, gesture recognizers may block or prevent one another from recognizing the event or sub-event as a corresponding gesture. In this example, gesture recognizer  1  ( 516 - 1 ) prevents gesture recognizer  2  ( 516 - 2 ) from recognizing the event or sub-event as a corresponding gesture. As a result, in this example, only gesture recognizer  1  ( 516 - 1 ) sends an action message ( 518 ) to a corresponding target-action pair (e.g., target:action  1  ( 522 - 1 )). 
       FIGS. 5B and 5C  are flow charts illustrating gesture recognition methods, according to some embodiments.  FIG. 5B  illustrates a flow chart where a gesture recognizer invokes a corresponding delegate, and  FIG. 5C  illustrates a flow chart where a software application invokes a delegate corresponding to a respective gesture recognizer. In  FIGS. 5B and 5C , each column represents processes performed at each entity or component (e.g., software application, gesture recognizer, or delegate). 
     In  FIG. 5B , a software application (e.g., application  132 - 1 ) displays ( 530 ) one or more views of the plurality of views (e.g.,  506 ,  508 ,  510 ). The plurality of views includes a plurality of gesture recognizers (e.g.,  516 - 1  through  516 - 6 ). The software application (e.g., application  132 - 1 ) assigns ( 532 ) distinct delegates to at least a subset of the plurality of gesture recognizers. In some embodiments, a respective gesture recognizer is assigned ( 533 - 1 ) to a corresponding delegate. In some embodiments, a respective delegate is assigned ( 533 - 2 ) to a corresponding gesture recognizer. Alternately, the correspondence between a delegate and a gesture recognizer may be established prior to runtime. Throughout the following discussion, each reference to an assigned delegate may also mean a corresponding delegate, and each reference to a gesture recognizer to which a delegate has been assigned may also mean a gesture recognizer corresponding to a particular delegate. 
     The software application (e.g., application  132 - 1 ) detects ( 534 ) one or more events, and processes ( 536 ) each of the events using one or more of the gesture recognizers (e.g.,  320 ). 
     The respective event is processed ( 538 ) at a respective gesture recognizer (of the one or more gesture recognizers (e.g.,  320 )). In order to explain operation of the delegates, we assume that a respective gesture recognizer that processes the event has a corresponding delegate. The respective gesture recognizer calls the assigned delegate, and the assigned delegate is executed ( 540 ) to determine one or more values in accordance with the application state. In response, the respective gesture recognizer conditionally sends ( 542 ) information corresponding to the respective event to the software application, in accordance with the one or more values determined by the assigned delegate. 
     The software application is executed ( 544 ) in accordance with information received from one or more of the gesture recognizers corresponding to one or more of the events. 
     In other words, in these embodiments, a respective gesture recognizer invokes an assigned delegate to obtain one or more values that determine the behavior of the gesture recognizer. As described above, the behavior of the gesture recognizer modified by its corresponding delegate includes whether to receive touch/event information, whether to transition out of the event possible state, and/or whether to allow simultaneous recognition. Operations by the delegate (sometimes with the coordinated action of the delegates of other gesture recognizers) also coordinate the operation of two or more gesture recognizers by controlling which gesture recognizers receive which touches, by determining which gesture recognizer is allowed to transition to the “event recognized” or “event began” state, and by allowing or disabling simultaneous recognition. 
     In  FIG. 5C , a software application (e.g., application  132 - 1 ) displays ( 530 ) one or more views of the plurality of views (e.g.,  506 ,  508 ,  510 ). The plurality of views includes a plurality of gesture recognizers (e.g.,  516 - 1  through  516 - 6 ). The software application (e.g., application  132 - 1 ) assigns ( 532 ) distinct delegates to at least a subset of the plurality of gesture recognizers. In some embodiments, a respective gesture recognizer is assigned ( 533 - 1 ) to a corresponding delegate. In some embodiments, a respective delegate is assigned ( 533 - 2 ) to a corresponding gesture recognizer. Alternately, the correspondence between a delegate and a gesture recognizer may be established prior to runtime. 
     The software application (e.g., application  132 - 1 ) detects ( 535 ) one or more touches, and processes ( 546 ) each of the one or more touches, using one or more of the gesture recognizers. In processing each of the one or more touches, the software application identifies ( 548 ) a set of candidate gesture recognizers of the plurality of gesture recognizers. In some embodiments, the candidate gesture recognizers are gesture recognizers attached to the hit view (e.g., gesture recognizers  516 - 1 ,  516 - 2 , and  516 - 3  in  FIG. 5A ). 
     The delegate assigned to a respective candidate gesture recognizer is executed ( 550 ) to obtain a “receive touch value” in accordance with the application state. The “receive touch value” is used to determine whether the respective candidate gesture recognizer can receive the event/touch information (e.g., “should receive” step  450  in  FIGS. 4C-4D ). 
     Based on the receive touch value obtained from a respective delegate, a set of receiving gesture recognizers is identified ( 552 ). The set of receiving gesture recognizers comprise ( 552 ) a subset of the candidate gesture recognizers. In some embodiments, the set of receiving gesture recognizers include all candidate gesture recognizers that do not have respective assigned delegates. If more than one of the candidate gesture recognizers has a corresponding delegate, the delegate of each such candidate gesture recognizer is executed to determine whether the candidate gesture recognizer can receive the event/touch information. The “receive touch values” obtained from the delegates corresponding to the candidate gesture recognizers are used to identify the set of receiving gesture recognizers. 
     The respective touch is processed ( 554 ) at the set of receiving gesture recognizers. If processing of the respective touch by a respective gesture recognizer results in the recognition of an event or gesture (see match definition  453 ,  FIGS. 4C and 4D ), the delegate (if any) corresponding to the respective gesture recognizer is called to determine if recognition of the event or gesture is allowed. This corresponds to the “should begin” operation  454 , discussed above with reference to  FIGS. 4C and 4D . The delegate returns one or more values indicating whether the state transition is to be allowed. The respective gesture recognizer conditionally sends ( 542 ) information corresponding to the respective event to the software application, in accordance with the one or more values determined by the assigned delegate. The software application is executed ( 545 ) in accordance with information received from one or more of the gesture recognizers corresponding to the respective touch. 
     In other words, in these embodiments, a software application (or the operating system  118  or control application  124 ) invokes the delegates corresponding to respective candidate gesture recognizers to obtain values that indicate which of the respective candidate gesture recognizers (if any) should process the respective touch. In addition, other aspects of the behavior of the gesture recognizers can be further modified by the assigned delegate. 
       FIGS. 6A-6B  are flow charts illustrating an exemplary method of processing a respective event in accordance with information obtained from a delegate, according to some embodiments. 
     Method  600  is performed ( 602 ) at an electronic device (e.g., device  102  or  104 ) having one or more event sensors (e.g.,  130 ) and configured to execute a software application (e.g.,  132 ) that includes a plurality of views (e.g., application views  316 ) and an application state of the software application (e.g.,  317 ). 
     The device ( 604 ) displays one or more views of the plurality of views. A respective view of the one or more displayed views includes one or more gesture recognizers (e.g., event recognizer  320 - 1 ). In some embodiments, at least a subset of the one or more displayed views includes one or more gesture recognizers, and the rest of the one or more displayed views do not include gesture recognizers. 
     A respective gesture recognizer of the one or more gesture recognizers has a corresponding delegate. In some embodiments, not all gesture recognizers have corresponding delegates (i.e., in some embodiments, some gesture recognizers do not have corresponding delegates). In some embodiments, the respective gesture recognizer corresponds to two or more delegates, where each delegate determines distinct values for the corresponding gesture recognizer for distinct conditions (e.g., a first delegate determines “should receive”  450 , a second delegate determines “recognition blocked”  451 , etc.). In some embodiments, two or more gesture recognizers correspond to (e.g., utilize) a same delegate. 
     In some embodiments, the device assigns ( 606 ) a respective delegate (e.g., delegate  321 - 1 ) to the respective gesture recognizer (e.g.,  320 - 1 ) (e.g., see the description of step  532  in  FIG. 5B ). Alternately, the respective gesture recognizer has a corresponding delegate, and thus a delegate does not need to be assigned at runtime. All references herein to the assigned delegate of an event/gesture recognizer shall be understood to be equally applicable to a corresponding delegate of an event/gesture recognizer, and all references to a corresponding delegate shall be understood to be equally applicable to an assigned delegate. 
     In some embodiments, the one or more displayed views include ( 608 ) a plurality of gesture recognizers, and the device assigns distinct delegates to at least a subset of the plurality of gesture recognizers. In other words, the device may have fewer delegates than the number of gesture recognizers, since some gesture recognizers may not have assigned delegates. 
     The device detects ( 610 ) one or more events. In some embodiments, the device detects one or more events using sensors  130 , input devices  128 , and/or touch-sensitive display  156 . 
     The device processes ( 612 ) a respective event of the one or more events using the respective gesture recognizer. The processing of the respective event includes processing the respective event at the respective gesture recognizer in accordance with a respective gesture definition corresponding to the respective gesture recognizer (e.g., comparing the event and gesture definitions  333  using event comparator  332 ), executing the corresponding delegate to determine one or more values in accordance with the application state (e.g.,  540  in  FIG. 5B ), and conditionally sending information corresponding to the respective event (e.g., whether the gesture recognizer recognizes the event, such as “tap gesture” or “swipe gesture”, related event information, such as the location and time stamp of the event, and/or other additional information) to the software application in accordance with an outcome of the processing of the respective event by the respective gesture recognizer and in accordance with the one or more values determined by the corresponding delegate. 
     In some embodiments, the delegate has instructions for determining event recognizer properties (such as “should begin”, “should receive”, and “simultaneous recognition”), and when executed, returns one or more corresponding values. In some embodiments, values for the event recognizer properties can be set by the software application in accordance with the application state. In some embodiments, the values for the properties are predefined by developers. In some embodiments, the internal properties of a respective event/gesture recognizer have default values that can be overridden by the delegate corresponding to the event/gesture recognizer. 
     For example, the device sends information corresponding to the respective event when the gesture recognizer is allowed to recognize the event (e.g., based on the one or more values determined by the gesture recognizer&#39;s corresponding delegate, the one or more values indicating whether the gesture recognizer can transition out of event possible state  410  to event recognized state  420  or event began state  412  or whether the gesture recognizer can simultaneously recognize the event despite the presence of a blocking gesture recognizer). In some embodiments, the device sends information corresponding to the respective event only when the event matches a corresponding gesture definition or a part thereof. Furthermore, application states or other conditions may prevent the respective gesture recognizer from sending information corresponding to the respective event. 
     The device executes ( 614 ) the software application (e.g.,  132 - 1 ) in accordance with information, received from the respective gesture recognizer, corresponding to the respective event. For example, the software application (e.g.,  132 - 1 ) includes a plurality of event handlers  322 , and one or more of event handlers  322  are activated according to information received from the respective gesture recognizer (e.g., event handlers  322  listed in action-target pairs  345  are activated). 
     In some embodiments, the one or more event sensors (e.g.,  130 ) include a touch-sensitive surface (e.g.,  156  or a separate touch-sensitive surface) configured to detect one or more touches, and the one or more events include the one or more touches, and processing the respective event comprises processing a respective touch ( 616 ). In some embodiments, the one or more event sensors (e.g.,  130 ) include accelerometers and the one or more events also include rotation or other movement of the electronic device. 
     In some embodiments, the device conditionally receives ( 618 ) the respective touch at the respective gesture recognizer in accordance with the one or more values determined by the assigned delegate. For example, the respective gesture recognizer receives the respective touch only when the one or more values (e.g., “receive touch value”) determined by the corresponding delegate allows the respective gesture recognizer to receive the respective touch (e.g., “should receive”  450  in  FIGS. 4C-4D ). 
     In some embodiments, processing the respective touch includes ( 620 ) the respective gesture recognizer disregarding the respective touch when the one or more values determined by the corresponding delegate matches predefined touch disregard criteria. In these embodiments, instead of conditionally receiving the respective touch as described in step  618 , the respective gesture recognizer disregards the respective touch. 
     In some embodiments, processing the respective touch includes ( 622 ) blocking the respective gesture recognizer from receiving the respective touch when the one or more values determined by the corresponding delegate match predefined touch disregard criteria. In these embodiments, the gesture recognizer does not have a need for conditionally receiving or disregarding the respective touch, since the respective touch is blocked and therefore does not reach the respective gesture recognizer. In some embodiments, the blocking the respective gesture recognizer from receiving the respective touch includes instructing event dispatcher module  315  not to send event information to the corresponding gesture recognizer. 
     In some embodiments, processing the respective touch at the respective gesture recognizer includes ( 624 ), when the detected touch is consistent with the respective gesture definition (e.g., the respective touch matches the gesture definition or a part thereof), enabling a corresponding state transition in the respective gesture recognizer when the state transition is enabled by the corresponding delegate (e.g., “should begin”  454  in  FIGS. 4C-4D ). In some embodiments, the state transition is enabled when a state transition enable value (e.g., “should begin” value) is determined by the corresponding delegate to meet state transition criteria. 
     In some embodiments, processing the respective touch at the respective gesture recognizer includes ( 626 ), when the detected touch is consistent with the respective gesture definition, conditionally enabling a corresponding state transition in the respective gesture recognizer when the state transition is enabled by the corresponding delegate. In other words, the state transition is conditionally enabled even if the corresponding delegate enables (e.g., does not block) the transition. For example, the condition for the state transition includes: whether the respective touch/event matches the gesture definition or a part thereof, whether the respective gesture recognizer is allowed to receive the respective touch/event, and/or whether the recognition of the respective touch/event is blocked. 
     In some embodiments, processing the respective touch at the respective gesture recognizer includes, when the detected touch is consistent with the respective gesture definition, (conditionally) disabling a corresponding state transition in the respective gesture recognizer when the state transition is prevented/disabled by another gesture recognizer that has also recognized a gesture. In particular, gesture recognizers can be paired (or grouped) so that one gesture recognizer can prevent the other gesture recognizer(s) from make a transition into event recognized state  420  or event began state  412  (e.g., when a first gesture recognizer is configured to prevent a second gesture recognizer, the first gesture recognizer, in recognizing an event/touch, prevents the second gesture recognizer from recognizing the event/touch, regardless of the values returned by the delegate corresponding to the second gesture recognizer). 
     In some embodiments, multiple gesture recognizers are listed based on priority (e.g., based on the sequence of the code, sequence of instantiation, view hierarchy corresponding to the respective gesture recognizer, or priority assigned by a developer or the software application). When two or more gesture recognizers simultaneously recognize a respective touch, the highest priority gesture recognizer blocks all other gesture recognizers from recognizing the respective touch. 
     In some embodiments, processing the respective touch at the respective gesture recognizer includes ( 628 ) simultaneously processing the gesture at a second gesture recognizer in accordance with one or more values determined by a delegate corresponding to the second gesture recognizer. For example, the delegate corresponding to the second gesture recognizer may allow the second gesture recognizer to process the gesture at the second gesture recognizer (e.g., step  452  in  FIGS. 4C-4D ), even though another gesture recognizer blocks the recognition of the event. 
     In some embodiments, processing the respective touch at the respective gesture recognizer includes ( 630 ) simultaneously processing the gesture at a second gesture recognizer in accordance with one or more values determined by the delegate corresponding to the respective gesture recognizer. For example, the delegate corresponding to the gesture recognizer may allow the second gesture recognizer to process the gesture at the second gesture recognizer (e.g., steps  455  and  456  in  FIGS. 4C-4D ), even though another gesture recognizer blocks the recognition of the event. 
     In some embodiments, processing the respective touch at the respective gesture recognizer includes simultaneously processing the gesture at a second gesture recognizer in accordance with values determined by the delegates corresponding respectively to the first and second gesture recognizers. 
       FIGS. 7A-7B  are flow charts illustrating an exemplary method of processing a respective touch in accordance with a receive touch value obtained from a delegate, according to some embodiments. 
     Method  700  is performed ( 702 ) at an electronic device (e.g., device  104 ) having a touch-sensitive surface (e.g.,  156 ) and configured to execute a software application that includes a plurality of views (e.g.,  316 ) and an application state of the software application (e.g.,  317 ). 
     The device displays ( 704 ) one or more views of the plurality of views (e.g.,  316 ). A respective view of the one or more displayed views includes one or more gesture recognizers (e.g.,  320 - 1  or  343 - 2 ), and a respective gesture recognizer of the one or more gesture recognizers has a corresponding delegate (e.g.,  321 - 1  or  346 ). 
     The device detects ( 706 ) one or more touches, on the touch-sensitive surface (e.g.,  156  or  130 ). The one or more touches have a touch position that falls within one or more of the displayed views. 
     The device processes ( 708 ) a respective touch of the one or more touches (e.g., determining ( 453 ) whether the respective touch matches gesture definitions  333  by using event comparator  332 ). The processing a respective touch includes: executing ( 710 ) the delegate corresponding to the respective gesture recognizer to obtain a receive touch value in accordance with the application state (e.g.,  550  in  FIG. 5C ); when the receive touch value meets predefined criteria (e.g., the predefined criteria is that the respective gesture recognizer is a receiving gesture recognizer  552  in some embodiments), processing the respective touch at the respective gesture recognizer (e.g.,  554 ); and conditionally sending information corresponding to the respective touch to the software application (e.g.,  542 ). 
     In some embodiments, the plurality of views includes ( 712 ) a plurality of gesture recognizers (e.g., application views  316  and recognizers  320  in  FIG. 3B ; views  508 ,  510 , and  512  and gesture recognizers  516  in  FIG. 5A ). Distinct delegates correspond to at least a subset of the plurality of gesture recognizers. Optionally, the device assigns the distinct delegates (e.g.,  321 ) to at least a subset of the plurality of gesture recognizers (e.g.,  320 ). Processing the respective touch of the one or more touches includes: identifying a set of candidate gesture recognizers of the plurality of gesture recognizers (e.g.,  548 ); for each candidate gesture recognizer having a corresponding delegate, executing the corresponding delegate to obtain a receive touch value in accordance with the application state (e.g.,  550 ); identifying one or more receiving gesture recognizers, comprising a subset of the candidate gesture recognizers, in accordance with the obtained receive touch values (e.g.,  552 ); and processing the respective touch at each gesture recognizer of the one or more of receiving gesture recognizers (e.g.,  554 ). 
     In some embodiments, identifying the set of candidate gesture recognizers of the plurality of gesture recognizers includes identifying a set of gesture recognizers attached to the hit view. Optionally, identifying the set of candidate gesture recognizers of the plurality of gesture recognizers includes identifying a set of gesture recognizers that include a gesture definition corresponding to the respective touch. Furthermore, in some embodiments, identifying the set of receiving gesture recognizers includes identifying a subset of candidate gesture recognizers for which corresponding delegates provide respective receive touch values meeting receive touch criteria (e.g., the receive touch value indicates that the corresponding gesture recognize can receive the respective touch). 
     In some embodiments, processing the respective touch at each gesture recognizer of the one or more receiving gesture recognizers includes ( 718 ) processing the respective touch at a respective receiving gesture recognizer having a corresponding delegate in accordance with a respective gesture definition corresponding to the respective gesture recognizer, executing the delegate to determine one or more values in accordance with the application state, and conditionally sending information corresponding to the respective touch to the software application in accordance with an outcome of the processing of the respective touch by the respective gesture recognizer and in accordance with the one or more values determined by the delegate. The device executes the software application in accordance with information, received from one or more of the receiving gesture recognizers, corresponding to one or more of the touches. 
     In some embodiments, processing the respective touch at the respective receiving gesture recognizer includes ( 720 ), when the detected touch is consistent with the respective gesture definition (e.g., the respective touch matches the gesture definition or a part thereof), enabling a corresponding state transition in the respective gesture recognizer when the state transition is enabled by the corresponding delegate (e.g., “should begin”  454  in  FIGS. 4C-4D ). 
     In some embodiments, processing the respective touch at the respective receiving gesture recognizer includes ( 722 ), when the detected touch is consistent with the respective gesture definition, conditionally enabling a corresponding state transition in the respective gesture recognizer when the state transition is enabled by the corresponding delegate. For example, the condition for the state transition includes: whether the respective touch/event matches the gesture definition or a part thereof, whether the respective gesture recognizer is allowed to receive the respective touch/event, whether the recognition of the respective touch/event is blocked, and/or whether system level instructions (e.g., a shutdown process or other process having higher priority than the application) prevent the state transition. 
     In some embodiments, processing the respective touch at the respective receiving gesture recognizer includes ( 724 ) simultaneously processing the gesture at a second gesture recognizer in accordance with one or more values determined by the delegate corresponding to the second gesture recognizer. For example, the delegate corresponding to the second gesture recognizer may allow the second gesture recognizer to process the gesture at the second gesture recognizer (e.g., step  452  in  FIGS. 4C-4D ). 
     In some embodiments, processing the respective touch at the respective receiving gesture recognizer includes ( 726 ) simultaneously processing the gesture at a second gesture recognizer in accordance with one or more values determined by the delegate corresponding to the respective gesture recognizer (e.g., steps  455  and  456  in  FIGS. 4C-4D ). 
     The device executes ( 716 ) the software application in accordance with information, received from the respective gesture recognizer, corresponding to the respective touch (e.g.,  545 ). For example, the software application (e.g.,  132 - 1 ) includes a plurality of event handlers  322 , and one or more of event handlers  322  are activated according to information received from the respective gesture recognizer (e.g., event handlers  322  listed in action-target pairs  345  are activated). 
       FIGS. 8A-8B  are flow charts illustrating an exemplary method of processing a respective touch in a software application including a discrete gesture recognizer and a continuous gesture recognizer, according to some embodiments. 
     Method  800  is performed ( 802 ) at an electronic device (e.g., device  104 ) having a touch-sensitive surface and configured to execute a software application. 
     The device displays ( 804 ) one or more views (e.g.,  316 ) of the software application (e.g.,  132 - 1 ). The one or more displayed views include a plurality of gesture recognizers (e.g.,  320 ). The plurality of gesture recognizers includes at least one discrete gesture recognizer (e.g.,  FIGS. 4A and 4C ), and at least one continuous gesture recognizer (e.g.,  FIGS. 4B and 4D ). 
     In some embodiments, the discrete gesture recognizer is configured  806 ) to send a single action message in response to a respective gesture, and the continuous gesture recognizer configured to send action messages at successive recognized sub-events of a respective recognized gesture. 
     In some embodiments, a discrete gesture recognizer is configured to send a single set of action messages in response to a respective gesture. When a plurality of target-action pairs are assigned to the respective discrete gesture recognizer, the single set of action messages includes a plurality of action messages. When a single target-action pair is assigned to the respective discrete gesture recognizer, the single set of action messages includes a single action message. 
     In some embodiments, each gesture recognizer has ( 822 ) a set of gesture recognizer states (e.g.,  FIGS. 4A-4D ). 
     In some embodiments, the discrete gesture recognizer has ( 824 ) a first set of gesture recognizer states including:
         gesture possible state  410 , corresponding to an initial state of the discrete gesture recognizer;   gesture recognized state  420 , corresponding to recognition of the respective gesture; and   gesture failed state  430 , corresponding to failure of the discrete gesture recognizer to recognize the one or more touches as the respective gesture.       

     In some embodiments, the continuous gesture recognizer has a second set of gesture recognizer states including:
         gesture possible state  410 , corresponding to an initial state of the continuous gesture recognizer;   gesture began state  412 , corresponding to initial recognition of the respective gesture;   gesture changed state  414 , corresponding to a respective change in location of the respective touch;   gesture ended state  416 , corresponding to completion of the respective recognized gesture;   gesture canceled state  418 , corresponding to interruption of the recognition of the respective gesture; and   gesture failed state  430 , corresponding to failure of the continuous gesture recognizer to recognize the one or more touches as the respective gesture.       

     In some embodiments, gesture recognizer states have assigned values (e.g., gesture recognizer state values). In some embodiments, the gesture recognized state and the gesture ended state have ( 826 ) an identical gesture recognizer state value. 
     In some embodiments, the at least one discrete gesture recognizer includes ( 828 ): one or more of a tap gesture recognizer, and a swipe gesture recognizer; and the at least one continuous gesture recognizer includes: one or more of a long press gesture recognizer, a pinch gesture recognizer, a pan gesture recognizer, a rotate gesture recognizer, and a transform gesture recognizer. 
     In some embodiments, the at least one discrete gesture recognizer includes ( 830 ): a tap gesture recognizer, and a swipe gesture recognizer; and the at least one continuous gesture recognizer includes: a long press gesture recognizer, a pinch gesture recognizer, a pan gesture recognizer, a rotate gesture recognizer, and a transform gesture recognizer. 
     A tap gesture recognizer is configured to recognize a tap gesture; a swipe gesture recognizer is configured to recognize a swipe gesture (e.g., a flick of a touch on a touch-sensitive surface); a long press gesture recognizer is configured to recognize a long press gesture (e.g., a press and hold of a touch); a pinch gesture recognizer is configured to recognize a pinch gesture (e.g., contact and relative movement of two or more touches); a pan gesture recognizer is configured to recognize a pan gesture (e.g., touch and coherent movement of one or more touches); a rotate gesture recognizer is configured to recognize a rotation (e.g., contact and rotational movement of two or more touches); and a transform gesture recognizer is configured to recognize a transform gesture (e.g., a simultaneous movement of two or more touches representing panning, rotation, and pinch). 
     In some embodiments, at least one discrete gesture recognizer (e.g., one or more of the aforementioned discrete gesture recognizers) and at least one continuous gesture recognizer (e.g., one or more of the aforementioned continuous gesture recognizers) are distributed in a software library such that software developers can incorporate them into any third party software using the software library. In comparison, views have view styles (e.g., color, size, and shape of user interface objects and frames). In some embodiments, predefined view styles are distributed as a part of UI Interface API (e.g.,  204  in  FIG. 2 ) such that software developers can develop a software application having the predefined view styles by using the software library (or template). 
     The device detects ( 808  in  FIG. 8A ) one or more touches. In some embodiments, The device detects one or more events using sensors  130 , input devices  128 , and/or touch-sensitive display  156 . 
     The device processes ( 810 ) each of the touches using one or more of the gesture recognizers. The processing of a respective touch includes ( 812 ) processing the respective touch at a respective gesture recognizer in accordance with a respective gesture definition corresponding to the respective gesture recognizer (e.g., comparing the event and gesture definitions  333  using event comparator  332  and determining whether the event matches the gesture definitions  333  or a part thereof), and conditionally sending one or more respective action messages to the software application in accordance with an outcome of the processing of the respective touch at the respective gesture recognizer (e.g., sending an action message when the respective touch matches the gesture definition). 
     In some embodiments, the software application has ( 814 ) an application state. Conditionally sending the one or more respective action messages includes conditionally sending the one or more respective action messages further in accordance with the application state of the software application. For example, the application state of the software application may delay or prevent sending the one or more respective action messages (e.g., when the system resources are overused, when a higher priority process needs to be processed, etc.). 
     The device executes ( 816 ) the software application in accordance with one or more action messages received from one or more of the gesture recognizers corresponding to one or more of the touches. For example, the software application (e.g.,  132 - 1 ) includes a plurality of event handlers  322 , and one or more of event handlers  322  are activated according to action message received from one or more of the gesture recognizers. 
     In some embodiments, the device requests ( 818 ) additional information from the respective gesture recognizer. Executing the software application includes executing the software application further in accordance with the additional information. For example, the respective gesture recognizer can provide additional information (e.g., detailed information, such as a time stamp for each sub-event, the amount of jitter, speed, direction, duration, scale factor, angle, etc.). 
     In some embodiments, the additional information includes ( 820 ) the number and locations of respective touches processed at the respective gesture recognizer. 
     The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.

Metadata:
Filing Date: 20100528
Publication Date: 20170620
Grant Date: 20170620
Priority Date: 20100126
Inventors: SHAFFER JOSHUA H.
MOORE BRADFORD ALLEN
BEAVER JASON CLAY
Assignee: APPLE INC
CPC Classifications: [{"code": "G06F3/04883", "inventive": true, "first": true, "tree": "[]"}, {"code": "G06F3/048", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F9/451", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F9/448", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F3/04883", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F3/04883", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F9/451", "inventive": true, "first": true, "tree": "[]"}, {"code": "G06F3/04883", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F9/4443", "inventive": true, "first": true, "tree": "[]"}, {"code": "G06F9/451", "inventive": true, "first": true, "tree": "[]"}]
Family ID: 43825308