Dynamically Resizable Content for Electronic Devices
A dynamically resizable UI view on locked screens of electronic devices addresses the inefficiency of accessing information by allowing users to view dynamic data without unlocking the device, maintaining security and privacy while enhancing user experience.
Patent Information
- Application Number
- JP2024566004
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-04-11
- Filing Date
- 2023-05-09
- Publication Date
- 2025-06-05
- Estimated Expiration
- 2043-05-09
AI Technical Summary
Existing electronic devices require users to unlock, launch applications, and navigate to relevant sections to access information, which is time-consuming and inefficient, especially for monitoring ongoing events while the device is locked.
The implementation of a dynamically resizable user interface (UI) view that can be displayed on a locked screen, allowing users to view dynamic data such as sports scores or ride-sharing information without unlocking the device, using system processes to animate transitions between UI states based on user interactions or data updates.
This solution enables users to efficiently monitor ongoing events without the need for repeated authentication and unlocking, while maintaining device security and privacy, by providing a power-efficient and resource-friendly way to display dynamic data on locked screens.
Smart Images

Figure 2025517302000001_ABST
Abstract
Description
[Technical field]
[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 340,418, entitled "Dynamically Resizeable Content for Electronic Devices," filed May 10, 2022, the disclosure of which is incorporated herein in its entirety.
[0002] This document relates generally to electronic devices, including, for example, dynamically resizable content for the electronic device. [Background technology]
[0003] Electronic devices often include applications that provide information for display in the application's user interface. To access information from an application, a user must typically unlock the electronic device, launch the application, wait for the application to launch, and navigate to the relevant section of the application's user interface that displays the information. [Brief description of the drawings]
[0004] Particular features of the present technology are set forth in the appended claims, however, for purposes of illustration, some implementations of the present technology are set forth in the following figures.
[0005] [Figure 1] FIG. 1 is a perspective view of an exemplary electronic device in which various aspects of the subject technology may be implemented.
[0006] [Diagram 2] 1 illustrates a dynamically resizable user interface (UI) view in a first state according to one or more implementations.
[0007] [Diagram 3]1 illustrates a dynamically resizable UI view in a second state in accordance with one or more implementations.
[0008] [Figure 4] 1 illustrates a dynamically resizable UI view in a third state in accordance with one or more implementations.
[0009] [Diagram 5] 1 illustrates a block diagram of an example electronic device that obtains application state information for an application UI view, according to one or more implementations.
[0010] [Figure 6] 1 illustrates a block diagram of an example electronic device that generates an application UI view for display in a first state in accordance with one or more implementations.
[0011] [Figure 7] 1 illustrates a block diagram of an example electronic device that animates transitions between states of an application UI view for display in accordance with one or more implementations.
[0012] [Figure 8] 1 illustrates a flow diagram of an exemplary process for providing state transitions for a user interface view in accordance with an aspect of the subject technology.
[0013] [Figure 9] 1 illustrates a flow diagram of an example process for operating an application in an electronic device to provide dynamic state transitions of a user interface view in accordance with an aspect of the subject technology.
[0014] [Figure 10] FIG. 1 illustrates an example computing device capable of implementing aspects of the subject technology. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0015] The detailed description set forth below is intended as a description of various configurations of the technology of the present application, and is not intended to represent the only configurations in which the technology of the present application can be implemented. The accompanying drawings are incorporated in this specification and form a part of the detailed description. The detailed description includes specific details to provide a thorough understanding of the subject technology. However, the technology of the present application is not limited to the specific details set forth herein, and may be implemented using one or more other implementation forms. In one or more implementation forms, structures and components are shown in block diagram form to avoid obscuring the concepts of the technology of the present application.
[0016] In one or more implementations, an application provides to a system process (or a user interface display process separate from the operating system) a plurality of states for a user interface (UI) view for the application and one or more transition definitions, each of which defines a transition between two of the plurality of states. Each of the plurality of states can specify a display element, a size of the display element, and an identifier for the display element. When a user or content of the UI view triggers a change of the UI view from one of the plurality of states to another of the plurality of states, the system process animates the change according to the one or more transition definitions. In one or more implementations, an application provides system animated transitions between application UI states and provides application data to be displayed in a rendered UI view.
[0017] An exemplary electronic device that may display content and / or dynamically resizable UI views is illustrated in FIG. 1. In the example of FIG. 1, electronic device 100 is implemented using a housing that is portable and small enough to be carried by a user (e.g., electronic device 100 of FIG. 1 may be a handheld electronic device such as a tablet computer, a smartphone, a smartwatch, a laptop, etc.). As illustrated in FIG. 1, electronic device 100 includes a display such as display 110 attached to a front side of housing 106. Electronic device 100 includes one or more input / output devices such as a touch screen integrated into display 110, buttons or switches such as button 104, and / or other input / output components located on or behind display 110 or on or behind other portions of housing 106. Display 110 and / or housing 106 include one or more openings for accommodating button 104, a speaker, a light source, or a camera.
[0018] 1, the housing 106 includes an opening 108 on a bottom sidewall of the housing 106. The one or more openings 108 form ports for audio components. The housing 106, which may also be referred to as a case, may be formed of plastic, glass, ceramic, fiber composite, metal (e.g., stainless steel, aluminum, etc.), other suitable materials, or a combination of any two or more of these materials.
[0019] The configuration of electronic device 100 in FIG. 1 is merely exemplary. In other implementations, electronic device 100 may be a computer, such as a computer with an integrated display such as a computer monitor, a laptop computer, a wearable device, such as a smart watch, a pendant device, or other wearable or small device, a media player, a gaming device, a navigation device, a computer monitor, a television, headphones, or other electronic device with a display. In some implementations, electronic device 100 may be provided in the form of a wearable device, such as a smart watch. In one or more implementations, housing 106 may include one or more interfaces for mechanically coupling housing 106 to a strap or other structure for securing housing 106 to a wearer.
[0020] 2 illustrates an example of a dynamically resizable UI view 205 displayed by electronic device 100. In some embodiments, UI view 205 is a system UI view (e.g., a view provided by an operating system of electronic device 100). In one or more implementations, UI view 205 may be a UI view for a widget. As shown in FIG. 2, UI view 205 is displayed by a lock screen 250 of the electronic device. However, in some embodiments, the electronic device is constructed to display the dynamically resizable UI view on any one of a lock screen (e.g., lock screen 250), a home screen, or the like.
[0021] In some embodiments, 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 the application. In some implementations, the system process is an application framework that receives configuration data associated with the 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, sports scores, etc.).
[0024] As shown in FIG. 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 of FIG. 2, the lock screen 250 includes an unlock feature 219. The unlock feature 219 may be selectable by a 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 to unlock the electronic device). In the example of FIG. 2, the lock screen 250 also includes a lock indicator 201 that indicates that 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 navigate away from the lock screen 250 (e.g., to another screen, such as a home screen or a 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 continues to be displayed.
[0025] In the example of FIG. 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 (e.g., a display element that can be used to access limited 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, the signal strength indicator 214, the battery indicator 216, and the functional element 218 are displayed within a dynamically resizable UI view. As shown in FIG. 2, the lock screen 250 may also include a background 206 (e.g., an image or color pattern), 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 a time 208 and a date 210. In the example of FIG. 2, the electronic device 100 includes one or more sensing components 204 (e.g., a camera and / or an infrared sensor or a depth sensor) that can be used to obtain biometric information from a user of the electronic device. In other examples, electronic device 100 may obtain biometric or non-biometric (e.g., passcode) authentication information from other sensors and / or input components, such as a touchscreen integrated into display 110, or a keyboard or other input interface of electronic device 100.
[0026] In the example of FIG. 2, the UI view 205 includes a background 207 within a boundary 215, a first element 209, and a second element 211. However, in other examples, the UI view 205 may include any number of elements (e.g., 209). As shown, the first element 209 may include a display of data 221. The second element 211 may include a display of data 223. In the example of FIG. 2, the UI view 205 is a bounded UI view having a boundary 215 that sets the UI view 205 apart from the background 206. In one or more other implementations, the UI view 205 may be a bounded display element. In the bounded state of the UI view 205, the first element 209 and / or the second element 211 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 the 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 obtained by the electronic device from an application executing 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 obtained by the electronic device from a remote server (e.g., remote with respect to device 100) associated with the UI view.
[0028] In one illustrative example, the UI view 205 may include a single graphical display element (e.g., first element 209) for a timer value of a 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 illustrative example, UI view 205 may include one or more graphical display elements (e.g., first element 209 and / or second element 211) of a sports-related application installed on electronic device 100. The sports-related application may be inactive at the time of display of UI view 205. In this example, data 221 may be a current score of a first individual or team currently participating in a competitive sporting 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 a current score of a second individual or team currently participating in the sporting event (e.g., relative to the first individual or team). In various implementations, data 221 and data 223 may be obtained 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 electronic device 100. In this way, the UI view 205 can display dynamic (eg, current real-time) data without having to run a sports-related application.
[0030] The examples of sports-related applications and sporting events are merely illustrative. In another illustrative 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 may view the location of the rideshare vehicle, an estimated arrival time, an estimated cost, or other dynamic data of the rideshare vehicle in a full user interface of the rideshare application (e.g., in a full user interface of the rideshare application, such as a user interface generated by the rideshare application and not by a system process). In this illustrative use case, when UI view 205 (generated by a system process) is displayed instead of the full user interface of the rideshare application (generated by the application), UI view 205 may display some or all of the data associated with the rideshare vehicle. For example, first element 209 may display data 221 corresponding to a current location of the rideshare vehicle, and second element 211 may display data 223 corresponding to an estimated arrival time of the rideshare vehicle.
[0031] In general, 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, task bar 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 may 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 user-provided resize input to the application for modification of the complete UI by the application. In contrast, UI view 205 may be resizable by a system process of electronic device 100 (e.g., by animating the resize and / or updating the state of the UI view based on state, transition, and / or trigger information previously received from the application) without providing any user input information to the application.
[0032] In the example of FIG. 2, UI view 205 is displayed in a first state. In the first state, UI view 205 is a first size and includes background 207, border 215, first element 209, and second element 211. The first state may be defined by an 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 of FIG. 2 may be one of multiple states of UI view 205 defined by the underlying application.
[0033] For example, FIG. 3 illustrates an example in which electronic device 100 displays UI view 205 in a second state that is different from the first state illustrated in FIG. 2. In the example of FIG. 3, UI view 205 is in the second state. As illustrated in the example of FIG. 3, in the second state, UI view 205 has a second size that is larger than the first size of UI view 205 in the first state of FIG. 2. In the example of FIG. 3, UI view 205 includes the same first element 209 and second element 211 (displaying respective first data 221 and second data 223), but first element 209 and second element 211 have a larger size than first element 209 and second element 211 in the first state of UI view 205 in FIG. 2. The relative sizes of the UI view 205, the first element 209, and the second element 211 may be defined by the underlying application prior to displaying the UI view 205 in the first state or the second state, such as by providing state definitions for the first state and the second state to a system process of the electronic device 100.
[0034] In the example of 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, third element 300 includes data 301. Data 301 may include static data or dynamic data. By way of example, static data may include application specific data (e.g., logos, etc.) that is unrelated to the event with which data 221 and data 223 are associated.
[0035] In one or more implementations, UI view 205 can transition from a first state shown in Figure 2 to a second state shown in Figure 3 in response to a user interaction with UI view 205 in the first state of Figure 2. For example, a user of electronic device 100 can provide a tap, swipe, or unpinch input at or near a location of UI view 205 when UI view 205 is displayed in the first state of Figure 2 to cause an increase in size of UI view 205. For example, a user may wish to view more information about a sporting event than just the scores displayed in the first state of Figure 2, or may wish to view a more graphically detailed display of the scores of the sporting event.
[0036] In one or more implementations, the UI view 205 may also, or alternatively, transition from the first state shown in FIG. 2 to the second state shown in FIG. 3 in response to a change in data associated with the UI view 205. For example, if the UI view 205 is displaying the scores of a sporting event while in the first state of FIG. 2, the UI view 205 may expand (e.g., temporarily) to the second state of FIG. 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 the score update (e.g., including the name of the individual or team who scored). In one or more implementations, the UI view 205 may be configured by its underlying application to return to the first state of FIG. 2 after a period of time after the notification is displayed 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, electronic device 100 and / or an underlying application for UI view 205 may configure system processes of electronic device 100 with one or more triggers (e.g., user interaction, data updates, and / or other content movements or changes) that cause UI view 205 to transition from the first state of Figure 2 to the second state of 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 state definitions prior to display of UI view 205 (e.g., before the underlying application is deactivated) that include trigger definitions for various triggers between various state combinations and that include definitions of states resulting from the various triggers.
[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 (e.g., including the first state of FIG. 2 and the second state of FIG. 3), an underlying application may also provide one or more transition definitions to a system process of electronic device 100. In one or more implementations, each transition definition provided from the application to a system process may define a transition between two of a plurality of states of UI view 205. For example, an underlying application for UI view 205 may provide a transition definition to a system process of electronic device 100 that defines various aspects of the display of a transition from the first state of FIG. 2 to the second state of FIG. 3.
[0039] In one or more implementations, the transition definition can define an animation for the transition of the UI view 205 from the first state of FIG. 2 to the second state of FIG. 3. The transition definition can also define an animation for the transition of the first element 209 growing 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 an animation for the new addition of the third element 300 as the UI view 205 grows to include room for the third element 300. For example, the transition definition can define an animation where the third element appears to fade in, slide in, or freeze out of a particleized view as the size of the boundary 215 expands during the transition. As another example, the transition definition may define how quickly 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 state definition of the second state and stops expanding, or whether the boundary 215 expands beyond the size defined for the boundary 215 in the state definition of the second state and snaps back to the size defined for the boundary 215 in the state definition of the second state.
[0040] The example states of UI view 205 of FIGS. 2 and 3 are just two of many different states of UI view 205 that may be defined by the application underlying UI view 205 in electronic device 100.
[0041] For example, FIG. 4 illustrates an example of a third state of the UI view 205. In the example of FIG. 4, the size of the boundary 215 of the UI view 205 is smaller than the size of the boundary 215 of the UI view 205 in the first state of FIG. 2 and the second state of FIG. 3. In this example, the amount of data displayed in the UI view 205 in the third state is also reduced relative to the amount of data displayed in the UI view 205 in the first state and the second state. In this example, the UI view 205 does not include the second element 211 or the third element 300 included in the first state and the second state shown in FIG. 2 and FIG. 3. In one or more implementations, the data 221 of the first element 209 of the UI view 205 of FIG. 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, a system process or an underlying application of the UI view 205 can define the third state shown in FIG. 4 to include only the first element 209 and its data 221, and can also define transition definitions between the first state of FIG. 2 and the third state of FIG. 4, between the second state of FIG. 3 and the third state of FIG. 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 of FIG. 2 to the third state of FIG. 4, or from the second state of FIG. 3 to the third state of FIG. 4. For example, the animation in the defined transition, when accomplished by a system process, can fade out, blur out, or particleize the second element 211 and / or the third element 300 out of view as the boundary 215 of the UI view 205 gets smaller. In one or more implementations, a system process of the electronic device may also animate the disappearance or appearance of the border 215 during a state transition between a borderless state and a bordered state of the UI view 205.
[0043] In one or more implementations, the underlying application for UI view 205 may also define trigger definitions that define triggers that transition UI view 205 from the third state of FIG. 4 to the first state of FIG. 2, from the third state of FIG. 4 to the second state of FIG. 3, from the first state of FIG. 2 to the third state of FIG. 4, and / or from the first state of FIG. 2 to the third state of FIG. 4. As discussed herein, the underlying application for UI view 205 may provide state definitions, trigger definitions, and / or transition definitions for various transitions between various states of UI view 205 to system processes of electronic device 100 before 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 UI view 205, may be incorporated into transition definitions of the multiple states of the UI view, may be incorporated into state definitions, and / or may be defined by system processes of electronic device 100.
[0044] In the examples of FIGS. 2-4, UI view 205 is shown as being displayed on lock screen 250 of electronic device 100 as an example of a screen that may display a resizable UI view. In implementations in which UI view 205 is displayed on a lock screen and is resizable, UI view 205 may provide various technical advantages. For example, when a device is locked, some devices may encrypt the entire system, including application data associated with applications installed on the electronic device. In order for a user to regain access to data and / or functionality of the electronic device, the user is often required to provide authentication information that proves to the device that the user is an authorized user. By way of example, authentication information may include a passcode entered by the user, or biometric information, such as a fingerprint, voiceprint, or facial feature information.
[0045] Following a lock event of the 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 information and / or the device may automatically obtain the authentication information (e.g., by obtaining imaging or depth data associated with the user's finger or face) and may unlock the device if the authentication information indicates that the user is an authorized user of the device.
[0046] In one or more use cases, a user of an electronic device may use the device to view or otherwise monitor ongoing events in the physical world using applications installed on the electronic device. As an 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 in the ride-sharing vehicle, or a delivery application may be used to monitor the status of an order and / or the location of a delivery vehicle. As another example, a nature-related application may be used to monitor natural phenomena such as tides, phases of the moon, weather, etc.
[0047] In one or more implementations, for example, to prevent unauthorized access to the electronic device and / or to manage power usage by the device, the 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 wish to continue monitoring a physical world event that an application was used to watch or monitor before locking the device. Typically, the user provides authentication information and navigates from the device's lock screen back to the application user interface (UI) that was previously used to watch or monitor the event. However, this may be a time-consuming and inefficient (e.g., including in terms of device power, components, and processing resources) way for a user to continue monitoring physical world events. Therefore, it may be desirable to be able to display a resizable UI view on the electronic device's lock screen that includes certain types of data (e.g., dynamic data such as system data, time-dependent data, or data associated with physical world events). In this manner, a 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 may be difficult to obtain and display data associated with an application on a lock screen of an electronic device without allowing the application to access data and / or resources for which access is locked in the locked state of the device. For example, it may be desirable to display data associated with an application while preventing the application itself from running on the electronic device and / or receiving information regarding user interactions with the lock screen of the electronic device (e.g., information that is typically protected by the device until the user provides authentication information and attempts to interact with the application).
[0049] Aspects of the subject technology can provide a resizable UI view, such as UI view 205 of Figures 2-4, while the electronic device is in a locked state in a manner that is power efficient and maintains user privacy and / or device security. For example, by providing state, trigger, and / or transition definitions to system processes of electronic device 100 before electronic device 100 enters the locked state, UI view 205 can be displayed on lock screen 250 in a manner that appears to respond to user interactions, data triggers, and / or other content on lock screen 250 while electronic device 100 is in the locked state, without allowing underlying applications to receive information regarding user interactions with the electronic device or other content displayed on the lock screen. In this manner, the privacy that a user may expect when their device is locked can be maintained and protected.
[0050] Although various examples are described herein in which UI view 205 is displayed on a lock screen of an electronic device, such as lock screen 250 of Figures 2-4, UI view 205 may also be displayed on other screens of the electronic device, such as a home screen of the electronic device (e.g., while the electronic device is unlocked), and updated and / or animated using state, transition, and / or trigger definitions from the underlying application. In one or more implementations, aspects of the subject technology can provide a resizable UI view of the home screen in a power-efficient and resource-efficient manner (e.g., in terms of processing and / or memory resources), such as by allowing a system process to handle the display aspects (e.g., resize animations) of an application's UI view while the application and / or the application's full UI is inactive on the electronic device. For example, regardless of whether UI view 205 is displayed on a lock screen or home screen or any other screen of electronic device 100, providing state definitions, trigger definitions, and / or transition definitions to a system process of electronic device 100 before electronic device 100 displays UI view 205 may enable UI view 205 to be displayed in a manner that is power and computing resource (e.g., in terms of processing and / or memory resources) efficient by dynamically displaying UI view 205 across multiple states without requiring operation of the underlying applications.
[0051] In various implementations described herein, whether a resizable UI view is displayed on a lock screen or home screen of an electronic device, in addition to the privacy, power efficiency, and / or computing resource efficiency advantages discussed above, aspects of the subject technology can also provide advantages in terms of developer and user efficiency. For example, an application developer can provide information to a system process of an electronic device that allows the system process to animate aspects of the UI view for the application information without the developer having to create or provide code for the animation. As another example, if a user desires to view more or less information in a UI view, the user is provided with the ability to directly interact with the UI view (e.g., click, tap, or pinch) to cause a resize of the UI view to allow for an increase or decrease in the amount of data displayed (rather than, for example, the user editing device settings to create a new fixed-size UI view to replace the current fixed-size UI view). As another example, whether displayed on a lock screen or home screen of an electronic device, a resizable UI view disclosed herein can allow the UI view to be automatically resized in response to a data trigger. In this way, a user can be provided with additional information when it is relevant to the user in a way that may be difficult or impossible with a fixed-sized UI view.
[0052] Further details of aspects of the subject 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 conjunction with Figures 5-9.
[0053] FIG. 5 illustrates an exemplary architecture that may be implemented by an electronic device 100 in accordance with one or more implementations of the subject technology. For purposes of explanation, portions of the architecture of FIG. 5 are described as being implemented by the electronic device 100 of FIG. 1, such as by the processor and / or memory of the electronic device. However, appropriate portions of the architecture may be implemented by any other electronic device. However, not all of the depicted components may be used in all implementations, and one or more implementations may include additional or different components than those shown in the figures. Variations in the configuration and type of components may be made without departing from the spirit or scope of the claims presented herein. Additional, different, or fewer components may be provided.
[0054] Various portions of the architecture of FIG. 5 may be implemented in software or hardware, including by one or more processors and a memory device that includes instructions that, when executed by the processor, cause the processor to perform the operations described herein. In the example of FIG. 5, electronic device 100 includes hardware components such as display 110 and memory 502. In this example, electronic device 100 also includes one or more logical processes, such as system process 500, and / or one or more applications 506. For example, system process 500 and / or one or more applications 506 may be logical processes executed from memory 502 by one or more processors of electronic device 100. System process 500 may be, for example, a process defined in hardware and / or as part of an operating system of electronic device 100.
[0055] In the example of FIG. 5 , electronic device 100 (e.g., memory 502) stores code for three applications 506 (e.g., “App 1”, “App 2”, and “App 3”). However, it is understood that this is merely an example and 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. Applications 506 may, for example, have been previously downloaded to and installed on electronic device 100. One or more of applications 506 may be associated with a UI view that displays data, which may be dynamic data (e.g., application-specific information, system status information, and / or information associated with physical world events as described herein) periodically, occasionally, or continuously while application 506 and / or the full user interface of 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 a UI view to a system process 500. In this example, app 1 provides one or more app 1 state definitions to the system process 500 for one or more respective states of a corresponding UI view of app 1. As shown in Figure 5, the system process 500 can store the state definitions provided by app 1 in memory 502 in association with app 1 (e.g., in an archive of state definitions).
[0057] For purposes of this discussion, UI view 205 discussed herein in connection with Figures 2-4 may be a UI view for an application 506 designated as app 1 in Figures 5-7 (e.g., app 1 may be the underlying application for UI view 205). As shown in Figure 5, one or more additional applications may also provide state definitions of their respective UI views to system process 500 for storage in memory 502 in association with the applications (e.g., app 2 may provide an app 2 state definition, and app 3 may provide an app 3 state definition to system process 500 for storage in memory 502 in association with their respective application 506).
[0058] In the example of Figure 5, the app 1 state definition provided by app 1 to system process 500 includes information used by system process 500 to display UI views 205 of 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 a first UI view (e.g., UI view 1 corresponding to UI view 205), a first state (e.g., state 1) of Figure 2, a second state (e.g., state 2) of Figure 3, and a third state (e.g., state 3) of Figure 4.
[0059] As shown, the state definition of UI view 1 (e.g., UI view 205) may include a definition of one or more UI elements of the UI view, a definition of one or more UI state transitions of the UI view, a definition of a size of one or more of the UI elements of the UI view, an identifier of one or more of the UI elements of the UI view, a size of the UI view (e.g., the size of UI view 205), and / or a 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, backgrounds, etc.). For example, for a first state of the UI view 205, the system process 500 may receive, and the memory 502 may store, a definition of the first element 209 (e.g., UI element 1), a definition of the second element 211 (e.g., UI element 2), a definition of a transition of the first element 209 from the first state to another state (e.g., state transition 1), a definition of a transition of the second element 211 from the first state to another state (e.g., state transition 2), a size of the first element 209 in the first state (e.g., UI element 1 size), a size of the second element 211 in the first state (e.g., UI element 2 size), an identifier of the first element 209 (e.g., UI element 1 identifier), an identifier of the second element 211 (e.g., UI element 2 identifier), a size of the bounds 215 of the UI view 205 (e.g., UI view size), and / or a layout of the UI view 205 (e.g., UI view layout). The UI view layout may define the location of the first element 209 and the second element 211 (as one 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 the graphical objects (e.g., a rectangular object with text, a rectangular object with an image, a circular object with text or an image, etc.) and / or data (e.g., data 221 including a source of data 221) for display within the graphical object of the first element 209, an update rate of the data, and / or a color, background, and / or one or more other visual aspects of the first element 209. UI element 2 can define the graphical objects (e.g., a rectangular object with text, a rectangular object with an image, a circular object with text or an image, etc.) and / or data (e.g., data 223 including a source of data 223), an update rate of the data, and / or a color, background, and / or one or more other visual aspects of the second element 211. State transition 1 may, for example, define an animation type (e.g., blur in, blur out, translate in, translate out, fade in, fade out, particleize, snap, balloon, rotate, spin, flash, etc.) of an animation for a transition of the first element 209 from a first state to another state. State transition 2 may, for example, define an animation type (e.g., particleize, snap, balloon, rotate, spin, flash, etc.) of an animation for a transition of the second element 211 from a first state to another state. In one or more implementations, if an application does not provide a transition definition for one or more elements, the system process 500 may store a default animation or may determine a transition definition based on the content of the UI view.
[0061] 5, for a second state of UI view 205 (e.g., UI view 1 of app 1), the state definition includes information defining third element 300 (e.g., UI element 3, UI element 3 size, UI element 3 identifier) in addition to 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 first element 209 from the second state to another state (e.g., the first state or the third state), state transition 2 can define an animation for the transition of second element 211 from the second state to another state (e.g., the first state or the third state), and state transition 3 can define an animation for the transition of third element 300 from the second state to another state. In this example, the UI element 1 size in the state definition for state 2 may be larger than the UI element 1 size in the state definition for state 1, the UI element 2 size in the state definition for state 2 may be larger than the UI element 2 size in the state definition for state 1, and the UI view size in the state definition for state 2 may be larger than the UI view size in the state definition for state 1 (e.g., as shown in Figures 2 and 3). In this example, the UI view may define a layout of the location of a third element 300 (e.g., above in the example of Figure 3) relative to the first element 209 and the second element 211.
[0062] In one or more implementations, a transition definition, such as state transition 1 and state transition 2, may include a single transition definition for a UI element that may apply to any transition to or from that UI element in a state transition, or may include multiple transition definitions for particular transition directions between particular pairs of states and / or between pairs of states. In one or more implementations, a transition definition may be defined in one way and a reverse transition may use the inverse of the defined transition, or transition definitions may be defined separately for transitions to and from particular states of a UI element.
[0063] In the example of FIG. 5, the state definition of the third state (e.g., state 3) of FIG. 4 includes a definition of a fourth element (e.g., UI element 4, which may be the same as the first element 209 as in the example of FIG. 4 or may be different from the UI elements included in states 1 and 2), an animation definition (e.g., state transition 4) for a transition of the fourth element from the third state to another state (e.g., to the second state or the first state), a definition of the fourth element in the third state (e.g., UI element 4 size), an identifier (e.g., UI element 4 identifier) for the fourth element, a definition of a size of the UI view 205 in the third state (e.g., a UI view size, such as the bounds 215 or a size of the bounds of the UI view), and a definition of a layout (e.g., relative to the bounds 215) of the fourth element (e.g., a UI view layout). In this example, state transition 4 may define an animation for a 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 UI element 4 size in the state definition for state 3 may be smaller than the UI element 1 size in the state definition for state 1 and the UI element 1 size in the state definition for state 2, and the UI view size in the state definition for state 3 may be smaller than the UI view sizes in the state definitions for states 1 and 2 (e.g., as shown in Figures 2-4).
[0064] 5, only the contents of the app 1 state definition for UI view 1 (e.g., UI view 205) are visible. However, system process 500 may receive and / or memory 502 may store 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.).
[0065] In one or more implementations, the state definitions shown in FIG. 5 (e.g., App1 state definition(s), App2 state definition(s), and App3 state definition(s)) may include all of the state definition information shown in FIG. 5 (e.g., including transition definitions between various states and / or trigger definitions for triggering the transitions). In one or more other implementations, the transition definitions and / or trigger definitions may be provided to the system process 500 from the application 506 separately from the state definitions shown in FIG. 5 (e.g., App1 state definition(s), App2 state definition(s), and App3 state definition(s)). In one or more implementations, the transition definitions may include trigger definitions. In one or more implementations, the state definitions may include trigger definitions. In one or more implementations, the trigger definitions may be determined by the system process 500.
[0066] In one or more implementations, the application 506 may provide the state and transition definitions to the system process 500 via a template (e.g., a single template or multiple templates may be used). In one or more implementations, the application 506 may provide the state and transition definitions to the system process 500 via an application programming interface (API). In one or more implementations, the application 506 may provide the state and transition definitions to the system process 500 via a file system in a template (e.g., the application 506 may store the state and / or transition definitions) and save the template in a known directory that is parsed by the system process 500 (e.g., the definitions may be saved as resource files for the application, etc.). In one or more implementations, application 506 can provide state and transition definitions to system process 500 via a combination of one or more templates and one or more API calls (e.g., a state definition via template and a transition definition via API, a state definition via template and a transition definition via API, or a state definition via API and a transition definition via template). In one or more implementations, the template can have a format consumable by system process 500 to render at least one UI view (e.g., UI view 205) according to information included in the template.
[0067] The provision of a state definition as shown in FIG. 5 may be performed before a corresponding UI view (wherein the state definition defines one or more states) is displayed, such that system process 500 of electronic device 100 can render data and 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, at least for some period of time while the application itself is inactive.
[0068] 6 illustrates operations of electronic device 100 that may be performed after a state definition is provided to system process 500 from application 506 and stored in memory 502. For example, the operations illustrated in FIG. 6 may be performed while electronic device 100 is in a locked state and while lock screen 250 of electronic device 100 is displayed on display 110 of electronic device 100.
[0069] For example, as shown in Figure 6, application 506 of electronic device 100 may be inactive while system process 500 renders a UI view of UI view 205 for display by display 110 of electronic device 100. In the example of Figure 6, 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 renders an app 1 rendered UI view for that state using the retrieved state definition. System process 500 provides app 1 rendered UI view to display 110 for display as UI view 205 (e.g., as in the example of Figure 2).
[0070] As shown in FIG. 6, the system process 500 can also receive app 1 data corresponding to app 1. The system process 500 can include some or all of the app 1 data in the app 1 rendered UI view. For example, the app 1 data can include dynamic data. For example, the app 1 data can include data 221 and data 223 of FIG. 2. The app 1 data can be received from app 1 and / or from a server associated with app 1 that is remote from the electronic device 100. For example, in or along with the state definition(s) provided from the application 506 to the system process 500, the application 506 can provide one or more links to communication channels for system process access to the app 1 data. For example, the system process 500 can use one or more links to subscribe to one or more publication channels to which the application 506 publishes application-related dynamic data. The publication channels can be hosted by one or more servers associated with the application 506. In this manner, the system process 500 can receive app 1 data from a server associated with app 1 while the app 1 is inactive on the electronic device. As examples, app1 data can include score data for an ongoing sporting event from a server associated with a sports-related application installed on electronic device 100, or can include location data for a rideshare vehicle from a rideshare server associated with a rideshare application installed on electronic device 100, or 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 non-volatile storage, 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 in which the UI view 205 displays system data (e.g., battery information, timers, signal strength information, or other data not provided by an application), a system process can generate the data that is displayed in the 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 app 1 rendered UI view. For example, one or more of the applications 506 may also be provided with a separate data extension. A data extension may be a lightweight data provider that allows data from an application 506 to be updated without querying data directly from an associated application 506, thereby avoiding computationally expensive wake-ups or launches of the application 506 to obtain updated data for display by a graphical element.
[0072] In the example of FIG. 6, the app 1 rendered UI view (e.g., rendered UI view 205) is displayed by system process 500 in a single state (e.g., any of the states shown in FIG. 2, FIG. 3, or FIG. 4). FIG. 7 illustrates an example operation of electronic device 100 for rendering a transition between two states of UI view 205 without the involvement of (e.g., without waking or otherwise operating) the underlying application app 1. As illustrated in FIG. 7, while app 1 is inactive, system process 500 can receive a trigger to transition from one state (e.g., state 1) of UI view 1 (e.g., UI view 205) to another state. For example, the trigger can be received through a user interface of electronic device 100, such as by receiving a user interaction with the displayed app 1 rendered state 1 UI view using a touch-sensitive element of display 110. As another example, the trigger can be a data-driven trigger corresponding to an update of app 1 data (e.g., when an individual or team scores at a sporting event or when a rideshare vehicle arrives at a pickup location or destination). In response to a trigger, system process 500 can obtain one or more transition definitions for a transition from state 1 to another state and can animate the transition on display 110 according to the transition definition. For example, as shown in FIG 7, system process 500 can generate an app 1 rendered animated UI state transition according to the transition definition and provide the app 1 rendered animated UI state transition to display 110 for display.
[0073] As an example, the system process 500 can receive an indication of an update to the score of a sporting event in the app 1 data. In response to the indication of the score update, the system process 500 can retrieve state transition 1 and state transition 2 from the state 1 definition of the UI view 1 of the app 1 and can generate an app 1 rendered animated UI state transition from state 1 to state 2 based on the retrieved state transition 1 definition and state transition 2 definition. The app 1 rendered animated UI state transition can include one or more animations of one or more elements of the UI view over time. For example, the app 1 rendered animated UI state transition can include an animation of the first element 209 over time and an animation of the second element 211 over time based on the respective state transition 1 definition and state transition 2 definition. The app 1 rendered animated UI state transition can also include an animation of the introduction of the third element 300 in the UI view over time (e.g., based on state transition 3 and / or other transition definition information previously received from the app 1) and / or an animation of the entire UI view 1 over time during the transition.
[0074] In one or more implementations, when a transition from one state to another state is triggered in system process 500 (e.g., by a user interaction with UI view 205 or another element of the screen on which UI view 205 is displayed, by a data trigger, or by a movement or change of another element of the screen on which UI view 205 is displayed), system process 500 performs a transition process on the elements in both the current state of UI view 205 and the destination state of UI view 205 (e.g., the first element in the example transition from the first state of FIG. 2 to the second state of FIG. 3 ). 209 and second element 211), an element in the current state of UI view 205 that is not in the destination state of the UI view (e.g., third element 300 in the example of a transition from the second state of FIG. 3 to the first state of FIG. 2 or the third state of FIG. 4), and / or an element that is not in the current state of UI view 205 but is in the destination state of UI view 205 (e.g., third element 300 in the example of a transition from the first state of FIG. 2 or the third state of FIG. 4 to the second state of FIG. 3).
[0075] The system process 500 may then identify (e.g., based on application-provided transition definitions and / or system-level preferences) a first animation (e.g., a blended animation, such as based on an interpolated view between a view of the element in the current state and a view of the element in the destination state) for an element included in both the current state and the destination state. The system process 500 may also identify one or more second animations (e.g., fade out, blur out, translate out, particleized and disappearing animations, etc.) for one or more elements included in the current state and not included in the destination state. The system process 500 may also identify one or more tertiary animations (e.g., fade in, blur in, translate in, solidify from particleized animations, etc.) for one or more elements included in the destination state and not included in the current state.
[0076] System process 500 may also determine one or more timelines for transitions of UI view 205 and / or one or more elements thereof without the involvement of an underlying application (e.g., app1). 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 UI view 205 is not aware of (and may not be permitted to be aware of) the other display content.
[0077] As an example, the system process 500 may animate the transition of various elements of the UI view 205 and / or the overall UI view 205 at various different times and / or at various different rates based on system preferences and / or information not provided or accessible by the underlying application for the UI view 205. For example, the transition of the size of the first element 209 of FIG. 2 from the first state of FIG. 2 to the second state of FIG. 3 may occur before and / or faster than the transition of the size of the second element 211 of FIG. 2 from the first state of FIG. 2 to the second state of FIG. 3. As another example, the system process 500 may animate the introduction of the third element 300 of FIG. 3 before or after (e.g., and / or at a different rate than) animating the increase in size of the first element 209 and the second element 211 in the transition from the first state of FIG. 2 to the second state of FIG. 3. In one or more implementations, the system process 500 can determine the time (e.g., a 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 destination state.
[0078] As shown in FIG. 7, the system process 500 can store transition time information 700, which can include one or more transition times and / or one or more transition curves, such as transition curve 702. For example, the transition curve 702 can define a linear or non-linear progression of an interpolated state between a current state of the UI view 205 and a destination 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, blur-out, etc. For example, the example transition curve 702 of FIG. 7, when applied to animating a transition of an element of the UI view 205, causes little change in the element's appearance during the first half of the transition time, causes a rapid change in the element (according to the animation defined for that element) over the third quarter of the transition time, and causes a slow change (according to the animation defined for that element) over the last quarter of the transition time. In this manner, 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 an 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, the system process 500 may define a time (e.g., an overall 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 a cover to the animation for the system-defined time. In the case of a linear curve, applying the curve to the animation may cause the animation to run linearly over the system-defined time. In other example curves, the animation may be held, for example, until the last portion of the transition's time (e.g., the last 50 percent).
[0080] As shown in FIG. 7, in one or more implementations, system process 500 can receive app 1 data while system process 500 is animating the transition, and the app 1 data can be included in the app 1 rendered animated UI state transition (e.g., such that the data can continue to be displayed and / or updated during the animated state transition of the UI view 205).
[0081] FIG. 8 illustrates a flow diagram of an exemplary process for providing a dynamically resizable user interface view in accordance with aspects of the subject technology. The 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 need not be performed in the order shown, and / or one or more blocks of process 800 need not be performed and / or may be replaced by other operations. In some embodiments, a system process of an operating system of an electronic device (e.g., system process 500) performs the process of FIG. 8. In some implementations, the system process is a user interface view display process (e.g., a process for displaying widgets, etc.). In other embodiments, a user interface view display process separate from the operating system of an electronic device (e.g., a process for displaying widgets, etc.) performs the process of FIG. 8.
[0082] In the example of FIG. 8 , at block 802, a system process (e.g., system process 500) of an electronic device (e.g., electronic device 100) may receive, from an application (e.g., application 506, such as “app 1” described herein) running on the electronic device, a state definition (e.g., app 1 state definition) for a plurality of states of a user interface view (e.g., UI view 1 or UI view 205) and one or more transition definitions each defining a transition between two of the plurality of states. In one or more implementations, each of the plurality of states includes at least one display element (e.g., first element 209, second element 211, and / or third element 300), at least one display element size (e.g., UI element N size), and at least one display element identifier (e.g., UI element N identifier). In one or more implementations, the plurality of states of the UI view correspond to at least one physical world event (e.g., a sporting event, a rideshare event, etc.). In one or more implementations, the user interface view may be a user interface view for a widget for an application.
[0083] At block 804, the system process may identify a trigger for a change from one of the multiple states of the user interface view (e.g., a current state) to another of the multiple states of the user interface view (e.g., a destination state). As discussed herein, the trigger may include a user interaction with the user interface view, a user interaction with another user interface view displayed simultaneously with the user interface view, a change in dynamic data displayed within the user interface view, a change in size or location of other content displayed simultaneously with the user interface view, or other user or data trigger. In one or more implementations, the trigger may be an application-defined trigger defined in a state definition and / or transition definition(s) from the application. In one or more implementations, the trigger may be a system-defined trigger.
[0084] At block 806, in response to the trigger, a system process may effectuate a change from one of the plurality of states of the user interface view to another of the plurality of states of the user interface view (e.g., as discussed herein in connection with FIG. 7) in accordance with one or more transition definitions. For example, the system process may effectuate the change, in part, by determining a time (e.g., a transition time) and a curve (e.g., a transition curve 702) for the change and applying one or more transition definitions to the curve. In one or more implementations, the plurality of states may be archived (e.g., in memory 502) by the system process before effecting the change (e.g., before rendering an animation for the transition). In one or more implementations, effecting the change may include animating the change.
[0085] In one or more implementations, the multiple states include a first state (e.g., the second state shown in FIG. 2 ) having a first element (e.g., first element 209) with a first identifier (e.g., UI element 1 identifier) and a second element (e.g., second element 211) with a second identifier (e.g., UI element 2 identifier), and the one or more transition definitions include a first transition definition (e.g., state transition 1) for the first element and a second transition definition (e.g., state transition 2) for the second element. In one or more implementations, the system process effects the change 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 effecting the change, the system process can compare the set of elements of the first state to the set of elements of the second state. For example, before effecting the change, the system process can determine based on the comparison that a second state of the plurality of states includes a first element having a first identifier and a second element having a second identifier (e.g., in an example where the first state corresponds to the first state of FIG. 2 and the second state corresponds to the second state of FIG. 3).
[0087] As another example, before effecting the change, the system process may determine that a second state of the plurality of states includes a first element having a first identifier and does not include a second element having a second identifier based on the comparison (e.g., in an example where the first state corresponds to the first state of FIG. 2 and the second state corresponds to the third state of FIG. 4, or an example where the first state corresponds to the second state of FIG. 3 and the second state corresponds to either the first state of FIG. 2 or the third state of FIG. 4). In this example, animating the transition of the second element using the second transition definition may include animating the removal of the second element from the user interface view (e.g., by animating a fade out, a translate out, a blur out, or a particleization and disappearance animation).
[0088] In one or more implementations, the multiple states include a first state having a first element having a first identifier (e.g., second element 211 of FIG. 2 having identifier UI ELEMENT 2 identifier), a second state not including the first element having the first identifier (e.g., the state shown in FIG. 4), and a third state including the first element having the first identifier (e.g., the state shown in FIG. 3). For example, the first element may have a first size in the first state (e.g., as shown in the examples of FIGS. 2 and 3) and a second size in the third state that is different from the first size. 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 plurality of states includes 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 (e.g., as shown in the examples of FIGS. 2-4). In one or more implementations, the first size and the second size of the user interface view are defined in a state definition received from the application.
[0090] In one or more implementations, the system process receives from the application application information (e.g., app 1 data as discussed herein in connection with FIG. 7) for display within an element of one of the states of the user interface view while one of the states of the user interface view is displayed. In one or more implementations, the system process can also receive from the application additional application information (e.g., additional app 1 data as discussed herein in connection with FIG. 7) for an element of one of the states of the user interface view for display within the element while effecting the change. In one or more implementations, the application information received from the application can include pre-rendered images of the application information for display at a future time as dynamic data within one or more of the states of the UI view. In one or more implementations, the application information received from the application can include application information received from an application extension of the application.
[0091] In one or more implementations, the system process receives, from a server associated with the application, application information (e.g., app 1 data as discussed herein in connection with FIG. 7) for display within an element of one of the multiple states of the user interface view while the one of the multiple states of the user interface view is displayed. In one or more implementations, the system process can also receive, from a server associated with the application, additional application information (e.g., additional app 1 data as discussed herein in connection with FIG. 7) regarding an element of one of the multiple states of the user interface view for display within the element while effecting the change.
[0092] 9 illustrates a flow diagram of an exemplary process for operating an application in an electronic device to provide a dynamically resizable user interface view, in accordance with aspects of the subject technology. The blocks of process 900 are described herein as occurring sequentially or linearly. However, multiple blocks of process 900 may be performed in parallel. In addition, the blocks of process 900 need not be performed in the order shown, and / or one or more blocks of process 900 need not be performed and / or may be replaced by other operations.
[0093] At block 902, an application (e.g., application 506, such as app1) executing on an electronic device (e.g., electronic device 100) may provide to a system process (e.g., system process 500) of the electronic device state definitions for a plurality of states of a user interface view and one or more transition definitions that each define a transition between two of the plurality of states (e.g., as discussed herein in connection with FIG. 5). In one or more implementations, each of the plurality of states includes at least one display element, a size of the at least one display element, and an identifier of the at least one display element.
[0094] In one or more implementations, an application can provide the state and transition definitions via an application programming interface (API). In one or more implementations, an application can provide the state and transition definitions via a file system (e.g., application 506 can store the state and / or transition definitions in templates and save the templates in a known directory that is parsed by a system process). For example, the definitions can be saved as a resource file of the application, etc. In one or more implementations, an application can provide the state and transition definitions through 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, the template can have a format consumable by a system process to render at least one UI view (e.g., UI view 205) according to information included in the template.
[0095] At block 904, an application executing on the electronic device may provide application information (e.g., app1 data) to be displayed by a system process within the user interface view while the user interface view is in at least one of the multiple states. In one or more implementations, the application may provide the system process with the application information for display in association with two or more elements of the user interface view (e.g., first element 209, second element 211, and / or third element 300 described herein in connection with FIGS. 2-4).
[0096] In one or more implementations, the multiple states include a first state (e.g., the state shown in FIG. 4 ) in which the user interface view has a first size and includes a first element (e.g., first element 209) and a second state (e.g., the state shown in FIG. 2 or the state shown in FIG. 3 ) in which the user interface view has a second size larger than the first size and includes the first element and a second element (e.g., second element 211 or third element 300). In one or more implementations, providing application information may include providing at least first application information (e.g., dynamic data 221) for display in association with the first element while the user interface view is in the first state, and providing the first application information (e.g., dynamic data 221) and second application information (e.g., dynamic data 223 and / or data 301) for display in association with the second element while the user interface view is in the second state. In one or more implementations, providing the application information may include providing, by the application to the system process, second application information for the second element while the user interface view is in a first state that does not include the second element (e.g., the application may provide application information for an element regardless of whether the element is currently displayed.) In this manner, the system process can determine what application information to display without informing the application of the display state of the UI view.
[0097] In one or more other implementations, the second application information may be provided to the system process only when the user interface view is in a state in which the second element is included. For example, in one or more implementations, process 900 may also include receiving, by the application from the system process, state transition information indicating a transition from the first state to the second state. For example, the system process may provide the state transition information to the application in response to receiving a trigger at the system process (e.g., as described herein in connection with FIG. 7). In one or more implementations, providing the application information may include providing, by the application to the system process in response to receiving the state transition information, the second application information about the second element.
[0098] In one or more implementations, providing application information from the application to the system process may include providing the first application information and the second application information by providing the system process with one or more links to communication channels for the system process access to the first application information and the second application information according to a state of a user interface view. For example, the links may be used by the system process to subscribe to a publication channel associated with the application, whereby a server associated with the application provides the application information to one or more subscriber processes. In this manner, the system process can receive application information (e.g., app1 data in the examples of FIGS. 6 and 7) according to a state of a UI view from a server associated with the application while the application is inactive on the electronic device.
[0099] In one or more implementations, the application may also provide additional application information to the system process that is displayed in a user interface view by the system process during a transition from one of the multiple states to another of the multiple states (e.g., while the system process is animating the transition in accordance with the transition definition and while the application is inactive on the electronic device).
[0100] As noted above, aspects of the subject technology may include the collection and transfer of data from an application to another user's computing device. This disclosure contemplates that in some cases, this 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, phone numbers, user activity data, user power consumption data, email addresses, home addresses, data or records related 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 recognizes that such uses of personal information data in the present technology may be for the benefit of the user. For example, the personal information data may be used in providing content on an electronic device. Additionally, other uses of personal information data that benefit the user are contemplated by this disclosure. For example, health and fitness data may be used according to user preferences to provide insight into general wellness and as positive feedback to individuals using the technology in pursuit of wellness goals.
[0102] This disclosure contemplates that entities responsible for the collection, analysis, disclosure, transmission, storage, or other use of such personal information data will adhere to well-established privacy policies and / or practices. Specifically, such entities will be 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 prominently and easily accessible by users, and should be updated as data collection and / or use changes. Personal information from users should be collected only for legitimate uses. Furthermore, such collection / sharing should be done after receiving user consent or based on other legitimate grounds specified in applicable law. Moreover, such entities should consider taking all necessary measures to protect and secure access to such personal information data and ensure that others with access to personal information data adhere to those privacy policies and procedures. Furthermore, such entities may subject themselves to third-party assessments to attest to their adherence to widely accepted privacy policies and practices. In addition, policies and practices should be tailored to the specific types of personal information data collected and / or accessed, and should conform to applicable laws and standards, including jurisdiction-specific considerations that may serve to impose higher standards. For example, in the United States, the collection of or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA). Meanwhile, health data in other countries may be subject to other regulations and policies and should be addressed accordingly.
[0103] Notwithstanding the above, the present disclosure also contemplates implementations in which a user selectively blocks use of or access to personal information data. That is, the present disclosure contemplates that hardware and / or software elements may be provided to prevent or block access to such personal information data. For example, when providing dynamic lock screen content on an electronic device, the present technology may be configured to allow a user to select to "opt-in" or "opt-out" of participating in the collection of personal information data during registration for the service or at any time thereafter. In addition to providing "opt-in" and "opt-out" options, the present disclosure contemplates providing notice regarding access or use of personal information. For example, the user may be notified upon download of an app that will access the user's personal information data, and then again immediately before the personal information data is accessed by the app.
[0104] Moreover, it is the intent of this disclosure that personal information data should be managed and processed in a manner that minimizes the risk of unintended or unauthorized access or use. Risk can be minimized by limiting the collection of data and deleting it when it is no longer needed. In addition, where applicable in certain health-related applications, anonymization of data can be used to protect user privacy. De-identification may be facilitated by removing identifiers when appropriate, controlling the amount or specificity of data stored (e.g., collecting location data at a city level rather than an address level), controlling how data is stored (e.g., aggregating data across users), and / or other methods such as differential privacy.
[0105] Thus, while this disclosure broadly covers the use of personal information data to practice one or more of the various disclosed embodiments, this disclosure also contemplates that the various embodiments may be practiced without requiring access to such personal information data, i.e., various embodiments of the technology are not rendered inoperable by the absence of all or a portion of such personal information data.
[0106] FIG. 10 illustrates an exemplary computing device capable of implementing aspects of the subject technology according to one or more implementations. The computing device 1000 may be and / or be part of any computing device or server for producing the features and processes described above, including, but not limited to, a laptop computer, a smartphone, a tablet device, a wearable device such as a smart watch, and the like. The computing device 1000 may include various types of computer readable media and interfaces for various other types of computer readable media. The computing device 1000 includes a permanent storage device 1002, a system memory 1004 (and / or buffers), an input device interface 1006, an output device interface 1008, a bus 1010, a ROM 1012, one or more processing unit(s) 1014, one or more network interface(s) 1016, and / or subsets and variations thereof.
[0107] The bus 1010 collectively represents all system, peripheral, and chipset buses that communicatively connect the various internal devices of the computing device 1000. In one or more implementations, the bus 1010 communicatively connects one or more processing unit(s) 1014 to the ROM 1012, the system memory 1004, and the permanent storage device 1002. From these various memory units, the one or more processing unit(s) 1014 retrieve instructions to execute and data to process in order to perform the processes of the present disclosure. The one or more processing unit(s) 1014 may be a single processor or a multi-core processor in different implementations.
[0108] The ROM 1012 stores static data and instructions needed by one or more processing unit(s) 1014 and other modules of the computing device 1000. The permanent storage device 1002, on the other hand, 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 or optical disk and its 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, a flash drive, and its corresponding disk drive) may be used as the permanent storage device 1002. Like 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 a random access memory. The system memory 1004 may store any of the instructions and data that the one or more processing unit(s) 1014 may need during execution. In one or more implementations, the processes of the present disclosure are stored in the system memory 1004, the permanent storage device 1002, and / or the ROM 1012. From these various memory units, the one or more processing unit(s) 1014 retrieves instructions to execute and data to process in order to execute the processes of one or more implementations.
[0110] The bus 1010 also connects to input and output device interfaces 1006 and 1008. The input device interface 1006 allows a user to communicate information and select commands to the computing device 1000. Input devices that may be used with the input device interface 1006 may include, for example, an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). The output device interface 1008 may allow, for example, the display of images generated by the computing device 1000. Output devices that may be used with the 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 device for outputting information.
[0111] One or more implementations may include a device that functions as both an input and an output device, such as a touch screen. In these implementations, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, haptic feedback, etc., and the input from the user may be received in any form, including acoustic input, voice input, or haptic input.
[0112] 10, the bus 1010 also couples the computing device 1000 to one or more networks and / or one or more network nodes via one or more network interface(s) 1016. In this manner, 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 may be used in conjunction with the present disclosure.
[0113] Implementations within the scope of this disclosure may be implemented in part or in whole using a tangible computer-readable storage medium (or one or more types of tangible computer-readable storage media) encoding one or more instructions. The tangible computer-readable storage medium may also be non-transitory in nature.
[0114] A computer-readable storage medium may be any storage medium that can be read, written, or otherwise accessed by a general-purpose or special-purpose computing device, including any processing electronics and / or processing circuitry capable of executing instructions. For example, but not limited to, a computer-readable medium may include any volatile semiconductor memory, such as RAM, DRAM, SRAM, T-RAM, Z-RAM, and TTRAM. A computer-readable medium may 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] Additionally, the computer-readable storage medium may include any non-semiconductor memory, such as optical disk storage, magnetic disk storage, magnetic tape, 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 the computing device, while in other implementations, the tangible computer-readable storage medium may be indirectly coupled to the computing device, for example, via one or more wired connections, one or more wireless connections, or any combination thereof.
[0116] The instructions may be directly executable or may be used to develop executable instructions. For example, the instructions may be implemented as executable or non-executable machine code, or as instructions in a high-level language that may be compiled to generate executable or non-executable machine code. Furthermore, the instructions may also be implemented as or include data. Computer-executable instructions may also be structured in any format, including routines, subroutines, programs, data structures, objects, modules, applications, applets, functions, and the like. As will be recognized by those skilled in the art, details including but not limited to the number, structure, order, and structure of the instructions may vary significantly without changing the underlying logic, function, processing, and output.
[0117] While the above discussion primarily refers to microprocessors or multi-core processors executing software, one or more implementations are performed by one or more integrated circuits, such as an ASIC or FPGA(s), which in one or more implementations execute instructions stored within the circuitry itself.
[0118] Those skilled in the art will appreciate that the various exemplary blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or a combination of both. In the above, the various exemplary blocks, modules, elements, components, methods, and algorithms have been generally described in terms of their functionality to illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends on the design constraints imposed on the overall system and the particular application. Those skilled in the art will be able to implement the described functionality in various ways for each particular application. The various components and blocks may be arranged differently (e.g., arranged in a different order or divided in a different way) without departing from the scope of the technology of the present application.
[0119] It will be understood that any particular order or hierarchy of blocks in the disclosed processes is an example of an example approach. Based on design preferences, it will be understood that the particular order or hierarchy of blocks in the processes may be rearranged or that the illustrated blocks may all be executed. Any of the blocks may be executed simultaneously. In one or more implementations, multitasking and parallel processing may be advantageous. Furthermore, it will be understood that the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and that the program components (e.g., computer program products) and systems described may generally be integrated together in a single software product or packaged in multiple software products.
[0120] As used herein and in the claims of this application, the terms "base station," "receiver," "computer," "server," "processor," and "memory" all refer to electronic or other technological devices. These terms exclude people or groups of people. For purposes of this specification, the terms "display" or "displaying" mean displaying on an electronic device.
[0121] As used herein, the phrase "at least one" preceding a list of items, with the terms "and" or "or" separating any of the items, modifies the list as a whole and not each member (i.e., each item) of the list. The phrase "at least one" does not require the selection of at least one of each listed item; rather, the phrase allows for the inclusion of 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. By way of 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 terms "configured to," "operable to," and "programmed to" do not imply any specific tangible or intangible modification of the subject matter, but rather are intended to be used interchangeably. 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 programmed to execute code or operable to execute code.
[0123] The phrases "one aspect," "that aspect," "another aspect," "some aspects," "one or more aspects," "one implementation," "that implementation," "another implementation," "some implementation," "one or more implementations," "one embodiment," "that embodiment," "another embodiment," "some implementation," "one or more implementations," "a configuration," "that configuration," "another configuration," "some configuration," "one or more configurations," "the technology of this application," "the disclosure," "the disclosure," "other variations thereof," and the like are used for convenience and do not imply that the disclosure of such phrase(s) is essential to the technology of this application or that such disclosure applies to all configurations of the technology of this application. The disclosure of such phrase(s) may apply to all configurations, or to one or more configurations. The disclosure of such phrase(s) may provide one or more examples. Phrases such as "aspect" or "some 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 "serving as an example, instance, or illustration." Any embodiment described herein as "exemplary" or "example" is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, to the extent that terms such as "include," "have," and the like are used in the specification or claims, such terms are intended to be inclusive in a similar manner as the term "comprise" is interpreted when "comprise" is used as a transitional term in the claims.
[0125] All structural and functional equivalents to the elements of the various embodiments described throughout this disclosure that are known or later become known to those skilled in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is made public, regardless of whether such disclosure is expressly recited in the claims. No claim element is to be construed under the provisions of 35 U.S.C. 112(f) unless the element is expressly recited using the phrase "means for" or, in the case of a method claim, the element is recited using the phrase "step for."
[0126] The foregoing description is provided to enable those skilled in the art to practice 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 may be applied to other embodiments. Thus, the claims are not intended to be limited to the embodiments set forth herein, but are to be accorded the full scope consistent with the claims as literalized, and references to elements in the singular are not intended to mean "one and only one" unless otherwise specified, but rather "one or more." The term "some" refers to one or more unless otherwise specified. Pronouns in the masculine (e.g., he) include the feminine and neuter genders (e.g., she and its), and vice versa. Headings and subheadings, if any, are used for convenience only and are not intended to limit the disclosure of this application.
Claims
1. 1. A method comprising: receiving, by a system process of an electronic device, from an application executing on the electronic device, state definitions for a plurality of states for a user interface view, each of the plurality of states including at least one display element, a 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; identifying, by the system process, a trigger for a change of the user interface view from one of the plurality of states to another of the plurality of states of the user interface view; and effecting, in response to the trigger, by the system process and in accordance with the one or more transition definitions, the change from one of the plurality of states of the user interface view to another of the plurality of states of the user interface view.
2. The method of claim 1 , wherein the system process accomplishes the change in part by determining a time and curve for the change and applying the one or more transition definitions to the curve.
3. 2. The method of claim 1 , wherein the plurality of states includes 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. 4. The method of claim 3, wherein the system process effects the change by animating a transition of the first element using the first transition definition and animating a transition of the second element using the second transition definition.
5. The method of claim 4 , further comprising comparing, by the system process, the set of elements in the first state to a set of elements in a second state before effecting the change.
6. 6. The method of claim 5, further comprising, prior to effecting the change, determining, by the system process, based on the comparison, that the second state of the plurality of states includes the first element having the first identifier and the second element having the second identifier.
7. 6. The method of claim 5, further comprising: prior to effecting the change, determining, by the system process, based on the comparison, that the second state of the plurality of states includes the first element having the first identifier and does not include the second element having the second identifier.
8. 8. The method of 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. 2. The method of claim 1 , wherein the plurality of states includes a first state with a first element having a first identifier, a second state that does not include the first element having the first identifier, and a third state that includes the first element having the first identifier.
10. 10. The method of claim 9, wherein the first element has a first size in the first state and a second size in the third state that is different from the first size.
11. The method of claim 1 , wherein the plurality of states includes 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. 2. The method of claim 1, further comprising receiving, by the system process, from the application, application information for display within an element of the one of the multiple states of the user interface view while the one of the multiple states of the user interface view is displayed.
13. 13. The method of claim 12, further comprising receiving, by the system process, from the application additional application information about the element in one of the multiple states of the user interface view for display within the element while the change is being effected.
14. The method of claim 1 , wherein the user interface view is a user interface view of a widget of the application.
15. 1. A method, comprising: using an application executing on an electronic device, providing to a system process of the electronic device state definitions for a plurality of states for a user interface view, each of the plurality of states including at least one display element, a 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; providing application information to the system process for display by the system process 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 includes 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 element and a second element, and providing the application information includes: providing at least first application information for display in association with the first element while the user interface view is in the first state; and providing the first application information and second application information for display in association with the second element while the user interface view is in the second state.
17. 17. The method of claim 16, further comprising receiving, by the application, state transition information from the system process indicating a transition from the first state to the second state, and wherein providing the application information comprises providing, by the application to the system process in response to receiving the state transition information, the second application information for the second element.
18. 17. The method of 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 a state of the user interface view.
19. 16. The method of claim 15, further comprising providing, by the application, to the system process additional application information for display 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. 1. A non-transitory computer-readable medium storing instructions for a user interface view display process, the instructions, when executed by one or more processors of an electronic device, causing the one or more processors to: receiving from an application executing on the electronic device a state definition for a plurality of states for a user interface view, each of the plurality of states including at least one display element, a 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; identifying a trigger for a change of the user interface view from one of the plurality of states to another of the plurality of states of the user interface view; A non-transitory computer-readable medium that, in response to the trigger, effects the change from one of the plurality of states of the user interface view to another of the plurality of states of the user interface view in accordance with the one or more transition definitions.
Citation Information
Patent Citations
Smooth layout animations for continuous and discontinuous properties
JP2012521041A
Animation between visualization objects in a virtual dashboard
JP2022505469A
Animated user interface control elements
US20090150813A1
Styleable transitions
US20190096115A1
Framework providing application programming interface for user interfaces and animation
WO2019236419A1