A computer-implemented method for building a software application is disclosed. The method includes: generating a plurality of application resources; creating a plurality of tags; applying one of the tags on each of the plurality of application resources; grouping the application resources by their tags to form at least two asset packs, each identifiable by at least one tag shared by all application resources in the asset pack; and creating an asset pack manifest comprising a location of each of the asset packs and an order in which the asset packs are to be downloaded.
|
1. A method comprising:
at an electronic device comprising a storage device and configured to run a respective application:
determining that one or more conditions are satisfied with respect to the respective application, wherein a plurality of on demand resources stored on the storage device are used to run the respective application on the electronic device; and
in response to determining that the one or more conditions are satisfied with respect to the respective application:
removing, from the storage device, first one or more on demand resources of the plurality of on demand resources used to run the respective application; and
maintaining, on the storage device, second one or more on demand resources of the plurality of on demand resources used to run the respective application, wherein the determining, the removing and the maintaining are performed while the electronic device is running the respective application.
19. A non-transitory computer-readable storage medium storing instructions, which are configured to be executed by one or more processors of an electronic device comprising a storage device and configured to run a respective application, the instructions for:
determining that one or more conditions are satisfied with respect to the respective application, wherein a plurality of on demand resources stored on the storage device are used to run the respective application on the electronic device; and
in response to determining that the one or more conditions are satisfied with respect to the respective application:
removing, from the storage device, first one or more on demand resources of the plurality of on demand resources used to run the respective application; and
maintaining, on the storage device, second one or more on demand resources of the plurality of on demand resources used to run the respective application, wherein the determining, the removing and the maintaining are performed while the electronic device is running the respective application.
18. An electronic device configured to run a respective application, the electronic device comprising:
a storage device,
one or more processors; and
memory storing instructions, which are configured to be executed by the one or more processors, the instructions for:
determining that one or more conditions are satisfied with respect to the respective application, wherein a plurality of on demand resources stored on the storage device are used to run the respective application on the electronic device; and
in response to determining that the one or more conditions are satisfied with respect to the respective application:
removing, from the storage device, first one or more on demand resources of the plurality of on demand resources used to run the respective application; and
maintaining, on the storage device, second one or more on demand resources of the plurality of on demand resources used to run the respective application, wherein the determining, the removing and the maintaining are performed while the electronic device is running the respective application.
2. The method of
3. The method of
in accordance with a determination that the first one or more on demand resources are not needed by the respective application for a threshold duration of time, determining that the one or more conditions are satisfied; and
in accordance with a determination that the first one or more on demand resources are in accordance with a determination that the first one or more on demand resources are needed by the respective application within the threshold duration of time, determining that the one or more conditions are not satisfied.
4. The method of
in accordance with detecting a shortage of storage space on the storage device, determining that the one or more conditions are satisfied; and
in accordance with not detecting a shortage of storage space on the storage device, determining that the one or more conditions are not satisfied.
5. The method of
in accordance with a determination that the first one or more on demand resources are marked as un-purgeable independent of a running status of the respective application, determining that the one or more conditions are not satisfied; and
in accordance with a determination that the first one or more on demand resources are not marked as un-purgeable independent of the running status of the respective application, determining that the one or more conditions are satisfied.
6. The method of
7. The method of
8. The method of
9. The method of
the usage pattern of the respective application indicates a plurality of time periods during which the respective application is likely to be used, and a respective time period between the plurality of time periods during which the respective application is not likely to be used,
wherein determining that the one or more conditions are satisfied with respect to the respective application includes determining that a current time has reached an end of a first time period of the plurality of time periods, the method further comprising:
after removing the first one or more on demand resources from the storage device, determining that the current time has reached a beginning of a second time period, after the respective time period, of the plurality of time periods; and
in response to determining that the current time has reached the beginning of the second time period, re-adding the first one or more on demand resources to the storage device.
10. The method of
adding, to the storage device, one or more on demand resources for the respective application for resuming the current progression of the user in the respective application.
11. The method of
12. The method of
after removing the first one or more on demand resources from the storage device, detecting that a second user is logged into the electronic device; and
in response to detecting that the second user is logged into the electronic device:
removing, from the storage device, third one or more on demand resources of the plurality of on demand resources associated with the respective application.
13. The method of
14. The method of
in response to detecting that the second user is logged into the electronic device:
maintaining, on the storage device, third one or more on demand resources of the plurality of on demand resources associated with the respective application.
15. The method of
16. The method of
in response to detecting that the second user is logged into the electronic device:
adding, to the storage device, fourth one or more on demand resources of the plurality of on demand resources associated with the respective application.
17. The method of
20. The method of
21. The method of
22. The method of
in accordance with a determination that a progression of running the respective application has reached a predetermined point, determining that the one or more conditions are satisfied; and
in accordance with a determination that the progression of running the respective application has not reached the predetermined point, determining that the one or more conditions are not satisfied; and the method further comprises:
in accordance with a determination that the one or more conditions are not satisfied, the removing and the maintaining are not performed.
23. The electronic device of
24. The electronic device of
wherein the respective application is installed on a plurality of electronic devices, including the electronic device, and a current progression of a user in the respective application on a second electronic device of the plurality of electronic devices is a first progression, the instructions further for:
adding, to the storage device, one or more on demand resources for the respective application for resuming the current progression of the user in the respective application.
25. The electronic device of
26. The electronic device of
27. The electronic device of
after removing the first one or more on demand resources from the storage device, detecting that a second user is logged into the electronic device; and
in response to detecting that the second user is logged into the electronic device:
removing, from the storage device, third one or more on demand resources of the plurality of on demand resources associated with the respective application.
28. The non-transitory computer-readable storage medium of
29. The non-transitory computer-readable storage medium of
wherein the respective application is installed on a plurality of electronic devices, including the electronic device, and a current progression of a user in the respective application on a second electronic device of the plurality of electronic devices is a first progression, the instructions further for:
adding, to the storage device, one or more on demand resources for the respective application for resuming the current progression of the user in the respective application.
30. The non-transitory computer-readable storage medium of
31. The non-transitory computer-readable storage medium of
32. The non-transitory computer-readable storage medium of
after removing the first one or more on demand resources from the storage device, detecting that a second user is logged into the electronic device; and
in response to detecting that the second user is logged into the electronic device:
removing, from the storage device, third one or more on demand resources of the plurality of on demand resources associated with the respective application.
|
|||||||||||||||||||||||||||||
This Application is a divisional of U.S. patent application Ser. No. 14/861,405, filed Sep. 22, 2015 and published on Dec. 8, 2016 as U.S. Publication No. 2016/0357544, which claims the benefit of U.S. Provisional Application No. 62/171,894 filed on Jun. 5, 2015, the entire disclosures of which are herein incorporated by reference in their entirety for all purposes.
This disclosure relates generally to systems and methods of building software applications, and more particularly, to building, deploying, running, and updating a software application with on demand resources that can be decoupled from the main application and other resources of the application so that these on demand resources can be requested and purged dynamically on an as-needed basis without disrupting the operation of the application.
Computing devices, especially small mobile devices, can have a limited amount of resources such as disk space for storing applications and data. Every time an application is installed on a computing device, it reduces the storage space available for other uses. Conventionally, each application is packed in a single app bundle that can be downloaded and installed on a client device. The single app bundle can include most, if not all, of its code and data, even though not all of them are needed at a given time when the application is in use. Some of the code and data may never get utilized, but nevertheless can occupy on-device storage space for as long as the application lives on the client device. This can be an inefficient use of the valuable storage space on the client device and limit the number of applications that can be installed on the device. Given that the applications, even those designed to run on mobile devices, can be of significant sizes, it is desirable to design and construct applications so as to minimize the waste of disk space when the applications are installed on the device without negatively affecting their usability.
One aspect of the disclosure is generally directed to systems and methods of building and deploying a software application that enables various application resources (i.e., on demand resources) associated with the application to be packaged separately, which in turn allows them to be installed and uninstalled from a client device individually without disrupting the use of the application and on an as-needed basis. The installing and uninstalling process can occur in the background and be transparent to the user. This allows applications, especially those with relatively large amounts of content, to reside and operate on a client device without consuming a significant amount of storage space. In turn, this can provide flexibility to the device so that it can better accommodate other applications and data. As such, this can provide a significant advantage over conventional applications that typically require a full download and installation of all of their files, which have to be kept on the client device regardless of whether they are actually needed.
In comparison, the applications built with on demand resources may only require a fraction of the storage space on the device to operate without sacrificing any user experience pertaining to the application. The on demand resources not initially installed can be requested at a later time, preferably before they are needed by the application. Similarly, some of these on demand resources that have been installed on the device can be removed when no longer needed and/or when there is a shortage of disk space. Essentially, various application resources associated with an application can be rotated on and off the device, based on the application's needs, so as to achieve optimal utilization of the finite amount of disk space of the device.
Another aspect of the disclosure generally relates to automatically requesting and/or removing on demand resources based on a need (or expected need) of the application/client device. For an application built with on demand resources, it can be critical to be able to anticipate when a particular on demand resource will likely be needed. This allows it to be fetched before getting called upon by the application, thus eliminating the need to make the user wait until the resources are downloaded. It can also prevent potential runtime errors from occurring. It can be equally critical to know which on demand resources can be purged when storage space becomes tight. In this aspect, some embodiments disclose methods of predetermining or dynamically determining criteria for requesting on demand resources. Other embodiments disclose methods of identifying and/or prioritizing the on demand resources already on the device for removal when requested.
Yet another aspect of the disclosure generally relates to an application program interface (API) and other software development tools that are designed to build applications with on demand resources and facilitate operation of these applications on a client device.
In the following description of example embodiments, reference is made to the accompanying drawings in which it is shown by way of illustration specific embodiments that can be practiced. It is to be understood that other embodiments can be used and structural changes can be made without departing from the scope of the various embodiments.
As used herein, the terms “device” and “client device” can be used interchangeably to refer to any electronic devices capable of running one or more software applications. Such devices can include, but are not limited to, personal computers (PCs), Macs, desktop and laptop PCs, tablet PCs, smartphones and other types of cellular phones, wearable devices, set top boxes, smart TVs, digital media players, and in-car entertainment systems. As used herein, the terms “storage space,” “disk space” and “storage medium” can be used interchangeably to refer to any type of storage on a client device. The storage space can be either internal (e.g., memory, hard drive, flash drive, and cache storage) or external (e.g., cloud storage). The term “software application,” “application,” and “app” can be used interchangeably to refer to any computer program that can be installed and executed on a device.
The term “application resource” (or “resource”) can refer to any data (or content) associated with an application. In one embodiment, application resources can exclude the software code (or programs) for running the application. The software code or programs can include, for example, executable files, functions, and libraries. Examples of application resources can include, but not limited to, image, text, audio, and video files (i.e., any file not software code). In another embodiment, application resources can also include at least some of the software code for running the application. The term “asset pack” can refer to a collection of one or more application resources that share at least one common trait. The term “app start bundle” can refer to a bundle of code and optionally a number of application resources required for starting the application for the first time on a client device. The code and resources in the app start bundle are needed to perform the most basic functions of the application such as launching the application and displaying the default screen of the application.
The term “on demand resource” can refer to one or more application resources that can be dynamically requested and purged without disrupting the running of the application. These on demand resources can include resources that are not included in the app start bundle (e.g., resources in asset packs that can be downloaded by request of the app when the app is running). Additionally or alternatively, they can include resources that are part of the app start bundle but can be purged when no longer needed. Additionally or alternatively, they can include resources in asset packs that are selected to be installed after the initial app and on demand resource (ODR) installation, yet still before the app is launched. The on demand resources can include data and/or code. The on demand resources can be grouped into one or more asset packs when the application is compiled but stored separately from the app start bundle and thus may not be a part of the initial download to the client device when the application is first requested. Instead, the asset packs with the on demand resources can be requested individually after the installation of the application on an as-needed basis. Once installed, they can be integrated into the application and perform their intended functions. When they are no longer needed by the application and/or there is a shortage of space on the client device, the on demand resources can be purged from the device individually in a predetermined order (e.g., an order based on heuristics used to determine what is least likely to be needed) without disrupting the running of the application. In some implementations, particular on demand resources are purged and other on demand resources are not purged.
The terms “server” or “remote server” can be used interchangeably to generally refer to one or more computers from which applications including their app start bundles, asset packs, and/or other resources can be obtained. The server can be connected to one or more client devices via any type of known network.
One aspect of the disclosure is generally directed to systems and methods of building and deploying a software application that enables various application resources (i.e., on demand resources) associated with the application to be packaged separately, which in turn allows them to be installed and uninstalled from a client device individually without disrupting the use of the application. The installing and uninstalling process can occur in the background and be transparent to the user. This allows applications, especially those with relatively large amounts of content, to reside and operate on a client device without consuming a significant amount of storage space. In turn, this can provide flexibility to the device so that it can better accommodate other applications and data. As such, this can provide a significant advantage over conventional applications that typically require a full download and installation of all of their files, which have to be kept on the client device regardless of whether they are actually needed.
In comparison, the applications built with on demand resources may only require a fraction of the storage space on the device to operate without sacrificing any user experience pertaining to the application. The on demand resources not initially installed can be requested at a later time, preferably before they are needed by the application. Similarly, some of these on demand resources that have been installed on the device can be removed when no longer needed and/or when there is a shortage of disk space. Essentially, various application resources associated with an application can be rotated on and off the device, based on the application's needs, so as to achieve optimal utilization of the finite amount of disk space of the device. Also because not the entire application needs to be downloaded before it can be used, the time between starting downloading the application and being able to launch the application can be dramatically shortened.
Another aspect of the disclosure generally relates to automatically requesting and/or removing on demand resources based on a need (or expected need) of the application/client device. For an application built with on demand resources, it can be critical to be able to anticipate when a particular on demand resource will likely be needed. This allows it to be fetched before getting called upon by the application, thus eliminating the need to make the user wait until the resources are downloaded. It can also prevent potential runtime errors from occurring. It can be equally critical to know which on demand resources can be purged when storage space becomes tight. In this aspect, some embodiments disclose methods of predetermining or dynamically determining criteria for requesting on demand resources. Other embodiments disclose methods of identifying and/or prioritizing the on demand resources already on the device for removal when requested.
Yet another aspect of the disclosure generally relates to an application program interface (API) and other software development tools that are designed to build applications with on demand resources and facilitate operation of these applications on a client device.
The following paragraphs discuss various embodiments of building and deploying software applications with on demand resources. Instead of including all resources (e.g., data, content, and/or code) associated with an application in a single application bundle, an exemplary application in one embodiment can be built with its application resources grouped into multiple asset packs, all of which can be a part of the application at compile time, but made available for download on their own, separate from the rest of the application.
As defined above, application resources can include any data (also referred to as content) and/or code associated with an application. In one embodiment, each data (or content) file can correspond to one application resource. In another embodiment, multiple files such as files in the same directory can constitute one application resource. Some of the application resources can be characterized as on demand resources, which are only needed at certain stage during the operation of the application. The on demand resources are typically not required to launch the application. The application resources can usually be associated with one particular application, but they can be shared by multiple applications.
As an example, application 100 of
After the application resources (or files) are tagged, the ones sharing a common tag (or tags) can be placed into an asset pack. For example, as illustrated in
In addition, there can also be a base resources pack 130 that includes the application resources 132, 134, 136 required to perform basic functions in the game every time the game is launched. For example, the base resources pack 130 can include, for example, the opening scene of the game, various menus and option settings of the game, at least one avatar that can be selected and controlled by the user, and any other resources that are utilized throughout the game regardless of the user's progress in the game. That is, these resources 132, 134, 136 are not specific to any of the levels in the game. In addition, the game can also include files 142, 144, 146 that are software code (e.g., executables) for launching the game and performing various operations in the game. These files can be included in the app start bundle (and excluded from the asset packs). In other embodiments, application resources sharing multiple tags can similarly form an asset pack in a way similar to resources sharing only one tag.
Although the asset packs in
Once the asset packs are built, the application resources in the asset packs can be in a format that can be accessed by the application when called upon. As illustrated in
Referring again to
The Asset Pack Manifest can indicate an address on the network from where each requested asset pack can be downloaded. In one embodiment, the addresses in the Asset Pack Manifest can include a list of uniform resource locators (URLs) that specify the location of the asset packs. In other embodiments, the locations specified in the Asset Pack Manifest can include, for example, IP addresses, server addresses, domain names, directory names, etc. Essentially, the Asset Pack Manifest can serve as the glue between the application and its asset packs. Additionally, the Asset Pack Manifest can also include metadata specifying various properties associated with each asset pack. For example, the metadata can include the size of the asset pack and the preferred order in which they are to be fetched by the application. Additionally or alternatively, the metadata can indicate the conditions to be satisfied before downloading certain asset packs (e.g., the download order of the asset packs as level 1 first, followed by level 2, and then level 3). As discussed in detail below, the Asset Pack Manifest can also include content hashes that can be used to verify the version of the asset pack and determine whether a new version needs to be downloaded. In one embodiment, the Asset Pack Manifest is not included in the initial download of the application and has to be requested separately and refreshed regularly to ensure that the application is entitled to get the asset packs it is requesting and also that the correct asset packs are released to the application. Requiring the Asset Pack Manifest to be downloaded separately from the app start bundle is preferred when the application is hosted at an app store. In another embodiment, while no Asset Pack Manifest is included in the application, a URL to the Asset Pack Manifest can be inserted into an installer manifest as a part of the app start bundle. This URL can support the initial installation of the application along with the prefetched on demand resources. This embodiment can be preferred when the Asset Pack Manifest is hosted on a continuous integration server or an internal enterprise server. In another embodiment, the Asset Pack Manifest can be embedded in the ODR application and downloaded to the client device. The Asset Pack Manifest can also be embedded in the application when a random web server hosts the asset packs. In yet another embodiment, a template of the Asset Pack Manifest rather than a complete Asset Pack Manifest with URLs can be embedded in the application. This arrangement can be preferred if the actual URLs (or other types of addresses of the on demand resources) are not yet finalized when the application is first downloaded. The template can be updated at a later time when the URLs are finalized.
Although
After the asset packs, the On Demand Resources List, and the Asset Pack Manifest are created, they can be placed in an archive on a server along with the rest of the application (e.g., the app start bundle), and the application can be made available in for download (step 205).
In one embodiment, when the application and the associated asset packs arrive from the server, they can be individually signed with a code signature. If the code signature of one asset pack does not match with the signature of the rest of the application, it can be determined that the asset pack has been tampered with and a replacement is required. Additionally or alternatively, if the application is being offered in an app store, the asset packs and the rest of the application can be signed with an app store signature, which can indicate that the application is offered by the app store rather than by, for example, the developer directly.
As mentioned above, a conventional application is typically downloaded in a single bundle including most if not all of its application resources (e.g., code and data). The single app bundle can be unpacked to install the application on the client device. The installation process typically involves copying the application resources from the app bundle onto the storage space of the client device. After a successful installation, the application can be launched to perform its designed functions. Normally, not all application resources are utilized at all times when the application is running. Nevertheless, they would occupy a portion of the storage space on the client device as long as the application is not deleted from the device. Large applications can take up a significant portion of the storage space on the client device, especially devices with a limited amount of space. When a conventional application is uninstalled to free up disk space, the entire application has to be purged.
In contrast, in the embodiments of the present disclosure, the application resources can be grouped into a number of asset packs as discussed above. One or more of the asset packs can be included in an app start bundle. When a client device requests the application for the first time, the app start bundle is sent to the client device while other asset packs including on demand resources can remain on the server. Preferably, the app start bundle includes only the software code and application resources that are required to run the application initially. For example, referring back to
After the game 100 is installed and as the user progresses through level 1 of the game, the asset packs required to run the subsequent level(s) can be requested and installed on the client device. Various conditions for requesting and installing asset packs can be set, based, for example, on how and/or when the asset packs are utilized. In addition, the level 1 asset pack may no longer be needed after the user completes level 1 in the game and can thus be removed from the client device if necessary. An exemplary method of dynamically updating asset packs (i.e., on demand resources) on the client device is described in the following paragraphs with reference to
As illustrated in
An area in storage medium 308 of the client device 300 can be designated as the storage area for application resources of the various applications 304 on the device 300. This designated storage area 308 can be accessible to ODR 302 to update the collection of application resources therein. Optionally, the client device 300 can also include a storage space monitoring module (or Cache Delete module) 310 that can be configured to monitor the available storage space (including the designated storage area 308 for the application resources) on the client device 300 and communicate with ODR 302 when a shortage of storage space is detected.
It should be understood that the client device 300 can include other hardware and software modules not shown in
When ODR 302 receives the request from application 304, it can first determine if an Asset Pack Manifest of the application is available (step 405). The Asset Pack Manifest can contain information regarding the order in which asset packs can be requested and the location of the asset pack on the network. If the Asset Pack Manifest is not available, ODR 302 can request it from the server (step 406). Some applications (e.g., a paid app) can require that the server verify that the entity (e.g., user or client device) requesting the Asset Pack Manifest is an authorized owner of the application and is thus entitled to receive the Asset Pack Manifest for the application (step 407). This verification can be performed using any suitable methods such as looking up the application in the user's purchase history. This verification step may either be skipped or always produce an affirmative response for some applications (e.g., a free application).
The server can then send the Asset Pack Manifest to ODR 302 on the client device 300 (step 408). ODR can use the Asset Pack Manifest to identify which asset pack(s) to download next and its address (e.g., URL) on the network (step 409). A request for the asset pack(s) can then be formulated and sent to that address (step 410). In one embodiment, the request can include one or more tags (e.g., Level 2) that identify the on demand resources (and their corresponding asset packs) being requested.
There are additional security measures that can be incorporated in the Asset Pack Manifest to ensure that the asset packs are being requested by an authorized entity (e.g., a user who has purchased the application). In some embodiments, each URL in the Asset Pack Manifest can have an expiration time (e.g., twelve hours). So even if the Asset Pack Manifest is shared with an unauthorized entity, the URLs will only be valid for a limited period of time. To that end, even an authorized entity can be required to refresh the Asset Pack Manifest before requesting new asset packs from the server, if the local copy of the Asset Pack Manifest has expired.
Additionally or alternatively, the Asset Pack Manifest can include at least one “time bomb” URL for authenticate an asset pack request from ODR 302. This “time bomb” can be a security key created by hashing parts of a URL with a timestamp and a secret key that is only known to the server. When a request for an asset pack is sent to the server, the request can include the URL incorporated with the timestamp. When the server receives the request, it can determine whether the URL and the timestamp in the request can hash with the server's secret key to produce the correct security key. If the correct security key is produced, the server can release the requested asset pack(s). Otherwise, the request can be rejected.
Referring back to
Steps 403-414 can be repeated as long as the application is running and new asset packs are needed based on the status (e.g., user progress) of the application. Some of these steps (e.g., steps 406-408) may be skipped if the Asset Pack Manifest on the client device has not expired. In the preferred embodiment, ODR 302 can anticipate the demand for the on demand resources based, for example, on the running status of the application, usage pattern data, and/or network strength, and automatically pre-fetch asset packs containing these resources before they are actually needed by the application 304. Depending on the platform of the client device (e.g., the type of device), ODR 302 can be programmed to be more or less aggressive in pre-fetching asset packs. If the device is one with relatively large storage space and/or inferior access to the network, ODR can be more aggressive in loading up asset packs so that the applications won't fail when the device loses its connection to the network and could not download additional resources. In contrast, the ODR of a device with a relatively small storage area but a fast and stable network connection can be less aggressive in pre-fetching on demand resources. Instead, the ODR of such as device would make more frequent requests as the resources become in demand.
This whole process of downloading on demand resources can be performed in the background without requiring any user input. The on demand resources can be made available transparently to the application as if they had already been part of the application from the initial installation. Indeed, the user would be unaware that parts of the application are being downloaded dynamically from the server at runtime.
As described above, by grouping the application resources associated with an application into asset packs, not all application resources have to reside on the client device at all times for the application to run normally. As a result, even the relatively large application can be installed on the client device without taking a lot of storage space. This in turn can free up storage space for other applications and data.
Not only can on demand resources associated with an application be obtained individually from the server when the application requests for them, the same on demand resources can be purged without affecting the rest of the application when they are no longer needed by the application for the near or long-term future. In some embodiments, on demand resources can be purged as soon as they are no longer in demand by the application. In other embodiments, on demand resources can be preserved on the device even when the application is no longer utilizing them. They can only be purged in response to a shortage of storage space on the device. In yet some other embodiments, on demand resources may be purged even if they may still be useful to the application. The criteria and priorities for purging resources can also be set by the developer when building the application.
In various embodiments, ODR 302 can be programmed to select on demand resources for purging based on one or more different criteria. In one embodiment, ODR 302 can simply purge any or all on demand resources that are no longer in demand (e.g., not requested by any applications). When an asset pack and its application resources are no longer being requested by the application and are unlikely to be needed again in the near future, the asset pack/resources can be marked as purgeable and/or placed towards the top of a list of candidates for purging. If an asset pack is still being called upon by the application and/or is expected to continue to be utilized to at least some extent, the asset pack can be marked as preserved and/or ranked lower on the purging list. For example, if the user has completed level 1 in the game, but is still working through level 2, the asset pack, “Level 2,” can be marked “preserved” and/or ranked lower than the asset pack, “Level 1,” on the purging list. The purging list can include asset packs/resources associated with one or more applications that are installed on the client device. The rankings of the asset packs/resources can change dynamically based, at least partially, on the running status of the applications.
Additionally or alternatively, ODR 302 can make the selection based on the preferences set by the application developer. These preferences can be stored as part of the metadata associated with each asset pack in the Asset Pack Manifest. For example, the developer can set a “Never Delete” flag associated with one asset pack to 1 to indicate that this particular asset pack should always remain on the client device as long as the application is not deleted from the device. If the same flag for another asset pack is set to 0, that asset pack can then be a candidate for purging. As another example, the developer can set a priority number for each asset pack (or on demand resource) in the application. The priority number can indicate a preferred purging order among the various asset packs (or resources) of the application. When ODR 302 looks to free space on the device, it can search for asset packs with, for example, the lowest priority number.
Additionally or alternatively, heuristics can be built into purging (and/or download) orders. In particular, different usage patterns of an application can be collected across a number of client devices. Based on these usage patterns, predictions can be made regarding the order in which the asset packs are likely utilized at different stages during the running of the application. The usage patterns may also reveal, for example, an overall utilization rate of each of the asset packs. It may also reveal how often and/or when an application is likely to be used by a particular user. For example, if an application is typically only being used during the weekends, it can be a likely candidate for purging after each weekend if storage space becomes tight. It can be reinstalled before the weekends by removing other applications/resources that are less likely to be used over the weekends.
As another example, if a user has downloaded the same application onto multiple client devices, his progress in the application on the first device can be tracked and saved on a remote server so that when he moves on to a second device, the application resources needed to resume his session can be pre-fetched onto the second device before he starts using the application on the second device.
As yet another example, if an application on the client device is shared by multiple users, each user's usage of the application can be tracked separately on the client side based, for example, on their device/application logins. When a first user is logged onto the client device/application, ODR 302 can determine, based on the user's prior app usage pattern, whether the applications/asset packs that he will likely use are available on the device. If not, ODR can request these applications/asset packs from the server as soon as the user logs onto the device. In some embodiments, if not enough storage space is available on the device, ODR may purge other applications/asset packs that were downloaded by other users. When a second user logs onto the device, his applications/asset packs may be automatically loaded onto the device and the applications/asset packs associated with the first user can be removed to free up storage space, if necessary. If multiple users share the same application or asset pack(s) of an application, the application or asset pack(s) can remain on the device regardless of which user is logged on to the device.
Depending on the platform of the client device (e.g., the type of device), ODR 302 can also be programmed to be more or less aggressive in purging asset packs. If the device is one with relatively large storage space and/or inferior access to the network, ODR can be less aggressive in purging asset packs. In contrast, the ODR of a device with a relatively small storage area but a fast and stable network connection can be more aggressive in purging on demand resources.
In one embodiment, the asset packs can be associated with not only an application, but also a particular version of the application. Typically, a new version of the application can be rolled out when changes have been made to the application. Because the various resources of applications disclosed in the embodiments of the present disclosure can be grouped into multiple asset packs, there may not be any changes to at least some of the asset packs when a new version of the application rolls out. If the changes in the new version are relatively minor, most of the asset packs may not need to be refreshed. Only those asset packs that have been updated need to be downloaded again to replace the previous version. In one embodiment, the content of each asset pack can be hashed to create a content hash, which can be used to determine if any of the content has changed when a new version of the asset pack is released. If the content hash for the new version remains the same as that of the current version, there is no need to download the particular asset pack again. If the content hash for the new version does not match with that of the current version, the new version of the asset pack can be downloaded to replace the current version. Preferably, the content hash can remain the same even if some of the not so relevant information (e.g., timestamp, code signatures, and other metadata) associated with the asset pack changes. The content hash should only change if the actual content (i.e., resources) in the asset pack changes.
In another aspect of the disclosure, an application program interface (API) (or a set of APIs) can be provided to the developers of the applications to build applications with on demand resources.
An API is an interface implemented by a program code component or hardware component (hereinafter “API-implementing component”) that allows a different program code component or hardware component (hereinafter “API-calling component”) to access and use one or more functions, methods, procedures, data structures, classes, and/or other services provided by the API-implementing component. An API can define one or more parameters that are passed between the API-calling component and the API-implementing component.
An API allows a developer of an API-calling component (which may be a third party developer) to leverage specified features provided by an API-implementing component. There may be one API-calling component or there may be more than one such component. An API can be a source code interface that a computer system or program library provides in order to support requests for services from an application. An operating system (OS) can have multiple APIs to allow applications running on the OS to call one or more of those APIs, and a service (such as a program library) can have multiple APIs to allow an application that uses the service to call one or more of those APIs. An API can be specified in terms of a programming language that can be interpreted or compiled when an application is built.
In some embodiments the API-implementing component may provide more than one API, each providing a different view of or with different aspects that access different aspects of the functionality implemented by the API-implementing component. For example, one API of an API-implementing component can provide a first set of functions and can be exposed to third party developers, and another API of the API-implementing component can be hidden (not exposed) and provide a subset of the first set of functions and also provide another set of functions, such as testing or debugging functions which are not in the first set of functions. In other embodiments the API-implementing component may itself call one or more other components via an underlying API and thus be both an API-calling component and an API-implementing component.
An API defines the language and parameters that API-calling components use when accessing and using specified features of the API-implementing component. For example, an API-calling component accesses the specified features of the API-implementing component through one or more API calls or invocations (embodied for example by function or method calls) exposed by the API and passes data and control information using parameters via the API calls or invocations. The API-implementing component may return a value through the API in response to an API call from an API-calling component. While the API defines the syntax and result of an API call (e.g., how to invoke the API call and what the API call does), the API may not reveal how the API call accomplishes the function specified by the API call. Various API calls are transferred via the one or more application programming interfaces between the calling (API-calling component) and an API-implementing component. Transferring the API calls may include issuing, initiating, invoking, calling, receiving, returning, or responding to the function calls or messages; in other words, transferring can describe actions by either of the API-calling component or the API-implementing component. The function calls or other invocations of the API may send or receive one or more parameters through a parameter list or other structure. A parameter can be a constant, key, data structure, object, object class, variable, data type, pointer, array, list or a pointer to a function or method or another way to reference a data or other item to be passed via the API.
Furthermore, data types or classes may be provided by the API and implemented by the API-implementing component. Thus, the API-calling component may declare variables, use pointers to, use or instantiate constant values of such types or classes by using definitions provided in the API.
Generally, an API can be used to access a service or data provided by the API-implementing component or to initiate performance of an operation or computation provided by the API-implementing component. By way of example, the API-implementing component and the API-calling component may each be any one of an operating system, a library, a device driver, an API, an application program, or other module (it should be understood that the API-implementing component and the API-calling component may be the same or different type of module from each other). API-implementing components may in some cases be embodied at least in part in firmware, microcode, or other hardware logic. In some embodiments, an API may allow a client program to use the services provided by a Software Development Kit (SDK) library. In other embodiments an application or other client program may use an API provided by an Application Framework. In these embodiments the application or client program may incorporate calls to functions or methods provided by the SDK and provided by the API or use data types or objects defined in the SDK and provided by the API. An Application Framework may in these embodiments provide a main event loop for a program that responds to various events defined by the Framework. The API allows the application to specify the events and the responses to the events using the Application Framework. In some implementations, an API call can report to an application the capabilities or state of a hardware device, including those related to aspects such as input capabilities and state, output capabilities and state, processing capability, power state, storage capacity and state, communications capability, etc., and the API may be implemented in part by firmware, microcode, or other low level logic that executes in part on the hardware component.
The API-calling component may be a local component (i.e., on the same data processing system as the API-implementing component) or a remote component (i.e., on a different data processing system from the API-implementing component) that communicates with the API-implementing component through the API over a network. It should be understood that an API-implementing component may also act as an API-calling component (i.e., it may make API calls to an API exposed by a different API-implementing component) and an API-calling component may also act as an API-implementing component by implementing an API that is exposed to a different API-calling component.
The API may allow multiple API-calling components written in different programming languages to communicate with the API-implementing component (thus the API may include features for translating calls and returns between the API-implementing component and the API-calling component); however the API may be implemented in terms of a specific programming language. An API-calling component can, in one embedment, call APIs from different providers such as a set of APIs from an OS provider and another set of APIs from a plug-in provider and another set of APIs from another provider (e.g. the provider of a software library) or creator of the another set of APIs.
It will be appreciated that the API-implementing component 710 may include additional functions, methods, classes, data structures, and/or other features that are not specified through the API 720 and are not available to the API-calling component 730. It should be understood that the API-calling component 730 may be on the same system as the API-implementing component 710 or may be located remotely and accesses the API-implementing component 710 using the API 720 over a network. While
The API-implementing component 710, the API 720, and the API-calling component 730 may be stored in a machine-readable medium, which includes any mechanism for storing information in a form readable by a machine (e.g., a computer or other data processing system). For example, a machine-readable medium includes magnetic disks, optical disks, random access memory; read only memory, flash memory devices, etc.
In
Note that the Service 2 has two APIs, one of which (Service 2 API 1) receives calls from and returns values to Application 1 and the other (Service 2 API 2) receives calls from and returns values to Application 2. Service 1 (which can be, for example, a software library) makes calls to and receives returned values from OS API 1, and Service 2 (which can be, for example, a software library) makes calls to and receives returned values from both OS API 1 and OS API 2. Application 2 makes calls to and receives returned values from OS API 2.
An embodiment of the API disclosed herein can include the following exemplary data structures (e.g., object classes), parameters, and routines. It should be understood that these examples can be implemented in any suitable programming languages such as Objective C.
In this exemplary implementation, a resource request object can manage the availability of on demand resources that are virtually part of the application but are stored remotely. The application can use the request to inform the system when the associated resources are needed and when it has finished using them. The resource request can then download any resources not already cached on the device and inform the application when the resources are ready for use.
Optional settings can provide hints on the relative priority of the downloading and purging groups of resources. Groups can be marked as required for the application. Depending on the platform, the system can be prevented from deleting these resources from storage, or they are downloaded when the application is launched. Each resource request can be used only once for accessing resources.
Each resource request object can manage a group of related on demand resources. Tags can be created for each set of related resources and assigned to the on demand resources being before the application is built. A resource request can include the set of tags for the resources it manages. The resource request can only download resources not already on the device. Downloaded resources can be accessed the same way as those in the app start bundle. Accessing a resource that has not been downloaded can behave the same way as accessing a resource that does not exist in the app.
The system may not attempt to purge a resource from on-device storage as long as one resource request object can access it. Access can end in response to a call to end access or when the resource request object is deallocated.
On demand resources can be persevered after no resource requests objects are accessing them. As the system requires more storage space, the resources can be purged. A tagged group of resources can have a relative preservation priority. The system can attempt to purge lower priority resources first.
Tagged resources can be set as required for the application. For some platforms this can prevent the resource being deleted from storage when they are no longer being accessed, including preserving them across application launches. On other platforms, the system can download the resources before launching the application. Resources that are marked as permanently preserved can count towards the total storage used by the application.
The APIs can provide the following exemplary functions. For example, an initialized resource request for managing remote resources tagged with a specified identifier can be created based on a call using the name of the tag (or tags) specifying one or more resources stored in the main bundle as input. The value of each tag can correspond to the identifier assigned to a logical grouping of resources. The bundle used to store the loaded resources can be specified by including an optional “bundle” parameter in the call. The configuration of a resource request can be accessed by using a reference to the bundle used for storing the downloaded resources. The bundle can be the main bundle or the one specified in the API call.
The APIs can also provide a way to configure the priority of each resource request. The system can then attempt to give priority to resource requests with higher values. The priority of a resource request can be changed at any time, even after the resource request has started.
The APIs can also provide a way to request access to the resources managed by a resource request object. The access to resources can be conditioned on whether the resources managed by the resource request object are already on the device. If they are, the system can begin accessing the resources. If the resources are not on the device, they can be requested from the server. The system can be prevented from purging resources while they can still be accessed.
The APIs can additionally provide a way to inform the system that the resources associated with a resource request object are no longer being accessed. This method can be called when the resource request object is deallocated. The APIs can also provide a way to track the progress of a resource request.
In addition, the APIs can also provide a way for configuring caching priority (e.g., the relative order for purging resources). This call can require a priority parameter that can be a number specifying the relative priority of preserving the resources in the group specified by the corresponding tag(s). The system can attempt to purge cached resources with lower priorities first. In addition, a Boolean value can be used for specifying whether the system can purge the resources associated with the specified tag(s). Resources marked for preserving can be made available across application launches. Depending on the platform, this may be done by preventing the system from purging them or by downloading them when the application is launched. One of the common reasons for preserving resources can be offline use.
In addition, the APIs can provide a way to post notifications after the resources request system detects the amount of available disk space for downloaded resources is getting low. After receiving the notification, the application can try to free up disk space by, for example, releasing any on demand resources that are no longer required. If the application is in the background and the application does not free up enough space, it can be terminated.
The above-described systems and methods of building, deploying, running, and updating applications with on demand resources can be implemented in software, firmware, hardware, and/or any combination of the three. In the embodiments where the one or more of the modules are implemented in software, they can be stored and/or transported within any non-transitory computer-readable storage medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a “non-transitory computer-readable storage medium” can be any medium that can contain or store the program for use by or in connection with the instruction execution system, apparatus, or device. The non-transitory computer readable storage medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, a portable computer diskette (magnetic), a random access memory (RAM) (magnetic), a read-only memory (ROM) (magnetic), an erasable programmable read-only memory (EPROM) (magnetic), a portable optical disc such a CD, CD-R, CD-RW, DVD, DVD-R, or DVD-RW, or flash memory such as compact flash cards, secured digital cards, USB memory devices, memory sticks, and the like. The non-transitory computer readable storage medium can be part of the storage medium of a computing device.
It should be understood that although the above embodiments are described with reference to a video game, any type of software application can be implemented using the disclosed systems and methods.
Although embodiments have been fully described with reference to the accompanying drawings, it is to be noted that various changes and modifications will become apparent to those skilled in the art. Such changes and modifications are to be understood as being included within the scope of the various embodiments as defined by the appended claims.
Makower, David, Heynen, Patrick, Bumgarner, William M., Oklota, Christopher L., Lewallen, Stephen Richard, Hess, Jonathan Joseph, Santamaria, Terry J., Pickford, David, Parker, Anthony S.
| Patent | Priority | Assignee | Title |
| Patent | Priority | Assignee | Title |
| 10152211, | Nov 11 2014 | Amazon Technologies, Inc | Application delivery agents on virtual desktop instances |
| 5483261, | Feb 14 1992 | ORGPRO NEXUS INC | Graphical input controller and method with rear screen image detection |
| 5488204, | Jun 08 1992 | Synaptics Incorporated; Synaptics, Incorporated | Paintbrush stylus for capacitive touch sensor pad |
| 5825352, | Jan 04 1996 | ELAN MICROELECTRONICS CORP | Multiple fingers contact sensing method for emulating mouse buttons and mouse operations on a touch sensor pad |
| 5835079, | Jun 13 1996 | International Business Machines Corporation | Virtual pointing device for touchscreens |
| 5880411, | Jun 08 1992 | Synaptics Incorporated | Object position detector with edge motion feature and gesture recognition |
| 5944821, | Jul 11 1996 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Secure software registration and integrity assessment in a computer system |
| 6188391, | Jul 09 1998 | Synaptics, Incorporated | Two-layer capacitive touchpad and method of making same |
| 6195678, | Sep 03 1996 | Fujitsu Limited | Remote resource management system for automatically downloading required files from application server depending on contents of selected files on requesting computer |
| 6310610, | Dec 04 1997 | Microsoft Technology Licensing, LLC | Intelligent touch display |
| 6323846, | Jan 26 1998 | Apple Inc | Method and apparatus for integrating manual input |
| 6690387, | Dec 28 2001 | KONINKLIJKE PHILIPS N V | Touch-screen image scrolling system and method |
| 7015894, | Sep 28 2001 | Ricoh Company, Ltd. | Information input and output system, method, storage medium, and carrier wave |
| 7069293, | Dec 14 1998 | UNILOC 2017 LLC | Methods, systems and computer program products for distribution of application programs to a target station on a network |
| 7184064, | Dec 16 2003 | Koninklijke Philips Electronics N.V. | Touch-screen image scrolling system and method |
| 7222341, | Jun 19 1998 | Microsoft Technology Licensing, LLC | Method and system for processing software dependencies in management of software packages |
| 7663607, | May 06 2004 | Apple Inc | Multipoint touchscreen |
| 7711775, | Oct 24 2001 | Microsoft Technology Licensing, LLC | Method and apparatus for managing software component downloads and updates |
| 7730164, | Nov 23 2005 | Adobe Inc | Bootstrap approaches to downloading data in response to a download indication |
| 8029365, | Mar 24 2005 | LNW GAMING, INC | Hierarchical multi-tiered system for gaming related communications |
| 8074217, | Jun 21 2000 | Microsoft Technology Licensing, LLC | Methods and systems for delivering software |
| 8356099, | Dec 17 2009 | International Business Machines Corporation | Server resource allocation |
| 8479122, | Jul 30 2004 | Apple Inc | Gestures for touch sensitive input devices |
| 8635360, | Oct 19 2007 | GOOGLE LLC | Media playback point seeking using data range requests |
| 8776254, | Jan 23 2013 | OWL Cyber Defense Solutions, LLC | System and method for the secure unidirectional transfer of software and software updates |
| 8789040, | Jul 16 2013 | Appenity LLC | Converting non-natively executable programs to downloadable executable programs |
| 9092286, | Dec 20 2002 | Qualcomm Incorporated | System to automatically process components on a device |
| 20030191716, | |||
| 20040003390, | |||
| 20040139430, | |||
| 20040237082, | |||
| 20040237083, | |||
| 20040254975, | |||
| 20050033728, | |||
| 20050091535, | |||
| 20050132357, | |||
| 20050282636, | |||
| 20050289535, | |||
| 20060136728, | |||
| 20060197753, | |||
| 20070197202, | |||
| 20080022290, | |||
| 20080215796, | |||
| 20100211941, | |||
| 20100299663, | |||
| 20100318985, | |||
| 20110214184, | |||
| 20120117214, | |||
| 20120198434, | |||
| 20130047036, | |||
| 20130054960, | |||
| 20130219383, | |||
| 20130263088, | |||
| 20150095653, | |||
| 20160021170, | |||
| 20160357538, | |||
| 20160357544, | |||
| 20170012838, | |||
| CN104090654, | |||
| CN1957327, | |||
| EP1076290, | |||
| JP2000163031, | |||
| JP2002342033, | |||
| KR1020110069718, | |||
| KR1020110082585, | |||
| WO2000033565, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Oct 14 2019 | Apple Inc. | (assignment on the face of the patent) | / |
| Date | Maintenance Fee Events |
| Oct 14 2019 | BIG: Entity status set to Undiscounted (note the period is included in the code). |
| Date | Maintenance Schedule |
| Nov 14 2026 | 4 years fee payment window open |
| May 14 2027 | 6 months grace period start (w surcharge) |
| Nov 14 2027 | patent expiry (for year 4) |
| Nov 14 2029 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Nov 14 2030 | 8 years fee payment window open |
| May 14 2031 | 6 months grace period start (w surcharge) |
| Nov 14 2031 | patent expiry (for year 8) |
| Nov 14 2033 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Nov 14 2034 | 12 years fee payment window open |
| May 14 2035 | 6 months grace period start (w surcharge) |
| Nov 14 2035 | patent expiry (for year 12) |
| Nov 14 2037 | 2 years to revive unintentionally abandoned end. (for year 12) |