CN111819535A

CN111819535A - Asynchronous C # -JS data binding bridge

Info

Publication number: CN111819535A
Application number: CN201880090401.7A
Authority: CN
Inventors: L·亚达弗; S·洛伊; C·帕特尔
Original assignee: Aviva Software Co ltd
Current assignee: Aviva Software Co ltd
Priority date: 2017-12-28
Filing date: 2018-12-27
Publication date: 2020-10-23
Anticipated expiration: 2038-12-27
Also published as: EP3732564A4; WO2019133709A1; EP3732564A1; US10394627B2; US20190205103A1; CN111819535B; US11531573B2; US20200159598A1

Abstract

A method and system provide for asynchronous bi-directional binding between a user interface and a data model implemented on different frameworks. The system includes a data controller, a data model controller, and a bridge controller. The data controller provides a front-end binding framework that interacts with a user interface of the user device to manage bindable properties or methods for views on the user device. The data model controller provides a back-end binding framework that manages the data model, the front-end binding framework and the back-end binding framework being different types of framework. The bridge controller implements asynchronous bi-directional binding for bindable properties or methods between the front-end binding framework and the back-end binding framework to update the bindable properties or methods in the data model when data at the user interface changes and to update the view on the user device when data at the data model changes.

Description

Asynchronous C # -JS data binding bridge

Technical Field

The present disclosure relates to a multi-platform bridging method and system for data and method binding across front-end and back-end implemented on different platforms, such as a Java Script framework and a C-sharp (C #) framework.

Background

Data binding in applications (also referred to as "apps") involves automatic synchronization of data between a model and a view component. When data in the model changes, the view reflects the change; and when the data in the view changes, the model is also updated in an asynchronous manner. This process occurs immediately and automatically, which ensures that the model and views are always updated.

Disclosure of Invention

There is currently no mechanism to support bi-directional binding in a multi-platform environment, such as with a hybrid multi-platform app based on Xanarin, where the front-end and back-end are implemented on different frameworks. To address these and other issues, a hybrid multi-platform binding bridge is provided that employs a bridge controller to facilitate asynchronous bi-directional communication between a front-end binding framework that interacts with a User Interface (UI) of a user device and a back-end binding framework that interacts with a data model (e.g., a view model or model). In this manner, the bridge controller can pass a binding request with requested data for a bindable property or method from the UI to the back-end binding framework via the front-end binding framework for implementation on the data model, and can pass a data response for the bindable property or method from the data model from the back-end binding framework to the front-end binding framework to update the view component and the UI of the user device.

The binding bridge may help quickly develop or design a multi-platform app developed in a model-view model (MVVM) architectural mode between an HTML/JavaScript User Interface (UI) and a C # ViewModel (e.g., in Xamarin C #, HTML, and JavaScript), and may leverage platform-specific infrastructure to quickly execute code and improve data binding performance in a stand-alone or offline app.

In example embodiments, computer-implemented methods and systems involve providing a front-end binding framework with a data controller that interacts with a user interface of a user device to manage bindable properties or methods for views on the user device; providing a back-end binding frame with a data model controller, wherein the back-end binding frame manages a data model, and the front-end binding frame and the back-end binding frame are different types of frames; and implementing asynchronous bidirectional binding via the bridge controller for bindable properties or methods between the data controller of the front-end binding framework and the back-end binding framework to update the bindable properties or methods in the data model when data at the user interface changes and to update the view on the user device when data at the data model changes. The front-end bounding frame may be a Javascript bounding frame and the back-end bounding frame may be a C # bounding frame.

The computer-implemented method and system may also involve receiving, at the front-end binding framework from the user interface, a binding request having request data for binding properties or methods. The implementing operation may include asynchronously obtaining a publication message corresponding to the bind request from the data controller. The publish message may include at least a peer identifier, a binding type, and a verb associated with the binding request. The implementing operation may further include parsing the publication message; and dispatch a bridge request (e.g., a request from the bridge controller) to the data model controller based on the parsed publish message to perform the implementation on the data model in accordance with at least the bind type and the verb.

The computer-implemented method and system may also involve generating a request object for the binding request in a front-end binding framework; placing the request object on a callback queue in a front-end binding frame; and generating a publication message for the requested object in the front-end binding framework. The request object may include at least a peer identifier, a binding type, and a verb associated with the binding request.

In another example, implementing the operation may also involve receiving a data model response (e.g., a response from the data model) as a reply to the bridge request; parsing the data model response at the bridge controller; and sending a bridge response with data from the data model to the front-end binding framework based on the parsed data model response. The data model response may include a value and a peer identifier associated with a binding property or method from the data model.

Moreover, the computer-implemented method and system may also involve accessing a callback queue to identify a request object corresponding to the data model response based on the peer identifier; and in response to the binding request, invoking a callback function for the request object via a bridge response having data from the data model to update the view of the user interface.

Drawings

The description of the various exemplary embodiments is explained in conjunction with the attached drawings, in which:

FIG. 1 illustrates a block diagram of an example computing environment implementing a binding bridge through a bridge controller to facilitate data binding across a multi-platform environment, according to an example embodiment of the present disclosure.

FIG. 2 illustrates a functional block diagram of an example bridge controller that facilitates data binding across a multi-platform environment, according to an example embodiment of the present disclosure.

FIG. 3 illustrates a more detailed functional block diagram of an example bridge controller that facilitates data binding across a multi-platform environment, according to an example embodiment of the present disclosure.

FIG. 4 illustrates a flow diagram of an example data binding process implemented across a multi-platform environment in accordance with an example embodiment of the present disclosure.

Fig. 5 illustrates an example request protocol definition according to an example embodiment of the present disclosure.

Fig. 6 illustrates an example response protocol definition according to an example embodiment of the present disclosure.

Fig. 7 illustrates an example request format according to an example embodiment of the present disclosure.

Fig. 8 illustrates an example response format according to an example embodiment of the present disclosure.

FIG. 9 illustrates example supported bindable data types according to an example embodiment of the present disclosure.

Fig. 10-12 illustrate example pages or screens of a user interface that allow a user to set or configure apps for bidirectional binding on a computer device.

Detailed Description

A system and method are provided to facilitate binding, such as data and/or method binding, using a binding bridge in a multi-platform environment that employs different frameworks for front-end and back-end. In an example, the front-end framework may be implemented using javascript (js) and the back-end framework may be implemented using C # (also referred to as C-sharp), or vice versa. The front-end framework includes a front-end data binding framework with a data controller that interacts with a User Interface (UI) of the user device through a front-end application, e.g., via HTML, to provide view(s) and updates to the views on the UI. The back-end framework includes a back-end data binding framework with a data model controller to manage and update the data model (e.g., view model or model). A binding bridge implemented via a bridge controller provides bi-directional communication and binding, such as data and/or method binding, between a front end (e.g., a JS/HTML front end) and a back end (e.g., a C # back end) in an asynchronous manner.

The bridge controller is in communication with the front-end binding framework and the back-end binding framework. In this manner, the binding bridge can provide an asynchronous layer of communication, for example, between two different binding frames (such as C # and JS), and create a portable binding layer, for example, between the HTML/JS front-end and the C # back-end. Thus, the bridge controller allows direct communication between the HTML/JS front-end and the C # backend to achieve asynchronous bi-directional data binding. For example, the binding bridge may be configured to inject multiple data types (e.g., JS (java. lang) objects) across the C # -JS layer in Android and queue messages; trap messages from JS with IWKScriptMessage handle for iOS; and performs WinRT component queuing in Windows 10. Examples of bound bridges and their general operation will be described in more detail below with reference to the accompanying drawings.

The binding bridge may help quickly develop or design multi-platform applications developed with a model-view model (MVVM) architectural model or other view-model architectural model between an HTML/JavaScript (ui) user interface and a C # ViewModel (e.g., with Xamarin C #, HTML, and JavaScript), and may leverage platform-specific infrastructure to quickly execute code and improve data binding performance in standalone or offline apps. Furthermore, the asynchronous nature of the bidirectional binding infrastructure frees the UI to perform other tasks while the binding request is pending.

I. Framework

FIG. 1 illustrates a block diagram of an example computing environment 100 implementing a binding bridge through a bridge controller to facilitate data binding across a multi-platform environment, according to an example embodiment of the present disclosure. As shown in FIG. 1, the computing environment 100 includes a User Interface (UI)110 (e.g., a user interface or web view), a data controller 120 of a front-end binding framework of a front-end framework, a bridge controller 130, and a data model controller 140 of a back-end binding framework of a back-end framework. As discussed previously, the front end frame may be a JS frame and the back end frame may be a C # frame. In such an environment, front-end and back-end applications (or apps) may be developed and implemented on different frameworks, such as for architectural modes where views and data models on the UI (which manage the application's data, rules, and logic) are managed on different platforms. One such schema is MVVM, which further separates the data model into a view model (e.g., logic and rules for views) and a model that contains data for applications. The view model is an intermediary between the view and the model.

Data controller 120 interacts with UI 110 to manage and update views on UI 110 to receive updates and facilitate updates of data models (e.g., view models and models that depend on schema) when data in the views on UI 110 has changed. In this example, the data controller 120 is a JS controller for the JS front-end framework and manages JS data components for applications (including front apps).

The data model controller 140 manages and updates data in the data model. For example, data model controller 140 is configured to update data in the data model when data associated with one or more bindable properties and/or methods at UI 110 has changed. The data model controller 140 is further configured to facilitate updating of the view in reply to a request (e.g., a request for a GET action) or when data associated with a bindable property or method in the data model changes. In this example, the data model controller is the C # controller of the C # backend framework.

The bridge controller 130 is part of a bonded bridge between the front end framework and the back end framework and is configured to provide bi-directional asynchronous communication between components of the front end framework and the back end framework, such as the data controller 120 and the data model controller 140. As will be described in more detail below, the bridge controller 130 obtains the published messages associated with each binding request from the front-end binding framework via asynchronous calls, parses the published messages, and communicates with the data model controller 140 to implement the property binding and/or method binding actions (e.g., GET or PUT) of the binding request at the target object (e.g., data model). After taking action at the data model, the data model controller 140 sends a data model response with the relevant data to the bridge controller 130. The bridge controller 130 parses the response and implements a callback for the corresponding request in the callback queue via the front-end binding framework. The callback invokes a callback function to send response data (e.g., data from the data model for bindable properties or methods) to the data controller 120 as a reply to the request. The data controller 120 then updates the view on the UI accordingly.

In this example, the computer environment may be a user device, such as a mobile device. The front-end binding framework with data controller 120, bridge controller 130, and back-end binding framework with data model controller 140 may be implemented on a user device. The user device may include at least processor(s) (e.g., CPU (s)), memory, and network interface device(s) or NID(s) to interact with other computers via one or more networks, input devices (e.g., touchscreen/display, keyboard, buttons, audio input devices, and/or other input devices), and output devices (e.g., display, audio output devices, and/or other output devices). The memory may store data and computer-executable applications, including an operating system, a bidirectional binding bridge, and other applications or programs. The user device may be a mobile device (e.g., Android or iOS smart phone, tablet or device, laptop computer, etc.), a desktop computer, or other computer-implemented system.

When a user device executes an application stored in memory via its processor(s), the processor(s) and memory of the computer(s) provide a framework, bindings, and communication bridges, as well as the functions and features described herein, including asynchronous bi-directional communication between different frameworks (e.g., a communication layer for implementing asynchronous communication between different frameworks) and asynchronous bi-directional binding (e.g., data and/or method bindings) for multi-platform applications implemented across different frameworks (e.g., different front-end and back-end frameworks).

Examples of a computing environment 100 are described above. The user device may interact with other computers (e.g., server(s), etc.) via the network(s) to implement applications and update data maintained at remote locations, including data in data models, and so forth. The two-way binding processes and functions, including various controller operations, may also be implemented across different computers, e.g., the user device may interact with other computer(s). Other computers may be connected across the network(s) and include at least processor(s) (e.g., CPU), memory, and NID to facilitate network communications across a wired network, a wireless network, the internet, or a combination thereof. The memory may store data and computer-executable applications including an operating system.

FIG. 2 illustrates a high-level functional block diagram of an example bridge controller and its functional components that facilitate data binding across a multi-platform environment. As shown in fig. 2, the multi-platform environment includes a front end frame 200 and a back end frame 250. In this example, the front end framework 200 includes a JS bounding framework with a JS data director, etc., while the back end framework 250 includes a C # bounding framework with a data model director. The bridge controller 130 provides a bidirectional communication layer between the front-end binding framework and the back-end binding framework to enable asynchronous bidirectional communication and binding therebetween.

In the front-end binding framework of front-end framework 200, JS data binding 210 can obtain all bindable properties and/or methods from the JS custom event. For example, the process may begin when the UI initiates a binding request, such as when data in a view at the UI changes or data for a view is requested. Finally, a publish message 200 is generated for the requested bindable property and/or method, and the publish message 200 may include parameters such as peer ID, property name, value, GET and PUT, member name, and binding type. The publish message 200 is then asynchronously sent as a publish asynchronous call to the data model, in this case to the view model 270 of the back-end framework 250 via the bridge controller 260, to update and/or request data from the data model.

In particular, the bridge controller 130 implements an asynchronous call trap 260 to obtain the published message 220 and resolves the published message through an initiate request resolver 262 to implement asynchronous binding to the source. The bridge controller 130 then sends a request (also referred to as a "bridge request") to the data model controller of the back-end binding framework of the back-end framework 250 based on the requested data in the parsed publish message. The data model controller can then act accordingly to implement the requested action of the bindable property and/or method on the data model (e.g., view model 270). These actions may include updating and/or obtaining data from the view model 270 for a bindable property or method. Once the data associated with the properties and/or methods is updated, accessed, and/or retrieved on the view model 270, a callback process is implemented in which a response (also referred to as a "data model response") with the data or updated data is sent from the view model 270 to the bridge controller 130. Bridge controller 130 obtains and parses response data from the data model responses with response parser 264. Then, when a response is returned for the request (e.g., a request with the same peer ID), the callback processor 266 gets the callback and automatically sends the relevant response data from the view model 270 to the data controller using, for example, a JS custom event. The JS data binding 210 gets a JS custom event, and can then update the view at the UI according to any changes at the data model (e.g., view model or model). Thus, by using a binding bridge implemented by bridge controller 130 and its components, bi-directional asynchronous binding of bindable properties and/or methods is provided between the UI and the data model (e.g., view model 270). Thus, when data changes in the view at the UI, the data model may be updated; the view may be updated at the UI when changes occur to the data in the data model.

FIG. 3 illustrates a more detailed functional block diagram of an example binding bridge having a bridge controller 130 and its functional components, the bridge controller 130 and its functional components facilitating bi-directional asynchronous data binding across a multi-platform environment (such as different front-end and back-end frameworks). In this example, the front-end binding framework for the front-end framework includes a data component, such as a JS component 310, that is managed by the data controller to obtain and manage all bindable properties and methods on the front-end that interact with the UI of the user device. The back-end binding framework of the back-end framework also includes components that are managed by the data model controller. The components of the back end framework include data mapping and execution 360 and a data model, such as view model 380 with view model implementation 382. The bridge controller 130 facilitates asynchronous two-way communication between the JS component 310 of the front-end binding frame and the data mapping and execution 360 of the back-end binding frame, thereby facilitating binding.

The JS component 310, which is a data component of the JS binding framework, includes all bindable properties and methods, such as property binding 312 and method binding 314. The JS component 310 obtains properties and methods from a data model, such as the view model 380 (e.g., the C # view model), through the bridge controller 130, and creates a binding with that view. The JS component 310 can include two parts: property binding and method binding. Property binding binds a value to a property of an element to modify its appearance or behavior; creating a bi-directional data binding with the view and the model; including properties such as Nullable, boot, Number, String Array, complete Type like JSON (JavaScript object notation) String, Item List Array, and Item List Array; binding the property value with the JS expression and the input element/attribute; and supports asynchronous mode of data binding. Method binding binds methods to view model methods; invoking a method with or without parameters; and returning a value from the method; and supports asynchronous mode of method binding.

The bridge controller 130 uses the callback events to fetch all bindable properties and methods from the data model (e.g., the C # view model) and passes the bindable properties and methods to the data controller. The bridge controller 130 includes a request creator 320 to create an object for a request (such as a bind request) received from the UI; callback queue 322 holds the request data; response parser 264 parses data model responses from view model 380; and the get callback 324 gets the callback associated with the request data in the callback queue 322 to invoke the callback function.

Request creator 320 generates JavaScript objects that hold protocol definitions, such as, for example:

// bingtype: general methods, methods of view models and characteristics of view models// verb: GET and PUT

// membername: name of method

// value: function names or method parameters for properties of view models

// memberdiameter: setting values of method parameters of a device

// peer: peer object identifier

The callback queue 322 holds all the request data, which will asynchronously send the publish message to the data model controller (e.g., the C # controller) along with the callback function values. The get callback 324 gets the callback when response data is received from the view model 380 from the peer C # object.

Bridge controller 130 also includes property setter and obtainer 330, property information binding 332, recipe information binding 334, data type conversion 336, view model state 338, property change equalizer 340, and scheduling custom events 344. The bridge controller 130 may implement these functions in response to requests such as binding requests or other requests related to the data model.

Data mapping and execution 360 holds all script message instances, and data mapping and execution 360 is used to generate property and method bindings through C # reflection. Data mapping and execution 360 will contain the same set of property and recipe binding instances. Data mapping and execution 360 includes: binding type 362, method identifier 364, parameter value 366, peer identifier 368, property callback 370, method callback 374, and raise property change event 374.

The view model 380 maintains all C # properties and method implementations that hook directly from the view.

Other descriptions of objects and object parameters are described below for the JS binding framework, and can be used to facilitate implementation of the binding bridge system and methods described herein. In addition to the above functions, the binding framework may also implement other functions: subscription property changes, unsubscribe property changes, state manager, current view model, state changes, changes on properties, creation of binding objects, data type conversion, and the like. These functional objects and some parameters are described below.

Peer object identifier-keeping a unique identifier of any C # object peer

DataTypes-maintaining supported data types in property bindings

Binding type-both supporting Properties and method binding types

Subscribe to property change-setting JavaScript object as a subscriber to a property change event

Unsubscribe to property changes-remove JavaScript object from property change subscription list state manager-keep view model state object

Current View model-obtaining the Current View model identifier from the C # model

State Change-invoking View Router to enter different states

On property change-triggered when a property changes in the C # view model, and invoke a property change callback on the JavaScript VM

Create binding object-generate all binding properties and methods, maintain property and method information, obtain and set property values from C # View model using getter and setter functions, and bind method information to C # recipe binding

Data type conversion-converting the basic data type of C # into JavaScript data types such as String, Number, and Boolean

These functions and parameters of the JS front end frame and the C # rear end frame are provided as examples. Other identifiers, data types, binding types, and object functions, as well as other naming conventions, may be used to implement the bridge binding system and method depending on the type of framework used to implement the multi-platform application.

Example processing

FIG. 4 illustrates a flow diagram of an example data binding process 400 implemented across a multi-platform environment, according to an example embodiment of the present disclosure. As shown in fig. 4, at step 402, a property and/or method binding request (e.g., propertyandmethodbindrequest) is initiated by a User Interface (UI) of a user device. In this example, the request is an HTML request that is implemented in the front-end HTML/JS framework through the HTML component of the UI. The request may be initiated, for example, based on a change, selection, or operation made by the user through the UI. The bind request may include an identifier of the source of the request (e.g., a source object), the type of binding(s), its name and value(s) associated therewith, and any action to be taken, including updating data at or obtaining data from the target of the request (e.g., a target object, such as a data model). Examples of protocol definitions and formats for instances of requests are shown in fig. 5 and 7, which are further described below.

At reference 404, a data controller (e.g., a JS controller) receives a bind request from the UI and, in response, generates a publish message (e.g., generateposmessage) in an asynchronous manner. For example, the data controller may create an object, e.g., a JS request object, for the request data in the binding request, place the object in a queue, e.g., a callback queue, to maintain the request data, and then asynchronously generate a publish message for the request data in the queue. At reference 406, the bridge controller of the bound bridge captures the published message using, for example, a call trap, and parses the requested data in the published message for transmission to a data model controller (e.g., a Web view controller) via a bridge request. At reference 408, the data model controller sends a RequestDispatch to the data model (e.g., ViewModel) to implement the requested action (e.g., GET or PUT, etc.) of the bindable property and/or method with respect to the data model. At reference 410, the data model sends response data (e.g., ResponseData) back to the data model controller, which in turn causes a callback event at the bridge controller and returns a data model response with the response data from the data model at reference 412. At reference 414, the bridge controller implements a ResponseParser operation that parses the data model response and retrieves the response data and retrieves a callback to a corresponding request (e.g., a peer request object in the queue) from the queue. The callback automatically invokes a return operation by sending response data to a data component (e.g., view component) of the data controller using, for example, a JavaScript custom event. At reference 416, the data controller updates the view at the UI and managed data components, such as property and recipe bindings, with response data from the data model.

While the example bound-bridge process is described with the JS-C # framework, it should be understood that the bound-bridge can be a user with other types of front-end and back-end frameworks and multi-platform apps.

Example protocols and formats

Examples of parameters and formats for request and response protocols that may be used in the computing environments of FIGS. 1-4 with bidirectional binding bridges are shown and described with reference to FIGS. 5-9.

Fig. 5 illustrates an example of request protocol 500 parameters and their definitions. In this example, the parameters may include bindingType, verb, Member Name, value, memberdiameter, and pereid. The bindingType defines the nature of the binding, such as a property binding and/or a method binding. verb defines actions to be taken, such as GET and PUT. membername is the name of the method. value is a member value. memberdiameter is the value of the method parameter for the setter. Peer is a peer object identifier.

Fig. 6 illustrates an example of response protocol 600 parameters. In this example, the parameters may include id, membername, and value. id is a peer object identifier and allows for associating a response with a request (e.g., peer object). membername is the name of the method. value is a member value.

FIG. 7 illustrates an example request format. As shown in fig. 7, an example format 700 of a request may include:

{

“bindingType”：bindingType，

“verb”：verb，“membername”：membername，

“value”：value，

“memberparameter″：″memberparameter”，

“peerid”：peerid

}

FIG. 8 illustrates an example response format. As shown in fig. 8, an example format 800 of a response may include:

{

“id”：id，

“membername”：membername，

“value”：value

}

FIG. 9 illustrates example supported bindable data types. As shown in FIG. 9, the bindable data types 900 can include, for example, Nullable, Bool, Number, String Array, Complex Type as JSON String, and Item List Array.

As described herein, a binding bridge may be configured for use with an application, such as a mobile app or other app, on a user device. In this example, the binding bridge may provide bidirectional data binding and notification about property changes. By binding the bridge, in a multi-platform app, any data-related changes that affect the model can be immediately propagated to the matching view(s), and any changes made in the view(s), such as by a user for example, can be immediately reflected in the underlying model. When app data changes, the UI changes accordingly, and vice versa. Examples of user interfaces that provide pages (or screens) to allow a user to set up or configure a bi-directionally bound application on a computer device are shown with reference to fig. 10-12.

As shown in FIG. 10, an example page 1000, referred to as a "device," is provided with inputs, such as text boxes and button controls, to set property and method bindings on the device. By default, the device name may be set from the data model and reflected in the text box. Similarly, if the data is changed in a text box, it will be immediately reflected in the data model.

In this example, property bindings having different data types may be used to bind text with a control. An example of bidirectional binding is described below using the AngularJS framework:

</diV>

while this example uses the Angular JS framework, the data-binding bridge is compatible with any JavaScript framework.

The method binding may subscribe to HTML button controls that may sense events and propagate the triggered operations to the model. Examples are provided below:

in this example, ng-app, ng-controller, and ng-bind are angular instructions; data is bi-directional binding data, which is synchronized with the data binding bridge and the C # model; while mymodel. continue () is an event binding, which directly subscribes to the C # method binding.

FIG. 11 illustrates an example page 1100, referred to as a "sync server," that may be provided to configure bindings to one control, which is also reflected in other controls. Page 1100 may have a text box or other graphical input, as well as a "continue" button, and the like. Initially, the text box may be empty of data and the "continue" button disabled. However, once data is entered in the text box, the "continue" button may be enabled and the data model may also be updated at the back end. In this example, the binding may be used with multiple controls based on the set conditions.

FIG. 12 illustrates an example page 1200 showing a plurality of list controls that may also be provided. The listed data may be based on dependently selected data and characteristic change events. The multiple list page 1200 may include a graphical drop-down box or other input to enter (e.g., select an option, enter text, etc.) relevant information, such as, for example, Base (Base), user, role, and password. When any data is selected, other controls are enabled based on the selected data.

In this example, the mobile app may be used to enable workflow, data collection, and general task management for plant operations, maintenance management, production tracking, and compliance applications.

The above is provided as an example protocol and format only. The response and request protocols and formats may include other parameters, or use other naming conventions or syntax, depending on the multi-platform environment including the type of framework(s).

It should be understood that the devices, systems, and methods described herein are provided by way of example only. Various devices, controllers, or systems (such as in the figures) may be implemented on one or more computer systems including processor(s), memory, communications devices including Network Interface Devices (NIDs), and other components to provide or control services and operations, including bi-directional communications and binding between different frameworks.

It should also be understood that the exemplary embodiments disclosed and taught herein are susceptible to various modifications and alternative forms. Thus, use of a singular term (such as, but not limited to, "a" and "an" etc.) is not intended to limit the number of items. Further, naming conventions for script syntax for script files or portions of scripts for test scenarios, instructions, command line switches, expressions, objects, attributes, thread names, file names, directory names, and other naming conventions used herein are provided as examples and may be assigned different names or labels.

It will be appreciated that the development of a practical, real-life business application incorporating aspects of the disclosed embodiments will require numerous implementation-specific decisions to achieve the developer's ultimate goal for the business embodiment. Such implementation-specific decisions may include, and may not be limited to, compliance with system-related, business-related, government-related and other constraints, which may vary by specific implementation, location and over time. While a developer's efforts might be complex and time-consuming in an absolute sense, such efforts would be, nevertheless, a routine undertaking for those of ordinary skill in this art having benefit of this disclosure.

Using the description provided herein, example embodiments may be implemented as a machine, process, or article of manufacture using standard programming and/or engineering techniques to produce programming software, firmware, hardware or any combination thereof.

Any resulting program(s), having computer-readable program code, may be embodied on one or more computer-usable media such as resident memory devices, smart cards or other removable memory devices, or transmitting devices, thereby making a computer program product or article of manufacture according to an embodiment. As such, the terms "article of manufacture" and "computer program product" as used herein are intended to encompass a computer program that exists permanently or temporarily on any computer-usable medium or in any transmitting medium which transmits such a program.

As indicated above, the memory/storage device may include, but is not limited to, a disk, a solid state drive, an optical disk, a removable memory device such as a smart card, a SIM, a WIM, a semiconductor memory such as RAM, ROM, PROM, and the like. Transmission media includes, but is not limited to, transmission via a wireless communication network (e.g., Radio Frequency (RF) communication, the internet, intranets, telephone/modem-based network communication, hard-wired/wired communication networks, satellite communication, and other fixed or mobile network systems/communication links.

While particular embodiments and applications of the present disclosure have been illustrated and described, it is to be understood that the disclosure is not limited to the precise construction and compositions disclosed herein and that various modifications, changes, and variations may be apparent from the foregoing descriptions without departing from the invention as defined in the appended claims.

Claims

1. A computer-implemented method, comprising:

providing a front-end binding framework having a data controller, the front-end binding framework interacting with a user interface of a user device to manage bindable properties or methods for a view on the user device;

providing a back-end binding frame with a data model controller, wherein the back-end binding frame manages a data model, and the front-end binding frame and the back-end binding frame are different types of frames; and

asynchronous bidirectional binding is implemented via the bridge controller for bindable properties or methods between the data controller of the front-end binding framework and the back-end binding framework to update the bindable properties or methods in the data model when data at the user interface changes and to update the view on the user device when data at the data model changes.

2. The computer-implemented method of claim 1, wherein the front-end bounding frame is a Javascript bounding frame and the back-end bounding frame is a C # bounding frame.

3. The computer-implemented method of claim 1, further comprising:

a bind request having request data for a binding property or method is received at a front-end binding framework from a user interface,

wherein the implementation comprises:

asynchronously obtaining a publish message corresponding to the binding request from the data controller, the publish message including at least a peer identifier, a binding type, and a verb associated with the binding request;

analyzing the release message; and

the bridge request is dispatched to the data model controller based on the parsed publish message to perform the implementation on the data model in accordance with at least the binding type and the verb.

4. The computer-implemented method of claim 3, further comprising:

generating a request object for the binding request in a front-end binding framework, the request object including at least a peer identifier, a binding type, and a verb associated with the binding request;

placing the request object on a callback queue in a front-end binding frame; and

a publication message is generated for the requested object in the front-end binding framework.

5. The computer-implemented method of claim 3, wherein the implementing further comprises:

receiving a data model response from the data model as a reply to the bridge request, the data model response including a value associated with a binding property or method from the data model and a peer identifier;

parsing the data model response at the bridge controller; and

sending a bridge response with data from the data model to the front-end binding framework based on the parsed data model response.

6. The computer-implemented method of claim 5, further comprising:

accessing the callback queue to identify a request object corresponding to the data model response according to the peer identifier; and

in response to the binding request, a callback function is invoked for the request object via a bridge response with data from the data model to update the view of the user interface.

7. The computer-implemented method of claim 1, wherein the providing and implementing operations are performed on a mobile device.

8. A computer system for providing asynchronous bi-directional binding between a user interface and a data model of a user device implemented on different frameworks, the computer system comprising:

a memory; and

one or more processors that implement:

a data controller providing a front-end binding framework that interacts with a user interface of a user device to manage bindable properties or methods for a view on the user device;

a data model controller providing a back-end binding frame managing the data model, the front-end binding frame and the back-end binding frame being different types of frames; and

the bridge controller implements asynchronous bidirectional binding for bindable properties or methods between the data controller of the front-end binding framework and the back-end binding framework to update the bindable properties or methods in the data model when data at the user interface changes and to update the view on the user device when data at the data model changes.

9. The computer system of claim 8, wherein the front-end binding frame is a Javascript binding frame and the back-end binding frame is a C # binding frame.

10. The computer system of claim 8, wherein the data controller is configured to receive a bind request having requested data for a bind property or method from the user interface at the front-end binding framework, and

wherein the bridge controller is further configured to:

analyzing the release message; and

11. The computer system of claim 10, wherein the bridge controller is further configured to:

12. The computer system of claim 10, wherein the bridge controller is further configured to:

parsing the data model response at the bridge controller; and

13. The computer system of claim 12, the bridge controller further configured to:

14. The computer system of claim 8, wherein the data model controller and the bridge controller are implemented on a mobile device comprising a memory and a processor.

15. A tangible memory medium storing executable code that, when executed by one or more processors, implements a method for providing asynchronous bidirectional binding between a user interface and a data model implemented on different frameworks, the method comprising:

16. The tangible memory medium of claim 15, wherein the front-end bounding frame is a Javascript bounding frame and the back-end bounding frame is a C # bounding frame.

17. The tangible memory medium of claim 15, wherein the method further comprises:

wherein the implementation comprises:

analyzing the release message; and

18. The tangible memory medium of claim 17, wherein the method further comprises:

19. The tangible memory medium of claim 17, wherein the implementation further comprises:

parsing the data model response at the bridge controller; and

20. The tangible memory medium of claim 19, wherein the method further comprises: