Techniques for evaluating applications through use of an auxiliary application

Disclosed are various embodiments for evaluating an application under development through use of a viewer application executing in a computer. The computer retrieves an application package comprising code for a target application to be evaluated in the computer. The code for the target application is stored in a memory of the computer accessible to the viewer application. The code for the target application is stored without installing the target application as a stand-alone application on the computer. Code of the viewer application is executed in order to execute the stored code for the target application for evaluation. Executing the stored code of the target application executes the target application within the execution of the viewer application.

FIELD

This disclosure relates generally to computer-implemented methods and systems and more particularly relates to evaluating an application under development through use of a viewer application executing in a computing device.

BACKGROUND

Given the proliferation of mobile devices and other types of computing devices, many people have been encouraged to develop applications for these computing devices. Some of these people may be experienced application developers, while others are new to the different routines required to not only author an application, but to also build and test the application. Development environments are available that simplify the application development process, but building and testing an application for different types of computing devices and with different operating systems can still be a complicated, time-consuming process.

SUMMARY

Disclosed are various embodiments for evaluating an application under development through use of a viewer application executing in a mobile device. The viewer application retrieves an application package that comprises code for the target application. In some implementations, the package is retrieved from a content management system (CMS). In other implementations, the package can be retrieved, if it exists, from local storage in the mobile device.

The viewer application stores the code for the target application in a memory of the mobile device that is accessible to the viewer application. In some implementations, the viewer application adds the code for the target application to the memory by replacing at least a portion of the code of the viewer application in a memory of the mobile device with the code for the target application. In various implementations, the code for the target application is modified to include supplementary code with a reference to code for the viewer application. In some implementations, an update server defined in the code for the target application is modified to use the CMS as the update server. In other implementations, supplementary code is added to the target application for retrieving an updated version of the target application and initiating execution of the updated version of the target application. In still other implementations, supplementary code is added to the target application for capturing one or more screenshots of a user interface of the target application during execution.

The viewer application executes the stored code for the target application for evaluation. Executing the stored code of the target application executes the target application within the execution of the viewer application. In further implementations, the target application monitors for input corresponding to a request to return to execution of the viewer application, including the user interface, via the reference. In some implementations, the input is selection of an item from a supplementary menu. In other implementations, the input is a gesture received via a touch-sensitive display.

DETAILED DESCRIPTION

Disclosed herein are techniques for simplifying the operations used to test and evaluate an application under development through use of a viewer application executing in a computing device. Traditionally, evaluating an application that is under development for computing devices, such as smartphones, required developers or other users to complete complex procedures to compile the application for the correct hardware and operating system, deploy the application, and install the application as a stand-alone application. Moreover, these procedures would be required for each individual application that a user wishes to evaluate and possibly for each type of device in which the application is to be evaluated.

In terms of the procedures involved to evaluate an application in a given computing device, it would be significantly less complex for users to have a general, existing application (i.e. the viewer application) installed in the computing device that could execute the code of any application selected for evaluation (i.e. the “target application”) without undergoing the various compilation and installation procedures for the target application as a stand-alone application. To this end, using techniques disclosed herein, the viewer application executing in a computing device acquires code for the target application, places the code for the target application in the memory, and initiates execution of the code for the target application that is located in the memory. As a result, the user is able to evaluate the target application in the particular computing device (possibly one computing device among many different types in which the application should be tested) without the complex and error-prone compilation and installation procedures for the target application as a stand-alone application. Furthermore, the viewer application is generalized such that it is capable of initiating execution of code for other applications under development in the same manner as performed for the current target application. In the following discussion, a general description of the system and its components is provided, followed by a discussion of the operation of the same.

As used herein, the “target application” is an application that has been selected for evaluation in a client device by a user.

As used herein, the “viewer application” is an application executed in a client device that facilitates the evaluation of one or more target applications in the client device by a user.

As used herein, the “content management system” (CMS) is a network-enabled service that allows users to manage the creation, editing, and deletion of content supporting development of applications (or simply “apps”) that are executable in one or more computing devices. In addition, the CMS can support features allowing users to collaborate with other users during the application development process, as well as authentication and authorization capabilities to manage access to the content among the various users.

With reference toFIG. 1, shown is a networked environment100according to various embodiments. The networked environment100includes a computing environment103and one or more client devices106, which are in data communication with each other via a network109. The network109includes, for example, the Internet, intranets, extranets, wide area networks (WANs), local area networks (LANs), wired networks, wireless networks, or other suitable networks, etc., or any combination of two or more such networks. For example, such networks can comprise cellular networks, satellite networks, cable networks, Ethernet networks, and/or other types of networks.

The computing environment103comprises, for example, a server computer or any other system providing computing capability. Alternatively, the computing environment103employs a plurality of computing devices arranged, for example, in one or more server banks or computer banks or other arrangements. Such computing devices can be located in a single installation or distributed among many different geographical locations. For example, in some embodiments, the computing environment103includes a plurality of computing devices that together comprise a hosted computing resource, a grid computing resource, and/or any other distributed computing arrangement. In some cases, the computing environment103corresponds to an elastic computing resource where the allotted capacity of processing, network, storage, or other computing-related resources may vary over time.

Various applications and/or other functionality may be executed in the computing environment103according to various embodiments. Also, various data is stored in a data store112that is accessible to the computing environment103. The data store112can represent a plurality of data stores112, as can be appreciated. The data stored in the data store112, for example, is associated with the operation of the various applications and/or functional entities described below.

The components executed on the computing environment103, for example, include a content management system (CMS)121and other applications, services, processes, systems, engines, or functionality not discussed in detail herein. The CMS121is executed to allow users to manage the creation, editing, and deletion of content supporting development of applications (or simply “apps”) that are executable in one or more computing devices, such as in a client device106. Among other features, the CMS121can support the use of credentials with which to authenticate users, managing user permissions of various files and other data for development projects, version history for the development data, version publication and release information for development projects, and/or other possible features as can be appreciated.

The data stored in the data store112includes, for example, user account data131, application records133, and potentially other data. The user account data131includes credentials for user accounts associated with the CMS121, user preferences, a history of interactions with the CMS121by the users, user permissions associated with applications and development projects, and/or other possible data. The applications records133each include various content and metadata associated with development of an application. The application records133are each associated with application data135, application metadata137, and possibly other data. The application data135includes content associated with development of a particular application, such as source and executable code for the application, text strings, audio, video, images, and/or other types of content as can be appreciated. The application metadata137include various metadata associated with a particular application such as a description, keywords, version history, indicators for versions published or released, build instructions for various different computing devices, network address from which released applications can be updated, change logs, release notes, identifiers for the application owner(s)/contributor(s), and/or other possible metadata.

The client106is representative of a plurality of client devices that can be coupled to the network109. The client106comprises, for example, a processor-based system such as a computer system. Such a computer system may be embodied in the form of a smartphone, a desktop computer, a laptop computer, a personal digital assistant (PDA), a cellular telephone, a set-top box, a music player, a web pad, a tablet computer system, a game console, an electronic book reader, or other devices with like capability. The client106may include a display161. The display161may comprise, for example, one or more devices such as liquid crystal display (LCD) displays, gas plasma-based flat panel displays, organic light emitting diode (OLED) displays, electrophoretic ink (E ink) displays, LCD projectors, or other types of display devices, etc. In some embodiments, the display161is touch-sensitive and can support various gesture-based forms of input.

The client106may be configured to execute various applications such as a viewer application163and/or other applications. The viewer application163is executed in a client106, for example, to access content served up by the computing environment103and/or other servers, thereby rendering a user interface164on the display161. To this end, the viewer application163may comprise, for example, a browser, a dedicated application, etc., and the user interface164may comprise a network page, an application screen, etc. Included among the various types of content accessible by viewer application163, are the applications under development that are managed by the CMS121. Selected applications (also referred to as “target applications”) can be requested and received via an application request165and target application data167, respectively. The target application171can be extracted from the target application data167and prepared for execution by the viewer application163. The preparation process may include the addition and/or modification of supplementary code173to the target application171, as is described in greater detail herein. The client106can also be configured to execute applications beyond the viewer application163such as, for example, email applications, social networking applications, word processors, spreadsheets, and/or other applications.

Next, a general description of the operation of the various components of the networked environment100is provided. To begin, an application developer or other user who is to test an application being developed, establishes a communication session between the viewer application163and the CMS121. The communication session may be carried out using various protocols such as, for example, hypertext transfer protocol (HTTP), simple object access protocol (SOAP), representational state transfer (REST), user datagram protocol (UDP), transmission control protocol (TCP), and/or other protocols for communicating data over the network109. In some implementations, the user is authenticated to the CMS121using one or more user credentials.

Thereafter, the user is presented with a user interface164for the viewer application163, such as shown inFIG. 2. Among the various possible screens of the user interface164is the application selection screen203in which a user is shown a list received from the CMS121that includes any applications which can be evaluated through the viewer application163. In some implementations, the application selection screen203also includes applications stored locally on the client106which can be evaluated through the viewer application163. The list of applications, such as the three applications shown in the application panel205, can also include names, version information, modification dates, and/or other possible metadata not shown, such as icons, screenshots, keywords, description, etc. In some embodiments, the application panel205also includes a menu207, such as a pop-up menu, through which various information and settings associated with the applications and the viewer app can be found. For example, the menu can allow the user to initiate evaluation of a selected application, find additional information about an application (e.g. application size, description, etc.), options or other user preferences for the viewer application163(e.g. user credentials, CMS server address, etc.), and/or other possibilities.

Once the user has provided input selecting an application to evaluate (i.e. the “target application”), the viewer application163transmits an application request165to the CMS121via the network109. The application request165can comprise an identifier for the target application to be evaluated, descriptors and version information for the viewer application163and client106in which the target application is to be executed for evaluation, and/or other possible information. In response to the application request165, the CMS121transmits the target application data167to the requesting viewer application163. As described previously, in some embodiments, the target application data167may be cached and stored locally on the client106or another storage device, instead of retrieving it from the CMS121. The target application data167comprises content, including both executable code and static content, needed to execute the target application171from the viewer application163. As can be appreciated, execution of the target application171can further utilize plug-ins or other code that pre-exists on the client106and/or is retrieved separately. In some embodiments, the target application data167comprises an application package, such as an APK (Android Application Package), ZIP, etc., that includes the content for the target application, as well as a manifest and/or other metadata instructing how the application is to be executed from the content, such as can be used to accommodate the differences among the various types of clients106and/or operating systems of each client106. Changes or modifications to the content of the target application made by the viewer application163are made to the local copy of the content held in the memory and storage space of the client106that are allocated to the viewer application163.

In other embodiments, the target application provides, when executing, a feature to check for updates to the target application and allowing an end-user to update the application if such an update exists. To carry out this feature, the target application is configured with a network address, such as a uniform resource identifier (URI), of an update server at which to check for published updates to the target application, where the update server may not be controlled by the developer of the target application. In order to evaluate the “application update” or “in-app update” feature of the target application prior to the release of the target application or with a development version of the target application, the viewer application163can modify the network address information of the update server in the local copy of the code of the target application. For example, the network address of the CMS121can be inserted as the update server. Thereafter, during execution of the target application171in the client106, the application update feature will instead check with the CMS121for more recent versions (i.e. developmental, pre-release versions) of the target application instead of the previously defined update server.

In order to execute the target application171in the client device106, the viewer application163stores the content, including executable code, of the target application171in the memory of the client106. In some embodiments, when the viewer application163adds the content of the target application171to memory, the viewer application163replaces a portion of its own content in the memory. As a result, the target application171can begin executing in the client106as if the target application had been compiled and installed in the client through a traditional application install routine.

In some implementations, the viewer application163initiates target applications171built using web content technology, such as HTML and JavaScript/CSS (cascading style sheets), whereby the viewer application163contains a web view user interface that takes up the full width and height on the display161of the client106. Once the application package for the target application171has been obtained and unpackaged by the client106, the viewer application163examines the metadata of the target application to determine the root HTML document for the target application. The viewer application163then initiates execution of the target application171by redirecting the content viewer providing the web view user interface of the viewer application to load the root HTML document for the target application171. This root HTML document of the target application171will then take care of requesting any other local assets that are needed, which may have been included as part of the application package (e.g. scripts, fonts, images, styles, etc.) and/or are available elsewhere on the client device106.

In various embodiments, a copy of code for the viewer application163is also stored in a separate location on the client106(e.g. in flash storage or other non-volatile storage, another location in memory, etc.) from the location in which it was executing in memory. In this manner, code for the viewer application still exists on the client106and can be initiated for execution if portions of the code of the viewer application163in memory are replaced with the target application171.

For example, the target application171previously selected for evaluation by the user through the viewer application163is “App Foxtrot,” an exemplary image editing application. As shown inFIG. 3, the content of App Foxtrot has now been placed in memory and is being executed such that the viewer application163, or at least the user interface for the viewer application163, is no longer executing.

Thus, without further modifications, in order for a user evaluating the target application171to return to the user interface for the viewer application163, the user would need to leave the target application171and re-start the viewer application163. Therefore, in some embodiments, to simplify the user interactions required to switch from execution of the target application171back to the user interface of the viewer application163, the viewer application163modifies the local copy of the code of the target application to insert supplementary code173that allows the user to, among other possible functions, “revert” to the user interface of the viewer application163from within the target application171. To this end, the viewer application163can insert supplementary code173into the target application171, where the supplementary code173contains a pointer or other type of reference back to the code for the user interface of the viewer application163in local storage and/or elsewhere in memory on the client106. Therefore, when executed as part of the execution of the target application171, the supplementary code173can activate the reference to begin executing code for the user interface of the viewer application163specified by the reference based on a gesture entered by the user, selection of an item from a menu, and/or elsewhere through the user interface of the target application171.

For example, as shown inFIG. 4, the App Foxtrot (i.e. the target application), now executing in the client106, has been previously modified by the viewer application163to include supplementary code173that includes a reference back to the code for the user interface of the viewer application stored in a location accessible to the client106. In this instance, the supplementary code173provides a supplementary menu403triggered by a particular gesture or other input received from a user. From the supplementary menu403, the user can select one or more items from the menu, such as “Revert to Viewer App,” which activates the reference to initiate executing code for the user interface of the viewer application163instead of App Foxtrot. In some embodiments, the state of the viewer application163is preserved in memory from prior to beginning execution of the target application171. In other embodiments, code for the viewer application163is re-initialized from the separate location, and the state from just prior to beginning execution of the target application171is not preserved.

The supplementary code173can include code for other features which can be added to the target application171, instead of or in addition to the feature described above to revert to the viewer application. In various embodiments, the viewer application163adds supplementary code173to a target application171to “refresh” the target application. In these embodiments, when activated, the code added to the target application171retrieves a new copy of the target application from the CMS121and begins executing this new copy of the target application171without the user having to first revert to the viewer application, then manually retrieve a new copy. The supplementary code173used to refresh the target application can be configured to get the latest version of the target application on the CMS121, the same version of the target application currently being executed, do nothing unless a newer version of the target application is available on the CMS121, and/or other possibilities as can be appreciated. As discussed previously, while some types of target applications can support in-app updates using an upgrade server, not all target applications do. Moreover, even for applications that do support in-app updates, users may wish to simply update the target application without configuring and testing the in-app update feature.

In still other embodiments, the viewer application163adds supplementary code173to a target application171to capture one or more screenshots. In these embodiments, when activated, the code added to the target application171captures a screenshot of the user interface164of the target application171during execution. The screenshot may be captured in various possible still image and/or video formats, such as JPEG (Joint Photographic Experts Group), BMP (bitmap), GIF (Graphics Interchange Format), MPEG1/2/4(Moving Picture Experts Group), etc. In addition, the screenshot feature can support transmitting the screenshot images that were captured from the client106to the CMS121. As can be appreciated, while the supplementary menu403can be used to initiate the various features available in supplementary code173, each of the feature can be initiated directly from user input through the user interface instead of or in addition to the supplementary menu403. For example, a three-finger touch gesture initiates a reversion to the viewer app, a circle touch gesture initiates a screenshot capture, and a triangle gesture initiates a refresh of the target app.

Referring next toFIGS. 5-7, shown are flowcharts that each provide one example of the operation of a portion of the viewer application163according to various embodiments. It is understood that each of the flowcharts ofFIGS. 5-7provides merely an example of the many different types of functional arrangements that may be employed to implement the operation of the portion of the viewer application163as described herein. As an alternative, each of the flowcharts ofFIGS. 5-7may be viewed as depicting an example of elements of a method implemented in the client106according to one or more embodiments.

FIG. 5is a flow chart illustrating functionality for executing a target application within a viewer application after obtaining the target application from a content management system and modifying the target application to include supplementary code, where the functionality is implemented as portions of a viewer application163executed in a client106. The operation of the viewer application163described inFIG. 5may be executed in response to a user initiating execution of the viewer application163on the client device106. Beginning with block503, an application developer or other user who is to test an application under being developed, establishes a communication session between the viewer application163and the CMS121. The communication session may be carried out using various protocols such as, for example, HTTP, SOAP, REST, UDP, TCP, and/or other protocols for communicating data over the network109. In some implementations, the user is authenticated to the CMS121using one or more user credentials.

Next, in block506, the viewer application163receives a list from the CMS121that includes applications which can be evaluated by the user through the viewer application163. The list of applications can also include names, version information, modification dates, icons, screenshots, keywords, description, and/or other possible metadata associated with the applications. The list of applications is presented to the user via a user interface from which the user can select a target application for evaluation.

Then, in block509, the user application determines whether the user has received input selecting an application for evaluation. If the user has not made a selection, execution of the viewer application returns to509. Alternatively, if a user has selected a target application, in block512, the viewer application163transmits an application request165to the CMS121via the network109. The application request165can comprise an identifier for the target application to be evaluated, descriptors and version information for the viewer application163and client106in which the target application is to be executed for evaluation, and/or other possible information.

Subsequently, in block515, the viewer application determines whether target application data167has been received in response to the application request. If the target application data167has not yet been received, execution of the viewer application163returns to block515. Alternatively, if the target application data167has been received, in block518, the viewer application163can modify the content of the received target application to include any supplementary code, including changes to existing code of the target application. For example, the supplementary code can include changes to the network address of a network server used for in-app updates, code with a reference to resume execution of the viewer application163, including the user interface, from within the target application171(i.e. “revert to viewer app”), code to initiate a refresh of the target application171, code to capture screenshots of the target application, and/or other possible changes to the code or content of the local copy of the target application171.

Next, in block521, the viewer application163stores content, including executable code, of the target application171in memory. Then, in block524, the viewer application163executes the stored code of the target application171in the client106. At this point, execution of the viewer application163, or at least the user interface of the viewer application163, ceases with the start of execution of the target application171, including any supplementary code173.

As discussed above, in some embodiments, execution of the viewer application, including the user interface, can resume by the user providing input initiating the “revert to viewer app” feature of the supplementary code173. In these embodiments, code for the viewer application still exists on the client106(e.g. in flash storage or other non-volatile storage, another location in memory, etc.) and can be initiated for execution after execution of the target application171has begun.

FIG. 6is a flow chart illustrating functionality for executing a target application within a viewer application, where the target application is built using web technology and the functionality is implemented as portions of a viewer application163executed in a client106. The operation of the viewer application163described inFIG. 6is executed in response to a user selecting a target application171for evaluation in the viewer application163on the client device106. The application package for the target application can be resident in local storage on the client106or be retrieved from a server, such as a CMS, via a network. Beginning with block603, the viewer application163obtains an application package for a target application171built using web content, such as HTML, XML (extensible markup language), JavaScript/CSS, and/or other web technologies. The application package can be in a ZIP, RAR, BZIP, APK, or other file packaging formats.

Next, in block606, the viewer application163examines the metadata for the target application171provided in the application package to determine the initial content to execute for the target application. In some implementations, the initial content is determinable by the viewer application163based upon an examination of the content of the target application171. For example, if the target application is built using HTML with JavaScript/CSS, the initial content would be the root HTML document. Then, in block609, the viewer application163obtains any plug-ins or additional code that is needed by the client106to support execution of the target application171. For example, a plug-in could be used to provide playback of video for the target application.

Continuing, in block612, the viewer application163instructs the content viewer that provides the web view user interface for the viewer application to redirect to the initial content determined for the target application171. In one embodiment, the content viewer is a rendering engine for various web content present in the viewer application163and various possible target applications. Next, in block615, the content viewer for the viewer application163loads at least the initial content for the target application171into the memory of the client106.

In one embodiment, the content for the target application171replaces at least a portion of the viewer application163, such as a portion of the content for the user interface of the viewer application. Replacing at least a portion of the code of the viewer application163with code of the target application171provides an advantage with regard to a reduction in the amount of memory resources of the client106consumed to execute the target application, among other possible advantages. In another embodiment, the content for the target application171is added to the memory without replacing any of the viewer application163. This provides the advantage, among other possibilities, of allowing the client106to promptly revert to and resume execution of the viewer application163from its state just prior to beginning execution of the target application171.

The target application is executed within the execution of the viewer application so that the target application does not need to be installed as a stand-alone application on the device. The code of the target application is executed within the execution of the viewer application when, in block618, the content viewer for the viewer application163initiates execution of the initial content of the target application171. In some embodiments, executing the initial content comprises the content viewer executing and rendering the initial web content, including HTML and JavaScript/CSS, for the target application171. Once execution of the target application171has begun, execution of this portion of the viewer application163(e.g. the user interface) ends as shown. Execution of the target application will proceed as though it had been installed through a traditional installation routine, which can include a full-screen user interface, access to sensors and other input devices, access to send/receive data through network interfaces and/or through local memory, as well as other possible resources. In some implementations, execution of the target application171will continue until such time as the execution is interrupted by user input (e.g. requesting via the UI of the target application171to exit the app) or by another function of the client106(e.g. the operating system terminating the execution of the target application). In other implementations, supplementary code173is added to the target application171that is responsive to input from a user requesting to, among other possible functions, revert to execution of the viewer application163from within the execution of the target application171, as previously described.

FIG. 7is a flow chart illustrating functionality for modifying code of a target application to include supplementary code for reverting back to the viewer application during execution of the target application, where the functionality is implemented as portions of a viewer application163executed in a client106. The operation of the viewer application163described inFIG. 7is executed in response to a user selecting a target application for evaluation in the viewer application163on the client device106. In particular, the operations described relate to the addition of supplementary code for reverting to the viewer application163from within the execution of the target application171. The application package for the target application171that is modified in the client106to include supplementary code can be resident in local storage on the client106or be retrieved from a server, such as a CMS, via a network. Beginning with block703, the viewer application163obtains an application package for a target application171. The application package can be in a ZIP, RAR, BZIP, APK, or other file packaging formats.

Then, in block706, the viewer application163determines whether supplementary code173should be added to the target application171to support reverting to the viewer application163from within the executing target application171. Such determination can be based on a selection within a user interface164of the viewer application163, based on a user preference, and/or other possible sources. If the code to revert to the viewer app is not to be added to the code for the target application171, execution of the viewer application163proceeds to block715. Alternatively, if code to revert to the viewer app is to be added to the code for the target application171, in block709, the viewer application163determines a reference point in the viewer application163at which execution should return from the target application171.

In embodiments where the viewer application163is built using web content, the reference point can be an identifier for a root HTML document that provides a user interface and other functionality for the viewer application. In other embodiments, the reference point is an address in memory of the client106or a link to a location in a file system for non-volatile storage on the client106. Next, in block712, the viewer application163modifies code of the target application171to include supplementary code for redirecting execution to the reference point of the viewer application163. In some embodiments, the supplementary code is responsive to a unique gesture made by a user on a touch-sensitive display that, during execution of the target application171, initiates reverting back to the viewer application163. In other embodiments, the supplementary code provides a supplementary menu of actions to initiate from within the execution of the target application, one of the actions being reverting back to the viewer application163.

Continuing, in block715, the viewer application stores the code for the target application171, including any supplementary code added, in the client106. From this point, the code for the target application171can be made available by the viewer application163for evaluation by a user, either immediately or at a later time. Thereafter, this portion of the execution of the viewer application163ends as shown.

With reference toFIG. 8, shown is a schematic block diagram of a client device106according to an embodiment of the present disclosure. Each client device106includes at least one processor circuit, for example, having a processor803and a memory806, both of which are coupled to a local interface809. The local interface809may comprise, for example, a data bus with an accompanying address/control bus or other bus structure as can be appreciated.

Stored in the memory806are both data and several components that are executable by the processor803. In particular, stored in the memory806and executable by the processor803are the viewer application163, target application171, supplemental code173, and potentially other applications. In addition, an operating system may be stored in the memory806and executable by the processor803.

A number of software components are stored in the memory806and are executable by the processor803. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by the processor803. Examples of executable programs may be, for example, a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of the memory806and run by the processor803, source code that may be expressed in proper format such as object code that is capable of being loaded into a random access portion of the memory806and executed by the processor803, or source code that may be interpreted by another executable program to generate instructions in a random access portion of the memory806to be executed by the processor803, etc. An executable program may be stored in any portion or component of the memory806including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.

Also, the processor803may represent multiple processors803and/or multiple processor cores and the memory806may represent multiple memories806that operate in parallel processing circuits, respectively. In such a case, the local interface809may be an appropriate network that facilitates communication between any two of the multiple processors803, between any processor803and any of the memories806, or between any two of the memories806, etc. The local interface809may comprise additional systems designed to coordinate this communication, including, for example, performing load balancing. The processor803may be of electrical or of some other available construction.

Further, any logic or application described herein, including the viewer application163, target application171, and supplemental code173, may be implemented and structured in a variety of ways. For example, one or more applications described may be implemented as modules or components of a single application. Additionally, it is understood that terms such as “application,” “service,” “system,” “engine,” “module,” and so on may be interchangeable and are not intended to be limiting.