Object model for a user interface   

Abstract: Various embodiments provide techniques and processes for defining elements of a user interface (UI) using a tree of objects created based on a markup language. In some embodiments, a client application provides markup that defines one or more aspects of a UI to an application programming interface (API). The API parses the markup to determine a namespace and one or more UI elements defined by the namespace. Instances of the UI elements are created, and properties of the UI elements are set on the instances. A user interface may then be displayed that includes the instances of the UI elements.

This application is a divisional of and claims priority under 35 U.S.C. §121 to application Ser. No. 12/163,367 filed on Jun. 27, 2008 and titled “Object Model for a User Interface,” the disclosure of which is incorporated by reference herein in its entirety.

Object-oriented programming (OOP) provides techniques for creating binary software components (objects) that can interact with each other. One example of OOP is the Component Object Model (COM). COM specifies an object model and programming requirements that enable this object interaction. A COM object can be created using one of a variety of different programming languages (e.g., C++, Visual Basic, and so on). The flexibility and simplicity of COM have enabled it to become a widely adopted and long-lived standard. However, certain aspects of COM present challenges when creating a graphical user interface (GUI).

First, COM typically lacks the ability to support a new object class which extends from a base class. As a result, a first party is unable to create a COM object that derives from and extends a COM object that is created by another party. Second, it is difficult to interface COM objects with declarative markup languages (e.g., XAML) to specify layouts, appearances, behaviors of a particular part or parts of a GUI. These particular challenges can make it difficult for COM to be used to implement a GUI.

SUMMARY

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Various embodiments provide techniques and processes for defining elements of a user interface (UI) using a tree of objects created based on a markup language. In some embodiments, a client application provides markup that defines one or more aspects of a UI to an application programming interface (API). The API parses the markup to determine a namespace and one or more UI elements defined by the namespace. Instances of the UI elements are created, and properties of the UI elements are set on the instances. A user interface may then be displayed that includes the instances of the UI elements.

BRIEF DESCRIPTION OF THE DRAWINGS

The same numbers are used throughout the drawings to reference like features.

FIG. 1 illustrates one example of an operating environment in which various principles and techniques described herein for generating user interface elements can be employed in accordance with one or more embodiments.

FIG. 2 illustrates one example of an object-oriented architecture that can implement techniques and processes for user interface creation discussed herein, in accordance with one or more embodiments.

FIG. 3 is a flow diagram of one example process for generating user interface elements utilizing techniques discussed herein, according to one or more embodiments.

FIG. 4 is a flow diagram of one example process for generating user interface elements utilizing the object-oriented architecture discussed herein, according to one or more embodiments.

DETAILED DESCRIPTION

Various embodiments provide a user interface (UI) platform that implements aspects of a markup language (e.g., XML, XAML, and so on) and object-oriented programming methods to provide flexible and customizable ways of defining and/or generating a graphical UI. While the UI platform is discussed with reference to component object model (COM) methodology and terminology, this is not intended to be limiting, and any suitable object-oriented programming methodology may be utilized without departing from the spirit and scope of the claimed embodiments.

The UI platform includes a User Interface Object Model (UIOM) that enables developers to create new object class types that inherit and/or override functionality from base classes. UIOM also enables objects and/or object properties to be referenced by name (e.g., within a namespace), such that objects and/or properties can be coded in a markup language to specify the layout, appearance, and/or behavior of one or more aspects of a UI. In some embodiments, UIOM includes an application programming interface (API) that manages the loading, registration, instantiation, and/or initialization of UIOM classes. A UIOM class may also inherit properties and/or behavior from a base class defined by UIOM.

In an implementation example, the UI platform receives markup from a client application that defines one or more aspects of a UI. The UI platform then parses the markup looking for a namespace and a class name of a UI object within the namespace. In some embodiments, a namespace comprises multiple class type objects, with each class type object representing one or more UI elements such as a button, a textbox, a banner, and so on. In this example, if the platform encounters the markup “acme:textbox”, the platform recognizes that the markup designates the namespace “acme” and the “textbox” class name within the “acme” namespace. The UI platform then creates a tree of one or more COM objects that correspond to the namespace “acme” and class name “textbox”, and sets properties (e.g., visual attributes such as size, color, and so on) on the object(s) within the tree. The tree includes a “textbox” node with particular properties, and the “textbox” node is used to display a textbox in a UI. As discussed above, the “textbox” node may inherit properties and or functionally from a UIOM base class.

In the discussion that follows, a section entitled “Operating Environment” is provided and describes an environment in which one or more embodiments can be employed. Following this, a section entitled “Example Architecture” is provided and describes one example of an object-oriented architecture that can implement various principles and techniques discussed herein. Next, a section entitled “Example Processes” discusses a few examples of processes that may implement various techniques discussed herein for defining and/or generating various aspects of a user interface. Following this, a section entitled “Implementation Specifics” discusses a variety of implementation details for implementing the UIOM architecture in one or more embodiments. Finally, some example object interfaces are provided that implement a variety of UI creation methods that utilize the UIOM architecture.

FIG. 1 illustrates generally at 100 one example of an operating environment that is operable to employ one or more aspects of the UI platform, in accordance with one or more embodiments. Environment 100 includes a computing device 102 having one or more processors 104, one or more input/output devices 106, and one or more computer-readable media 108. The computing device 102 can be embodied as any suitable computing device such as, by way of example and not limitation, a desktop computer, a portable computer, or a handheld computer such as a personal digital assistant (PDA), cell phone, and the like. The computing device 102 is configured such that it can interface with one or more networks (not shown), such as a local area network, a wide area network, the Internet, the World Wide Web, and so on.

Stored on computer-readable media 108 are one or more client applications 110 and a UI platform 112. Examples of client applications include a web browser, a media rendering application, an instant messaging client, a web development application, and so on. As part of UI platform 112 are markup parser 114, a User Interface Object Model (UIOM) framework 116 and UI customization features 118. Markup parser 114 processes markup code and converts the markup into a form that can be utilized by the UI platform. The UIOM framework is an object model that provides, among other things, the ability for class types to extend and/or override functionality in base classes, as well as functionality for creating and initializing instances of classes based on markup namespace identifiers. The UI customization features enable developers and other parties to create custom UI objects and/or properties that can be used by the UIOM framework to create a UI.

FIG. 2 illustrates at 200 one example of an object-oriented architecture that may implement the techniques and processes for UI creation discussed herein. The architecture may be implemented in connection with any suitable hardware, software, firmware, or combination thereof. As part of the architecture are one or more client applications 110, examples of which are given above. Illustrated at 202 are some of the core objects of the UIOM framework. These core objects include a Type Manager 204, a Namespace Manager 206, and a Class Type Manager 208. Illustrated at 210 are some UI customization objects that can be created and/or otherwise utilized by the UIOM framework to create a UI. These UI customization objects include, in this example, a Namespace Type Factory 212, a Class Type Object 214, a Base Class Type Object 216, one or more Class Instances 218, and one or more Base Class Instances 220.

Each of the objects in architecture 200 includes one or more interfaces that can expose functions and/or methods that can be accessed by applications, objects, and/or processes to implement the techniques for UI creation discussed herein. In this particular example, the double-headed arrows indicate that a particular object is created and/or owned by another object, application, and/or process. For example, Type Manager object 204 may be created by client application 110. The single-headed arrows indicate that one object is holding a reference to another object. Implementation examples of architecture 200 and its interfaces and methods are discussed below.

In example architecture 200, the Type Manager object is a top-level interface to the UIOM framework. The Type Manager manages loading and creation of classes of objects for one or more namespaces. In some embodiments, a namespace represents one or more sets of related classes of UI elements that are defined by the same party (e.g., a software developer). One or more of the namespaces are represented by the Namespace Manager object 206, which handles communication with one or more Namespace Type Factory objects 212 provided by an entity that creates custom types (e.g., custom UI objects). A custom type is represented by the Class Type object 214, which specifies a base class type, and provides a factory for creating instances of the class. In some embodiments, the Class Type object provides functionality to query for class-specific interfaces to set properties, subscribe to events, and access other functionality that may be exposed by an interface.

FIGS. 3 and 4 illustrate examples of processes and operating scenarios that implement aspects of the principles and techniques discussed herein, according to one or more embodiments. These processes and/or scenarios are discussed in reference to architecture 200. This is not intended to be limiting, however, and the processes and/or scenarios may be implemented by any suitable architecture and/or UI framework. These processes can be implemented in connection with any suitable hardware, software, firmware, or combination thereof.

FIG. 3 illustrates at 300 a flow diagram that represents one process that utilizes the UIOM framework to generate a UI. At 302, a client application is launched. At 304, the client application provides markup to the UIOM framework. In some embodiments, the markup specifies one or more aspects of a UI (e.g., a textbox, a radio button, a banner, and so on). At 306, the markup is parsed to extract one or more UI specifications from the markup. The UIOM framework may include a markup parser and/or the UIOM framework may provide the markup to an external parser, which then returns the parsed markup to the framework for further processing.

At 308, the UIOM framework determines a namespace and a class name from the parsed markup. In one example, the UIOM framework receives the markup “acme:textbox”, from which it determines that the namespace is “acme” and the class name is “textbox”. At 310, the UIOM framework creates a tree of objects that includes one or more class types and class instances that correspond to the namespace and the class name. In the current example, the class instances include a textbox instance of the textbox class. At 312, one or more properties are set on the objects of the object tree, which may include the class instance(s). Continuing the current example, the size and color of the textbox are specified. At 314, one or more of the class instances are displayed. In the current example, this can include displaying the text box in a UI.

FIG. 4 illustrates a process 400 for utilizing one or more aspects of the UIOM architecture to generate a UI. Some aspects of process 400 explain in more detail certain implementation specifics of process 300, discussed above. Also, for purposes of example only, process 400 is discussed in reference to architecture 200.

At 402, a client application creates a type manager. In one example, the client application calls a CoCreateInstance( ) API that creates an instance of the type manager. At 404, to register a namespace with the type manager, the client application calls a method on the type manager (e.g., the RegisterNamespace method discussed below in the “Interfaces” section) and provides a string name of the namespace and an identifier (e.g., a class identifier) for a namespace type factory for the namespace. At 406, the type manager associates the string name with the identifier and a pointer to a namespace manager. Initially, the pointer value is set to null. At 408, the client application provides markup to the type manager and requests that the type manager parse the markup and create a tree of objects from the markup. At 410, the type manager parses the markup and determines one or more namespaces from the markup. The type manager may implement its own markup parser, or it may send the markup to an external parser to be processed. At 412, a class in the namespace is determined from the markup and, in response, a method is called that creates a namespace manager. In one or more embodiments, the namespace manager is not created until a class in the namespace is encountered and/or the client application calls an API to access a class in the namespace. This “on demand” aspect provides a more efficient and economical way of generating a UI and UI elements.

The type manager calls a method on the namespace manager that requests that a namespace type factory be created for the namespace (block 414). According to some embodiments, the type manager provides a globally unique identifier (GUID) to the namespace manager and requests that the namespace manager create a namespace type factory that is associated with the GUID. For example, a developer may create a namespace type factory and register the namespace type factory using the GUID. The namespace manager handles communication with the namespace type factory.

At 416, the namespace type factory is created and the namespace manager calls a method on the namespace type factory that asks the namespace type factory for its identifier (e.g., its namespace, its GUID, and so on). If the namespace type factory returns the identifier that the namespace manager used to request the creation of the factory, this verifies that the correct namespace type factory has been created. At 418, the client application calls a method that creates a class type manager. The class type manager provides one or more interfaces to class type objects that are to be created. At 420, the client application calls a method that creates a class type object. Using the example discussed above in FIG. 3, the client application calls a method on the namespace type factory that creates a class type object with the class name “textbox”.

To create an instance of the class, at 422 a method is called that creates a class instance. Using the example from FIG. 3, the class instance would comprise a textbox object. As one example of the creation of a textbox object, the class type manager includes an IUIClassFactory interface that provides a method for creating an instance of a class. This interface is accessible to one or more of the objects in the UI architecture, as well as the client application. The object(s) and/or the client application may call the method to initiate the creation of the class instance. At 424, one or more base class instances for the class instance are created. In one or more embodiments, the base class instances include functionality and/or properties that the class instance inherits from the base classes. A base class instance may include one or more interfaces for registering properties for the base class. The class instance may also override and/or extend properties and functionality of one or more of its base classes. At 426, properties are set on the class instance and/or its base class instance(s). Properties may include visual aspects (e.g., size, color, and so on) as well as behavior and functionality.

This example process is effective to create a tree of objects that are used to define one or more aspects of a UI. For purposes of simplicity, this example process discusses the creation of a tree that includes a single instance of a single class and one or more base classes (i.e., the text box instance of the text box class). However, in many implementation scenarios, a tree of objects will be created with multiple different class types, class instances, and base classes.

The following sections discuss particular UIOM implementation specifics, according to one or more embodiments.

In some embodiments, the UIOM framework utilizes a DependencyObject base class, from which one or more class types may inherit properties and/or functionality. The DependencyObject type exposes interfaces for accessing properties and for subscribing to and raising UIOM events. For generating a UI, a hierarchy of objects that define different aspects of the UI may descend from the DependencyObject type.

In some embodiments, the UIOM framework utilizes COM-based aggregation techniques such as blind aggregation. The following pseudo-code illustrates one example of a ToggleButton class that inherits properties and/or functionality from a Button class using COM-based aggregation:

class ToggleButton :   public CComObjectRootEx<CComObjectThreadModel>,   public IUIToggleButton {   CComPtr<IUINamespaceTypeFactory> m_spCoreFactory;   ToggleButton(IUINamespaceTypeFactory pCoreFactory)   {     // Store a ref to the factory for types from the core namespace.     m_spCoreFactory = pCoreFactory;   }   CComPtr<IUIButtonBase> m_spButtonBase;   HRESULT FinalConstruct( )   {     // COM blind-aggregation to reuse the Button base class implementation.     m_spButtonBase = m_spCoreFactory-> CreateInstance(“Button”, GetUnknown( ));   } BEGIN_COM_MAP( )   COM_INTERFACE_ENTRY(IUIToggleButton)   COM_INTERFACE_ENTRY_AGGREGATE_BLIND-   (m_spButtonBase) END_COM_MAP( )   // Add only IUIToggleButton functionality   BOOL m_fToggled;   STDMETHOD IsToggled(BOOL* pValue)   {     return m_fToggled;   }   STDMETHOD Toggle( )   {     m_fToggled = !m_fToggled;   } }

In some embodiments, IUINamespaceTypeFactory is used for creating ClassTypes and ClassFactories are used for creating instances. The following is some sample UIElement Code that blind aggregates a TreeElement, which it creates by calling pClassFactoryTreeElement->CreateBaseInstance.

class ATL_NO_VTABLE CUIElement :  public CComObjectRootEx<CComSingleThreadModel>,  public CUIElementBase { public:  DECLARE_NO_REGISTRY( )  DECLARE_GET_CONTROLLING_UNKNOWN( )  BEGIN_COM_MAP(CUIElement)   COM_INTERFACE_ENTRY(IUIElement) COM_INTERFACE_ENTRY_AGGREGATE_BLIND- (_pUnkTreeElement)  END_COM_MAP( )  DECLARE_PROTECT_FINAL_CONSTRUCT( )  HRESULT FinalConstruct( )  {   _pUnkTreeElement = NULL;   return S_OK;  }  CHKMETHOD InitializeBaseClass(IUIClassFactory *pClassFactoryTreeElement)  {   RETURN_IF_FAILED(pClassFactoryTreeElement->

Download full PDF for full patent description/claims.




You can also Monitor Keywords and Search for tracking patents relating to this Object model for a user interface patent application.

Patent Applications in related categories:

20130117694 - Polling systems and methods - Computer systems and computer-implemented methods for assisting individuals in conducting, participating in, and viewing polls, while minimizing statistical bias and maximizing poll accessibility and poll viewing functionalities, are disclosed. A computer-implemented polling method is implemented on a website. The polling method includes registering a user account, facilitating the creation of ...


###