Framework providing application programming interface for user interfaces and animation

The subject technology sends, from a parent node of a hierarchy of views, information related to a preference list, the preference list include preference keys corresponding to respective attributes of a UI, where the hierarchy of views represents the UI. The subject technology receives, at a child node of the parent node, the information related to the preference list. The subject technology updates, by the child node, a particular preference key from the preference list to a particular value, the particular preference key related to an attribute of the UI.

TECHNICAL FIELD

The present description relates generally to implementing user interfaces and animation of graphical elements on electronic devices with and/or without touchscreens.

BACKGROUND

A given operating system may provide graphics and imaging frameworks for developers to create “views” for graphical user interfaces (GUIs or UIs) of a computer application. User Interfaces (UIs) for software applications have increased in complexity and may be implemented to handle views, animations, videos, windows, frames, events, etc., among other types of graphical-related functionality.

DETAILED DESCRIPTION

The subject system provides a framework for handling graphics animation and operations for graphical user interfaces of a software application executing on a given electronic device. A framework can refer to a software environment that provides particular functionality as part of a larger software platform to facilitate development of software applications, and may provide one or more application programming interfaces (APIs) that may be utilized by developers to design, in a programmatic manner, user interfaces and to handle operations for such user interfaces including animations and layout of graphical elements. In an example, this framework provides components to implement a graphical, event-driven user interface that includes UI elements (e.g., windows, dialogs, labels, images, buttons, menus, text fields, pickers, sliders, switches, etc.), handles the rendering of UI elements and animations, and communicates with hardware devices and screen buffers.

For example, the framework as described herein enables developers to create “views” for graphical user interfaces (GUIs) of a computer application. A view can be understood as a visual component of a given application's user interface that can be seen by a user. In some examples, a view may be interacted with, by a user, in some manner. Moreover, the framework supports a user interface with a hierarchy of views such that at least one view can be included within another view, which can be further utilized to define a layout of views within the user interface and/or other properties associated with a set of views within the hierarchy. As discussed further herein, a tree structure may be provided to represent such a hierarchy of views in which parent-child relationships between views are established between respective nodes in the tree structure.

In one or more implementations, the subject system provides a user interface (UI) API that enables developers to create UIs that animate and interact with gesture events in a manner that reduces UI exceptions (e.g., bugs), and significantly reduces an amount of code required to support such animations and/or gesture events. Components of the UI API further provide features that improve UI consistency by implementing an environment system that passes down parameters to views of the UI, and a preference system that applies preferences to the views of the UI in a manner consistent with expected UI behavior. For the purposes of explanation, the UI API is described as a single API herein. However, it is appreciated that the UI API may be implemented as multiple different APIs in which one or more APIs provide a particular set of functionality described further herein.

The network environment100includes an electronic device110, a server120, and a server122in which the server120and/or the server122may be included in a group of servers130. The network106may communicatively (directly or indirectly) couple, for example, the electronic device110with the server120and/or the server122and/or the group of servers130. In one or more implementations, the network106may be an interconnected network of devices that may include, or may be communicatively coupled to, the Internet. For explanatory purposes, the network environment100is illustrated inFIG.1as including the electronic device110, the server120, the server122, and the group of servers130; however, the network environment100may include any number of electronic devices and any number of servers or a data center including multiple servers.

The electronic device110may include a touchscreen and may be, for example, a portable computing device such as a laptop computer that includes a touchscreen, a smartphone that includes a touchscreen, a peripheral device that includes a touchscreen (e.g., a digital camera, headphones), a tablet device that includes a touchscreen, a wearable device that includes a touchscreen such as a watch, a band, and the like, any other appropriate device that includes, for example, a touchscreen, or any electronic device with a touchpad. In one or more implementations, the electronic device110may not include a touchscreen but may support touchscreen-like gestures, such as in a virtual reality or augmented reality environment. In one or more implementations, the electronic device110may include a touchpad. InFIG.1, by way of example, the electronic device110is depicted as a tablet device with a touchscreen. In one or more implementations, the electronic device110may be, and/or may include all or part of, the electronic system discussed below with respect toFIG.26.

The electronic device110may implement the subject system to provide graphical user interfaces and animations. In one or more implementations, the electronic device110may include a framework that is able to support graphical user interfaces and animations, which may be provided in a particular software library in one implementation. For example, the electronic device110may implement the example software architecture for implementing the framework and UI API that is discussed further below with respect toFIG.2. Examples of animations and operations performed via touchscreen are discussed further below with respect toFIGS.3A-3C,FIGS.4A-4C,FIGS.5A-5C,FIGS.9A-9C,FIGS.10A-10C,FIGS.11A-11C,FIG.17,FIGS.20A-20B, andFIGS.21A-21B.

The server120and/or the server122may be part of a network of computers or the group of servers130, such as in a cloud computing or data center implementation. The server120, the server122, and/or the group of servers130may store data, such as photos, music, text, web pages and/or content provided therein, etc., that may be accessible on the electronic device110. In one or more implementations, the electronic device110may support a UI operation that involves a representation of a data item that is physically stored on the server120, the server122, and/or one or more servers from the group of servers130, such as an image file, text, a sound file, a video file, an application, etc.

For providing the UI API described herein, a software architecture is described, in the following discussion ofFIG.2, that implements the functionality for supporting UIs and animations in accordance with one or more implementations.

FIG.2illustrates an example UI framework200that may be implemented on an electronic device in accordance with one or more implementations. For explanatory purposes, the UI framework200is described as being implemented by the electronic device110ofFIG.1, such as by a processor and/or memory of the electronic device110; however, the UI framework200may be implemented by any other electronic device. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the spirit or scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided.

The UI framework200includes a root process205which is configured to manage an event in connection with a UI. In one or more implementations, the root process205may be implemented as an application or daemon running on the electronic device110. The root process205deals with the following three systems included in the UI framework200: a transaction module210, a preferences module230, and an environment module220.

In an example, the root process205receives an event280(e.g., gesture or touch input), and then passes the event280into the transaction module210and passes the event280to an event handler270. The root process205may work in conjunction with a gesture handler system (not shown) in order to receive gesture-related events. The transaction module210handles and tracks the passing of time and time-based events (e.g., animations), and also tracks a gesture as the gesture is occurring (e.g., more event based and less time based). The transaction module210stores transient information about a current change that is happening. In an example, when a view tree is being updated, the transaction module210stores information about the current animation. The transaction module210passes a value of time (e.g., the current time or an elapsed time) to a particular node included in a tree structure related to views of the UI (as discussed further below), which the particular node may utilize to update its associated view(s).

In one or more implementations, the environment module220passes parameters implicitly down the tree. Such parameters, as discussed further herein, can include a size parameter and/or a landscape or portrait mode parameter, for example. The preferences module230applies different preferences to a child node based on information being passed upward from the child node to the parent node. In an example, preferences may include a preferred size and a property related to a status bar.

For managing views of the UI, the UI framework200provides a view module250and a node module260. As discussed further herein, the view module250provides a tree structure including nodes representing hierarchy of views of the UI. Examples of nodes in the tree structure include layout related nodes and animation related nodes.

The software architecture includes a node module260that provides persistent data structures corresponding to the views of the view module250. In one or more implementations, the node module260provides a one-to-one corresponding tree structure with nodes that mirror the tree structure provided by the view module250. Alternatively, as discussed further herein, the node module provides an attribute graph with 1 to n number of nodes providing 1 to n relationships between nodes of the tree structure of views and nodes of the attribute graph.

For supporting animations, the UI framework200includes an animation module240that provides information related to an animation which is used during the performance of the animation. The animation module240communicates with the view module250and the transaction module210to provide animation-related information in order to update one or more views of the tree structure provided by the view module250, and also to receive information related to the passage of time from the transaction module210. An animation, in an example, may be animated based on a timing curve which defines a function that controls the progression of the animation over time. Animations may use different timing functions as provided in the UI framework200. In an example, the timing functions in the UI framework200can generally be represented by segments of functions describing timing curves. The timing functions can be used to define the pacing of an animation over its duration. Examples of such timing functions are discussed in more detail inFIG.6below. In addition, an interpolation curve may be utilized to provide an animation that is interpolated (e.g., blended together) from an initial state to a destination state.

Implementations of the subject technology facilitate creation of UIs in a simplified manner by enabling developers to use general-purpose, flexible constructs (e.g., Swift structures or “structs”) to programmatically define an animation. Using Swift structs, animations may be expressed in code at a high level (e.g., declaratively) indicating an initial state and a destination state. The initial state and destination state may include long lived information about a particular view associated with the animation. Further, animations may be linked with gestures to support gesture-drive animations that are either time-based or independent of time (e.g., depending on the state of the gesture only).

FIGS.3A-3Cillustrate an example animation for moving a horizontal location of a graphical UI element on a screen of the electronic device110. InFIG.3A, the graphical UI element is a graphical element310(e.g., an image or another type of graphical object) at an initial position which eventually moves to a destination position320during the course of the animation. As illustrated inFIG.3C, the animation module240, in at least one implementation, may provide information related to an initial state315and a destination state325of the animation. The initial state315includes information of the initial position of the graphical element310, and the destination state325includes information of the destination position320.

InFIG.3B, the animation module240has updated the animation on the screen which now shows the graphical element310moving to an intermediate position as the animation progresses over time. In one or more implementations, the animation module240generates synthetic data for sending to the screen as the animation is occurring. The synthetic data may be utilized to represent an intermediate state317inFIG.3Cbetween the initial state315and the destination state325. In an example, the animation module may store information related to the intermediate state317as an animation record. An example of an animation record is discussed in more detail inFIG.7below.

In the example ofFIG.3B, the animation module240makes a copy of the destination state325to represent the intermediate state317and injects values into the intermediate state317to represent a state between the initial state315and the destination state325. As discussed above, the node module260provides a tree structure corresponding to a hierarchy of views, in which the tree structure includes nodes for the views. In an example, a particular injected value can be utilized to update a particular node of a view tree for the intermediate state317(which was before a copy of the destination state325). For example, the initial state315has a value of x=1, and the destination state325has a value of x=11. InFIG.3B, the intermediate state317has a value of 4, which is injected in the intermediate state317to update a node in its view tree. The animation module240can then instruct the view tree of the intermediate state317to update itself in order to show the graphical element310at a different position based at least on the updated value of the node.

In one or more implementations, the animation module240creates an animation record, which stores properties for animation, e.g., 1) a from value (e.g., 0), 2) a to value (e.g., 11), 3) an animation function such as an associated animation (e.g., represented as a particular timing curve such a linear animation, an ease-in ease-out animation drive by an input gesture, or generally any animation function); and 4) a start time (e.g., for calculating the delta or time offset) for calculating an elapsed time for the animation. It is appreciated that the animation record may have additional properties, and in some implementations, have fewer than the aforementioned properties.

FIGS.4A-4Cillustrate an example for interpolating an animation of a graphical UI element on a screen of the electronic device110. This example involves receiving multiple touch inputs on a touchscreen of the electronic device110. Each touch input initiates a particular animation that moves the graphical element410at a current position to a particular destination position corresponding to the position of the touch input as received on the touchscreen. InFIG.4A, the graphical UI element is a graphical element410(e.g., an image or another type of graphical object) at an initial position. A touch input is received at a time t1and initiates a first animation that moves the horizontal position of the graphical element410toward a destination position420corresponding to the position of the touch input on the touchscreen.

In an example, the touch input is detected as an event by the root process205, which forwards the event to the event handler270and the transaction module210. The transaction module210then forwards information related to the event to the animation module240. The animation module240uses the information related to the event and initiates the first animation to change the position of the graphical element410on the screen.

InFIG.4B, a second touch input is received at a subsequent time t2from time t1. The graphical element410is at a different horizontal position moving toward the destination position420when the second touch input is received. A second animation is initiated that intends to move the position of the graphical element410toward a second destination position430corresponding to the position of the second touch input on the touchscreen.

To provide a smoother transition and avoid a visually jarring change of the movement of the graphical element along its current path, the animation module240, using combining logic, can perform interpolation of the first animation of the first touch input and the second animation related to the recently received second touch input. Based on this interpolation between the two respective animations, the position of the graphical element410is now updated to move along a curved path425toward a second destination position430corresponding to the second touch input. InFIG.4C, the position of the graphical element410has been moved along the curved path425closer to the second destination position430.

FIGS.5A-5Cillustrate an example of nested animations on a screen of the electronic device110. In some instances, the UI framework200supports having an animation of a parent view which impacts an animation associated with a child view (or vice versa).

InFIG.5A, a parent view includes a first graphical element510(e.g., a window or graphical area) and a child view includes a second graphical element520that is at an initial position of bottom left aligned of first graphical element510of the parent view. In one or more implementations, an animation of the second graphical element520related to the child view may be defined in relative terms with respect to the parent view. For example, the child view includes an animation that moves the second graphical element520along a path515to being top center aligned of the parent view, and then move to being bottom right aligned at a destination position530of the parent view.

InFIG.5B, the first graphical element510of the parent view has decreased in size, and the second graphical element520is now at a second position at the top of the parent view due to the decreased size of the parent view. The destination position530of the parent view, corresponding to the bottom right alignment discussed above, has also changed due to the decreased size of the parent view, which also changes the path515in which the second graphical element520moves along to the bottom right alignment of the parent view.

InFIG.5C, the first graphical element510of the parent view has further decreased in size, and the second graphical element520is now at a third position moving along the path515which again has changed due to the further decreased size of the parent view. The second graphical element of the child view is animated to move toward the destination position530of the parent view, corresponding to the bottom right alignment discussed above, which has again changed due to the further decreased size of the parent view.

In some implementations, a multi-touch driven animation may be supported by the animation module240in which a multi-touch gesture is received for animating the parent view and the child view. For example, a first gesture (e.g., two finger pinch on a first hand) may be received which shrinks the size of the parent view, and a second gesture (e.g., a swipe gesture from a second hand) provides an input for animating the child view.

FIG.6illustrates examples of animations functions related to timing curves. A given animation function may include a function describing a timing curve. More specifically, the timing curve functions for the UI framework200can be used to define the pacing of an animation over its duration from an initial state to a destination state.

In one or more implementations, a timing curve may be utilized to define an animation that occurs linearly across the entire animation such that the animation moves in an even manner over the entire time duration of the animation. Alternatively, a timing curve may be utilized to define an animation that occurs non-linearly such that the animation may accelerate at the beginning and decelerate at the end of the animation (or vice versa).

As illustrated inFIG.6, respective timing curves include a linear timing curve610, an ease in timing curve615, an ease out timing curve620, an ease out in timing curve625, and an ease in out timing curve630. It is appreciated that other types of timing curves may be provided and still be within the scope of the disclosure. For example, a timing curve that mimics a physics simulation or some other type of physical movement, such as movement of a spring, may be provided.

FIG.7illustrates an example data structure for an animation record. The UI framework200, and in particular the animation module240, can create an animation record for storing information related to a given animation. One or more animation records may be created during the progression of the animation (e.g., depending on whether more than one event such as a second touch input is received). For example, a first animation record may be created for a first touch input, and a second animation record may be created for a second touch input, and the first animation record may be utilized to feed into the second animation record. In some instances involving multiple animation records, such animation records may be eventually merged. For example, in a spring animation, two different animation records may be merged. As illustrated inFIG.7, an animation record700includes a from value710, a to value712, an animation function714, and a start time716.

In example, the from value710can include a value representing an initial state of the animation (e.g., a position of 0), the from value710representing a destination state of the animation (e.g., a position of 11). The animation function714may be represented as a particular timing curve such a linear animation or an ease-in ease-out animation as discussed above inFIG.6. Further, the start time716may include information for calculating the delta or time offset in connection with calculating an elapsed time.

FIG.8illustrates a flow diagram of an example process800of generating an animation record of a given animation for performing on an electronic device110in accordance with one or more implementations. For explanatory purposes, the process800is primarily described herein with reference to the electronic device110ofFIGS.1and2, particularly with reference to the animation module240described above inFIG.2. However, the process800is not limited to the electronic device110ofFIGS.1and2, and one or more blocks (or operations) of the process800may be performed by one or more other components of other suitable devices. Further for explanatory purposes, the blocks of the process800are described herein as occurring in serial, or linearly. However, multiple blocks of the process800may occur in parallel. In addition, the blocks of the process800need not be performed in the order shown and/or one or more blocks of the process800need not be performed and/or can be replaced by other operations.

As illustrated inFIG.8, the animation module240receives first information related to an animation, the first information including an initial state, a destination state, and an animation function (810). In one or more implementations, the animation function corresponds to a function of time such as a timing curve. In another example, the animation function corresponds to a gesture (e.g., gesture-driven and dependent on a current state of the feature) and is not time-dependent. Alternatively, the animation function corresponds to a physics simulation such as a spring-like motion discussed above inFIG.6. In some implementations, the first information further includes a start time for animation. The animation module240may determine an elapsed time based at least in part on a current time and the start time for the animation.

The animation module240generates a record of the animation (e.g., the animation record discussed inFIG.6) including information for the initial state, the destination state, and the animation function (812). The animation module240generates a copy of the destination state in which the copy of the destination state is based on the record for the animation (814).

The animation module240updates a value related to an intermediate state of the animation in the copy of the destination state, the intermediate state being between the initial state and the destination state (816).

The animation module240provides the copy of the destination state that includes the value related to the intermediate state for rendering the animation (818). In an example, an interpolation curve may be applied to blend the animation from the initial state to the destination state based at least in part on the intermediate state.

FIGS.9A-9Cillustrate an example of an animation initiated by an input gesture on a touchscreen of the electronic device110. In some instances, the UI framework200supports an animation that is gesture-driven.

InFIG.9A, a user input, corresponding to a touch input gesture (e.g., a tap), is received at a first graphical element915inside a view910with a graphical element such as a window or graphical region of a UI. An animation may be initiated based on the received user input.

InFIG.9B, the animation slides a second graphical element920, corresponding to a second window or graphical region different than the first graphical element915, in a horizontal direction across the touchscreen. InFIG.9C, the animation is completed and the second graphical element920is displayed in the view. In an example, although the animation is initiated from the input gesture, the animation may also be defined to complete with a specified amount of time (e.g., 0.3 seconds). In this manner, an input gesture may be utilized as an event to trigger the start of the animation and the duration of the animation is also completed with the specified amount of time. Additionally, it is appreciated that the animation may be tied to a particular timing curve to further specify a speed in which the animation occurs.

FIGS.10A-10Cillustrate an example of an animation initiated by an input gesture on a touchscreen of the electronic device110and then controlled by a gesture until completion. In some instances, the UI framework200supports an animation that is gesture-driven and independent of time, with a current state of a gesture determining the progression of the animation.

InFIG.10A, a user input, corresponding to a touch input, is received inside a view with a first graphical element1010such as a window or graphical region of a UI. An animation may be initiated based on the received user input and then controlled as driven by a current state of a gesture such as a sliding drag gesture or swipe across the touchscreen of the electronic device110.

InFIG.10B, the movement of the gesture slides a second graphical element1020, corresponding to a second window or graphical region different than the first graphical element1010, in a horizontal direction across the touchscreen. InFIG.10C, the animation is completed after the gesture has moved across the portion of the touchscreen displaying the view, and the second graphical element1020is displayed, alone, in the view.

FIGS.11A-11Cconceptually illustrate an example of nested animations involving color properties from a parent view and a child view. In some instances, the UI framework200supports having an animation of parent view which impacts an animation associated with a child view (or vice versa).

InFIG.11A, a parent view1110includes color properties with a hue value and a brightness value. The parent view1110has a hue value of red and a brightness value of 1. In some implementations, properties related to color are animatable, which means such properties may be utilized in animations and changed from one value to another. The parent view1110in this example animates color by changing the hue value and/or the brightness value over time, which will impact an animation of color in the child view1120. As also shown, a child view1120includes color properties of a color value with a value of orange, and a brightness value with a value of 1. The child view1120in this example animates color by changing the brightness value of the color. Changes in the values for the properties related to color in the parent view1110affects the animation of the brightness value in the child view1120as discussed further below.

InFIG.11B, a value for hue in the parent view1110has changed from red to orange. The child view1120detects the change in hue in the parent view1110and changes its brightness value from 1 to 0.5 and updates its color value to orange.

InFIG.11C, the parent view1110has changed its value for hue from orange to green. The child view1120updates its color value to green with respect to the change in the hue value in the parent view1110. In this manner, the animation in the child view1120is changed with respect to the animation occurring in the parent view1110.

In one or more implementations, the UI framework200provides a hierarchy of view nodes representing respective views of a UI. Based on the hierarchy of view nodes, a corresponding hierarchy of nodes representing the underlying data structures is generated to facilitate the storage of properties and/or other information related to such view nodes in a persistent manner, which remains in memory as the view nodes are discarded and/or re-created with updated properties. Additionally, the UI framework200provides various protocols to implement different types of view nodes, which are discussed further below.

FIG.12illustrates an example of a view tree1220and a node tree1250with a one-to-one relationship between respective nodes of each tree in accordance with one or more implementations. The view module250creates the view tree1220for an application UI1205including views for an image1210(e.g., a chevron) and text1215(e.g., “Hello”) shown in the display of the electronic device110.

The view tree1220includes a root node for a custom view node1230, which has a child node for a layout view node1232. The layout view node1232has two respective child nodes corresponding to an image node1240and a label node1242. The view tree1220in an example represents a hierarchy with at least a root node (e.g., the custom view node1230) corresponding to a root view, which may include one or more child nodes. The root view is the parent view of the entire UI. In the example ofFIG.12, the custom view node1230corresponds to a particular type of view supported by the UI framework200. Each node in a given view tree may correspond to a particular view type such as a custom view or a layout view, or correspond to a property such as color, an image, label, etc.

For storing information related to the view tree1220in a persistent manner, the node tree1250includes a root node1260corresponding to the custom view node1230in the view tree1220. The node tree1250further includes a node1262corresponding to the layout view node1232, a node1270corresponding to the image node1240, and a node1272corresponding to the label node1242.

View trees are ephemeral and get recreated frequently and discarded. For example, when an event is received and changes the state of a view tree, then the view module250may create a new view tree in response to the event. Thus, a view tree may be considered transient and gets re-generated upon an update (e.g., receiving an input or event that causes a change, such as events, data received over the network, user input (e.g., gesture), and time changes when animation is already running). Further, when a new view tree is generated for portions of the UI that have changed, nodes in the node tree are updated.

In an example, a developer can call an update function on the root node of the view tree1220, which in turn calls an update for all of its child nodes. For an animation, the update function initiates a creation of an animation record, which stores properties for animation.

In some implementations, instead of a node tree structure (e.g., the node tree1250), the UI framework200provides an attribute graph as discussed further below in the discussion ofFIG.13. An attribute graph may support 0 to n number of inputs, and applies a function on the inputs for calculating an output. The output may be stored in a persistent memory structure, and whenever any of the n inputs get changed then the function gets re-run to generate a new output.

To provide support for different types of views and/or nodes, the software architecture implements various protocols as discussed further. In one or more implementations, protocols are analogous to interfaces in the Java® programming language. Further, protocols as described herein correspond to Swift language structs instead of objects. The following discussion relates to different types of protocols supported by the UI framework200for creating UIs and supporting animations.

In one or more implementations, the UI framework200provides a view protocol that generally has fundamental definition for a view, and how a node of a view tree and a node of a node tree may interoperate. Further, the view protocol also includes a function for making one or more nodes of a view tree. The following is a discussion of sub-protocols for the view protocol (e.g., corresponding to a type of view). Each of the sub-protocols may include a specific implementation of a function to make nodes of a view tree where the function can receives inputs corresponding to a state of the UI and environment parameters of the UI, and the function provides the generated child node corresponding to that particular view type after being called.

In one or more implementations, the UI framework200provides a custom view where a customized UI with one or more views may be defined. Further, in one or more implementations, the UI framework200provides different layout view protocols for various layouts of graphical elements, including the following: X Stack protocol for x-axis layouts, Y Stack protocol for y-axis layouts, and a Z Stack protocol for a z-axis layout.

In one or more implementations, the UI framework200provides a unary layout protocol, which is similar to the layout view protocol but only has a single child. Some examples of a unary layout protocol include an alignment layout protocol, and a size layout protocol.

To support animations, in one or more implementations, the UI framework200provides an animatable view protocol, including sub-protocols for an animation protocol and an animatable protocol. The animation protocol supports, for example, a timing curve animation that is based on timing curves over time (e.g., linear or ease-in ease-out curve over a duration of time), or a physics simulation such as a spring animation. The animatable protocol provides support for any property that can be animated: e.g., color, numbers, vectors, and any property where values may be interpolated.

Further, the animatable view protocol provides combining logic for animating between respective child views, and/or between a parent view and a child view. A discussion of an example of how the combining logic performs follows below. Two events (e.g., a first event, and a second event) may be received for an animatable view. Respective animation records are created for each event based on respective input values including: a from value, a to value, and an start time value. The combining logic combining logic returns for 1stevent: 1) a 1steffective value (e.g., corresponding to new interpolated value); and 2) Boolean value indicating whether the animation has completed. Next, the combining logic returns for 2ndevent: 1) a 2ndeffective value based on the 1steffective value that is passed as the from value in the input values; and 2) Boolean value indicating whether the second animation has completed.

In one or more implementations, the UI framework200provides an event handler protocol (e.g., for gestures). Further, in one or more implementations, the UI framework200provides a custom event handler protocol, which is similar to the custom view protocol but is for supporting events. Additionally, in one or more implementations, the UI framework200includes a combining event handler protocol, which provides combining logic for child nodes, and/or between parent and child nodes.

FIG.13illustrates an example of a view tree1320and an attribute graph1350with a one to n number relationship between the nodes of the view tree1320and the nodes of the attribute graph1350in accordance with one or more implementations. The view module250creates the view tree1320for an application UI1305including views for an image1310(e.g., a chevron) and text1315(e.g., “Hello”) shown in the display of the electronic device110.

The view tree1320is the same as the view tree1220shown inFIG.12. For example, the view tree1320includes a root node for a custom view node1330, which has a child node for a layout view node1332. The layout view node1332has two respective child nodes corresponding to an image node1340and a label node1342.

The attribute graph1350includes an n number of nodes that each respectively represent a property or attribute. As shown, the attribute graph1350includes an attribute node1360for a first attribute, an attribute node1362for a second attribute, an attribute node1364for a third attribute, an attribute node1365for a fourth attribute, and an attribute node1366for a n number attribute. Each of the attributes nodes in the attribute graph1350may include one or more links to respective other attribute nodes in the attribute graph1350. Each of the nodes from the view tree1320may create one or more of the aforementioned attribute nodes in the attribute graph1350in order to associate a particular node in the view tree to such attributes. Thus, when an attribute node in the attribute graph1350is updated one or more nodes from the view tree1320may be notified.

In one or more implementations, each of the nodes from the view tree1320may have a particular number of attributes (e.g., 5 to 10 different attributes) assigned to it from the attribute graph1350. In an example, such attributes included in the attribute graph1350may include, but not limited to, attributes related to a preferred size, rendering output, the view itself (e.g., for indicating a change to the view), dynamic type size, position, size, etc. A node corresponding to a layout view may include attributes for a size and position, etc., for each of its child views, and each of the child views may include attributes for a preferred size (which may be constrained based on the size and/or position attributes from the parent layout view node). A node corresponding to text may include attributes for a preferred size, dynamic type size (e.g., for changing a font size), etc.

In an implementation, the view tree1320can be traversed starting from the root node, and each view can be requested to provide a set of attributes corresponding to a set of inputs and a second set of attributes corresponding to a set of outputs for the corresponding view. The set of outputs for a corresponding node in the view tree1320can be referred to as a display list in an example. When new inputs are provided (e.g., as events occur over the progression of time), each attribute that is affected by the new inputs can set a dirty bit (e.g., by changing the value to ‘1’) to indicate that the corresponding attribute has been changed based on at least one of the inputs. The view tree1320can then be traversed bottom up from a respective child node where attributes that are marked as dirty can initiate an update of respective output attributes at the corresponding node (e.g., thereby changing the output of the corresponding view of that node) based on the updated input attributes.

FIG.14illustrates an example of a view tree1470with various types of child nodes, enabling different views of content, from a root node of the view tree1470in accordance with one or more implementations. The view module250can create the view tree1470for a given application UI including various views of content, based on a given input or a conditional, for displaying on the display of the electronic device110.

The view tree1470, as shown, includes a root node1475corresponding to a root view, and various child nodes including a child node1476, a child node1477, a child node1478, a child node1480, and a child node1481. In particular, child node1476corresponds to a layout view that has two respective child nodes corresponding to child node1477and child node1481. As further shown, child node1477corresponds to a view for a first image “Image A” and child node1478corresponds to a view for a second image “Image B” which is discussed in further detail in the examples below.

In the example ofFIG.14, the view tree1470may be implemented, as enabled by the UI framework200(e.g., a developer provides additional code), to provide a child view that corresponds to static content, or a child view that corresponds to dynamic content (e.g., a data driven child view). For a given data driven child view, the UI framework200can enable configuring a set of data that the child view can handle, and how the child view will construct a view in order to display the data. As illustrated inFIG.14, child node1477, and child node1478correspond to respective data driven child views of a root node1475which is discussed below.

In an implementation, child node1476can receive an input that determines whether to display the image corresponding to child node1477or the other image corresponding to child node1478. For example, a particular child view can correspond to a conditional view of content that provides a conditional based selection of a particular view to output for display. For such a child view, in an example, the child view (e.g., child node1476) may be provided a Boolean value (e.g., a conditional value) as an input, which the child view uses to determine which view among at least two respective views to output for display. Such an input can be, for example, an indication that a selection of a particular portion of the view corresponding to child node1476has occurred which is provided as input data to child node1476. In this example, child node1476, based on the input, determines to display one of the images in either child node1477or child node1481based on the Boolean value, such as display the view corresponding to child node1477when the Boolean value is true or display the view corresponding to child node1478when the Boolean value is false.

In another example, the conditional view of content can provide an optional view of content in which the corresponding child view can display a particular view when the conditional is true but does not display any view when the conditional is false. As an example, this may occur in an application that provides a view when a particular event has occurred (e.g., receiving a new email) such that a particular child view is provided as output for display when the event has occurred, but no view is displayed absent of that event. As shown in the example ofFIG.14, the view corresponding to child node1477can be provided as output for display when a true conditional is satisfied. However, in this optional view example, the view corresponding to child node1478would not be provided for display.

FIG.15illustrates an example of a view tree1585with various nodes that utilize bindings in order to update values of data included in a portion of the nodes in the view tree1585in accordance with one or more implementations. The view module250can create the view tree1585for a given application UI including various views for displaying on the display of the electronic device110.

The view tree1585, as shown, includes a root node1590corresponding to a root view, and various child nodes including a child node1591, a child node1592, a child node1593, a child node1594, and a child node1595. In an implementation, a scope for updating nodes within the view tree1585may be established based on binding information associated with each node. For each node that may include data that can be changed, binding information can include a current value for data and a way to update the value of the data (e.g., a location where the data is updated such as a database or a temporary buffer or value), and an indication of whether the current value for data has been read or accessed (e.g., by the application). When a node has data that has been updated and the data has been read in the node based on the associated binding information, the view tree1585may be updated at the node to reflect the updated data while forgoing updates at any other nodes within the view tree1585where binding information does not indicate that data has been read or accessed.

As shown inFIG.15, respective binding information is included in root node1590, child node1592, child node1593, and child node1594. At an initial time, respective binding information indicates (e.g., by having a “false” value) that none of the aforementioned nodes have data that has been read. At a subsequent time, child node1594has been read and the binding information is updated (e.g., by having a “true” value). At a further subsequent time, child node1594has its data updated. At this time, the binding information of each of the aforementioned nodes is read to determine whether that node is to be updated. In this example, since child node1594includes binding information indicating that its data has been read, an update is performed on child node1594and its child node1595, while the other nodes forgo the processing for updates. In this manner, updates to the view tree1585can be optimized using the binding information.

FIG.16illustrates a flow diagram of an example process1600of generating a view tree (e.g., the view tree1220) and a corresponding node tree (e.g., the node tree1250) for performing on an electronic device110in accordance with one or more implementations. For explanatory purposes, the process1600is primarily described herein with reference to the electronic device110ofFIGS.1and2, particularly with reference to components of the UI framework200as described above inFIG.2. However, the process1600is not limited to the electronic device110ofFIGS.1and2, and one or more blocks (or operations) of the process1600may be performed by one or more other components of other suitable devices. Further for explanatory purposes, the blocks of the process1600are described herein as occurring in serial, or linearly. However, multiple blocks of the process1600may occur in parallel. In addition, the blocks of the process1600need not be performed in the order shown and/or one or more blocks of the process1600need not be performed and/or can be replaced by other operations.

In one or more implementations, the root process205may receive a command to initiate an application, which gets forwarded to the event handler270and/or the transaction module210that will initiate operations to create a view tree for views of a UI of the application and a corresponding node tree (1610). In response to the command, the view module250generates a root node (e.g., the custom view node1230) related to a root view of a first hierarchy of views representing a UI of the application (e.g., the application UI1205inFIG.12) (1612).

The view module250generates a child node (e.g., the layout view node1232) of the root node for including in the first hierarchy of views, the child node corresponding to a first type of view (1614). The first type of view may include a layout of a graphical element of the UI. In some implementations, the first type of view includes at least one of an X-axis layout, a Y-axis layout, a Z-axis layout, and a radial layout, which are discussed in further detail inFIG.19below. Alternatively or conjunctively, the first type of view may be a property that is animated, and the property relates to at least one of a color, a numerical value, a vector, and a particular property where values are interpolated.

The view module250generates a first child node (e.g., the image node1240or the label node1242) of the child node for including in the first hierarchy of views, and the first child node corresponds to a second type of view (e.g., an image or a label, etc.) (1616). The node module260generates, based at least in part on the hierarchy of views, a second hierarchy (e.g., the node tree1250inFIG.12) including respective nodes corresponding to each node from the hierarchy of views, and the respective nodes correspond to persistent data structures of each node from the hierarchy of views (1618).

FIG.17illustrates a flow diagram of an example process1700of generating a view tree (e.g., the view tree1320) and a corresponding attribute graph (e.g., the attribute graph1350) for performing on an electronic device110in accordance with one or more implementations. For explanatory purposes, the process1700is primarily described herein with reference to the electronic device110ofFIGS.1and2, particularly with reference to components of the UI framework200as described above inFIG.2. However, the process1700is not limited to the electronic device110ofFIGS.1and2, and one or more blocks (or operations) of the process1700may be performed by one or more other components of other suitable devices. Further for explanatory purposes, the blocks of the process1700are described herein as occurring in serial, or linearly. However, multiple blocks of the process1700may occur in parallel. In addition, the blocks of the process1700need not be performed in the order shown and/or one or more blocks of the process1700need not be performed and/or can be replaced by other operations.

In one or more implementations, the root process205may receive a command to initiate an application, which gets forwarded to the event handler270and/or the transaction module210that will initiate operations to create a view tree for views of a UI of the application and a corresponding node tree (1710). In response to the command, the view module250generates a root node (e.g., the custom view node1330) related to a root view of a first hierarchy of views representing a UI of the application (e.g., the application UI1305inFIG.13) (1712). The view module250creates one or more attributes related to the root node corresponding to the root view (1714). In an example, such attributes are stored as respective nodes in an attribute graph (e.g., the attribute graph1350).

The view module250generates a child node (e.g., the layout view node1332) of the root node for including in the first hierarchy of views, the child node corresponding to a first type of view (1716). The view module250creates one or more attributes related to the child node, which may be stored in the attribute graph (1718). The view module250generates a first child node (e.g., the image node1340or the label node1342) of the child node for including in the first hierarchy of views, and the first child node corresponds to a second type of view (e.g., an image or a label, etc.) (1720). The view module250creates one or more attributes related to the first child node, which may be stored in the attribute graph (1722).

FIG.18illustrates different example code segments for various operations involving a node tree and an attribute graph. The code segments may be provided by a developer and compiled for execution by the UI framework200. Moreover, the code segments may call one or more APIs provided by the UI framework200.

As shown inFIG.18, a code segment1810with example code for creating nodes of a view tree is provided. A code segment1840is illustrated with example code for initiating an application and creating a view tree. Further, a code segment1880is illustrated with example code for initiating an application and creating an attribute graph.

FIG.19illustrates different example layouts for graphical elements of a UI that are provided by the UI framework200in accordance with one or more implementations. As discussed above, the UI framework200supports various ways to provide layouts for graphical elements. As shown, an X stack layout1910is provided for a layout of graphical elements along an x-axis (e.g., horizontally), a Y stack layout1930is provided for a layout of graphical elements along a y-axis (e.g., vertically), and Z stack layout1950is provided for a layout of graphical elements along a z-axis. Further, a radial layout1970is provided for a layout of graphical elements in a radial arrangement.

The UI framework200supports a layout of graphical elements that is expressed in declarative code (e.g., code written using a declarative syntax), potentially easing the burden on a developer by enabling the developer to more easily define the structure of a particular layout without requiring defining a control flow of an application. Based on the declarative code, the API calls corresponding imperative code to perform layout functions. Thus, the UI framework200enables the developer to write declarative code that corresponds to a high level description of a layout for graphical elements, and the UI framework200automatically calls low level imperative code (e.g., code written using an imperative syntax) that can be executed faster by the electronic device110. In comparison with declarative code, the imperative code may be written using an imperative syntax that uses statements to change a state of the application. Example code segments including declarative code and imperative code are discussed in more detail with respect toFIG.21below.

FIG.20illustrates a flow diagram of an example process2000of receiving code in declarative syntax and calling imperative code for performing on an electronic device110in accordance with one or more implementations. For explanatory purposes, the process2000is primarily described herein with reference to the electronic device110ofFIGS.1and2, particularly with reference to components of the UI framework200as described above inFIG.2. However, the process2000is not limited to the electronic device110ofFIGS.1and2, and one or more blocks (or operations) of the process2000may be performed by one or more other components of other suitable devices. Further for explanatory purposes, the blocks of the process2000are described herein as occurring in serial, or linearly. However, multiple blocks of the process2000may occur in parallel. In addition, the blocks of the process2000need not be performed in the order shown and/or one or more blocks of the process2000need not be performed and/or can be replaced by other operations.

The UI framework200receives code including declarative syntax related to operations describing a layout for graphical elements of a UI (2010). In an example, the UI framework200executes the code including the declarative syntax before calling the imperative code. The UI framework200calls imperative code, based at least in part on the declarative syntax of the received code, to perform the operations describing the layout for the graphical elements of the UI (2012). In response to calling the imperative code, the UI framework200executes the imperative code in which the imperative code executes in an amount of time less than executing the code including the declarative syntax.

FIG.21illustrates different example code segments for declarative code to define a layout and imperative code to change a state of the layout. The code segments may be provided by a developer and compiled for execution by the UI framework200. Moreover, the code segments may call one or more APIs provided by the UI framework200.

As shown inFIG.21, a code segment2110with example code in a declarative syntax to define a layout, including a graphical element (e.g., chevron) within a 10×10 sized box, is provided. A code segment2140is also illustrated with example code in an imperative syntax that changes the state of the layout when executed.

In one or more implementations, the UI framework200provides a preferences system (e.g., as provided by the preferences module230) to allow a parent view in a view tree to determine preferences related to UI properties from one or more child views of the parent view. A preference list is passed down from the parent view to its children, where each child view may write preferences that are included in the preference list, which then get passed back to the parent view to determine expected UI behavior.

FIGS.22A-22Bconceptually illustrate examples of utilizing a preference list in a view tree to change a state of a particular view for a status bar of a UI. In some instances, a parent view of a view tree may want to change something about itself. However, in order to draw the parent view, the parent view queries its child views about their properties.

For a given application with at least one view for a status bar and a other view for a different portion of the UI (e.g., a main graphical area of the UI), the application may have a dark background or a light background for the other view. Based on this view, the application might want to change the color of the status bar. For example, for an application that is mostly light in color, the application may want a dark status bar and/or the text to be white at the top whereas an application that was predominately dark may want the status bar to be light in color.

As illustrated inFIG.22A, a view tree2210includes a root view node2220for an application, and a first child view node2222for a main graphical area2232of the application, and a second child view node2224for a status bar2230of the application.

As further shown, for updating the status bar2230, the root view node2220may call an update function provided by the UI framework200, which initiates the passing of a preference list2240downward to each of the child view nodes. While passing the preference list2240downward to traverse the view tree2210, a particular child view node may utilize a preference writing view (not shown) to write a value to a preference in the preference list. Alternatively, the particular child view may write directly into the preference list2240to update a particular preference.

In response, the preferences module230sends a preference list2240to the second child view node2224. In one implementation, the preference list2240includes keys of preferences for a preferred size, a status bar, and color. In an example, the preferences module230may communicate with the environment module220to coordinate the sending of the preference list. In particular, the preferences module230may send a request to the environment module220to send the preference list2240to the second child view node2224(e.g., instead of the preferences module230directly sending the preference list2240).

InFIG.22B, the second child view node2224receives the preference list2240as part of the update function called by the root view node2220. To update the preference for the status bar, the second child view node2224passes, as a set of parameters, a particular key (e.g., the status bar color) and a value for that particular key (e.g., dark or light) to a function for calling a preference writing view. This action by the second child view node2224creates a preference writing view which also creates an associated preference writing view node. The second child view node2224may then call an update function on the preference writing view.

In response, the preference writing view may check the preference list2240and determine whether a key of the preference list2240matches the particular key previously provided (e.g., a status bar color). Since the particular key matches one of the keys included in the preference list2240, the preference writing view will update the value of the key for the status bar color in the preference list2240. In some implementations, the preference list2240initially includes default values for each key. The preference writing view now injects the value for the status bar color into the preference list to include this particular key value and update the default value. The preference list2240is then passed up to the root view node2220, which reads the updated value for the status bar color in the preference list2240and updates the view for the status bar2230to be a dark color.

In one or more implementations, when a preference is set by a given node of the view tree2210, a pointer to that node is established between a parent node that called an update function and the child node that wrote the preference in the preference list. In this example, since the aforementioned preference writing view associated with the second child view node2224, wrote a value to the preference list2240, a relationship is established between the node for the preference writing view and the particular node (e.g., parent node corresponding to the root view node2220) that asked for the preference. After which, any time an update function gets called by the particular node, the preference writing view (or the second child view node2224) will send a message to the particular node that asked about the preference so that the particular node can update itself which causes the particular node to reevaluate the preference and get the new value for the preference. For example, if the status bar view (e.g., the second child view node2224) changed from light to dark, the second child view node2224may send the message up to the root view node2220which would then cause the view corresponding to the root view node2220to reevaluate the view tree2210to get back the new preference value for the status bar color in order to update the color of the status bar2230.

Alternatively, in one or more implementations involving using an attribute graph, initialization of attributes and relationships between parent and child nodes of a given view tree occur before a preference list is passed down to the child nodes. As a result, the above discussion of establishing a pointer between a child node and a parent node does not occur after the preference key is written by the child node.

Further, in some implementations, it is appreciated that additional preferences may be added to the preferences list2240. For example, a particular view node of the view tree may also add additional preferences if there are properties that the view node wants to set as a preference.

In some implementations, the preferences module230provides special combiner rules to resolve potential conflicts between preferences. For example, when a first view writes a preference for a light status bar and a second view writes a preference for a dark status bar, a rule may be utilized to determine how multiple values are evaluated together to get a single value for the preference. In this example, the rule may provide a light status bar when preferences conflict with each other.

FIG.23Aconceptually illustrates an example of utilizing a preferences list in a view tree to change a size of a particular view of a UI. The example ofFIG.23relates to updating a preference for a preferred size of a particular graphical UI element.

In one or more implementations, a preferred size relates to a preference for intelligently deciding how to divide up the space in between graphical elements that are displayed in an application. For example, for a given layout such as an X stack, the X stack might include a particular amount of space assigned to the X stack in a table view. In response to a change to one of the graphical elements in the X stack (e.g., an amount of text), a value for a preferred size of that graphical element may be written into the preference list to update the size of the view of the graphical element. The root node of the view tree may then call for an update from its child nodes to draw the X stack on the screen.

As illustrated inFIG.23A, a view tree2310includes a root view node2320for an application, and a first child view node2322for an X stack layout view of the application, and a second child view node2324for a status bar (not shown) of the application. The first child view node2322includes child view nodes2325,2326, and2327respectively corresponding to graphical elements2350,2352, and2354(e.g., image, short text, long text) in the X stack layout view.

In response to an event that updates the text of the graphical element2354(e.g., changing longer text to shorter text), the root view node2320may call an update function provided by the UI framework200, which initiates the passing of a preference list2330downward to each of the child view nodes. Although not shown, alternatively, in some implementations, the first child view node2322may instead call an update function directly on its child view nodes2325,2326, and2327.

In response, the preferences module230sends a preference list2330to the first child view node2322. In one implementation, the preference list2330includes keys of preferences for a preferred size, a status bar, and color. Each of the keys in the preference list2330may have a particular value as shown in preference values2335. For example, the preferred size key may have a value of “Size1”, the status bar key may have a value of “light” and the color key may have a value of “Color123”. As further shown inFIG.23A, the first child view node2322receives the preference list2330as part of the update function called by the root view node2320. The first child view node2322may forward the preference list2330to each of the child view nodes2325,2326, and2327.

To update the preference for the preferred size in response to the changed text, the child view node2327passes, as a set of parameters, a particular key (e.g., a preferred size) and a value for that particular key (e.g., a smaller size than the current size since the text is shorter) to a function for calling a preference writing view. This action by the child view node2327creates a preference writing view which also creates an associated preference writing view node. The child view node2327may then call an update function on the preference writing view. In response, the preference writing view may check the preference list2330and determine whether a key of the preference list2330matches the particular key previously provided (e.g., a preferred size). The preference writing view updates the value of the key for the preferred size of the graphical element2354in the preference list2330. After updating the value, each of the keys in the preference list2330may have a particular value as shown in the preference values2335. For example, as shown inFIG.23B, the preferred size key may now an updated value of “Size2”, while the values for the status bar key the color key are unchanged. As shown inFIG.23B, the preference list2330is then passed up to the root view node2020, which reads the updated value for the preferred size key in the preference list2330and updates the view for X stack layout to have a different size of the graphical element2354to accommodate for the shorter text.

In some implementations, the preferences module230provides special combiner rules to resolve potential conflicts between preferences. For example, for different preferred sizes, the preferences module230may add up the preferred sizes together, take an average of the preferred sizes, or select the largest value among the preferred sizes, etc., to determine the preferred size preference for the parent.

FIG.24illustrates a flow diagram of an example process2400of updating a preference list for performing on an electronic device110in accordance with one or more implementations. For explanatory purposes, the process2400is primarily described herein with reference to the electronic device110ofFIGS.1and2, particularly with reference to components of the UI framework200as described above inFIG.2. However, the process2400is not limited to the electronic device110ofFIGS.1and2, and one or more blocks (or operations) of the process2400may be performed by one or more other components of other suitable devices. Further for explanatory purposes, the blocks of the process2400are described herein as occurring in serial, or linearly. However, multiple blocks of the process2400may occur in parallel. In addition, the blocks of the process2400need not be performed in the order shown and/or one or more blocks of the process2400need not be performed and/or can be replaced by other operations. The example process2400inFIG.24discusses an implementation that updates preferences between parent and child view nodes of a view tree using a preference list.

In one or more implementations, the UI framework200sends, from a parent node of a hierarchy of views, information related to a preference list, the preference list including preference keys corresponding to respective attributes of a UI (2410). The UI framework200receives, at the child node of the parent node, the information related to the preference list (2412).

The UI framework200updates, at the child node, a particular preference key from the preference list to a particular value, the particular preference key related to the attribute of the UI (2414). In an example, after updating, an indication of a dependency (e.g., a pointer) between the child node to the parent node, related to an attribute of the UI, may be generated where the indication can be utilized for a subsequent update of the attribute of the UI. Additionally, the UI framework200sends, after the particular preference key was updated by the child node, the preference list including the updated particular preference key to the parent node (2416). Further, the UI framework200updates, at the parent node, the attribute of the UI based at least in part on the updated particular preference key sent from the child node.

In an example, at a subsequent time, the UI framework200updates, at the child node, the particular preference key to a different value from the particular value. In response to the child node updating the particular preference key to the different value, the UI framework200updates, at the parent node, the attribute of the UI based at least in part on the different value and the indication of the dependency between the child node and the parent node.

FIG.25illustrates a flow diagram of an example process2500of updating an attribute related to a particular view for performing on an electronic device110in accordance with one or more implementations. For explanatory purposes, the process2500is primarily described herein with reference to the electronic device110ofFIGS.1and2, particularly with reference to components of the UI framework200as described above inFIG.2. However, the process2500is not limited to the electronic device110ofFIGS.1and2, and one or more blocks (or operations) of the process2500may be performed by one or more other components of other suitable devices. Further for explanatory purposes, the blocks of the process2500are described herein as occurring in serial, or linearly. However, multiple blocks of the process2500may occur in parallel. In addition, the blocks of the process2500need not be performed in the order shown and/or one or more blocks of the process2500need not be performed and/or can be replaced by other operations. The example process2500inFIG.25discusses an implementation that initializes attributes and establishes relationships between parent and child nodes using an attribute graph.

In one or more implementations, the UI framework200initializes a set of attributes related to a hierarchy of views representing a user interface (UI), the hierarchy of views including a parent node and a child node (2510). In an example, initializing the set of attributes creates an attribute graph including respective nodes related to attributes for each of the view nodes from the hierarchy of views. Each of the nodes in the attribute graph may have links to one or more other attributes nodes to indicate a dependency between respective attributes.

In the example where the attribute graph is utilized for updating attributes, a particular attribute node from the attribute graph may be updated directly. The UI framework200updates a particular attribute from the set of attributes (2512). In an example, the particular attribute may correspond to an attribute node related to a child view node from the hierarchy of views. Based on the update to the attribute of the child view, a change to an attribute node related to a parent view may occur based on the update to the attribute of the child view.

To provide full interoperability with existing drawing frameworks (e.g., UI Kit, App Kit, Metal, etc.), the UI framework200provides an extensible renderer view system for enabling view nodes to draw themselves. In one or more implementations, each view node can convert itself into drawing commands that are compatible with a given external drawing framework.

FIG.26illustrates an example renderer view system2600for supporting interoperability with different drawing frameworks which may be executed on the electronic device110.

In one or more implementations, the renderer view system is an extensible drawing system that facilitates interoperability with external drawing frameworks. Some examples of drawing frameworks include: 1) UI Kit (iOS) that uses persistent classes modeled in a tree structure; 2) App Kit (MacOS) that also uses persistent classes modeled in a tree structure; 3) Metal (iOS & MacOS) that provides low level GPU drawing in a framebuffer, generally more difficult for a developer to code but may result in faster rendering, and sends imperative drawing commands instead of building of a hierarchy for rendering views; and/or generally any drawing framework; and 4) AR Kit which enables 3D rendering in 2D environments and for use in 2D and 3D applications. Accordingly, it is appreciated that the renderer view system2600could support any type or number of drawing frameworks and still be within the scope of the subject technology.

As illustrated inFIG.26, the renderer view system2600includes an application2610that calls functions provided by a UI framework2620(e.g., provided by the UI framework200). The UI framework2620converts the function call into a command that is compatible with a particular drawing framework provided in a render framework2630.

In one or more implementations, each node in a given view tree knows how to convert itself into a format compatible with the drawing commands from the external drawing framework. For example, operations performed in connection with a view tree structure and a node tree structure for animations, gestures, etc., eventually get drilled down into a label, image or color that knows how to draw itself, e.g. that corresponds to particular code for drawing itself.

In one or more implementations, the renderer view system2600utilizes a separate tree hierarchy for a renderer view called a render view tree. The render view tree may be a sparser tree than node tree structure described above because most views in the UI framework do not actually draw. For example, a custom view does not draw or render anything, and only creates other views that draw and render. For example, a layout view does not draw or render, and only calculates frames for the particular views that actually do draw. A render view tree may include one node for root and respective nodes for views that draw. Moreover, in an example, a render view tree is instructed to draw itself by 1) updating properties that a particular drawing framework (e.g., UI Kit or App Kit) uses, or 2) sending out rendering commands for a different framework (e.g., Metal).

FIG.27illustrates a flow diagram of an example process2700of generating a command for rendering a visual property and providing the command to an external drawing framework for performing on an electronic device110in accordance with one or more implementations. For explanatory purposes, the process2700is primarily described herein with reference to the electronic device110ofFIGS.1,2, and24, particularly with reference to components of the renderer view system2400as described above inFIG.24. However, the process2700is not limited to the electronic device110ofFIGS.1,2, and24, and one or more blocks (or operations) of the process2700may be performed by one or more other components of other suitable devices. Further for explanatory purposes, the blocks of the process2700are described herein as occurring in serial, or linearly. However, multiple blocks of the process2700may occur in parallel. In addition, the blocks of the process2700need not be performed in the order shown and/or one or more blocks of the process2700need not be performed and/or can be replaced by other operations.

The UI framework2420receives information related to a visual property of a user interface (UI), the visual property including at least one of a label, image, or color (2710). The UI framework2420determines an external drawing framework to render the visual property of the UI (2712).

Based on the determined external drawing framework, the UI framework2420generates a command for rendering the visual property, the generated command being in a format compatible with the external drawing framework (2714). The UI framework2420provides the generated command to the external drawing framework for rendering the visual property of the UI (2716).

As described above, one aspect of the present technology is the gathering and use of data available from specific and legitimate sources to improve the delivery to users of invitational content or any other content that may be of interest to them. The present disclosure contemplates that in some instances, this gathered data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data can include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records relating to a user's health or level of fitness (e.g., vital signs measurements, medication information, exercise information), date of birth, or any other personal information.

The present disclosure recognizes that the use of such personal information data, in the present technology, can be used to the benefit of users. For example, the personal information data can be used to deliver targeted content that may be of greater interest to the user in accordance with their preferences. Accordingly, use of such personal information data enables users to have greater control of the delivered content. Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure. For instance, health and fitness data may be used, in accordance with the user's preferences to provide insights into their general wellness, or may be used as positive feedback to individuals using technology to pursue wellness goals.

Therefore, although the present disclosure broadly covers use of personal information data to implement one or more various disclosed embodiments, the present disclosure also contemplates that the various embodiments can also be implemented without the need for accessing such personal information data. That is, the various embodiments of the present technology are not rendered inoperable due to the lack of all or a portion of such personal information data. For example, content can be selected and delivered to users based on aggregated non-personal information data or a bare minimum amount of personal information, such as the content being handled only on the user's device or other non-personal information available to the content delivery services.

FIG.28illustrates an electronic system2800with which one or more implementations of the subject technology may be implemented. The electronic system2800can be, and/or can be a part of, the electronic device110, and/or the server120shown inFIG.1. The electronic system2800may include various types of computer readable media and interfaces for various other types of computer readable media. The electronic system2800includes a bus2808, one or more processing unit(s)2812, a system memory2804(and/or buffer), a ROM2810, a permanent storage device2802, an input device interface2814, an output device interface2806, and one or more network interfaces2816, or subsets and variations thereof.

The bus2808collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system2800. In one or more implementations, the bus2808communicatively connects the one or more processing unit(s)2812with the ROM2810, the system memory2804, and the permanent storage device2802. From these various memory units, the one or more processing unit(s)2812retrieves instructions to execute and data to process in order to execute the processes of the subject disclosure. The one or more processing unit(s)2812can be a single processor or a multi-core processor in different implementations.

The ROM2810stores static data and instructions that are needed by the one or more processing unit(s)2812and other modules of the electronic system2800. The permanent storage device2802, on the other hand, may be a read-and-write memory device. The permanent storage device2802may be a non-volatile memory unit that stores instructions and data even when the electronic system2800is off. In one or more implementations, a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) may be used as the permanent storage device2802.

In one or more implementations, a removable storage device (such as a floppy disk, flash drive, and its corresponding disk drive) may be used as the permanent storage device2802. Like the permanent storage device2802, the system memory2804may be a read-and-write memory device. However, unlike the permanent storage device2802, the system memory2804may be a volatile read-and-write memory, such as random access memory. The system memory2804may store any of the instructions and data that one or more processing unit(s)2812may need at runtime. In one or more implementations, the processes of the subject disclosure are stored in the system memory2804, the permanent storage device2802, and/or the ROM2810. From these various memory units, the one or more processing unit(s)2812retrieves instructions to execute and data to process in order to execute the processes of one or more implementations.

The bus2808also connects to the input and output device interfaces2814and2806. The input device interface2814enables a user to communicate information and select commands to the electronic system2800. Input devices that may be used with the input device interface2814may include, for example, alphanumeric keyboards and pointing devices (also called “cursor control devices”). The output device interface2806may enable, for example, the display of images generated by electronic system2800. Output devices that may be used with the output device interface2806may include, for example, printers and display devices, such as a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a flexible display, a flat panel display, a solid state display, a projector, or any other device for outputting information. One or more implementations may include devices that function as both input and output devices, such as a touchscreen. In these implementations, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

Finally, as shown inFIG.28, the bus2808also couples the electronic system2800to one or more networks and/or to one or more network nodes, such as the electronic device110shown inFIG.1, through the one or more network interface(s)2816. In this manner, the electronic system2800can be a part of a network of computers (such as a LAN, a wide area network (“WAN”), or an Intranet, or a network of networks, such as the Internet. Any or all components of the electronic system2800can be used in conjunction with the subject disclosure.