Patent Application
20150222691
Traditional products that can be controlled via a user device generally have a standalone user interface such as a website or an application that communicates with the product. As an example, a traditional speaker system that is capable of being controlled by a user's mobile phone may have a corresponding application that is installed on the user's mobile phone. The application may be accessed by a user via the mobile phone and the user may control the speakers via a user interface corresponding to the application. However, a user may be required to install multiple applications that correspond to multiple products, cluttering up the user's user device.
According to implementations of the disclosed subject matter, the presence of a physical device may be detected and communication with the physical device may be established. A device identification corresponding to the detected first physical device may be extracted. A widget associated with the detected physical device may be received based on the extracted device identification and the widget may contain template information. A template may be received based on the template information such that values from the template may be bound with the widget and the widget may be compiled and rendered based on the bound values. The widget may be rendered in a hub application that contains control interfaces for multiple physical devices.
Systems and techniques according to the present disclosure multiple physical devices may be controlled via a hub application using widgets associated with the physical devices and templates that allow configuration of the hub application. Additional features, advantages, and implementations of the disclosed subject matter may be set forth or apparent from consideration of the following detailed description, drawings, and claims. Moreover, it is to be understood that both the foregoing summary and the following detailed description include examples and are intended to provide further explanation without limiting the scope of the claims.
The accompanying drawings, which are included to provide a further understanding of the disclosed subject matter, are incorporated in and constitute a part of this specification. The drawings also illustrate implementations of the disclosed subject matter and together with the detailed description serve to explain the principles of implementations of the disclosed subject matter. No attempt is made to show structural details in more detail than may be necessary for a fundamental understanding of the disclosed subject matter and various ways in which it may be practiced.
Traditionally, physical devices that are controlled via a user electronic device utilize a standalone application for each physical device. Alternatively or in addition, a manufacture of a physical device cannot customize a central application that controls multiple physical devices. Accordingly, a user may be required to switch between applications or may not be able to control physical devices as intended by the manufacturer due to lack of customization.
According to techniques disclosed herein, a hub application may be used to control multiple physical devices. For example, it may provide interfaces for a user to control lighting devices, televisions, media playback devices such as set-top boxes and game consoles, and/or other electronic devices. More generally, a physical device as disclosed herein may be any device configured to electronically communicate with a user device and may include lighting devices, entertainment devices, appliances, audio devices, video devices, media devices, securing devices (e.g., door locks, window controls, etc.), or the like. A physical device may communicate with a user device in any applicable manner such as a wired or wireless connection. A wireless connection may be established using any wireless medium such as Wi-Fi, Bluetooth™, radio frequency, infrared, near field communication, or the like. A physical device may be controlled by a hub application by receiving a widget associated with the physical device from a server (e.g., a third party manufacturer server, a server that stores widgets, etc.), which contains a pointer to a template such that the hub application interface is configured by compiling the widget using content contained in the template. The widget may enable a manufacturer to customize brand and product information for their products within a hub application while the hub application maintains a consistent look and feel for control of various physical devices. Additionally, a widget may extend existing hub applications to support new devices that are shipped independent of a hub application's release cycle. Thus, techniques and systems disclosed herein may allow for control of multiple disparate devices, without requiring the user to identify, install, learn, or otherwise interact with entirely separate applications or user interfaces for each device.
As shown in
Alternatively, the hub application may transmit a request for physical devices, within communication range of a user device, to transmit a signal identifying the user devices. The hub application may then determine if there is a new physical device which has not previously been configured and, based on the determination, initiate configuration of the hub application for control of the newly detected physical device. As an illustrative example, as shown in
As shown at step 330, device information corresponding to a detected physical device may be extracted via the communication with the physical device. The device information may be any applicable information that enables identification of the physical device and/or software associated with the physical device and may include information such as a model number, vendor ID, device type, device version, or the like.
According to an implementation of the disclosed subject matter, a user device may communicate with a server or storage entity. The server or storage entity may be a third party manufacturer entity, a widget storage entity, or the like. At step 340, a widget containing template information associated with a corresponding physical device may be receive based on extracted device information. The extracted device identification may be used to either determine which server or storage entity to request a widget from, to enable a server or storage entity to extract a corresponding widget, or both. As an example, a user device may receive a lamp model number and vendor ID from a recently powered on lamp. The user device may identify a manufacturer server based on the vendor ID and communicate with the manufacturer server based on the identification. The user device may provide the lamp model number to the manufacturer server and the manufacturer server may identify a corresponding widget based on the lamp model number. More specifically, the manufacturer server may contain multiple widgets that may be associated with various products produced by the manufacturer. The user device may provide the manufacturer server with the lamp model number such that the manufacturer server can identify the widget corresponding to the lamp based on the lamp model number. Subsequently, the manufacturer server may provide the user device with the identified widget.
At step 350, a widget corresponding to a physical device and containing template information may be transmitted from the manufacturer server to a user device. The widget may enable a manufacturer to customize brand and product information for their products within a hub application while the hub application maintains a consistent look and feel for control of various physical devise. The template information may identify one or more templates that are required to compile the widget. The templates may be identified using template IDs that distinguish one template from another, and may contain any applicable interface or back end values such as icons, graphics, color schemes, images, buttons, or the like. The values may be static such as an icon to be displayed or a color to be shown to a user. Alternatively or in addition, a value may be dynamic. An example of a dynamic value may be a variable that is to be replaced by device name when a use is presented with the controls within the hub application. A dynamic value in a template may be bound with a widget at runtime and may define the type (e.g., device profile) that a compilation manager may use to deserialize a payload to extract runtime values. Notably, a upon receiving a template based on a template ID, a widget manager may instantiate a widget by binding the template received to either static (e.g., custom drawables) or dynamic values (e.g., runtime states like brightness or on-off state, etc.). Subsequently, the instantiated widget may be a portion of the user interface of a hub application that a user may interact with to control the physical device. As a specific example, the following code corresponds to a customized light widget with a logo:
Here, the code within the template contains the template ID “@+id/simple_light_template” and contains layout information to bind with a widget.
A template may be requested from an application server that contains templates that are designated for the hub application. The user device and/or hub application may provide the application server with the template ID extracted from a widget corresponding to a physical device. In response, the application server may provide the requested template. The widget then may be rendered at the user device using the template. Alternatively, a template manager may load pre-compiled templates supported by the hub application when the hub application is activated. Accordingly, when a new physical device is detected and a widget corresponding to the physical device is received, the template manager may be accessed by the hub application to retrieve a template identified by a widget. Subsequently, the widget may be compiled by binding to values received from the respective template. The widget may be compiled in any applicable manner and the complied widget may result in the rendered interface to be rendered via the hub application.
As an illustrative example of the disclosed subject matter, as shown in
As another example of an implementation of the disclosed subject matter, as shown in
As an illustrative example of a customized user interface corresponding to a physical device, as shown in
Implementations of the presently disclosed subject matter may be implemented in and used with a variety of component and network architectures.
The bus 21 allows data communication between the central processor 24 and the memory 27, which may include read-only memory (ROM) or flash memory (neither shown), and random access memory (RAM) (not shown), as previously noted. The RAM can include the main memory into which the operating system and application programs are loaded. The ROM or flash memory can contain, among other code, the Basic Input-Output system (BIOS) which controls basic hardware operation such as the interaction with peripheral components. Applications resident with the computer 20 can be stored on and accessed via a computer readable medium, such as a hard disk drive (e.g., fixed storage 23), an optical drive, floppy disk, or other storage medium 25.
The fixed storage 23 may be integral with the computer 20 or may be separate and accessed through other interfaces. A network interface 29 may provide a direct connection to a remote server via a telephone link, to the Internet via an internet service provider (ISP), or a direct connection to a remote server via a direct network link to the Internet via a POP (point of presence) or other technique. The network interface 29 may provide such connection using wireless techniques, including digital cellular telephone connection, Cellular Digital Packet Data (CDPD) connection, digital satellite data connection, WiFi, Zigbee™, Z-Wave™, or the like. For example, the network interface 29 may allow the computer to communicate with other computers via one or more local, wide-area, or other networks, as shown in
Many other devices or components (not shown) may be connected in a similar manner (e.g., caches, servers, appliances, lighting, electric vehicle chargers, pumps, document scanners, digital cameras and so on). Conversely, all of the components shown in
More generally, various implementations of the presently disclosed subject matter may include or be implemented in the form of computer-implemented processes and apparatuses for practicing those processes. Implementations also may be implemented in the form of a computer program product having computer program code containing instructions implemented in non-transitory and/or tangible media, such as floppy diskettes, CD-ROMs, hard drives, USB (universal serial bus) drives, or any other machine readable storage medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing implementations of the disclosed subject matter. Implementations also may be implemented in the form of computer program code, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing implementations of the disclosed subject matter. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits. In some configurations, a set of computer-readable instructions stored on a computer-readable storage medium may be implemented by a general-purpose processor, which may transform the general-purpose processor or a device containing the general-purpose processor into a special-purpose device configured to implement or carry out the instructions. Implementations may be implemented using hardware that may include a processor, such as a general purpose microprocessor and/or an Application Specific Integrated Circuit (ASIC) that implements all or part of the techniques according to implementations of the disclosed subject matter in hardware and/or firmware. The processor may be coupled to memory, such as RAM, ROM, flash memory, a hard disk or any other device capable of storing electronic information. The memory may store instructions adapted to be executed by the processor to perform the techniques according to implementations of the disclosed subject matter.
The foregoing description, for purpose of explanation, has been described with reference to specific implementations. However, the illustrative discussions above are not intended to be exhaustive or to limit implementations of the disclosed subject matter to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The implementations were chosen and described in order to explain the principles of implementations of the disclosed subject matter and their practical applications, to thereby enable others skilled in the art to utilize those implementations as well as various implementations with various modifications as may be suited to the particular use contemplated.
