Dynamically resizable content for electronic devices

Abstract

Provides dynamically resizable content for electronic devices. [Solution] A dynamically resizable UI view for an electronic device is disclosed. The dynamically resizable UI view may be a widget UI view. In one or more implementations, the application provides a system process with a plurality of states of the application's user interface (UI) view, and one or more transition definitions, each defining a transition between two of the plurality of states. When a user or content of the UI view triggers a change from one of the plurality of states of the UI view to another of the plurality of states, the system process can animate the change according to one or more transition definitions.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of priority of U.S. Provisional Patent Application No. 63 / 340,418, filed on May 10, 2022, entitled "Dynamically Resizeable Content for Electronic Devices", the disclosure of which is incorporated herein in its entirety.

[0002] This specification generally relates to electronic devices, for example, including dynamically resizeable content for an electronic device.

Background Art

[0003] Electronic devices often include applications that provide information for display on a user interface of an application. To access information from an application, a user typically has to unlock the electronic device, launch the application, wait for the application to launch, and navigate to the relevant section of the user interface of the application that displays the information.

Brief Description of the Drawings

[0004] The specific features of the technology of this application are set forth in the appended claims. However, for purposes of illustration, some implementations of the technology of this application are shown in the following figures.

[0005] [Figure 1] A perspective view of an exemplary electronic device capable of implementing various aspects of the subject technology.

[0006] [Figure 2] Shows a dynamically resizeable user interface (UI) view in a first state according to one or more implementations.

[0007] [Figure 3]This shows a dynamically resizable UI view in a second state, implemented in one or more ways.

[0008] [Figure 4] This shows a dynamically resizable UI view in a third state, implemented in one or more different ways.

[0009] [Figure 5] This shows a block diagram of an exemplary electronic device that retrieves application state information of an application UI view using one or more implementation forms.

[0010] [Figure 6] This shows a block diagram of an exemplary electronic device that generates an application UI view for displaying a first state, using one or more implementation forms.

[0011] [Figure 7] This shows a block diagram of an exemplary electronic device that animates transitions between states of an application UI view for display purposes, using one or more implementations.

[0012] [Figure 8] This diagram shows an exemplary process flow diagram for providing state transitions for a user interface view, depending on the aspect of the subject technology.

[0013] [Figure 9] This diagram illustrates an exemplary process for operating an application in an electronic device to provide dynamic state transitions of a user interface view, depending on the aspect of the subject technology.

[0014] [Figure 10] This figure shows an exemplary computing device that can implement aspects of the subject technology. [Modes for carrying out the invention]

[0015] The detailed description below is intended to describe various configurations of the present technology and is not intended to represent only one configuration in which the present technology can be carried out. The accompanying drawings are incorporated herein and constitute part of the detailed description. The detailed description includes certain details to provide a complete understanding of the subject technology. However, the present technology is not limited to the certain details shown herein and can be carried out using one or more other implementations. In one or more implementations, the structure and components are shown in block diagram form to avoid obscuring the concepts of the present technology.

[0016] In one or more implementations, the application provides a system process (or a user interface display process separate from the operating system) with multiple states for the application's user interface (UI) view, and one or more transition definitions, each defining a transition between two of the multiple states. Each of the multiple states can specify a display element, the size of the display element, and an identifier for the display element. When a user or content in the UI view triggers a change from one of the multiple states of the UI view to another of the multiple states, the system process animates the change according to one or more transition definitions. In one or more implementations, the application provides system-animated transitions between application UI states and application data to be displayed in the rendered UI view.

[0017] Figure 1 shows an exemplary electronic device capable of displaying content and / or a dynamically resizable UI view. In the example of Figure 1, the electronic device 100 is portable and implemented using a housing small enough to be carried by a user (for example, the electronic device 100 in Figure 1 could be a handheld electronic device such as a tablet computer, smartphone, smartwatch, or laptop). As shown in Figure 1, the electronic device 100 includes a display such as a display 110 mounted on the front of a housing 106. The electronic device 100 includes one or more input / output devices such as a touchscreen incorporated into the display 110, buttons or switches such as a button 104, and / or other input / output components located above or behind the display 110, or above or behind other parts of the housing 106. The display 110 and / or the housing 106 include one or more openings for housing a button 104, a speaker, a light source, or a camera.

[0018] In the example shown in Figure 1, the housing 106 includes an opening 108 on the bottom side wall of the housing 106. One or more openings 108 form ports for audio components. The housing 106, sometimes referred to as the case, may be formed from plastic, glass, ceramic, fiber composite, metal (e.g., stainless steel, aluminum, etc.), other suitable materials, or any two or more combinations of these materials.

[0019] The configuration of the electronic device 100 in FIG. 1 is merely exemplary. In other implementations, the electronic device 100 can be a computer such as a computer incorporated in a display such as a computer monitor, a laptop computer, a smartwatch, a pendant device, or other wearable or small device such as other wearable devices, a media player, a game device, a navigation device, a computer monitor, a television, headphones, or other electronic devices having a display. In some implementations, the electronic device 100 can be provided in the form of a wearable device such as a smartwatch. In one or more implementations, the housing 106 can include one or more interfaces for mechanically coupling the housing 106 to a strap or other structure for fixing the housing 106 to the wearer.

[0020] FIG. 2 shows an example of a dynamically resizable UI view 205 displayed by the electronic device 100. In some embodiments, the UI view 205 is a system UI view (e.g., a view provided by the operating system of the electronic device 100). In one or more implementations, the UI view 205 can be a UI view for widgets. As shown in FIG. 2, the UI view 205 is displayed by the lock screen 250 of the electronic device. However, in some embodiments, the electronic device is configured to display a dynamically resizable UI view on any one of a lock screen (e.g., the lock screen 250), a home screen, etc.

[0021] In some embodiments, the UI view 205 is a UI view displayed by a system process.

[0022] In some implementations, the system process generates the UI view 205 according to parameters provided by an application. In some implementations, the system process is an application framework that receives configuration data associated with an application and generates the UI view 205 according to the configuration data. In some implementations, the configuration data is included in a template data structure. In some implementations, the configuration data is defined using a declarative syntax.

[0023] In some implementations, the UI view includes at least one data element (e.g., the first element 209 or the second element 211) associated with system data (e.g., a battery indicator, a signal strength indicator, or a timer). In some implementations, the UI view includes at least one data element (e.g., the first element 209 or the second element 211) associated with application data (e.g., fitness tracking data, a sports score, etc.).

[0024] As shown in Figure 2, the lock screen 250 is displayed by the electronic device 100 while the electronic device 100 is in a locked state. For example, the electronic device 100 may include a housing 106 and a display 110 that displays the lock screen 250. In the example in Figure 2, the lock screen 250 includes an unlock feature 219. The unlock feature 219 may be selectable by the user of the electronic device 100 to initiate an unlock procedure (e.g., a procedure in which the user provides authentication information and / or the device obtains authentication information in order to unlock the electronic device). In the example in Figure 2, the lock screen 250 also includes a lock indicator 201 that indicates the electronic device is locked. In one or more implementations, when authentication information is received by the electronic device 100 and before providing additional interaction for the user to leave the lock screen 250 (e.g., to another screen such as the home screen or the user interface of an application or system process), the lock indicator 201 may indicate that the electronic device 100 is unlocked for a period of time while the lock screen 250 remains displayed.

[0025] In the example in Figure 2, the lock screen 250 also includes a carrier indicator 212, a signal strength indicator 214, a battery indicator 216, and a functional element 218 (a display element that can be used to access restricted functions of the electronic device 100, such as a light source function or a camera function). In some implementations, one or more of the carrier indicator 212, signal strength indicator 214, battery indicator 216, and functional element 218 are displayed within a dynamically resizable UI view. As shown in Figure 2, the lock screen 250 may also include a background 206 (e.g., an image or a pattern of colors), a dynamically resizable UI view 205 (e.g., a UI view in one or more states defined by a corresponding application or system process installed on the electronic device 100), and may include publicly available data such as time 208 and date 210. In the example in Figure 2, the electronic device 100 includes one or more sensing components 204 (e.g., a camera and / or an infrared sensor or depth sensor) that can be used to obtain biometric information from the user of the electronic device. In other examples, the electronic device 100 may obtain biometric or non-biometric (e.g., passcode) authentication information from a touchscreen integrated into the display 110, or from other sensors and / or input components such as a keyboard or other input interface of the electronic device 100.

[0026] In the example in Figure 2, UI view 205 includes a background 207 within a boundary 215, a first element 209, and a second element 211. However, in other examples, UI view 205 may contain any number of elements (e.g., 209). As shown, the first element 209 may contain a display of data 221. The second element 211 may contain a display of data 223. In the example in Figure 2, UI view 205 is a bounded UI view with a boundary 215 that sets UI view 205 apart from background 206. In one or more other implementations, UI view 205 may be an unbounded display element. In the unbounded state of UI view 205, the first element 209 and / or the second element 211 and / or their respective associated data 221 and data 223 may be displayed to appear as integrated content with background 206.

[0027] In some variations, one or more pieces of data (e.g., data 221 and / or data 223) displayed by a UI view (e.g., UI view 205) are retrieved by the electronic device from an application running on the electronic device. In some variations, one or more pieces of data (e.g., data 221 and / or data 223) displayed by a UI view (e.g., 205) are retrieved by the electronic device from a remote server associated with the UI view (e.g., remote to device 100).

[0028] In one exemplary example, UI view 205 may contain a single graphical display element (e.g., first element 209) for the timer value of the countdown timer. In various implementations, the data displayed by the single graphical display element may be obtained by the electronic device from a timer application running on the electronic device.

[0029] In another exemplary example, UI view 205 may include one or more graphical display elements (e.g., a first element 209 and / or a second element 211) of a sports-related application installed on the electronic device 100. The sports-related application may be inactive when UI view 205 is displayed. In this example, data 221 may be the current score of a first individual or team currently participating in a competitive sports event (e.g., a basketball game, a football game, a soccer game, a hockey game, a golf match, a chess tournament, a rugby game, a tennis match, a fencing tournament, a bowling match, a curling match, etc.). In this example, data 223 may be the current score of a second individual or team currently participating in the sports event (e.g., against the first individual or team). In various implementations, data 221 and data 223 may be retrieved by the electronic device from a server associated with the sports-related application while the sports-related application on the electronic device is inactive on the electronic device 100. In this way, UI view 205 can display dynamic (e.g., current real-time) data without requiring the sports-related application to be running.

[0030] Examples of sports-related applications and sporting events are for illustrative purposes only. In another exemplary example, a user of electronic device 100 may be waiting for or riding in a rideshare vehicle associated with a rideshare application installed on electronic device 100. The user can view the location, estimated time of arrival, estimated cost, or other dynamic data of the rideshare vehicle in the full user interface of the rideshare application (for example, a user interface generated by the rideshare application rather than by a system process). In this exemplary use case, when a UI view 205 (generated by a system process) is displayed instead of the full user interface of the rideshare application (generated by the application), the UI view 205 may display some or all of the data associated with the rideshare vehicle. For example, a first element 209 may display data 221 corresponding to the current location of the rideshare vehicle, and a second element 211 may display data 223 corresponding to the estimated time of arrival of the rideshare vehicle.

[0031] Generally, a UI view 205 may be a system-generated system-resizable UI view (e.g., a system-generated notification, status bar UI view, toolbar UI view, system tray view, taskbar view, or other system-generated UI view that displays system-generated data), or a system-generated application-specific resizable UI view that is separate from the application's complete (application-generated) UI and can be displayed while the application's complete UI is inactive (e.g., minimized or closed). For example, the application's complete UI may be resizable by providing the application with user-provided resizing input for the application to modify the complete UI. In contrast, a UI view 205 may be resizable by a system process of the electronic device 100 (e.g., by animating the resizing and / or updating the state of the UI view based on state information, transition information, and / or trigger information previously received from the application) without providing the application with any user input information.

[0032] In the example in Figure 2, UI view 205 is displayed in a first state. In this first state, UI view 205 has a first size and includes a background 207, a border 215, a first element 209, and a second element 211. The first state may be defined by the underlying application of UI view 205. For example, the first state may be defined by the underlying application before the electronic device displays UI view 205. In one or more implementations, the first state shown in the example in Figure 2 may be one of several states of UI view 205 defined by the underlying application.

[0033] For example, Figure 3 shows an example in which the electronic device 100 displays the UI view 205 in a second state, which is different from the first state shown in Figure 2. In the example in Figure 3, the UI view 205 is in the second state. As shown in the example in Figure 3, in the second state, the UI view 205 has a second size that is larger than the first size of the UI view 205 in the first state in Figure 2. In the example in Figure 3, the UI view 205 contains the same first element 209 and second element 211 (displaying individual first data 221 and second data 223), but the first element 209 and second element 211 have a larger size than the first element 209 and second element 211 in the first state of the UI view 205 in Figure 2. The relative sizes of UI view 205, the first element 209, and the second element 211 may be defined by the underlying application before displaying UI view 205 in the first or second state, for example, by providing state definitions for the first and second states to the system process of the electronic device 100.

[0034] In the example in Figure 3, UI view 205 also includes a third element 300 that is not included in UI view 205 in the first state of Figure 2. As shown, the third element 300 includes data 301. Data 301 may include static or dynamic data. For example, static data may include application-specific data (e.g., a logo) that is unrelated to the events to which data 221 and data 223 are associated.

[0035] In one or more implementations, the UI view 205 can transition from the first state shown in Figure 2 to the second state shown in Figure 3, depending on user interaction with the UI view 205 in the first state shown in Figure 2. For example, when the UI view 205 is displayed in the first state shown in Figure 2, the user of the electronic device 100 can provide tap, swipe, or unpinch input at or near the location of the UI view 205 to cause the UI view 205 to enlarge in size. For example, the user may want to view more information about the sporting event than just the score displayed in the first state shown in Figure 2, or may want to view a more graphically detailed display of the sporting event score.

[0036] In one or more implementations, the UI view 205 may also, or alternatively, transition from a first state shown in Figure 2 to a second state shown in Figure 3 in response to a change in data associated with the UI view 205. For example, if the UI view 205 is displaying the score of a sporting event while in the first state of Figure 2, the UI view 205 may (e.g., temporarily) expand to the second state of Figure 3 when an individual or team participating in the sporting event scores. In this example, the data 301 of the third element 300 may include a notification of a score update (e.g., including the name of the individual or team that scored). In one or more implementations, the UI view 205 may be configured by its underlying application to return to the first state of Figure 2 after a period of time following the display of the notification with the third element 300, or to remain in the second state until a new trigger causes a change in state.

[0037] In one or more implementations, the underlying application of the electronic device 100 and / or the UI view 205 may configure one or more triggers (e.g., user interaction, data update, and / or movement or modification of other content) in the system process of the electronic device 100 that cause the UI view 205 to transition from the first state in Figure 2 to the second state in Figure 3 (e.g., without interaction with the underlying application to detect the trigger, or during the transition). For example, the underlying application may provide a state definition that includes trigger definitions for various triggers between various state combinations and definitions of states resulting from various triggers before the display of the UI view 205 (e.g., before the underlying application is deactivated).

[0038] In one or more implementations, in addition to providing state definitions for one or more states of a UI view such as UI view 205 (including, for example, the first state in Figure 2 and the second state in Figure 3), the underlying application may also provide one or more transition definitions to the system process of the electronic device 100. In one or more implementations, each transition definition provided by the application to the system process can define a transition between two of the multiple states of UI view 205. For example, the application underlying UI view 205 can provide the system process of the electronic device 100 with transition definitions that define various ways of displaying the transition from the first state in Figure 2 to the second state in Figure 3.

[0039] In one or more implementations, a transition definition can define animation for the transition of UI view 205 from a first state in Figure 2 to a second state in Figure 3. The transition definition can also define animation for the transition of the first element 209 to grow from the size of the first element 209 in the first state to the size of the first element 209 in the second state. The transition definition can also define animation for the addition of a third element 300 as UI view 205 grows to include room for the third element 300. For example, the transition definition can define animation for the third element to appear to fade in, slide in, or freeze out of a particled view as the size of the boundary 215 expands during the transition. As another example, a transition definition can define the rate at which the boundary 215 of the UI view 205 expands, and / or whether the boundary 215 expands to the size defined for the boundary 215 in the second state definition and stops expanding, or whether the boundary 215 expands beyond the size defined for the boundary 215 in the second state definition and snaps back to the size defined for the boundary 215 in the second state definition.

[0040] The exemplary states of the UI view 205 in Figures 2 and 3 are just two of many different states of the UI view 205 that can be defined by the underlying application in the electronic device 100.

[0041] For example, Figure 4 shows an example of a third state of UI view 205. In the example in Figure 4, the size of the boundary 215 of UI view 205 is smaller than the size of the boundary 215 of UI view 205 in the first state in Figure 2 and the second state in Figure 3. In this example, the amount of data displayed within UI view 205 in the third state is also reduced compared to the amount of data displayed within UI view 205 in the first and second states. In this example, UI view 205 does not include the second element 211 or the third element 300 that are included in the first and second states shown in Figures 2 and 3. In one or more implementations, the data 221 of the first element 209 of UI view 205 in Figure 4 may be a countdown timer generated by a system process, system data (e.g., battery life, signal strength, etc.), calendar data, etc.

[0042] In one or more implementations, the system process or underlying application of the UI view 205 can define a third state, as shown in Figure 4, that includes only the first element 209 and its data 221, and can also define transition definitions between the first state in Figure 2 and the third state in Figure 4, between the second state in Figure 3 and the third state in Figure 4, and / or vice versa. For example, the underlying application can define an animation for the removal of the second element 211 and its dynamic data 223 when the UI view 205 transitions from the first state in Figure 2 to the third state in Figure 4, or from the second state in Figure 3 to the third state in Figure 4. For example, the animation in the defined transition, once achieved by the system process, can cause the second element 211 and / or the third element 300 to fade out, blur out, or particle out and become invisible as the boundary 215 of the UI view 205 shrinks. In one or more implementations, the system process of the electronic device may also animate the disappearance or appearance of the boundary 215 during state transitions between the unbounded state and the bounded state of the UI view 205.

[0043] In one or more implementations, the underlying application for the UI view 205 may also define trigger definitions that define triggers to transition the UI view 205 from the third state in Figure 4 to the first state in Figure 2, from the third state in Figure 4 to the second state in Figure 3, from the first state in Figure 2 to the third state in Figure 4, and / or from the first state in Figure 2 to the third state in Figure 4. As discussed herein, the underlying application for the UI view 205 may provide the system process of the electronic device 100 with state definitions, trigger definitions, and / or transition definitions for various transitions between the various states of the UI view 205 before the UI view 205 is displayed. In one or more implementations, trigger definitions that define triggers that cause transitions between multiple states of another UI view, such as the UI view 205, may be incorporated into the transition definitions of the multiple states of the UI view, may be incorporated into the state definitions, and / or may be defined by the system process of the electronic device 100.

[0044] In the examples in Figures 2-4, UI view 205 is shown as an example of a screen that can display a resizable UI view, displayed on the lock screen 250 of electronic device 100. In an implementation where UI view 205 is displayed on the lock screen and is resizable, UI view 205 can offer various technical advantages. For example, when the device is locked, some devices can encrypt the entire system, including application data associated with applications installed on the electronic device. In order for a user to regain access to the data and / or functions of the electronic device, the user often needs to provide authentication information that proves to the device that the user is an authorized user. For example, authentication information can include a passcode entered by the user, or biometric information such as fingerprints, voiceprints, or facial features.

[0045] Following a lock event on an electronic device, the electronic device may display a lock screen. While the electronic device is locked and the lock screen is displayed, the user may provide authentication credentials, and / or the device may automatically obtain these credentials (for example, by acquiring image data or depth data associated with the user's finger or face), and if the credentials indicate that the user is an authorized user of the device, the device may unlock.

[0046] In one or more use cases, a user of an electronic device may use an application installed on the device to view or otherwise monitor ongoing events in the physical world. For example, a sports-related application may be used to monitor or track the scores of a sporting event; a ride-sharing application may be used to monitor the location of a ride-sharing vehicle before or during a ride; or a delivery application may be used to monitor the status of an order and / or the location of a delivery vehicle. Another example is the use of a nature-related application to monitor natural phenomena such as tides, lunar phases, and weather.

[0047] In one or more implementations, for example, to prevent unauthorized access to the electronic device and / or to manage the device's power usage, an electronic device may be configured to automatically lock after a predetermined amount of time without receiving active user input. However, in many use cases, a user may want to continue monitoring physical world events that an application was using to view or monitor before locking the device. Typically, the user provides credentials and navigates from the device's lock screen back to the application user interface (UI) previously used to view or monitor the event. However, this can be a time-consuming and inefficient way for the user to continue monitoring physical world events (including in terms of device power, components, and processing resources). Therefore, it may be desirable to be able to display a resizable UI view containing certain types of data (e.g., dynamic data such as system data, time-dependent data, or data associated with physical world events) on the electronic device's lock screen. In this way, the user may be provided with the ability to continue using the electronic device to monitor physical world events without expending user and device resources on repeated authentication and unlocking procedures.

[0048] However, it can be difficult to retrieve application-associated data and display it on the electronic device's lock screen without allowing the application to access data and / or resources that are locked when the device is locked. For example, it may be desirable to display application-associated data while preventing the application itself from running on the electronic device and / or receiving information about user interaction with the electronic device's lock screen (e.g., information that is normally protected by the device until the user provides authentication credentials and attempts to interact with the application).

[0049] Aspects of the subject technology can provide a resizable UI view, such as the UI view 205 shown in Figures 2-4, in a power-efficient manner while an electronic device is locked, while maintaining user privacy and / or device security. For example, by providing state definitions, trigger definitions, and / or transition definitions to the system process of the electronic device 100 before the electronic device 100 enters a locked state, the UI view 205 can be displayed on the lock screen 250 in a manner that appears to respond to user interactions, data triggers, and / or other content on the lock screen 250, without allowing the underlying application to receive information about user interactions with the electronic device or other content displayed on the lock screen while the electronic device 100 is locked. In this way, the privacy that a user might expect when their device is locked can be maintained and protected.

[0050] While various examples of the UI view 205 being displayed on the lock screen of an electronic device, such as the lock screen 250 in Figures 2 to 4, are described herein, the UI view 205 may also be displayed on other screens of the electronic device, such as the home screen (e.g., while the electronic device is unlocked), and may be updated and / or animated using state definitions, transition definitions, and / or trigger definitions from the underlying application. In one or more implementations, aspects of the subject technology can provide a resizable UI view on the home screen in a power-efficient and resource-efficient manner (e.g., with respect to processing and / or memory resources), for example, by enabling a system process to handle the display manner of the application's UI view (e.g., resizing animation) while the application and / or the full UI of the application is inactive on the electronic device. For example, providing state definitions, trigger definitions, and / or transition definitions to the system process of the electronic device 100 before the electronic device 100 displays the UI view 205, regardless of whether the UI view 205 is displayed on the lock screen, home screen, or any other screen of the electronic device 100, can enable the UI view 205 to be displayed in a power and computing resource (e.g., with respect to processing and / or memory resources) efficient manner by dynamically displaying the UI view 205 across multiple states without requiring the operation of the underlying application.

[0051] In the various implementations described herein, whether the resizable UI view is displayed on the lock screen or home screen of an electronic device, in addition to the aforementioned advantages of privacy, power efficiency, and / or computing resource efficiency, the aspects of the subject technology can also offer advantages in terms of developer and user efficiency. For example, an application developer can provide the system process of an electronic device with information that enables the system process to animate aspects of the UI view for application information without the developer having to write or provide code for the animation. As another example, if a user wishes to view more or less information within a UI view, the user is provided with the ability to directly interact with the UI view (e.g., by clicking, tapping, or pinching) to cause the UI view to resize, thereby increasing or decreasing the amount of data displayed (rather than, for example, the user editing device settings to create a new fixed-size UI view and replacing the current fixed-size UI view). As yet another example, whether displayed on the lock screen or home screen of an electronic device, the resizable UI views disclosed herein can enable the UI view to automatically resize in response to data triggers. In this way, users can be provided with additional information when it is relevant to them, in ways that may be difficult or impossible with fixed-size UI views.

[0052] Further details of aspects of the subject's technology that can be used to display, update, and / or resize UI views on various screens, including the lock screen and home screen, are described below in relation to Figures 5 to 9.

[0053] Figure 5 shows an exemplary architecture that may be implemented by the electronic device 100 in one or more implementation forms of the subject technology. For illustrative purposes, the portion of the architecture in Figure 5 is described as being implemented by the electronic device 100 in Figure 1, including the processor and / or memory of the electronic device. However, suitable portions of the architecture may be implemented by any other electronic device. However, not all of the depicted components are to be used in all implementation forms, and one or more implementation forms may include additional or different components than those shown in the figure. Variations in the configuration and type of components can be made without departing from the spirit or scope of the claims set forth herein. Additional components, different components, or fewer components may be provided.

[0054] Various parts of the architecture in Figure 5 can be implemented in software or hardware, including by one or more processors and memory devices containing instructions that, when executed by the processors, cause the processors to perform the operations described herein. In the example in Figure 5, the electronic device 100 includes hardware components such as a display 110 and memory 502. In this example, the electronic device 100 also includes one or more logical processes, such as a system process 500, and / or one or more applications 506. For example, the system process 500 and / or one or more applications 506 may be logical processes executed from memory 502 by one or more processors of the electronic device 100. The system process 500 may be a process defined, for example, in hardware and / or as part of the operating system of the electronic device 100.

[0055] In the example in Figure 5, the electronic device 100 (e.g., memory 502) stores code for three applications 506 (e.g., "App 1", "App 2", and "App 3"). However, this is merely illustrative, and it is understood that the electronic device 100 can store code for one application 506, two applications 506, four or more applications 506, or generally any number of applications 506. The applications 506 may, for example, have been previously downloaded to and installed on the electronic device 100. One or more of the applications 506 may be associated with a UI view that displays data that may be dynamic periodically, occasionally, or continuously (e.g., application-specific information, system status information, and / or information associated with physical world events as described herein) while the application 506 and / or the full user interface of the application 506 are inactive.

[0056] For example, as shown in Figure 5, one or more applications 506 can provide one or more state definitions for UI views to the system process 500. In this example, app 1 provides one or more app 1 state definitions to the system process 500 for each of the one or more states of the corresponding UI views of app 1. As shown in Figure 5, the system process 500 can store the state definitions provided by app 1 in memory 502 (for example, in an archive of state definitions) in relation to app 1.

[0057] For the purposes of this discussion, the UI view 205 discussed herein in relation to Figures 2 to 4 may be a UI view for an application 506 designated as App 1 in Figures 5 to 7 (for example, App 1 may be the underlying application for UI view 205). As shown in Figure 5, one or more additional applications may also provide the system process 500 with state definitions for their respective UI views to be stored in memory 502 in relation to the application (for example, App 2 may provide the App 2 state definition, and App 3 may provide the system process 500 with the App 3 state definition to be stored in memory 502 in relation to their respective applications 506).

[0058] In the example in Figure 5, the App 1 state definition provided from App 1 to the system process 500 includes information used by the system process 500 to display the UI view 205 in Figures 2, 3, and 4 in the respective first, second, and third states shown therein. For example, as shown in Figure 5, the App 1 state definition may include definitions for the first state in Figure 2 (e.g., state 1), the second state in Figure 3 (e.g., state 2), and the third state in Figure 4 (e.g., state 3) for the first UI view (e.g., UI view 1 corresponding to UI view 205).

[0059] As shown, the state definition of UI view 1 (e.g., UI view 205) may include the definition of one or more UI elements of the UI view, the definition of one or more UI state transitions of the UI view, the definition of the size of one or more UI elements of the UI view, the identifier of one or more UI elements of the UI view, the size of the UI view (e.g., the size of UI view 205), and / or the layout of the UI view (e.g., the layout of the UI elements of UI view 205 relative to other UI elements of the UI view, borders, background, etc.). For example, for a first state of UI view 205, system process 500 may receive the definition of a first element 209 (e.g., UI element 1), the definition of a second element 211 (e.g., UI element 2), the definition of a transition of the first element 209 from one state to another (e.g., state transition 1), the definition of a transition of the second element 211 from one state to another (e.g., state transition 2), the size of the first element 209 in the first state (e.g., UI element 1 size), the size of the second element 211 in the first state (e.g., UI element 2 size), the identifier of the first element 209 (e.g., UI element 1 identifier), the identifier of the second element 211 (e.g., UI element 2 identifier), the size of the boundary 215 of UI view 205 (e.g., UI view size), and / or the layout of UI view 205 (e.g., UI view layout), and memory 502 may store them. The UI view layout can define the locations of the first element 209 and the second element 211 (for example) within and relative to the boundary 215, and / or relative to each other and / or other elements of the UI view.

[0060] UI element 1 can define graphical objects (e.g., rectangular objects containing text, rectangular objects containing images, circular objects containing text or images, etc.) and / or data (e.g., data 221 containing the source of data 221), the data update rate, and / or the color, background, and / or one or more other visual aspects of the first element 209 for display within the graphical objects of the first element 209. UI element 2 can define graphical objects (e.g., rectangular objects containing text, rectangular objects containing images, circular objects containing text or images, etc.) and / or data (e.g., data 223 containing the source of data 223), the data update rate, and / or the color, background, and / or one or more other visual aspects of the second element 211. State transition 1 can define, for example, the animation type for the animation of the transition of a first element 209 from a first state to another state (e.g., blur in, blur out, translation in, translation out, fade in, fade out, particle effect, snap, balloon, rotate, spin, flash, etc.). State transition 2 can define, for example, the animation type for the animation of the transition of a second element 211 from a first state to another state (e.g., particle effect, snap, balloon, rotate, spin, flash, etc.). In one or more implementation forms, if the application does not provide transition definitions for one or more elements, the system process 500 can store a default animation or determine the transition definition based on the content of the UI view.

[0061] In the example in Figure 5, for the second state of UI view 205 (for example, UI view 1 of app 1), the state definition includes information defining a third element 300 (for example, UI element 3, UI element 3 size, UI element 3 identifier) ​​in addition to the state information of the UI view and the first and second elements in the second state. In this example, state transition 1 can define an animation for the transition of the first element 209 from the second state to another state (for example, the first or third state), state transition 2 can define an animation for the transition of the second element 211 from the second state to another state (for example, the first or third state), and state transition 3 can define an animation for the transition of the third element 300 from the second state to another state. In this example, the size of UI element 1 in the state definition of state 2 may be larger than the size of UI element 1 in the state definition of state 1, the size of UI element 2 in the state definition of state 2 may be larger than the size of UI element 2 in the state definition of state 1, and the size of the UI view in the state definition of state 2 may be larger than the size of the UI view in the state definition of state 1 (for example, as shown in Figures 2 and 3). In this example, the UI view can define the layout of the location of the third element 300 (for example, above in the example of Figure 3) relative to the first element 209 and the second element 211.

[0062] In one or more implementations, transition definitions such as state transition 1 and state transition 2 may include a single transition definition for a UI element that can be applied to any transition to or from that UI element in a state transition, or they may include multiple transition definitions for specific pairs of states and / or specific transition directions between pairs of states. In one or more implementations, transition definitions may be defined in one way, reverse transitions may use the reverse of the defined transition, or transition definitions may be defined separately for transitions of a UI element to a specific state and transitions of a UI element from a specific state.

[0063] In the example in Figure 5, the state definition of the third state in Figure 4 (e.g., state 3) includes the definition of a fourth element (e.g., UI element 4, which may be the same as the first element 209 as in the example in Figure 4, or may be different from the UI elements included in states 1 and 2), the definition of an animation for the transition of the fourth element from the third state to another state (e.g., to the second state or the first state) (e.g., state transition 4), the definition of the fourth element in the third state (e.g., UI element 4 size), the identifier of the fourth element (e.g., UI element 4 identifier), the definition of the size of the UI view 205 in the third state (e.g., UI view size, such as the size of the boundary 215 or the boundary of the UI view), and the definition of the layout of the fourth element (e.g., UI view layout, relative to the boundary 215). In this example, state transition 4 can define an animation for the transition of the fourth element (e.g., the first element 209 or another different UI element) from the third state to the first state, or from the third state to the second state. In this example, the size of UI element 4 in the state definition of state 3 may be smaller than the size of UI element 1 in the state definition of state 1 and the size of UI element 1 in the state definition of state 2, and the size of the UI view in the state definition of state 3 may be smaller than the size of the UI view in the state definitions of state 1 and state 2 (for example, as shown in Figures 2 to 4).

[0064] In the example in Figure 5, only the contents of the App 1 state definition for UI view 1 (e.g., UI view 205) are visible. However, the system process 500 can receive state definitions for additional states of UI view 1, additional states of other UI views associated with the same application 506, and / or state definitions for one or more other UI views associated with other applications (e.g., App 2, App 3, etc.), and / or memory 502 can store them.

[0065] In one or more implementations, the state definitions shown in Figure 5 (e.g., App 1 state definition(s), App 2 state definition(s), and App 3 state definition(s)) may include all of the state definition information shown in Figure 5 (e.g., including transition definitions between various states and / or trigger definitions for triggering transitions). In one or more other implementations, transition definitions and / or trigger definitions may be provided to the system process 500 from application 506 separately from the state definitions shown in Figure 5 (e.g., App 1 state definition(s), App 2 state definition(s), and App 3 state definition(s)). In one or more implementations, transition definitions may include trigger definitions. In one or more implementations, state definitions may include trigger definitions. In one or more implementations, trigger definitions may be determined by the system process 500.

[0066] In one or more implementations, application 506 may provide state definitions and transition definitions to system process 500 via templates (e.g., a single template or multiple templates may be used). In one or more implementations, application 506 may provide state definitions and transition definitions to system process 500 via an application programming interface (API). In one or more implementations, application 506 may provide state definitions and transition definitions to system process 500 in template form via a file system (e.g., application 506 may store state definitions and / or transition definitions), and may store templates in known directories that are parsed by system process 500 (e.g., definitions may be stored as resource files for the application). In one or more implementations, application 506 can provide state definitions and transition definitions to system process 500 by a combination of one or more templates and one or more API calls (e.g., state definition via template and transition definition via API, state definition via template and transition definition via template, state definition via API and transition definition via API, or state definition via API and transition definition via template). In one or more implementations, a template may have a format that can be consumed by system process 500 to render at least one UI view (e.g., UI view 205) according to the information contained in the template.

[0067] The provision of state definitions shown in Figure 5 may occur before the corresponding UI view (in which the state definition defines one or more states) is displayed, and as a result, the system process 500 of the electronic device 100 can render data, as well as the corresponding graphics having the layout, size, and / or other visual characteristics of the UI view, in any of the various states defined in the state definition for at least a certain period of time while the application itself is inactive.

[0068] For example, Figure 6 shows the operation of the electronic device 100 that may be executed after the state definition is provided from the application 506 to the system process 500 and stored in memory 502. For example, the operation shown in Figure 6 may be executed while the electronic device 100 is in a locked state and while the lock screen 250 of the electronic device 100 is displayed on the display 110 of the electronic device 100.

[0069] For example, as shown in Figure 6, the application 506 of the electronic device 100 may be inactive while the system process 500 renders the UI view of UI view 205 for display on the display 110 of the electronic device 100. In the example in Figure 6, the system process 500 retrieves from memory 502 a state definition previously provided by app 1 for state 1 of UI view 1 of app 1, and uses the retrieved state definition to render the app 1 rendered UI view for that state. The system process 500 provides the display 110 with the app 1 rendered UI view for display as UI view 205 (for example, as in the example in Figure 2).

[0070] As shown in Figure 6, the system process 500 can also receive app 1 data corresponding to app 1. The system process 500 may include some or all of the app 1 data in the UI view rendered for app 1. For example, the app 1 data may include dynamic data. For example, the app 1 data may include data 221 and data 223 in Figure 2. The app 1 data may be received from a server associated with app 1, which is remote from app 1 and / or the electronic device 100. For example, in, or in, a state definition(s) provided to the system process 500 by application 506, application 506 may provide one or more links to communication channels for system process access to app 1 data. For example, the system process 500 may use one or more links to subscribe to one or more publishing channels from which application 506 publishes application-related dynamic data. The publishing channels may be hosted by one or more servers associated with application 506. In this way, the system process 500 can receive app 1 data from the server associated with app 1 while app 1 is inactive on the electronic device. For example, App 1 data may include score data for an ongoing sports event from a server associated with a sports-related application installed on electronic device 100, or location data for a rideshare vehicle from a rideshare server associated with a rideshare application installed on electronic device 100, or location data for a delivery vehicle associated with a delivery application installed on electronic device 100. In some implementations, the data is data stored on device 100 (e.g., in memory, in a non-volatile storage device, in one or more hardware registers, etc.). In some implementations, the data is data generated by electronic device 100 (e.g., system process 500).For example, in a use case where UI view 205 displays system data (e.g., battery information, timers, signal strength information, or other data not provided by the application), a system process can generate the data displayed in UI view 205.

[0071] In one or more other implementations, some or all of the app 1 data may be received from app 1 before and / or during the display of the UI view rendered by app 1. For example, one or more of the applications 506 may also provide separate data extensions. Data extensions can be lightweight data providers that allow data from an application 506 to be updated without directly querying the associated application 506, thereby avoiding the computationally expensive wake-up or startup of the application 506 to retrieve the updated data for display by the graphical elements.

[0072] In the example in Figure 6, the rendered UI view of App 1 (e.g., rendered UI view 205) is displayed by the system process 500 in a single state (e.g., one of the states shown in Figures 2, 3, or 4). Figure 7 shows exemplary operation of the electronic device 100 for rendering transitions between two states of UI view 205 without the involvement of the underlying application App 1 (e.g., without waking or otherwise operating). As shown in Figure 7, while App 1 is inactive, the system process 500 can receive triggers to transition from one state (e.g., state 1) to another state of UI view 1 (e.g., UI view 205). For example, the trigger may be received through the user interface of the electronic device 100, such as by receiving user interaction with the rendered UI view of state 1 of App 1 displayed using the touch-sensitive elements of the display 110. As another example, the trigger may be a data-driven trigger corresponding to an update of App 1 data (e.g., when an individual or team scores in a sporting event, or when a rideshare vehicle arrives at a pickup location or destination). In response to a trigger, the system process 500 can obtain one or more transition definitions for transitions from one state to another, and can animate the transitions on the display 110 according to the transition definitions. For example, as shown in Figure 7, the system process 500 can generate an animated UI state transition rendered for app 1 according to the transition definitions and provide the animated UI state transition rendered for app 1 to the display 110 for display.

[0073] As an example, system process 500 can receive an indication of an update to the score of a sports event in app 1 data. In response to the score update indication, system process 500 can obtain state transition 1 and state transition 2 from state 1 definition of UI view 1 of app 1, and based on the obtained state transition 1 and state transition 2 definitions, can generate an animated UI state transition rendered by app 1 from state 1 to state 2. The animated UI state transition rendered by app 1 can include one or more animations over time of one or more elements of the UI view. For example, the animated UI state transition rendered by app 1 may include an animation over time of a first element 209 and an animation over time of a second element 211, based on the individual state transition 1 and state transition 2 definitions. The animated UI state transition rendered by app 1 may also include an animation of the introduction of a third element 300 in the UI view over time (based on, for example, state transition 3 and / or other transition definition information previously received from app 1), and / or an animation over time of the entire UI view 1 during the transition.

[0074] In one or more implementations, when a transition from one state to another is triggered in the system process 500 (for example, by user interaction with the UI view 205 or another element on the screen on which the UI view 205 is displayed, by a data trigger, or by the movement or modification of another element on the screen on which the UI view 205 is displayed), the system process 500 includes elements that are included in both the current state of the UI view 205 and the target state of the UI view 205 (for example, the first element in the example of the transition from the first state in Figure 2 to the second state in Figure 3). Elements that are in the current state of UI view 205 but not in the target state of UI view (e.g., the third element 300 in the example of a transition from the second state in Figure 3 to the first state in Figure 2 or the third state in Figure 4), and / or elements that are not in the current state of UI view 205 but are in the target state of UI view 205 (e.g., the third element 300 in the example of a transition from the first state in Figure 2 or the third state in Figure 4 to the second state in Figure 3) can be identified (e.g., using UI element N identifiers for the current state and the target state).

[0075] Next, the system process 500 can identify a first animation (e.g., a mixed animation based on an interpolated view between the view of the element in the current state and the view of the element in the target state) for elements that are included in both the current state and the target state (e.g., based on application-provided transition definitions and / or system-level preferences). The system process 500 can also identify one or more second animations (e.g., fade-out, blur-out, translation-out, particleization, and disappearance animations) for one or more elements that are included in the current state but not in the target state. The system process 500 can also identify one or more third animations (e.g., fade-in, blur-in, translation-in, solidification from particleization animations) for one or more elements that are not included in the current state but are included in the target state.

[0076] The system process 500 may also determine one or more timelines for the transitions of the UI view 205 and / or one or more of its elements, without the involvement of the underlying application (e.g., App 1). In one or more implementations, the timelines may be determined by the system process to accommodate other display content to be displayed, and the underlying application for the UI view 205 is unaware of (and may not be permitted to be aware of) the other display content.

[0077] For example, the system process 500 may animate the transitions of various elements of the UI view 205 and / or the overall UI view 205 at various different times and / or different rates, based on system preferences and / or information that are not provided or inaccessible by the underlying application for the UI view 205. For example, the size transition of the first element 209 in Figure 2 from the first state in Figure 2 to the second state in Figure 3 may occur before and / or earlier than the size transition of the second element 211 in Figure 2 from the first state in Figure 2 to the second state in Figure 3. As another example, the system process 500 may animate the introduction of the third element 300 in Figure 3 before or after (for example, and / or at a different rate) the animation of the size increase of the first element 209 and the second element 211 in the transition from the first state in Figure 2 to the second state in Figure 3. In one or more implementations, the system process 500 can determine the time (e.g., one second, a few seconds, or a fraction of a second) for the overall transition of the UI view 205 from its current state to its target state.

[0078] As shown in Figure 7, the system process 500 can store transition time information 700 which may include one or more transition times and / or one or more transition curves, such as a transition curve 702. For example, a transition curve 702 can define the linear or nonlinear progression of an interpolated state between the current state of the UI view 205 and the desired state of the UI view 205. The transition curve 702 may also be applied to control the progression of non-interpolated animations such as fade-in, fade-out, blur-in, and blur-out. For example, if the exemplary transition curve 702 in Figure 7 is applied to the animation of transitions of elements in the UI view 205, it will cause little change in the appearance of the element in the first half of the transition time, cause a rapid change in the element (according to the animation defined for that element) over the third quarter of the transition time, and cause a slow change (according to the animation defined for that element) over the last quarter of the transition time. In this way, the system process 500 can provide a dynamic and / or interactive display of the UI view 205 that can adapt to other content on the screen and give the appearance of application control, without the operation of the underlying application for the UI view 205.

[0079] In one or more implementations, the transition curve 702 may be applied to an animation defined in a state definition (e.g., and / or a separate transition definition). For example, a system process 500 may define a time (e.g., the total time for a state transition, such as 1 second, 2 seconds, 4 seconds, or a fraction of a second) and a curve (e.g., a transition curve 702 such as an ease-in curve, an ease-out curve, or a linear curve) and apply coverage to an animation of system-defined time. In the case of a linear curve, by applying the curve to the animation, the animation can be made to run linearly over system-defined time. In other exemplary curves, the animation may be held up to, for example, the last part of the transition time (e.g., the last 50 percent).

[0080] As shown in Figure 7, in one or more implementations, the system process 500 can receive app 1 data while the system process 500 is animating the transition, and the app 1 data may be included in the animated UI state transition rendered by app 1 (for example, as a result, the data can continue to be displayed and / or updated during the animated state transition of the UI view 205).

[0081] Figure 8 shows an exemplary process flowchart for providing a dynamically resizable user interface view according to an aspect of the subject art. Blocks of process 800 are described herein as occurring sequentially or linearly. However, multiple blocks of process 800 may occur in parallel. In addition, the blocks of process 800 do not have to be performed in the order shown, and / or one or more blocks of process 800 do not have to be performed and / or can be replaced by other operations. In some embodiments, a system process of the electronic device's operating system (e.g., system process 500) executes the process in Figure 8. In some implementations, the system process is a user interface view display process (e.g., a process for displaying widgets). In other embodiments, a user interface view display process (e.g., a process for displaying widgets) separate from the electronic device's operating system executes the process in Figure 8.

[0082] In the example in Figure 8, in block 802, a system process (e.g., system process 500) of an electronic device (e.g., electronic device 100) can receive from an application running on the electronic device (e.g., application 506 such as "App 1" described herein) state definitions (e.g., App 1 state definitions) of multiple states of a user interface view (e.g., UI view 1 or UI view 205), and one or more transition definitions that define transitions between any two of the multiple states. In one or more implementations, each of the multiple states includes at least one display element (e.g., a first element 209, a second element 211, and / or a third element 300), the size of at least one display element (e.g., UI element N size), and the identifier of at least one display element (e.g., UI element N identifier). In one or more implementations, the multiple states of the UI view correspond to at least one physical world event (e.g., a sports event, a rideshare event, etc.). In one or more implementations, a user interface view can be a user interface view for a widget in an application.

[0083] In block 804, a system process can identify triggers for a change from one of several states of a user interface view (e.g., the current state) to another of several states of the user interface view (e.g., the target state). As discussed herein, triggers may include user interactions with a user interface view, user interactions with another user interface view displayed simultaneously with the user interface view, changes in dynamic data displayed within the user interface view, changes in the size or location of other content displayed simultaneously with the user interface view, or other user or data triggers. In one or more implementations, a trigger may be an application-defined trigger defined in the state definition and / or transition definition(s) from the application. In one or more implementations, a trigger may be a system-defined trigger.

[0084] In block 806, in response to a trigger, a system process can achieve a change from one of several states of a user interface view to another of several states of the user interface view according to one or more transition definitions (for example, as discussed herein in relation to Figure 7). For example, the system process can achieve the change by partially determining the time for the change (e.g., transition time) and the curve (e.g., transition curve 702) and applying one or more transition definitions to the curve. In one or more implementations, several states may be archived by the system process (e.g., in memory 502) before achieving the change (e.g., before rendering the animation for the transition). In one or more implementations, achieving the change may include animating the change.

[0085] In one or more implementations, multiple states include a first state (e.g., the second state shown in Figure 2) having a first element (e.g., first element 209) having a first identifier (e.g., UI element 1 identifier) ​​and a second element (e.g., second element 211) having a second identifier (e.g., UI element 2 identifier), and one or more transition definitions include a first transition definition for the first element (e.g., state transition 1) and a second transition definition for the second element (e.g., state transition 2). In one or more implementations, a system process achieves changes by animating the transition of the first element using the first transition definition and animating the transition of the second element using the second transition definition.

[0086] In one or more implementations, before the change is achieved, the system process can compare the set of elements of the first state with the set of elements of the second state. For example, before the change is achieved, the system process can determine, based on the comparison, that the second state among several states (for example, in an example where the first state corresponds to the first state in Figure 2 and the second state corresponds to the second state in Figure 3) contains a first element having a first identifier and a second element having a second identifier.

[0087] As another example, before achieving a change, a system process can determine, based on comparison (for example, in an example where the first state corresponds to the first state in Figure 2 and the second state corresponds to the third state in Figure 4, or in an example where the first state corresponds to the second state in Figure 3 and the second state corresponds to the first state in Figure 2 or the third state in Figure 4), that the second state among several states includes a first element having a first identifier and does not include a second element having a second identifier. In this example, animating the transition of the second element using a second transition definition may include animating the removal of the second element from the user interface view (for example, by animating a fade-out, translation-out, blur-out, or particle-and-disappear animation).

[0088] In one or more implementations, the states include a first state having a first element having a first identifier (e.g., the second element 211 in Figure 2 having the identifier UI element 2); a second state not having the first element having the first identifier (e.g., the state shown in Figure 4); and a third state including the first element having the first identifier (e.g., the state shown in Figure 3). For example, the first element may have a first size in the first state (e.g., as shown in the examples in Figures 2 and 3) and a second size different from the first size in the third state. In one or more implementations, the third state including the first element having the first identifier also includes additional elements not included in the first state.

[0089] In one or more implementations, the multiple states include a first state in which the user interface view has a first size (as shown in the examples in Figures 2 to 4, for example) and a second state in which the user interface view has a second size. In one or more implementations, the first and second sizes of the user interface view are defined in the state definition received from the application.

[0090] In one or more implementations, the system process receives application information from the application for display within an element of one of the multiple states of the user interface view while one of the multiple states of the user interface view is displayed (e.g., App 1 data, as discussed herein in relation to Figure 7). In one or more implementations, the system process may also receive additional application information from the application for display within an element of one of the multiple states of the user interface view while a change is being made (e.g., additional App 1 data, as discussed herein in relation to Figure 7). In one or more implementations, the application information received from the application may include pre-rendered images of the application information for display at a future time as dynamic data within one or more of the multiple states of the UI view. In one or more implementations, the application information received from the application may include application information received from application extensions of the application.

[0091] In one or more implementations, the system process receives application information (e.g., App 1 data, as discussed herein in relation to Figure 7) from a server associated with the application for display within one of the multiple states of the user interface view while one of the multiple states of the user interface view is displayed. In one or more implementations, the system process may also receive additional application information (e.g., additional App 1 data, as discussed herein in relation to Figure 7) from a server associated with the application for display within one of the multiple states of the user interface view while a change is being made.

[0092] Figure 9 shows an exemplary process flow diagram for operating an application in an electronic device to provide a dynamically resizable user interface view, according to an aspect of the subject art. Blocks of process 900 are described herein as occurring sequentially or linearly. However, multiple blocks of process 900 may occur in parallel. In addition, the blocks of process 900 do not have to be performed in the order shown, and / or one or more blocks of process 900 do not have to be performed, and / or can be replaced by other operations.

[0093] In block 902, an application (e.g., application 506 such as app 1) running on an electronic device (e.g., electronic device 100) may provide a system process of the electronic device (e.g., system process 500) with state definitions for multiple states of a user interface view, and one or more transition definitions each defining a transition between two of the multiple states (e.g., as discussed herein in relation to Figure 5). In one or more implementations, each of the multiple states includes at least one display element, the size of at least one display element, and an identifier for at least one display element.

[0094] In one or more implementations, an application may provide state definitions and transition definitions via an application programming interface (API). In one or more implementations, an application may provide state definitions and transition definitions via a file system (for example, application 506 may store state definitions and / or transition definitions in a template and save the template in a known directory that is parsed by a system process). For example, the definitions may be saved as an application resource file. In one or more implementations, an application may provide state definitions and transition definitions by a combination of one or more templates and one or more API calls (for example, state definitions via a template and transition definitions via an API, state definitions via a template and transition definitions via a template, state definitions via an API and transition definitions via an API, or state definitions via an API and transition definitions via a template). In one or more implementations, a template may have a format that can be consumed by a system process to render at least one UI view (e.g., UI view 205) according to the information contained in the template.

[0095] In block 904, an application running on an electronic device may provide application information (e.g., App 1 data) to be displayed by a system process within the user interface view while the user interface view is in at least one of several states. In one or more implementations, an application may provide a system process with application information to be displayed in relation to two or more elements of the user interface view (e.g., a first element 209, a second element 211, and / or a third element 300 as described herein in relation to Figures 2 to 4).

[0096] In one or more implementations, the states include a first state (e.g., the state shown in Figure 4) in which the user interface view has a first size and includes a first element (e.g., a first element 209), and a second state (e.g., the state shown in Figure 2 or Figure 3) in which the user interface view has a second size greater than the first size and includes the first element and a second element (e.g., a second element 211 or a third element 300). In one or more implementations, providing application information may include providing at least first application information (e.g., dynamic data 221) to be displayed in relation to the first element while the user interface view is in the first state, and providing first application information (e.g., dynamic data 221) and second application information (e.g., dynamic data 223 and / or data 301) to be displayed in relation to the second element while the user interface view is in the second state. In one or more implementations, providing application information may involve the application providing the system process with second application information for a second element while the user interface view is in a first state that does not contain the second element (for example, the application may provide application information for an element regardless of whether the element is currently displayed or not). In this way, the system process can determine which application information to display without notifying the application of the display state of the UI view.

[0097] In one or more other implementations, second application information may be provided to the system process only when the user interface view is in a state that includes the second element. For example, in one or more implementations, process 900 may also include receiving state transition information from the system process by the application indicating a transition from a first state to a second state. For example, the system process may provide state transition information to the application in response to receiving a trigger in the system process (for example, as described herein in relation to Figure 7). In one or more implementations, providing application information may include the application providing second application information about the second element to the system process in response to receiving state transition information.

[0098] In one or more implementations, providing application information from an application to a system process may include providing the system process with one or more links to communication channels for system process access to the first and second application information, according to the state of the user interface view. For example, the links may be used by the system process to subscribe to a publishing channel associated with the application, thereby allowing the server associated with the application to provide application information to one or more subscriber processes. In this way, the system process can receive application information (e.g., App 1 data in the examples of Figures 6 and 7) from the server associated with the application, according to the state of the UI view, while the application is inactive on the electronic device.

[0099] In one or more implementations, the application may also provide the system process with additional application information that is displayed in the user interface view by the system process during transitions from one of several states to another of several states (for example, while the system process is animating the transition according to the transition definition, and while the application is inactive on the electronic device).

[0100] As described above, aspects of the subject technology may include the collection and transfer of data from an application to another user's computing device. In some cases, this disclosure intends that the collected data may include personal information data that uniquely identifies or can be used to identify a particular person. Such personal information data may include demographic data, location-based data, online identifiers, telephone numbers, user activity data, user power consumption data, email addresses, home addresses, data or records relating to a user's health or fitness level (e.g., vital sign measurements, medication information, exercise information), date of birth, or any other personal information.

[0101] This disclosure acknowledges that such use of personal data in the technology may be for the benefit of the user. For example, personal data can be used when providing content on electronic devices. Furthermore, other uses of personal data that benefit the user are also intended by this disclosure. For example, health and fitness data can be used according to the user's preferences to provide general wellness insights or as positive feedback to individuals using the technology to pursue wellness goals.

[0102] This disclosure assumes that entities responsible for collecting, analyzing, disclosing, transferring, storing, or otherwise using such personal data will adhere to well-established privacy policies and / or privacy practices. Specifically, such entities are expected to implement and consistently apply privacy practices that are generally recognized as meeting or exceeding industry or government requirements for maintaining user privacy. Such information regarding the use of personal data should be conspicuously and readily accessible to users and should be updated as data collection and / or use changes. Personal data from users should be collected only for legitimate use. Furthermore, such collection / sharing should be done after obtaining user consent or on other legitimate grounds specified in applicable law. In addition, such entities should consider taking all necessary steps to protect and secure access to such personal data and to ensure that others with access to personal data faithfully adhere to those privacy policies and procedures. Furthermore, such entities may undergo third-party evaluations to demonstrate their compliance with widely accepted privacy policies and practices. In addition, policies and practices should be tailored to the specific types of personal data collected and / or accessed, and should conform to applicable laws and standards, including jurisdiction-specific considerations that may play a role in imposing higher standards. For example, in the United States, the collection or access to certain health data may be subject to federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA). Health data in other countries, on the other hand, may be subject to other regulations and policies and should be addressed accordingly.

[0103] Notwithstanding the foregoing, this disclosure also envisions implementations that allow users to selectively prevent the use of or access to their personal data. Specifically, this disclosure intends that hardware and / or software elements may be provided to prevent or prevent access to such personal data. For example, when providing dynamic lock screen content on an electronic device, the technology may be configured to allow users to choose to "opt in" or "opt out" of participating in the collection of personal data during or at any time thereafter. In addition to providing "opt-in" and "opt-out" options, this disclosure intends to provide notices regarding the access to or use of personal data. For example, users may be notified when downloading an app that will access their personal data, and then again immediately before the app accesses their personal data.

[0104] Furthermore, the intent of this disclosure is that personal data should be managed and processed in a manner that minimizes the risk of unintentional or unauthorized access or use. Risks can be minimized by limiting data collection and deleting data when it is no longer needed. In addition, where applicable in certain health-related applications, data anonymization can be used to protect user privacy. De-identification may be facilitated, where appropriate, by removing identifiers, controlling the amount or specificity of data stored (e.g., collecting location data at the city level rather than the address level), controlling how data is stored (e.g., aggregating data across users), and / or by other means such as differential privacy.

[0105] Therefore, while this disclosure extensively covers the use of personal data to implement one or more of the disclosed embodiments, it is also conceivable that these embodiments can be implemented without requiring access to such personal data. In other words, the various embodiments of the Technology are not rendered inoperable by the absence of all or part of such personal data.

[0106] This figure shows an exemplary computing device that can implement aspects of the subject technology according to one or more implementation forms. Computing device 1000 may be and / or part thereof any computing device or server for generating the features and processes described above, including, but not limited to, laptop computers, smartphones, tablet devices, smartwatches and other wearable devices. Computing device 1000 may include various types of computer-readable media and interfaces for various other types of computer-readable media. Computing device 1000 may include a permanent memory device 1002, system memory 1004 (and / or buffers), input device interface 1006, output device interface 1008, bus 1010, ROM 1012, one or more processing units 1014, one or more network interfaces 1016, and / or subsets and variations thereof.

[0107] Bus 1010 collectively represents all system buses, peripheral buses, and chipset buses that communicate with a number of internal devices of computing device 1000. In one or more implementations, bus 1010 communicates with one or more processing units 1014 to ROM 1012, system memory 1004, and permanent storage device 1002. From these various memory units, one or more processing units 1014 retrieve instructions to execute and data to process in order to perform the processes of this disclosure. One or more processing units 1014 may be a single processor or a multi-core processor in different implementations.

[0108] ROM 1012 stores static data and instructions required by one or more processing units 1014 and other modules of the computing device 1000. On the other hand, the permanent storage device 1002 may be a read and write memory device. The permanent storage device 1002 may be a non-volatile memory unit that stores instructions and data even when the computing device 1000 is off. In one or more implementations, a mass storage device (such as a magnetic disk or optical disk and a corresponding disk drive) may be used as the permanent storage device 1002.

[0109] In one or more implementations, a removable storage device (such as a floppy disk, flash drive, and corresponding disk drive) may be used as the permanent storage device 1002. Similar to the permanent storage device 1002, the system memory 1004 may be a read-and-write memory device. However, unlike the permanent storage device 1002, the system memory 1004 may be a volatile read-and-write memory such as random-access memory. The system memory 1004 can store any of the instructions and data that one or more processing units 1014 may need at runtime. In one or more implementations, the process of this disclosure is stored in the system memory 1004, the permanent storage device 1002, and / or the ROM 1012. From these various memory units, one or more processing units 1014 retrieve the instructions to be executed and the data to be processed in order to execute the process of one or more implementations.

[0110] Bus 1010 also connects to input and output device interfaces 1006 and 1008. Input device interface 1006 allows a user to communicate information to computing device 1000 and select commands. Input devices that may be used with input device interface 1006 may include, for example, an alphanumeric keyboard and a pointing device (also referred to as a “cursor control device”). Output device interface 1008 may, for example, enable the display of images generated by computing device 1000. Output devices that may be used with output device interface 1008 may include, for example, printers and display devices such as liquid crystal displays (LCDs), light-emitting diode (LED) displays, organic light-emitting diode (OLED) displays, flexible displays, flat panel displays, solid-state displays, projectors, or any other devices for outputting information.

[0111] One or more implementations may include a device that functions as both an input and output device, such as a touchscreen. In these implementations, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or haptic feedback, and input from the user may be received in any form, including acoustic input, voice input, or haptic input.

[0112] Finally, as shown in Figure 10, the bus 1010 also connects the computing device 1000 to one or more networks and / or one or more network nodes via one or more network interfaces 1016. In this way, the computing device 1000 may be part of a network of computers (such as a LAN, a wide area network ("WAN"), or an intranet), or a network such as the Internet. Any or all components of the computing device 1000 can be used in conjunction with this disclosure.

[0113] Implementations within the scope of this disclosure can be partially or completely realized using tangible computer-readable storage media (or multiple tangible computer-readable storage media of one or more types) that encode one or more instructions. The tangible computer-readable storage media may also be, in fact, non-transient.

[0114] A computer-readable storage medium can be any storage medium that can be read, written to, or otherwise accessed by a general-purpose or dedicated computing device, including any processing electronic equipment and / or processing circuitry capable of executing instructions. For example, but not limited to, a computer-readable medium can include any volatile semiconductor memory such as RAM, DRAM, SRAM, T-RAM, Z-RAM, and TTRAM. A computer-readable medium can also include any non-volatile semiconductor memory such as ROM, PROM, EPROM, EEPROM, NVRAM, flash, nvSRAM, FeRAM, FeTRAM, MRAM, PRAM, CBRAM, SONOS, RRAM, NRAM, Racetrack memory, FJG, and Millipede memory.

[0115] Furthermore, the computer-readable storage medium may include any non-semiconductor memory, such as optical disk storage devices, magnetic disk storage devices, magnetic tapes, other magnetic storage devices, or any other medium capable of storing one or more instructions. In one or more implementations, the tangible computer-readable storage medium may be directly coupled to a computing device, while in other implementations, the tangible computer-readable storage medium may be indirectly coupled to a computing device, for example, via one or more wired connections, one or more wireless connections, or any combination thereof.

[0116] Instructions can be made directly executable or used to develop executable instructions. For example, instructions can be implemented as executable or non-executable machine code, or as instructions in a high-level language that can be compiled to produce executable or non-executable machine code. Furthermore, instructions can also be implemented as data or contain data. Computer executable instructions can also be structured in any format, including routines, subroutines, programs, data structures, objects, modules, applications, applets, functions, etc. As will be recognized by those skilled in the art, details including, but not limited to, the number, structure, order, and structuring of instructions can be changed considerably without altering the basic logic, function, processing, and output.

[0117] The above discussion primarily refers to microprocessors or multicore processors that run software, but one or more implementations are performed by one or more integrated circuits, such as ASICs or FPGAs (one or more). In one or more implementations, such integrated circuits execute instructions stored within the circuit itself.

[0118] Those skilled in the art will understand that the various exemplary blocks, modules, elements, components, methods, and algorithms described herein can be implemented as electronic hardware, computer software, or a combination of both. Above, to demonstrate this hardware- and software compatibility, the various exemplary blocks, modules, elements, components, methods, and algorithms have been generally described in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the design constraints imposed on the overall system and the specific application. Those skilled in the art will be able to perform the described functionality in various ways for each specific application. The various components and blocks may be arranged differently (for example, in a different order or divided in a different way) without departing entirely from the scope of the art of this application.

[0119] Any particular order or hierarchy of blocks in the disclosed process should be understood as an example of an exemplary approach. Based on design preferences, any particular order or hierarchy of blocks in the process may be rearranged, or all of the exemplary blocks may be executed. Any of the blocks may be executed simultaneously. Multitasking and parallel processing may be advantageous in one or more implementations. Furthermore, the separation of various system components in the implementations described above should not be understood as a requirement for all implementations, and the described program components (e.g., computer program products) and systems may generally be integrated into a single software product or packaged into multiple software products.

[0120] As used herein and in the claims, the terms “base station,” “receiver,” “computer,” “server,” “processor,” and “memory” all refer to electronic or other technical devices. These terms exclude persons or groups of persons. For the purposes of this specification, the terms “display” or “displaying” mean displaying on an electronic device.

[0121] When used herein, the phrase “at least one” preceding a set of items, along with the terms “and” or “or” separating any of the items, qualifies the list as a whole, rather than each element of the list (i.e., each item). The phrase “at least one” does not require the selection of at least one of each item listed; rather, it allows for meanings including at least one of any one of the items, and / or at least one of any combination of the items, and / or at least one of each of the items. For example, the phrases “at least one of A, B, and C” or “at least one of A, B, or C” refer, respectively, to A only, B only, or C only, any combination of A, B, and C, and / or at least one of each of A, B, and C.

[0122] The predicates “configured to,” “operable to,” and “programmed to” are not intended to imply any specific tangible or intangible modification of the object, but rather to be interchangeable. In one or more implementations, a processor configured to monitor and control operations or components may also mean that the processor is programmed to monitor and control operations, or that the processor is operable to monitor and control operations. Similarly, a processor configured to execute code may be interpreted as a processor that is programmed to execute code, or operable to execute code.

[0123] The phrases "one aspect," "that aspect," "another aspect," "several aspects," "one or more aspects," "one implementation," "that implementation," "another implementation," "several implementations," "one or more implementations," "one embodiment," "that embodiment," "another embodiment," "several implementations," "one or more implementations," "one configuration," "that configuration," "another configuration," "several configurations," "one or more configurations," "the Art of the Application," "disclosure," "this disclosure," "other variations thereof," and similar phrases are for convenience only and do not imply that disclosures relating to such phrases (singular or plural) are essential to the Art of the Application or that such disclosures apply to all configurations of the Art of the Application. Disclosures relating to such phrases (singular or plural) may apply to all configurations or one or more configurations. Disclosures relating to such phrases (singular or plural) may provide one or more examples. Phrases such as "aspect" or "several aspects" may refer to one or more aspects, and vice versa, as with the other aforementioned phrases.

[0124] The word “exemplary” is used herein to mean “to serve as an example, case, or illustration.” Any embodiment described herein as “exemplary” or “example” should not necessarily be construed as being preferable or advantageous over other forms of implementation. Furthermore, to the extent that terms such as “include” and “have” are used in the specification or claims, such terms are intended to be comprehensive in the same manner as the term “comprise,” as “comprise” is construed as when “comprise” is used as a transitional term in the claims.

[0125] All structural and functional equivalents to the various aspects of the elements described herein, whether known to those skilled in the art or to become known thereafter, are expressly incorporated herein by reference and are intended to be included in the claims. Furthermore, nothing disclosed herein is to be made public, whether such disclosure is expressly enumerated in the claims. No element of any claim should be construed under Section 112(f) of the United States Patent Act unless the element is expressly enumerated using the phrase “means for” or, in the case of a method claim, the element is enumerated using the phrase “step for”.

[0126] The foregoing description is provided to enable those skilled in the art to implement the various embodiments described herein. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein can also be applied to other embodiments. Therefore, the claims are not intended to limit themselves to the embodiments shown herein, but rather to encompass the entire scope consistent with the literal claims, and references to elements in the singular are not intended to mean "one and only one" unless otherwise noted, but rather "one or more." Unless otherwise noted, the term "some" refers to one or more things. Masculine pronouns (e.g., he) include feminine and neuter genders (e.g., she and her), and vice versa. Headings and subheadings, if any, are used for convenience only and do not limit the disclosure of this application.

Claims

1. It is a method, The system process of an electronic device receives from an application running on the electronic device a state definition for a plurality of states for a user interface view, each of which includes at least one display element, the size of the at least one display element, and an identifier of the at least one display element, and one or more transition definitions each defining a transition between two of the plurality of states. The system process identifies a trigger for changing the user interface view from one of the multiple states to another of the multiple states, A method comprising, in response to the trigger, achieving the change from one of the multiple states of the user interface view to another of the multiple states of the user interface view by the system process and in accordance with one or more transition definitions.

2. The method according to claim 1, wherein the system process determines the time and curve for the change and partially achieves the change by applying one or more transition definitions to the curve.

3. The method according to claim 1, wherein the plurality of states include a first state having a first element having a first identifier and a second element having a second identifier, and the one or more transition definitions include a first transition definition for the first element and a second transition definition for the second element.

4. The method according to claim 3, wherein the system process achieves the modification by animating the transition of the first element using the first transition definition and animating the transition of the second element using the second transition definition.

5. The method according to claim 4, further comprising the system process comparing the set of elements of the first state with the set of elements of the second state before achieving the aforementioned change.

6. The method of claim 5, further comprising, before achieving the change, the system process determining, based on the comparison, that the second state among the plurality of states includes the first element having the first identifier and the second element having the second identifier.

7. The method of claim 5, further comprising, before achieving the change, the system process determining, based on the comparison, that the second state among the plurality of states includes the first element having the first identifier and does not include the second element having the second identifier.

8. The method according to claim 7, wherein animating the transition of the second element using the second transition definition includes animating the removal of the second element from the user interface view.

9. The method according to claim 1, wherein the plurality of states include a first state having a first element having a first identifier, a second state not having the first element having the first identifier, and a third state including the first element having the first identifier.

10. The method according to claim 9, wherein the first element has a first size in the first state and a second size different from the first size in the third state.

11. The method according to claim 1, wherein the plurality of states include a first state in which the user interface view has a first size and a second state in which the user interface view has a second size.

12. The method according to claim 1, further comprising the system process receiving application information from the application to be displayed within one of the multiple states of the user interface view while one of the multiple states of the user interface view is displayed.

13. The method according to claim 12, further comprising the system process receiving additional application information from the application about one of the multiple states of the user interface view of the element to be displayed within the element while the change is being achieved.

14. The method according to claim 1, wherein the user interface view is the user interface view of the application's widget.

15. A method that uses an application running on an electronic device, The system process of the electronic device is provided with a state definition for a plurality of states for a user interface view, each of which includes at least one display element, the size of the at least one display element, and an identifier for the at least one display element, and one or more transition definitions that each define a transition between two of the plurality of states. A method comprising providing the system process with application information displayed within the user interface view while the user interface view is in at least one of the plurality of states.

16. The plurality of states include a first state in which the user interface view has a first size and includes a first element, and a second state in which the user interface view has a second size larger than the first size and includes the first and second elements, and providing the application information is, While the user interface view is in the first state, it provides at least first application information to be displayed in relation to the first element, The method according to claim 15, comprising providing the first application information and the second application information to be displayed in relation to the second element while the user interface view is in the second state.

17. The method according to claim 16, further comprising the application receiving state transition information from the system process indicating a transition from the first state to the second state, and providing the application information comprising the application providing the system process with the second application information for the second element in response to the receipt of the state transition information.

18. The method according to claim 16, wherein providing the application information includes providing the first application information and the second application information by providing the system process with one or more links to communication channels for system process access to the first application information and the second application information, according to the state of the user interface view.

19. The method according to claim 15, further comprising providing the system process with additional application information displayed by the system process in the user interface view during a transition from one of the plurality of states to another of the plurality of states.

20. A non-temporary computer-readable medium for storing instructions for a user interface view display process, wherein, when the instructions are executed by one or more processors of an electronic device, the one or more processors... The application running on the electronic device receives a state definition for a plurality of states for a user interface view, each of which states includes at least one display element, the size of the at least one display element, and an identifier of the at least one display element, and one or more transition definitions each defining a transition between two of the plurality of states, Identify a trigger for changing the user interface view from one of the multiple states to another of the multiple states, A non-temporary computer-readable medium that, in response to the trigger, achieves the change from one of the multiple states of the user interface view to another of the multiple states of the user interface view, according to one or more transition definitions.

Images