Patent Application
20120188264
This application relates to the field of wireless communications, and more particularly, to wireless communications systems and related methods.
Mobile communication systems continue to grow in popularity and have become an integral part of both personal and business communications. Various mobile devices now incorporate Personal Digital Assistant (PDA) features such as calendars, address books, task lists, calculators, memo and writing programs, media players, games, or other mobile applications. These multi-function devices usually allow electronic mail (email) messages to be sent and received wirelessly, as well as access the Internet via a cellular network and/or a wireless local area network (WLAN), for example.
Typically, different applications are installed on the mobile device that are used to retrieve corresponding types of data. A native or local client user interface (UI) on the mobile device renders visual objects on the mobile device display based upon the different applications and retrieved data.
The present description is made with reference to the accompanying drawings, in which example embodiments are shown. However, many different embodiments may be used, and thus the description should not be construed as limited to the embodiments set forth herein. Like numbers are refer to like elements throughout, and prime notation is used to similar elements in different embodiments.
Generally speaking, a method for visually rendering data on a display of a mobile wireless communication device having a native client user interface (UI) is provided. The method may include storing application data on a backend data server without visual attribute formatting associated therewith, and generating a visual attribute formatting rules for storage on an application proxy server so that application data retrieved from the backend data server has the visual attribute formatting rules applied thereto. The method further includes generating at least one application for the mobile wireless communications device configured to at least cause the mobile wireless communications device to retrieve the stored application data having the visual attribute formatting rules applied thereto from the backend data server via the application proxy server, and visually render on the display of the mobile wireless communications device the retrieved application data having the visual attribute formatting rules applied thereto using the native client UI and without visual attribute formatting by the at least one application. Accordingly, this may provide desired flexibility in rendering various types and combinations of information without having to configure the mobile device application for visual formatting of retrieved data.
More particularly, the at least one application may comprise a plurality of different applications for the mobile wireless communications device, and the visual attribute formatting rules may comprise a respective different set of visual attribute formatting rules for each of the different applications. By way of example, the visual attribute formatting rules may comprise at least one of rich client formatting rules or markup language formatting rules. Also by way of example, the application data may comprise extensible markup language (XML) data. In some example embodiments, the at least one application may be further configured to cause the mobile wireless communications device to generate response information for the backend data server using key-value pairs.
One example visual attribute formatting rule is an active label rule. Another example visual attribute formatting rule is a button component rule. Still another example visual attribute formatting rule is a text component rule. Yet another example visual attribute formatting rule is a dropdown component rule. Another example visual attribute formatting rule is a checkbox component rule. An additional example visual attribute formatting rule is a contact component rule. Another example visual attribute formatting rule is a map component rule. An additional example visual attribute formatting rule is a calendar event component rule.
A related communications system may include a backend data server configured to store application data without visual attribute formatting associated therewith, and an application proxy server configured to store and apply visual attribute formatting rules to application data retrieved from the backend data server. The system may further include a mobile wireless communications device comprising a display and having a native client UI. The mobile wireless communications device may be configured to at least retrieve the application data having the visual attribute formatting rules applied thereto from the application proxy server based upon an application on the mobile wireless communications device, and visually render on the display the retrieved application data having the visual attribute formatting rules applied thereto using the native client UI and without visual attribute formatting by the at least one application.
By way of background, mobile application or “app” developers may need to process data from enterprise backend servers, and ultimately render information on a mobile wireless communications device (also referred to as a “mobile device” herein) screen. This information may be pushed to the mobile device when new content is available. Yet, it may be a relatively complex task for a developer to design and arrange screens for a wide variety of pushed content payloads, screen sizes and resolutions. The speed at which a developer can provide a solution may be slowed by coding the UI details. Likewise, changing the UI to accommodate new payloads or UI requirements may be costly. In addition, backend enterprise server data is typically provided in a basic markup language format, such as extensible markup language (XML). This format does not include information about how the data will be visually presented on a smartphone or other type of handset.
Turning now to
The system 30 further illustratively includes an application proxy server 33, which further includes a database 34 configured to store visual attribute formatting rules, and a processor 35 configured to apply the visual attribute formatting rules to application data retrieved from the backend data server 31, at Block 52, as will be discussed further below. The backend data server 31 may communicate with the application proxy server 33 via a local area network (LAN), wireless data network, the Internet, etc., and they may be remotely located or co-located depending on a given implementation. In accordance with one example, the backend data server 31 may be provided by a mobile application developer, while the application proxy server may be provided by a mobile service provider (e.g., a cellular network provider or mobile device manufacturer).
The system 30 also illustratively includes a mobile device 36 which communicates with the application proxy server 33 via a wireless network 37 (e.g., a cellular network, wireless LAN, etc.). The mobile device 36 illustratively includes a display 38 and has a native client UI 39 and one or more mobile device applications or “apps” resident thereon. More particularly, the native client UI 39 and applications 40 may be implemented using a combination of hardware components (e.g., microprocessor, memory, etc.) and software components (e.g., computer-executable instructions stored on a computer-readable medium). Example mobile devices 36 may include portable or personal media players (e.g., music or MP3 players, video players, etc.), portable gaming devices, portable or mobile telephones, smartphones, tablet computers, digital cameras, etc.
The mobile device 36 may be configured to retrieve application data having the visual attribute formatting rules applied thereto from the application proxy server 33 based upon the application 40, and visually render on the display 38 the retrieved application data having the visual attribute formatting rules applied thereto using the native client UI 39, and without visual attribute formatting by the application, at Block 53, which concludes the method illustrated in
Moreover, as noted above, a plurality of different applications 40 may be provided on the mobile device 36, in which case the visual attribute formatting rules may comprise a respective different set of visual attribute formatting rules for each of the different applications. However, in some instances different applications may share a common set of visual attribute formatting rules. Here again, this advantageously allows application developers to update the way in which visual attribute formatting occurs for multiple different applications by uploading the appropriate rules to a single, central application proxy server 33.
More particularly, the application proxy server 33 functions as an intermediate server that may be used to process the information sent from the backend data server 31 to the mobile device 36 that runs the application 40 designed to consume, render, or act on the information. Using the application proxy server 33 to enhance or augment this data by altering or adding attributes that provide information about how the data should be rendered (i.e., through the use of the visual attribute formatting rules) allows the application 40 or the native client UI 39 on the mobile device 36 to be “thinner” and more flexible in rendering various types and combinations of information—even those not present at the time of the original development of the client application.
In an example implementation, which will be discussed in greater detail below, leaf nodes of the application data feed may be obtained, an element name may be used or inserted as a label by the application proxy server 33, and an element value may be used as the value to be displayed by the native client UI 39. A mapping of attribute types to UI elements may provide conversion of the feed to a format that is sent to the native client UI, which then uses the new markup to determine how to render each field on the mobile device 36.
By way of example, a field may be rendered as a list of items in a pull down menu, or it may be rendered as a button. A “content type” attribute may indicate whether the information should be rendered as HTML, or presented in a rich client interface, for example. HTML content may be rendered in a browser field in this case, as opposed to using UI elements specific to the mobile device widgets or native client UI elements. Additionally, when information is entered on the mobile device 36 or the native client UI is used, response information may be sent via key-value pairs to the application proxy server 33, and converted to a payload in a format (e.g., XML) known to the backend data server 31 (Block 53).
Example processing for rich client styles and markup language systems will now be described respectively with reference to
Referring first to the example shown in
This example data set represents a form to be displayed on the display 38 for data entry by a user (i.e., to select a country of residence for the user). This form is delineated by “Task” tags (i.e., an open task tag “<Task>” and a close task tag “</Task>”), and includes owner information (delineated by “Owner” and “Name” tags) which provides the owner's (or user's) name, country information (delineated by “Countries” tags) providing available country selection choices, and outcome information (delineated by “Outcomes” tags) providing for potential outcomes or actions (i.e., accepting the data, rejecting the data, or holding the data).
The backend application information is pushed to the application proxy server 33 (although it may be “pulled” in other embodiments) for conversion processing to format the backend application data for display in a rich client format. More particularly, the rich client visual formatting rules may be stored in the data base 34, which may be conceptually considered as a look-up table. In the illustrated look-up table, a “countries” tag is mapped to a rich client “dropdown” type, an “outcomes” tag is mapped to a rich client “button” type, and all other tags within a task are considered as “default” tags and are mapped to a rich client “string” type. The processor 35 uses these formatting rules to format the backend data as shown in the box 41, i.e., with corresponding dropdown, button, and string format types, and as reproduced below:
When this formatted data is pushed to the mobile device 36 (which is referred to as a “handset” in
A similar example is provided in
The native client UI 39′ rendering logic for HTML pages accordingly generates on the display 38′ an appropriate form including name text 42′, a drop down menu 43′, and respective hyperlinks 44′, 45′, and 46′ for the “accept”, “reject”, and “hold” outcomes, as opposed to buttons in the rich client example of
Various examples of visual formatting rules that developers may provide to the application proxy server 33 are now described. That is, an application developer provides the application proxy server 33 with the appropriate formatting rules so that the incoming backend application data it provides to the application proxy server 33 may advantageously be formatted appropriately for native client UIs on different mobile devices. However, it will be appreciated that the techniques described herein may also be used with other wireless communications systems and devices.
The application developer (which may be the mobile device manufacturer or a third-party developer) provides visual formatting rules that allow the application proxy server 33 to parse and display the appropriate UI content on the push container and details screen of the mobile device. A first example is for container screen elements and attributes. For example, if the backend application XML data is as follows:
The above would be enhanced by the application proxy server 33 to:
This would then be rendered by the native client UI as follows:
Another example is a label attribute. By default, elements may be laid out as a label name and its value as the text corresponding to the label. For example:
would be laid out as
would be laid out as
A next example is an active label component type. By default, all information may be assumed to be labels, as noted above. If the label value is an email, phone, URL, etc., and the developer desires to add more rich formatting, such as opening respective applications based on which label is clicked, then an activeLabel component type may be used. For example:
<Work Email>jDoe@abc.com</Work Email>would be laid out as Work Email jDoe@abc.com
Clicking on it will have no effect by default, but the syntax below may be used by a developer to make the label active. For example:
Now clicking on this label will invoke menu items related to email. To change or override the default label, the label attribute may be used as set forth below. For example:
would be laid out as:
Another example is a button component type formatting rule. For example:
would be laid out as
would be laid out as an “accept” button and a “reject” button. Again, to change or override the default label, the label attribute may be used. For example:
would be laid out as an “Accept” button and a “Reject” button.
Still another example is a “more” button component type. This is an extension of the above-noted buttons. When clicked, the “more” button would select a designated URL and supply an ID of the message whose “more details” are to be retrieved. For example:
would be laid out as a “More . . . ” button and a “Background” button. Upon clicking the “More . . . ” button, a GET request would be made to the URL “http://www.XYZ.com?id=12345&source.XYZ” and results would be parsed and shown as key-value pairs in a new screen. Similarly, upon clicking the “Background” button, a GET request would be made to the URL “http://www.XYZ.com/background?id=12345&source=XYZ” and results would be parsed and shown as key-value pairs in a new screen.
Still another example is a text component type. By default, the following example:
would be laid out as “Name” followed by a “John Doe” button. To change the default label, the label attribute may be used as set forth below. For example:
would be laid out as “Full Name” followed by a “John Doe” button.
To display elements in a dropdown, a component element designation may be used, with the type attribute set to dropdown. For example:
would be laid out as a dropdown box with “United States”, “Canada”, and “India” as selection options. A “selected” attribute may be used to show or highlight a specific value by default.
Another example is a contact component type. This component type is used to add a contact into the BlackBerry address book upon push of a workflow. For example:
would be laid out as below in the details screen, while the whole contact including other details above would be added to the BlackBerry Address Book.
Still another example is a map or GPS component type, which may be used to display Map It! and Route It! buttons in the details screen and launch BlackBerry Maps for location and routing directions respectively. The application proxy server 33 may advantageously geocode the contact address and send the resultant values to this component. For example:
would be laid out as a “Map It!” button and a “Route It!” button. Clicking on the “Map It!” button would generate a BlackBerry Map map screen 60 as seen in
Another example is an event component type. This component type may be used to add an event into the BlackBerry Calendar upon push of a workflow. For example:
would be laid out set forth below in a details screen:
Various components of an example mobile device 1000 that may be used with the above described systems are now described with reference to
The housing 1200 may be elongated vertically, or may take on other sizes and shapes (including clamshell housing structures). The keyboard may include a mode selection key, or other hardware or software for switching between text entry and telephony entry.
In addition to the processing device 1800, other parts of the mobile device 1000 are shown schematically in
Operating system software executed by the processing device 1800 is stored in a persistent store, such as the flash memory 1160, but may be stored in other types of memory devices, such as a read only memory (ROM) or similar storage element. In addition, system software, specific device applications, or parts thereof, may be temporarily loaded into a volatile store, such as the random access memory (RAM) 1180. Communications signals received by the mobile device may also be stored in the RAM 1180.
The processing device 1800, in addition to its operating system functions, enables execution of software applications 1300A-1300N on the device 1000. A predetermined set of applications that control basic device operations, such as data and voice communications 1300A and 1300B, may be installed on the device 1000 during manufacture. In addition, a personal information manager (PIM) application may be installed during manufacture. The PIM may be capable of organizing and managing data items, such as e-mail, calendar events, voice mails, appointments, and task items. The PIM application may also be capable of sending and receiving data items via a wireless network 1401. The PIM data items may be seamlessly integrated, synchronized and updated via the wireless network 1401 with corresponding data items stored or associated with a host computer system.
Communication functions, including data and voice communications, are performed through the communications subsystem 1001, and possibly through the short-range communications subsystem. The communications subsystem 1001 includes a receiver 1500, a transmitter 1520, and one or more antennas 1540 and 1560. In addition, the communications subsystem 1001 also includes a processing module, such as a digital signal processor (DSP) 1580, and local oscillators (LOS) 1601. The specific design and implementation of the communications subsystem 1001 is dependent upon the communications network in which the mobile device 1000 is intended to operate. For example, a mobile device 1000 may include a communications subsystem 1001 designed to operate with the Mobitex™, Data TAC™ or General Packet Radio Service (GPRS) mobile data communications networks, and also designed to operate with any of a variety of voice communications networks, such as AMPS, TDMA, CDMA, WCDMA, PCS, GSM, EDGE, etc. Other types of data and voice networks, both separate and integrated, may also be utilized with the mobile device 1000. The mobile device 1000 may also be compliant with other communications standards such as 3GSM, 3GPP, UMTS, 4G, etc.
Network access requirements vary depending upon the type of communication system. For example, in the Mobitex and DataTAC networks, mobile devices are registered on the network using a unique personal identification number or PIN associated with each device. In GPRS networks, however, network access is associated with a subscriber or user of a device. A GPRS device therefore typically involves use of a subscriber identity module, commonly referred to as a SIM card, in order to operate on a GPRS network.
When required network registration or activation procedures have been completed, the mobile device 1000 may send and receive communications signals over the communication network 1401. Signals received from the communications network 1401 by the antenna 1540 are routed to the receiver 1500, which provides for signal amplification, frequency down conversion, filtering, channel selection, etc., and may also provide analog to digital conversion. Analog-to-digital conversion of the received signal allows the DSP 1580 to perform more complex communications functions, such as demodulation and decoding. In a similar manner, signals to be transmitted to the network 1401 are processed (e.g. modulated and encoded) by the DSP 1580 and are then provided to the transmitter 1520 for digital to analog conversion, frequency up conversion, filtering, amplification and transmission to the communication network 1401 (or networks) via the antenna 1560.
In addition to processing communications signals, the DSP 1580 provides for control of the receiver 1500 and the transmitter 1520. For example, gains applied to communications signals in the receiver 1500 and transmitter 1520 may be adaptively controlled through automatic gain control algorithms implemented in the DSP 1580.
In a data communications mode, a received signal, such as a text message or web page download, is processed by the communications subsystem 1001 and is input to the processing device 1800. The received signal is then further processed by the processing device 1800 for an output to the display 1600, or alternatively to some other auxiliary I/O device 1060. A device may also be used to compose data items, such as e-mail messages, using the keyboard 1400 and/or some other auxiliary I/O device 1060, such as a touchpad, a rocker switch, a thumb-wheel, or some other type of input device. The composed data items may then be transmitted over the communications network 1401 via the communications subsystem 1001.
In a voice communications mode, overall operation of the device is substantially similar to the data communications mode, except that received signals are output to a speaker 1100, and signals for transmission are generated by a microphone 1120. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on the device 1000. In addition, the display 1600 may also be utilized in voice communications mode, for example to display the identity of a calling party, the duration of a voice call, or other voice call related information.
The short-range communications subsystem enables communication between the mobile device 1000 and other proximate systems or devices, which need not necessarily be similar devices. For example, the short-range communications subsystem 1020 may include an infrared device and associated circuits and components, NFC or a Bluetooth™ communications module to provide for communication with similarly-enabled systems and devices.
Many modifications and other embodiments will come to the mind of one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is understood that various modifications and embodiments are intended to be included within the scope of the appended claims.
This application claims the benefit of U.S. provisional app. No. 61/386,658 filed Sep. 27, 2010, which is hereby incorporated herein in its entirety by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61386658 | Sep 2010 | US |
