Managing data access in mobile devices

A method for managing data access in a mobile device is provided in the illustrative embodiments. Using a data manager executing in the mobile device, a data item is configured in a data model. A value parameter of the data item is populated with data and a status parameter of the data item is populated with a status indication. A subscription to the data item is received from a mobile application executing in the mobile device. In response to the subscription, the data and the status of the data item are sent to the mobile application.

BACKGROUND

1. Technical Field

The present invention relates generally to a computer implemented method for accessing data. More particularly, the present invention relates to a computer implemented method for managing data access in mobile devices.

2. Description of the Related Art

As the workforce becomes increasingly mobile, more and more demands are being placed on software applications that execute on mobile computing platforms. Some mobile computing platforms, such as laptop computers, are fully functional computers, which are often connected to a high bandwidth wired or wireless network.

Mobile devices, such as smartphones or mobile communication devices are quickly becoming a popular alternative to laptop computers. Applications are being designed for the mobile devices that bring complex functionality and operations to the mobile devices in a mobile data network environment.

Some mobile applications, that is, applications executing on mobile devices, need efficient access to significant volumes of data. The data volume and the rate of change of data is such that a mobile device may not be able to store the entire dataset or keep the data up-to-date because of memory, communication bandwidth, communication availability, and energy conservation constraints.

The mobile applications are becoming increasingly sophisticated and data intensive. The mobile users expect similar responsiveness and functionality from applications on mobile devices as expected from more capable computing platforms and data networks. Even as the data communication capabilities of mobile networks, such as the cellular networks, improve, the demands on such networks are ever increasing.

SUMMARY

The illustrative embodiments provide a method for managing data access in mobile devices. An embodiment configures, using a data manager executing in the mobile device, a data item in a data model. The embodiment populates a value parameter of the data item with data and a status parameter of the data item with a status indication. The embodiment receives a subscription to the data item from a mobile application executing in the mobile device. The embodiment sends, responsive to the subscription, the data and the status of the data item to the mobile application.

Another embodiment further receives an update for the data item. The embodiment updates the data in value parameter of the data item. The embodiment determines whether the status indication should be changed because of the update, forming a status determination. The embodiment adjusts the status parameter with a second status indication responsive to the status determination being affirmative. The embodiment pushes contents of the updated value parameter and the adjusted status parameter to the mobile application. The embodiment causes a use of the value parameter to change in the mobile application due to the adjusted status parameter.

In another embodiment, the data in the value parameter is computed using the update. The embodiment further repeats the receiving, the updating, the determining, and the adjusting responsive to an update frequency period specified for the data item elapsing.

Another embodiment further receives, from the mobile application executing in the mobile device, a request to unsubscribe from the data item. The embodiment unsubscribes the mobile application from the data item. The embodiment determines whether a second mobile application is subscribed to the data item. The embodiment receives an update for the data item responsive to the second mobile application being subscribed to the data item. The embodiment discontinues the update for the data item responsive to no subscriptions remaining for the data item.

In another embodiment, the mobile application and the second mobile application use the update at different frequencies, wherein the update is received at a source's frequency, and wherein the update and a status indication from the data item are pushed to the mobile application and the second mobile application at their respective frequencies.

In another embodiment, the configuring configures a subset of a set of parameters of the data item. The embodiment further configures, using the mobile application, another subset of the set of parameters of the data item, wherein the data item is not previously configured in the data model.

In another embodiment the configuring further identifies a source of data for the data item, determines an update method for the data item, and determines an update frequency for the data item, wherein the source, the update method, and the update frequency are provided to the data manager and not to the mobile application.

Another embodiment further uses a policy to adjust an update frequency of the data item, or prioritize an update of the data item.

Another embodiment further uses a policy to determine the mobile application's entitlement to the data item, wherein the policy is used for denying the mobile application from subscribing to the data item.

In another embodiment, the policy uses a combination of an identity of the application, an identity of the mobile device, and a history of previous actions by the mobile application to determine the entitlement.

Another embodiment further allows a second mobile application executing in a second mobile device access to the data item by sending the date item to a second data manager in the second mobile device such that the second data manager does not have to receive an update to the data item from a designated source of the data item.

In another embodiment, the data manager uses a combination of subscriptions to the data item, parameters of the data item, and available memory at the mobile device to purge the data item.

Another embodiment further causes the provision of a cue at the mobile application based on a status indication in a status parameter of a data item, wherein the cue indicates in the mobile application that a value associated with the data item is out of date.

Another embodiment further pre-fetches an update for the data item, the pre-fetching being based on a subscription history of the data item.

DETAILED DESCRIPTION

The invention recognizes that the qualities of the mobile device, the mobile application, the mobile network, and the data sources all contribute to the effectiveness of mobile computing. A data source is a system, device, instrumentation, or equipment, including but not limited to computers or data processing systems, that provides data.

The invention recognizes that even if the computing capabilities of mobile devices rival those of desktop or laptop computers, and even if mobile networks' performance becomes comparable to wired or wireless data networks, some data sources cannot be converted to active or interactive data providers. Furthermore, many data sources cannot match the data rate or the efficiency of data communication when communicating with increasingly sophisticated, responsive, or interactive applications on mobile device.

Existing systems attempt to hide the latency in data communications with data sources by caching data on the provider side of the network. In other words, a mobile application (a client-side application) interacts not with a data source but from an intermediary source-side (server-side) system or application that masks the actual data source's data latency, legacy capabilities, or both.

The invention recognizes that server-side caching has several disadvantages. For example, even with the server-side caching enabled, the cache may not contain the data that a mobile application needs. In such a case, the server-side caching becomes ineffective and the mobile application performance suffers.

The illustrative embodiments used to describe the invention generally address and solve the above-described problems and other problems related to mobile applications. The illustrative embodiments provide a method for managing data access in mobile devices. The illustrative embodiments describe a client-side data management technique to improve the responsiveness and readiness of mobile applications and to improve the user-experience resulting there from.

Using an illustrative embodiment, a mobile application executing on a mobile device (client-side) interacts with one or more data sources through a client-side data management configuration comprising a data manager and a data model as described in detail herein. The data manager together with the data model interacts with data sources directly or through any existing intermediaries.

According to an embodiment, the responsiveness of the mobile application is improved because the mobile application requests and receives data from a client-side data management configuration. The client-side data management configuration effectively makes a passive data source appear as an active data source. A passive data source is a data source that does not provide data on its own initiative, but from which the data has to be requested. An active data source is a data source that proactively provides data.

The client-side data management configuration requests the data from passive data sources in the background such that updated data is available to the mobile application and the application logic need not be aware of whether a new request has to be made for an update. Even an active data source may be incompatible with a mobile application in that the active data source may provide the data at a rate that is different from a rate at which the mobile application can consume the data. The data management configuration on the client-side according to an embodiment can facilitate the data rate or update frequency discrepancy between data sources and the one or more mobile applications that may use their data.

The illustrative embodiments are described with respect to certain data, data structures, file-systems, file names, directories, and paths only as examples. Such descriptions are not intended to be limiting on the invention. For example, an illustrative embodiment described with respect to one form of local application name and path can be implemented as an application on a different form of path or name within the scope of the invention.

The illustrative embodiments are further described with respect to certain applications only as examples. Such descriptions are not intended to be limiting on the invention. An embodiment of the invention may be implemented with respect to any type of application, such as, for example, applications that are served, the instances of any type of server application, a platform application, a stand-alone application, an administration application, or a combination thereof.

An application may further include data objects, code objects, encapsulated instructions, application fragments, services, and other types of resources available in a data processing environment. For example, a Java® object, an Enterprise Java Bean (EJB), a servlet, or an applet may be manifestations of an application with respect to which the invention may be implemented. (Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates).

FIG. 1depicts a pictorial representation of a network of data processing systems in which illustrative embodiments may be implemented. Data processing environment100is a network of computers in which the illustrative embodiments may be implemented. Data processing environment100includes network102. Network102is the medium used to provide communications links between various devices and computers connected together within data processing environment100. Network102may include connections, such as wire, wireless communication links, or fiber optic cables. Server104and server106couple to network102along with storage unit108. Software applications may execute on any computer in data processing environment100.

In addition, clients110,112, and114couple to network102. A data processing system, such as server104or106, or client110,112, or114may contain data and may have software applications or software tools executing thereon.

Mobile device118may be any suitable mobile device communicating with network102. Some examples of mobile device118may be smartphones, mobile phones, personal digital assistants, mobile communication devices, limited purpose mobile computing devices, wearable mobile devices, or devices whose primary use may be other than as a computer. Application119may be a mobile application executing on mobile device118. Data manager121may be a data manager according to an embodiment, interacting with a data model (not shown) according to an embodiment. Temperature sensor105in server104or fan speed monitor107in a rack where server106may be mounted are some examples of passive data sources.

A storage array used in storage108is an example of a passive data source under some circumstances, and an active data source under different circumstances. For example, one type of storage array may provide disk utilization information only upon request. Another type of storage array may provide the disk utilization on a periodic basis or upon some event, without an explicit request.

The examples of the active and passive data sources are not intended to be limiting on the invention. Generally, any data source may behave as a passive data source under some circumstances and as an active data source under different circumstances without limitation.

In the depicted example, data processing system200employs a hub architecture including North Bridge and memory controller hub (NB/MCH)202and south bridge and input/output (I/O) controller hub (SB/ICH)204. Processing unit206, main memory208, and graphics processor210are coupled to north bridge and memory controller hub (NB/MCH)202. Processing unit206may contain one or more processors and may be implemented using one or more heterogeneous processor systems. Graphics processor210may be coupled to the NB/MCH through an accelerated graphics port (AGP) in certain implementations.

An operating system runs on processing unit206. The operating system coordinates and provides control of various components within data processing system200inFIG. 2. The operating system may be a commercially available operating system such as Microsoft® Windows® (Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both), or Linux® (Linux is a trademark of Linus Torvalds in the United States, other countries, or both). An object oriented programming system, such as the Java™ programming system, may run in conjunction with the operating system and provides calls to the operating system from Java™ programs or applications executing on data processing system200(Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates).

Program instructions for the operating system, the object-oriented programming system, the processes of the illustrative embodiments, and applications or programs are located on storage devices, such as hard disk drive226, and may be loaded into a memory, such as, for example, main memory208, read only memory224, or one or more peripheral devices, for execution by processing unit206. Program instructions may also be stored permanently in non-volatile memory and either loaded from there or executed in place. For example, the synthesized program according to an embodiment can be stored in non-volatile memory and loaded from there into DRAM.

With reference toFIG. 3, this figure depicts a block diagram of a client-side data management configuration for managing data access in a mobile device in accordance with an illustrative embodiment. Mobile device302may be analogous to mobile device118inFIG. 1. Mobile application304may be implemented using application119inFIG. 1.

Data model306and data manager308together form a client-side data management configuration. Data manager308may use the mobile communication capabilities of mobile device302to communicate over network310. Source312may be a data source. Source312may be a passive data source, an active data source, or a combination thereof.

Data model306is a local data structure on mobile device302. Data manager308, among other functions as described elsewhere in this disclosure, manages data model306. Data model306presents an active view of data that may be acquired from passive data sources such as one embodiment of source312. Data model306also presents an active view of data that may be acquired from active data sources, such as another embodiment of source312, whose data rate or update frequency may not match those of mobile application304or may be unknown to mobile application304.

As an example, “attribute 1”, “attribute 2”, and “attribute 3” may be example data that may be acquired from one or more source312for use in mobile application304. Mobile application304may use “attribute 1”, “attribute 2”, and “attribute 3” as shown in mobile application304's operations. For example, mobile application304may display, plot, or graph the values of these attributes and their updates.

Mobile application304interacts with data model306to identify itself as a receiver of certain data, for example the depicted “attribute 1”, “attribute 2”, and “attribute 3” data. The process of identifying mobile application304as a receiver of certain data in data model306is called a subscription process. The identification is called a subscription. For example, mobile application304has a subscription to “attribute 1” to display the current and updated values of “attribute 1”. Mobile application304unsubscribes to a particular data in data model by removing or deactivating its subscription to such data.

Mobile application304is described as configuring to receive “attribute 1”, “attribute 2”, and “attribute 3” only as an example without limiting the scope of the invention. Any number of mobile application(s)304may configure information about any type and any number of data items in data model306they wish to receive. Any number of mobile application(s)304may subscribe to a particular data item configured in data model306.

Data manager308further configures the data items present in data model306. For example, data manager308may configure a data item in data model306with further information about the address, protocol, update rate, and any other suitable aspect of data exchange needed for receiving that data item from the appropriate source312.

Data manager308also implements policies governing data model306. For example, some policies may define the operations that mobile application304is allowed to perform on data model306. Other example policies may define how a particular source312is to be accessed or a particular data item received from a particular source312. Other example policies may define how and when a data item is to be purged from data model306or retained therein. Any number and type of policies may be implemented using data manager308.

Given these examples of the policies, many other policies will become apparent to those of ordinary skill in the art and the same are contemplated within the scope of the invention. For example, mobile application304may subscribe or unsubscribe to the various data items in data model306according to a certain policy. As another example, data manager308may use a policy about the subscription information at a given time to determine whether to update a certain data item, retain the data item's configuration in data model306, or purge the data item from data model306.

Mobile application304may subscribe or unsubscribe to a data item in data model306dynamically based on application logic, user preferences, and the current user view in mobile application304. In one embodiment, when mobile application304is subscribed to a particular data item in data model306, data manager308may acquire updates for that data item and push the updated data item to mobile application304.

Data manager308may consolidate or modify data requests to one or more source312depending upon which mobile application(s)304, and what number of them, may be using a particular data item. For example, data manager308may aggregate subscriptions from different mobile applications304and optimize the use of the bandwidth, memory, and energy available to mobile device302while meeting the needs of mobile application304or its user.

A data item may be represented in any suitable form in data model306. For example, a data item may be a string, Boolean value, an integer or floating point number, a data structure, a data object, a class or an object thereof, code, or any data form suitable for a given implementation.

Furthermore, a data item may be configured in data model306with one or more indications (status), such as for urgency, age, completeness, reliability, disclaimers, applicable policy, rate of change, priority, or any other indication suitable for a given data item in a given implementation. Data manger308may modify such indications, and mobile application304may use such indications when using the associated data item.

Data manager308may be pre-configured or configured on-the-fly with information about accessing various source(s)312. Such information may include knowledge of how to obtain and refresh data items from a certain source312over a particular combination of data networks.

With reference toFIG. 4, this figure depicts a block diagram of an example data model in accordance with an illustrative embodiment. Data model400may be used as data model306inFIG. 3.

In the example depicted in this figure, data model400is shown to include column402to identify an “attribute name” parameter of a data item. An attribute name of a data item is the name by which the data item can be referenced.

Column408identifies a “source” parameter of a data item. A source identifies or references the source that has can provide the data for that data item.

Column412identifies an “update frequency” parameter of a data item. An update frequency specifies how often the data for the data item should be updated. Update frequency may be specified in any manner suitable to a particular implementation without departing the scope of the invention.

These columns are not limiting on the invention. Any number of columns may be similarly configured in data model400within the scope of the invention.

For example, row418defines the data item “attribute 1” which has been presently subscribed to by mobile applications “application 1” and “application 2.” Attribute 1 was previously subscribed to (and is currently unsubscribed from) by mobile application “application 3.” The source of “attribute 1” is a temperature sensor at (a machine located at) an IP address 192.168.1.100. The method to use for acquiring “attribute 1” from that source is over Hypertext transport protocol (HTTP). The temperature data for “attribute 1” should be acquired every 30 seconds. The last received value for “attribute 1” was “123.45” in some designated unit of measurement. The status of “attribute 1” is current (as of an optional time stamp), which means that the value “123.45” is a current value for “attribute 1.”

Row420defines a data item “attribute 2” to which no mobile application is currently subscribing. The source of “attribute 2” is a fan speed sensor at a rack reachable using address “//rack15” over the local area network. The update method to use with this source is “xyz.” No update frequency is specified because no mobile application is currently subscribing to this data item and updating this data item would waste data communication bandwidth. “Attribute 2” had the last received value of “0.52”. That value of “attribute 2’ is older than a specified threshold and should not be relied upon. For example, a mobile application that subscribes to “attribute 2” may begin by displaying the old value of “attribute 2” but may use the “old” status to exclude that value from any decision making process until it receives the current value for “attribute 2”.

Data item422is “attribute 3” to which mobile application “application 1” is currently subscribing. “Attribute 3” is a disk utilization of one or more drives mapped to path “X:/” in a network. “Attribute 3” should be updated using TCP every 30 minutes. The last received (current) value of “attribute 3” is 23 (percentage or any other unit of measure). The current value for “attribute 3” is “partial” in that while the value is current, the disk utilization computation at “X:/” has not completed and that source reports the utilization to be 23 percent up to this point in the utilization computation.

Data item424is “attribute 4” to which mobile application “application 2” is subscribing. “Attribute 4” is the processor availability at all available sources (indicated by the wildcard character “*”). Accordingly, the update method for “attribute 4” varies depending upon which of the various available sources is being queried. The frequency of update may also vary depending upon the source. The value and status of the value also varies depending upon which source's processor availability is being held in “attribute 4”.

Data items like data item424can be implemented in several different ways. For example, data item424can be a data structure comprising multiple rows in data model400to hold each parameter combination for “attribute 4” separately. As another example, data item424can be a single row whose parameters periodically cycle through all possible combinations. As another example, data item424may be a single row with multiple row entries in columns410,412,414, and416.

The specific columns, rows, row entries, and the parameter values described above are only examples to illustrate the configuration of data model400. Those of ordinary skill in the art will be able to configure more, less, or different artifacts in an implementation of data model400based on this description and the same are contemplated within the scope of the invention.

With reference toFIG. 5, this figure depicts a block diagram of an example process of managing data access in mobile devices in accordance with an illustrative embodiment. Mobile application502may be analogous to mobile application304inFIG. 3, or any of “application 1” “application 2” or “application 3” identified in rows418-424inFIG. 4. Data model504may be implemented using data model400inFIG. 4. Data manager506may be analogous to data manager308inFIG. 3.

Communication component510may be a communication device or component of mobile device512in which mobile application502, data model504, and data manager506may be stored or executing. Network514may be any data network over which data items in data model504may be acquired. Any number of sources516may be able to provide such data items to data model504over network514. Source516may comprise any combination of active sources or passive sources. Some examples of active sources516may be resource monitors for various type of computing resources in various data processing systems. Some examples of passive sources516may be sensors and facilities management instrumentation, such as controls, meters and gauges, or switches.

Mobile application502may perform certain operations against some or all or the parameters of one or more data items in data model504. Data manager506may also perform certain operations against some or all or the parameters of one or more data items in data model504. For example, in one embodiment, mobile application502may configure columns402,404, and406for row422in data model400ofFIG. 4(used as data model504) and data manager506may configure parameters408,410,412,414, and416for that row.

Thus, mobile application502may define532a data item, subscribe or unsubscribe534to a data item, or query and receive538value of a data item. Mobile application502may also receive the value of a data item as a result of push538operation initiated from data model504by data manager506.

Data manager506may detect540a data item being defined. Data manager506may further define or update542a data item, populate544the data item's parameters, and adjust546the attribute status of the data item. Data manager506requests548data for a data item, and receives550the requested data from any of sources516.

With reference toFIG. 6, this figure depicts a flowchart of an example process for managing data access in mobile devices in accordance with an illustrative embodiment. Process600may be implemented in a data manager, such as data manager506inFIG. 5.

Process600begins by receiving a definition (or an indication thereof) of a data item from a mobile application in a data model (step602). Process600identifies a source of data for the data item (step604). Process600determines a suitable update method for the data item (step606). Process600determines a suitable update frequency for the data item (step608).

Process600configures the data item in the data model with the information determined or identified in steps604,606, and608(step610). Process600may then end thereafter. Alternatively, process600may proceed to exit labeled “A”, to enter another process, such as process700inFIG. 7, having a corresponding entry point labeled “A”.

With reference toFIG. 7, this figure depicts a flowchart of another process for managing data access in mobile devices in accordance with an illustrative embodiment. Process700may be implemented in a data manager, such as data manager506inFIG. 5.

Process700begins by requesting the data for a data item configured in a data model (step702). For example, step702may be performed for the data item defined in step602and further configured in step610inFIG. 6. Another process, such as process600inFIG. 6or process800inFIG. 8, may enter process700at the entry point labeled “A”.

Process700updates the value parameter of the data item, such as by performing some computation based on the data received, writing the value to a memory location, or adjusting the contents of a data storage area (step704). Process700updates the attribute status parameter of the data item with a suitable indication (step706).

Process700determines whether to repeat the data acquisition and update process for the data item (step708). For example, the data acquisition and update may be repeated if an update frequency so warrants or a mobile application subscribes to the data item. Another process, such as process800inFIG. 8, may enter process700at entry point labeled “B”. If the data acquisition and update should be repeated for the data item (“Yes’ path of step708), process700returns to step702.

If the data acquisition and update is not to be repeated (“No” path of step708), process700determines whether to retain the data item's definition in the data model (step710). For example, in one embodiment, when a data item is not subscribed to by any mobile application for a predetermined period, the definition of the data item may be purged from the data model. As another example, if a source of data for a data item no longer exists or provides that data, the corresponding data item's definition may be purged. Many other reasons or policies for purging a data item definition will become apparent from this disclosure to those of ordinary skill in the art and the same are contemplated within the scope of the invention.

If the definition is to be retained, such as by execution of a policy by a data manager (“Yes” path of step710), process700updates the attribute status of the data item, such as by indicating the data of the data item to be “old” after a period has elapsed (step712). Process700ends thereafter.

If the definition is to be purged, such as by execution of a policy by a data manager (“No” path of step710), process700purges the definition of the data item from the data model (step714). Process700ends thereafter.

With reference toFIG. 8, this figure depicts a flowchart of managing data acquisition bases on subscriptions in a mobile device in accordance with an illustrative embodiment. Process800may be implemented in a data manager, such as data manager506inFIG. 5.

Process800begins by monitoring the subscription status of a data item in a data model (step802). Process800detects a change in the subscription status, for example, a change from unsubscribed to subscribed, or from subscribed to unsubscribed status of the data item (step804).

Process800determines whether the subscription status as changed indicates that the data item has been subscribed to by a mobile application (step806). If a mobile application has subscribed to the data item (“Yes” path of step806), process800exists at exit point labeled “A” and enters another process, process700inFIG. 7, at a corresponding entry point labeled “A”. If a mobile application has unsubscribed from the data item (“No” path of step806), process800exists at exit point labeled “B” and enters another process, process700inFIG. 7, at a corresponding entry point labeled “B”.

With reference toFIG. 9, this figure depicts a flowchart of a process for using data in a mobile device in accordance with an illustrative embodiment. Process900may be implemented in a mobile application, such as mobile application502inFIG. 5.

Process900begins by detecting a need for an attribute or a particular data (step902). Process900accesses a data manager, such as data manager506inFIG. 5, to determine whether the attribute or data is available in a data model, such as data model504inFIG. 5(step904). In one embodiment, process900may access the data model directly for making the determination of step904.

Process900determines whether the requested data is configured and available in the data model (step906). If the data is available in the data model (“Yes” path of step906), process900subscribes to the corresponding data item (step908).

Process900receives the presently available value and status of the data item (step910). Process900uses the present value according to the associated attribute status (step912). Receiving and using an existing value allows a mobile application to initiate a use of the data from some value as opposed to no value at all. For example, a user may prefer seeing at least a last known value instead of a blank data field until the data is refreshed.

If the data is not available in the data model (“No” path of step906), process900defines a data item for the desired data (step914). Process900receives updates to the value of the data item as they become available in the data model, such as by being pushed from the data model to the mobile application (step916). Process900also executes step916following step912.

Process900determines whether to terminate or unsubscribe from the data item, such as when the mobile application exists, or no longer requires the data of the data item (step918). If process900determines to continue the subscription (“No” path of step918), process900returns to step916. If process900decides to terminate or unsubscribe (“Yes’ path of step918), process900unsubscribes from the data item (step920). Process900ends thereafter.

Thus, a computer implemented method is provided in the illustrative embodiments for managing data access in mobile devices. Using an embodiment of the invention, persistent local data model in the mobile device allows a view of the data therein even when a source of the data is offline. Using an embodiment, a passive data source can be made to appear as active with respect to a mobile application executing on the mobile device. When the mobile application cannot communicate adequately with an active source, an embodiment can transparently synchronize the data updates as provided by the source and as needed by the application without changing either the source or the application's configurations.

The policy based implementation of the data manager and the data model according to an embodiment allows for dynamic configuration changes as data source come online or go offline without the mobile application caring for the details of source management. The policy based implementation further allows the data access from the mobile device to occur such that the bandwidth and storage space available to the mobile device are optimally utilized for the desired user-experience in the mobile application.

Furthermore, an embodiment may be used in conjunction with a data source that is capable of sending an indication when new data, updated data, or modified data is available at that data source. In the prior art, the mobile application would have to keep an open connection to the data source to receive the updated or new data, which is a disadvantageous use of mobile data bandwidth. By using an embodiment, a mobile application can avoid keeping connections open by using the described data model with such smart data sources. For example, the data model may be configured to check for updates from certain data sources, including such smart data sources based on the data items that are subscribed to at present or during a predetermined period.

Using an embodiment, metrics such as anticipated rate of change of data, probability of change, lifetime of the data, penalty for being out of date, value of being current, relative priority, and many other metrics that can be used for measuring or improving a mobile application's performance can be implemented. These and other metrics can form parameters of a data item that can be used in policies. The policies can then be used by the data manager according to an embodiment to prioritize, expedite, consolidate, or delay certain data access.

Furthermore, mobile applications can authenticate with the data manager for subscribing to data items. A combination of a subset of the application, the current user, installed certificates, answers to challenges (e.g. password), the device identity, history of previous actions, the current location, and the carrier, and many other factors can be used to determine entitlement to certain data items. For example, a combination of user actions (preferences, navigation, current view, location, etc.) and the nature of the application may used to allow or deny subscription to data items.

In addition to the processes described in this disclosure, the data manager of an embodiment may also use subscriptions, data item parameters, available data connectivity, available memory, and energy state of the mobile device to evict/purge and update data items in the data model.

An embodiment allows mobile applications to execute asynchronously and make requests to the data manager. The data manager returns data from data items to the requesting application without blocking data that may have unfavorable status indications, such as old or partial, or even invalid data, but such status indications assist the mobile application in deciding how to use the data.

The data manager performs asynchronous updates to data items as more recent data becomes available. The mobile applications can select appropriate actions based on data updates, such as whether to refresh a view.

An embodiment allows for providing cues, such as visual indications, in the mobile application based on the status indications of a data item. Such cues may be useful in keeping the end-user informed about the validity state of the data. For example, display intensity can be used to represent the probability of the data being current, guaranteed to be current, guaranteed to be out of date, and probability of being current. Any suitable manner of providing cues, such as visual, audible, or tactile can be similarly used in conjunction with the status indicators in mobile applications. For example, buttons may be grayed out to represent out of date data.

An embodiment may use a predictive algorithm to pre-fetch data based on data subscriber's profile, subscription history, current state of the data, and any other suitable factor.

An embodiment may also allow for peer-to-peer data caching, such as when multiple mobile devices are accessing the same data item and direct data links are available (e.g. Bluetooth connection) between the mobile devices. A data item stored in one mobile device's data model may be shared by that device's data manager to mobile applications executing in other mobile devices through the data managers executing therein. Data items can be populated in the data models of connected devices from other mobile devices instead of a data source. For peer-to-peer data caching, data items may be encrypted or signed during transmission.

Any combination of one or more computer readable storage device(s) or computer readable media may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage device may be an electronic, magnetic, optical, electromagnetic, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage device would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage device may be any tangible device that can store a program for use by or in connection with an instruction execution system, apparatus, or device. The terms “computer readable storage device,” “computer usable storage device,” and “storage device” do not encompass a signal propagation medium, any description in this disclosure to the contrary notwithstanding.

Program code embodied on a computer readable storage device or computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to one or more processors of one or more general purpose computers, special purpose computers, or other programmable data processing apparatuses to produce a machine, such that the instructions, which execute via the one or more processors of the computers or other programmable data processing apparatuses, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in one or more computer readable storage devices or computer readable media that can direct one or more computers, one or more other programmable data processing apparatuses, or one or more other devices to function in a particular manner, such that the instructions stored in the one or more computer readable storage devices or computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto one or more computers, one or more other programmable data processing apparatuses, or one or more other devices to cause a series of operational steps to be performed on the one or more computers, one or more other programmable data processing apparatuses, or one or more other devices to produce a computer implemented process such that the instructions which execute on the one or more computers, one or more other programmable data processing apparatuses, or one or more other devices provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.