CN117918012A - Webpage management in native application - Google Patents

Abstract

Methods, systems, and computer programs for rendering web components in a native application are presented. A method comprising the operations of: a first User Interface (UI) presented on the native application is monitored, and a second UI selectable by a user when accessing the first UI is determined based on the monitoring. The second UI is based on web components downloaded from the web server. The method also includes operations for authenticating a user to access the web server, selecting a web component associated with the UI for preloading, and preloading the selected web component. Further, the method includes an operation for detecting that the user has selected the second UI and causing presentation of the second UI, the presentation of the second UI comprising: the preloaded components are presented on the second UI and the components that were not preloaded are downloaded and presented in the second UI.

Description

Webpage management in native application

Technical Field

The subject matter disclosed herein relates generally to methods, systems, and machine-readable storage media for rendering web content within a native application.

Background

When providing web functionality for accessing data on a remote server, a developer may choose to use a browser-based application or write a program called a native application or native application that connects to the server to exchange data and then present information or obtain user input on a user interface.

However, writing code for each option in the native application can be expensive, especially when there is already a browser interface for the same function. Hybrid approaches are sometimes used in which the native application embeds a simple browser engine in the native application User Interface (UI) to implement certain functions. However, using an embedded browser engine may result in reduced performance due to the overhead imposed by the browser, such as authenticating the user each time information is downloaded.

Drawings

The various drawings illustrate only example embodiments of the disclosure and are not to be considered limiting of its scope.

FIG. 1 is a user interface of a native application according to some example embodiments.

FIG. 2 is a web user interface presented within a native application according to some example embodiments.

FIG. 3 illustrates a process for loading web components according to some example embodiments.

FIG. 4 illustrates a method for preloading web components, according to some example embodiments.

FIG. 5 is a system including a loader manager for loading web components according to some example embodiments.

FIG. 6 is a flowchart of a method for managing the loading of components, according to some example embodiments.

FIG. 7 is a block diagram illustrating an example of a machine on or through which one or more example process embodiments described herein may be implemented or controlled.

Detailed Description

Example methods, systems, and computer programs relate to rendering web components in a native (native) application. Examples merely typify possible variations. Unless explicitly stated otherwise, components and functions are optional and may be combined or sub-divided, and operations may be varied in sequence or combined or sub-divided. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the example embodiments. It will be apparent, however, to one skilled in the art that the subject matter may be practiced without these specific details.

The loader manager is a component of the native application that predicts the functions that can be used by the user and the functions that need to communicate with the web server. The loader manager determines which components to preload before the user invokes a given feature, so when the user selects the feature, some Web components are already in the machine's memory and respond more quickly. Further, the loader manager authenticates the user to the server in advance, so the user does not have to wait for authentication when the user needs data from the server. Preloading web components reduces the loading time and response time for activating web-dependent functions. Preloading does not include displaying the preloaded information to the user. Furthermore, a single code library may be available to the loader manager, which may be shared by multiple native applications in the same platform.

One general aspect includes a method that includes operations for monitoring a first User Interface (UI) presented on a native application and determining a second UI selectable by a user when accessing the first UI based on the monitoring. The second UI is based on web components downloaded from the web server. The method also includes operations for authenticating a user to access the web server, selecting a web component associated with the UI for preloading, and preloading the selected web component. Further, the method includes an operation for detecting that the user has selected the second UI and causing presentation of the second UI, the presentation of the second UI including presenting preloaded components on the second UI and downloading and presenting non-preloaded components in the second UI.

FIG. 1 is a user interface 102 of a native application according to some example embodiments. The machine uses MicrosoftIs an email application that includes options for reading email in panel 106 and a view of email in panel 108. On the left panel, options 104 are provided for group functions, each group corresponding to one user set of the native application.

The User Interface (UI) 102 is provided as a native function and is independent of browser functionality. The UI 102 provides options related to the group, such as sending an email to the group, reading a message from the group, adding a member to the group, deleting a member from the group, inviting the user to join the group, and so forth. Microsoft Outlook also provide web versions to users as alternatives to native applications.

FIG. 2 is a web UI 202 presented within a native application according to some example embodiments. After the user selects the edit group option, the UI 202 is presented. In this example, the UI 202 is the same interface as in the corresponding browser application, and the native application 202 displays the UI 202 using the browser.

The UI 202 includes several components including a title 224 of the UI (e.g., edit the group), menu options 222 (e.g., about (which is selected) and members), a menu description 206, an image 204, a photo 208 of the group, a box 210 for editing the group name, an email address 212 of the group (e.g., kayteamgroup@service.corpx.com), a box 214 for editing the group description, a sensitivity (sensitivity) drop-down menu 216, a button 218 for saving and discarding settings, and a button 220 for deleting the group.

Some components are generic and independent of user or application parameters and are referred to herein as static components. Other components depend on user or application parameters, such as user name or group name, and are referred to as dynamic components.

Some static components include a title 224, a menu option 222, a menu description 206, an image 204, a box 210 for editing a group name, a box 214 for editing a group description, a sensitivity drop down menu 216, a button 218, and a button 220 for deleting a group.

Some dynamic components include the photo 208, the current name of the group in box 210, the email address 212, a description of the group in box 214, and the value of the sensitivity drop down menu 216.

It should be noted that the embodiment shown in fig. 2 is an example and that every possible embodiment is not described. Other embodiments may utilize different combinations, have other static or dynamic components, have fewer components, etc. The embodiment shown in fig. 2 is therefore not to be construed as exclusive or limiting, but rather as illustrative.

If the native application only uses a browser to display the UI 202, the embedded browser must perform operations associated with the browser, such as authenticating the user, downloading all components, and so forth. In addition, the native application may interact with web components loaded into the browser and utilize native functions, such as performing file input and output operations within the web browser, accessing system settings, and the like.

In some example embodiments, the loader manager program preloads some components so that when the user selects the option to edit the group, the UI 202 immediately displays the preloaded components. Moreover, since the user has been authenticated, authentication is not required at this time, resulting in faster presentation of the UI 202.

In some example embodiments, static components are preloaded, while dynamic components are loaded when the user selects the UI. In other example embodiments, some or all of the dynamic components are also preloaded. For example, when presenting the UI of FIG. 1 to a user, the program obtains a list of all groups of the user and then preloads dynamic components for all or part of the groups.

Note that some embodiments are described with reference to an email application, but the same principles can be used for any other native application that incorporates browser functionality, such as web-based editors, collaboration applications, web-based spreadsheets, video conferencing, banking applications, search applications, games, payment applications, and the like.

FIG. 3 illustrates a process for loading web components according to some example embodiments. In some applications, a hybrid model is used to combine native capabilities and web functions. The Web component is used with browser-type controls in native applications (e.g., webview2, progressive Web application (Progressive Web Apps, PWA)). This facilitates the development of native applications and provides cross-platform consistency (e.g., web browser, mobile access, desktop access).

When the native application 302 is used, the user selects a UI action (e.g., button click, launch task pane) that requires a web service at operation 304. From operation 304, the method flows to operation 306, wherein the native application 302 loads 324 the browser module 310, the browser module 310 being a browser program that interacts with the web server 320. The browser module 310 uses the corresponding Uniform Resource Locator (URL) to navigate 314 to the web server 320 and the web server 320 returns 322 the requested data (e.g., web page).

Communications are exchanged (e.g., messages, events) between the browser module 310 and the web server 320, and the browser module passes 316 the information to the native application 302.

At operation 308, the native application 302 closes the corresponding dialog box or task pane and the native application 302 sends a close request 318 to the browser module 310. At operation 312, the browser module 310 closes.

One of the problems with this approach is that operations 314 and 322 may take a significant amount of time (e.g., two to ten seconds or more) due to network calls to the corresponding URLs, downloads of scripts (e.g., javascript packages), and operations to authenticate the user to access the requested information or service. The result is a poor user experience due to the delay caused by using the browser module 310.

Further, when the user closes the browser module 310, all information previously obtained, including user authentication, will be lost, and later requests need to be restarted from the beginning.

FIG. 4 illustrates a method for preloading web components, according to some example embodiments. To address the slow response issue, some embodiments utilize a policy to preload the web component even before the user activates the corresponding feature in the native application. The preloaded components are cached and retained in memory so that when the user activates the web feature, the preloaded components are immediately available without downloading from the server. This may result in the native application responding seemingly immediate to all or part of the elements of the UI.

There are three aspects to the preload strategy. The first is to finish the authentication procedure in advance. The user is authenticated to the server even before authentication is required, and when web access is activated, the user has already been authenticated, so authentication does not have to be performed. This means that authentication is performed in advance and the authentication token is stored and available for future use. Furthermore, the authentication token may be used as many times as desired.

Second, there are static and dynamic components. Static components may be downloaded in advance so they are already cached in memory when they are needed. In addition, all or part of the dynamic content may also be preloaded. As discussed above in the group example, the dynamic content of the user group may also be preloaded so that when the user selects the option to edit a particular group, all components are already available in local memory, resulting in a seemingly immediate response of the native application.

Third, the loader manager utilizes heuristics to determine web components to preload. For example, heuristics may be based on user behavior, frequency of feature selections by the user, benefits of preloading components, available bandwidth and amount of computer resources, and so forth. By using heuristics, a balance between cost and the benefits of preloading can be achieved, providing a quick response without burdening the system with preloading too many web components. Browser control 402 is a module that loads web loader 404. For example, browser control 402 may be a local library that provides a utility for loading web loader 404.

Web loader 404 is a program that exchanges communications with web server 320 to obtain web page data, and web loader 404 provides an interface with native application 302 for completing requests and providing information. In some example embodiments, web loader 404 is a separate program from native application 302, and in other embodiments, web loader 404 is a module within native application 302.

Further, while a single web loader 404 is shown, there may be multiple web loaders 404, and each web loader 404 may have specific functionality, such as preloading components for specific features in the UI.

Further, while separate browser controls 402 and web loader 404 are shown, some embodiments may combine the two into a single module.

At operation 406, the native application 302 creates a dialog feature (e.g., for loading a web page) and keeps information associated with the dialog hidden from view in the UI.

At operation 408, the native application 302 activates the web loader 404 to preload one or more web components and cache information in memory. Further, if the user has not been authenticated, the user is authenticated to the server and the authentication token is also stored in memory.

At operation 410, instructions are sent to the web loader 404 via the browser control 402 to navigate to a corresponding web page in the web server 320 using the given configuration parameters (e.g., user identifier, group name). web loader 404 establishes a session with web server 320 and authenticates the user. Note that operation 408 may be slow due to the need to download URL data and the need to authenticate the user.

At operation 412, the native application 302 requests data for a preloaded web page, referred to herein as a dialog web page with the user, although any type of web page may be suitable. The native application 302 sends the web page name to the browser control 402, and the browser control 402 forwards the web page name to the web loader 404.

The web loader then determines the preloaded web components and the web components that need to be downloaded. If there are Web components that need to be downloaded, the Web loader downloads them from the Web server 320.

After all web components are downloaded, the web loader sends a web page load complete message to browser control 402, which is forwarded to native application 302. In addition, web loader 404 is suspended (e.g., closed) and native application 302 is notified via browser control 402. The preloading operation is transparent to the user, that is, the user does not know that the web component is being loaded in the background, that is, the preloaded information is not visible in the UI presented to the user until the corresponding dialog feature is activated by the user.

The native application 302 keeps the dialog box hidden 414 invisible until requested. At operation 416, the native application 302 detects that the user has requested a dialog, e.g., changes the user interface to a UI for the dialog.

The native application 302 sends a load web page message to the web loader 404 via the browser control 402. The web loader 404 then determines the web components that have been preloaded and the web components that need to be downloaded based on the state of the UI (e.g., user ID, options selected). Web loader 404 then loads network components from network server 320 that are not cached in memory. The web loader 404 combines the cached data (if any) and the downloaded data (if any) and sends the combined data to the native application 302 via the browser control 402.

At operation 416, when the user selects the dialog box, the web page is loaded faster than on a conventional browser because the web loader 404 has preloaded some or all of the required web components.

It is noted that after the user leaves the dialog UI, the corresponding web component remains in memory, so that if the user comes back, the loading of the UI will still be fast.

It should be noted that the embodiment shown in fig. 4 is an example and that every possible embodiment is not described. Other embodiments may combine browser control 402 and web loader 404 into one module, utilize different messages, preload different information, and so forth. The embodiment shown in fig. 4 is therefore not to be construed as exclusive or limiting, but rather as illustrative.

The preload strategy provides three benefits. First, web page loading time is reduced (e.g., UI loading time is reduced by 80%, thereby improving performance). Second, memory consumption is reduced by using a single browser control that does not increase as more web loaders are added. Third, the user experience of the native application is improved to provide similar performance as the user experience on the browser interface.

FIG. 5 is a system including a loader manager 508 for loading web components, according to some example embodiments. web server 320 provides server-side functionality to one or more client devices 504 via a network 532, such as the internet or a Wide Area Network (WAN).

Client devices 504 may include, but are not limited to, mobile phones, desktop computers, laptops, portable Digital Assistants (PDAs), smart phones, tablets, netbooks, multiprocessor systems, microprocessor-based or programmable consumer electronics, or any other communication device by which user 502 can access web server 320. In some embodiments, client device 504 may include a display module (e.g., in the form of a user interface) for displaying information.

Client device 504 may include one or more applications (also referred to as "applications (apps)"), web browsers, and other client applications such as messaging applications, electronic mail (email) applications, news applications, and the like.

In some example embodiments, the client device 504 includes the native application 302. The native application 302 includes a web browser engine 506, a native application manager 528, and a loader manager 508. The web browser engine 506 provides web browser functionality and may include a limited set of browser features for rendering UIs associated with web services.

The native application manager 528 includes components associated with the native application, such as native program 516 (e.g., email application, team application, word processor) that provides custom functionality of the native application 302. In addition, native application manager 528 includes loader interface 510, state 512, and UI manager 514.

Loader interface 510 interfaces with loader manager 508. In some embodiments, loader interface 510 sends a request to loader manager 508 to perform a web page operation. The loader manager 508 can also monitor the state 512 of the native application (e.g., the current UI is presented to the user) and decide which web pages to preload. State 512 provides information about the current state of native application 302 and may include one or more of user information, UI being presented, user history, memory usage, memory availability, client device information, and the like.

The UI manager 514 provides UI functionality for presenting a UI to the user 502 in the client device 504. Further, the native program 516 is a program that executes the client device 504 to provide native application functions.

Note that the UI manager 514 can accurately render the web page as if the page were viewed on a browser (e.g., by utilizing the web browser engine 506), and the UI manager 514 can also use information obtained from the web page to provide a custom UI. That is, the UI manager may present a different UI than the browser UI. This may be useful in some situations, for example when the client device 504 is a mobile phone and the UI may be customized to fit the small display of the mobile phone.

Loader manager 508 provides the capability for implementing browser-based capabilities within native application 302. In some example embodiments, the loader manager 508 includes a status detector 518, a load predictor 520, a preload selector 522, an authenticator 524, a cache 526, a web loader 404, and a browser control 402.

The state detector 518 accesses the state 512 information to determine the current state of the native application 302. Load predictor 520 analyzes state 512 and predicts web pages that the user may select based on the state. For example, load predictor 520 may determine that the user is accessing the UI of FIG. 1 and that the user may load other UIs related to group functions.

The preload selector 522 determines which web components to preload for a given web page. The preload selector 522 may obtain web pages from the load predictor 520 that may be preloaded and select web components to load based on available resources, the benefits of preloading, the amount of bandwidth required for downloading, and the like. For example, preload selector 522 may decide to preload all static components for a given web page. Additionally, the preload selector may determine to preload one or more dynamic components.

Authenticator 524 authenticates a user to a web server that serves one or more web pages. Once the user is authenticated, the authentication token is used for future downloads from the server. If the authentication token expires, the authenticator 524 may periodically re-authenticate the user.

Cache 526 stores information used by loader manager 508, such as preloaded web components for certain web pages. The information may also include a time to upload the web component and a process may be used to clear stale entries from the cache after a predetermined amount of time has elapsed since preloading the component.

Web loader 404 exchanges communications with web server 320 to download web components in advance or when the UI requires web components.

In some example embodiments, preload selector 522 utilizes heuristics to determine which components to preload. Some heuristic factors utilized by preload selector 522 to determine components to preload include:

Options available on the UI presented to the user (e.g., group options, chat options)

-The amount of available space in the memory available for storing web components;

Hardware functions of the device (e.g. CPU model, available disk storage, network bandwidth);

-the current CPU utilization of the device;

-cost in terms of time and computer resource utilization of downloading web components;

benefits of preloading web components, e.g., an amount of time saved compared to having to load while the user waits for a response;

User history when using the native application 302 (e.g., determining the most commonly used operations by the user;

-histories of a plurality of users when using the native application 302, e.g. determining the most commonly utilized options by the users);

Based on one or more of these factors, preload selector 522 determines which components are to be preloaded in the background and requests web loader 404 to preload those components.

Note that the embodiment shown in fig. 5 is an example and that every possible embodiment is not described. Other embodiments may utilize different modules, combine two or more modules into one, split one module into several modules, include additional or fewer modules, and so forth. The embodiment shown in fig. 5 is therefore not to be construed as exclusive or limiting, but rather as illustrative.

FIG. 6 is a flowchart of a method 600 for managing loading of components, according to some example embodiments. While various operations in the flowchart are presented and described sequentially, one of ordinary skill will appreciate that some or all of the operations may be performed in a different order, combined or omitted, or performed in parallel.

In operation 602, the UI state is monitored. At operation 604, a check is made to determine if the user has been authenticated for accessing a web page associated with the UI (e.g., a server providing chat functionality). If the user has been authenticated, the method 600 flows to operation 608, and if the user has not been authenticated, the method 600 flows to operation 606 to authenticate the user to the web server.

At operation 608, the component to be preloaded is selected, and at operation 610, the selected component is preloaded.

At operation 612, the method 600 detects that the user has selected the option to load the UI. The UI is presented at operation 614, operation 614 including operations 616 and 618.

At operation 616, the preloaded components are presented in the UI. Since some components are preloaded, the UI presentation speed is faster than if all web components had to be downloaded for the web page in a standard browser. Further, since the user has been authenticated, the authentication operation is skipped, which results in a significant improvement in response time.

At operation 618, the components that have not been preloaded are downloaded from the server and presented in the UI.

In one example, the selected web components include static components that are independent of user parameters and dynamic components that are based on one or more user parameters.

In one example, preloading the selected web components includes: the static component is preloaded.

In one example, preloading the selected web components includes: a dynamic component that preloads multiple values of one of the user parameters.

In one example, the preloaded web components are not presented until the second UI is detected to have been selected.

In one example, the method 600 further comprises: a selection to exit the second UI is detected and the web component of the second UI is retained in memory after exiting the second UI.

In one example, a native application includes a browser engine, a native application manager, and a loader manager for preloading web components.

In one example, the native application manager sends instructions to the loader manager to preload the web component.

In one example, selecting the web component further comprises: identifying other UIs that are selectable when accessing the first UI, selecting which of the other UIs to preload based on one or more rules, and preloading web components for the selected UIs.

In one example, the rules include one or more of selectable options available in the first UI, an amount of available space in memory for storing the web component, hardware capabilities of a device presenting the first UI, current CPU utilization of the device, cost of downloading the web component, benefits of preloading the web component, user history when using the native application, and history of multiple users when using the native application.

Another general aspect is a system that includes a memory including instructions and one or more computer processors. The instructions, when executed by the one or more computer processors, cause the one or more computer processors to perform operations comprising: monitoring a first User Interface (UI) presented on a native application; based on the monitoring, determining a second UI that can be selected when the first UI is presented, the second UI based on the web component downloaded from the web server; authenticating a user to access a web server; selecting a web component associated with the second UI for preloading; preloading selected web components; detecting that the second UI has been selected; and causing presentation of the second UI by: presenting the preloaded components on the second UI; and downloading and rendering the web component in the second UI that is not preloaded.

In yet another general aspect, a machine-readable storage medium (e.g., a non-transitory storage medium) includes instructions that, when executed by a machine, cause the machine to perform operations comprising: monitoring a first User Interface (UI) presented on a native application; based on the monitoring, determining a second UI that can be selected when the first UI is presented, the second UI based on the web component downloaded from the web server; authenticating a user to access a web server; selecting a web component associated with the second UI for preloading; preloading selected web components; detecting that the second UI has been selected; and causing presentation of the second UI by: presenting the preloaded components on the second UI; the web component that was not preloaded is downloaded and presented in the second UI.

In view of the above disclosure, various examples are set forth below. It should be noted that one or more features of the examples, whether alone or in combination, are contemplated within the present disclosure.

Fig. 7 is a block diagram illustrating an example of a machine 700 on which one or more example process embodiments described herein may be implemented or controlled, or by the machine 700. In alternative embodiments, machine 700 may operate as a stand-alone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 700 may operate in the capacity of a server machine, a client machine, or both, in server-client network environments. In an example, machine 700 may act as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. Furthermore, while only a single machine 700 is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as by cloud computing, software as a service (SaaS), or other computer cluster configuration.

Examples may include, or may operate through, logic, multiple components, or mechanisms as described herein. Circuitry is a collection of circuits implemented in a tangible entity comprising hardware (e.g., simple circuitry, gates, logic). Circuitry membership may be flexible over time and underlying hardware variability. Circuitry includes members that, when operated, may perform specified operations, either alone or in combination. In an example, the hardware of the circuitry may be invariably designed to perform a particular operation (e.g., hardwired). In an example, the hardware of the circuitry may include variably connected physical components (e.g., execution units, transistors, simple circuits), including computer-readable media physically modified (e.g., magnetically, electrically, through movable placement of unchanged aggregated particles) to encode instructions of a specific operation. Upon connection of the physical components, the basic electrical properties of the hardware constituent parts change (e.g., from an insulator to a conductor, and vice versa). These instructions enable embedded hardware (e.g., execution units or loading mechanisms) to create members of circuitry in the hardware via a variable connection to perform portions of a particular operation when operated upon. Thus, when the device is operating, the computer readable medium can be communicatively coupled to other components of the circuitry. In an example, any physical component may be used in more than one member of more than one circuitry. For example, in operation, an execution unit may be used in a first circuit of a first circuit system at one point in time and reused by a second circuit in the first circuit system or a third circuit in the second circuit system at a different time.

The machine (e.g., computer system) 700 may include a hardware processor 702 (e.g., a Central Processing Unit (CPU), a hardware processor core, or any combination thereof), a Graphics Processing Unit (GPU) 703, a main memory 704, and a static memory 706, some or all of which may communicate with each other via an interconnection link (e.g., bus) 708. Machine 700 may also include a display device 710, an alphanumeric input device 712 (e.g., a keyboard), a User Interface (UI) navigation device 714 (e.g., a mouse). In an example, the display device 710, the alphanumeric input device 712, and the UI navigation device 714 may be a touch screen display. Machine 700 may also include a mass storage device (e.g., a drive unit) 716, a signal generation device 718 (e.g., a speaker), a network interface device 720, and one or more sensors 721, such as a Global Positioning System (GPS) sensor, compass, accelerometer, or other sensor. Machine 700 can include an output controller 728, such as a serial (e.g., universal Serial Bus (USB)), parallel, or other wired or wireless (e.g., infrared (IR), near Field Communication (NFC)) connection to communicate with or control one or more peripheral devices (e.g., printer, card reader).

The mass storage device 716 may include a machine readable medium 722 on which is stored one or more sets of data structures or instructions 724 (e.g., software) embodying or used by any one or more of the techniques or functions described herein. The instructions 724 may also reside, completely or at least partially, within the main memory 704, within the static memory 706, within the hardware processor 702, or within the GPU 703 during execution thereof by the machine 700. One or any combination of the hardware processor 702, the GPU 703, the main memory 704, the static memory 706, or the mass storage device 716 may constitute a machine readable medium.

While the machine-readable medium 722 is shown to be a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 724.

The term "machine-readable medium" can include any medium capable of storing, encoding or carrying instructions 724 for execution by the machine 700 and that cause the machine 700 to perform any one or more of the techniques of the present disclosure or that can store, encode or carry data structures used by or associated with such instructions 724. Non-limiting examples of machine readable media may include solid state memory, optical and magnetic media. In an example, the mass machine readable medium includes a machine readable medium 722 having a plurality of particles with a constant (e.g., stationary) mass. Thus, the mass machine readable medium is not a transitory propagating signal. Specific examples of a mass machine readable medium may include non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disk; CD-ROM and DVD-ROM disks.

The instructions 724 may also be transmitted or received over a communications network 726 via the network interface device 720 using a transmission medium.

Throughout this specification, multiple instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently and nothing requires that the operations be performed in the order illustrated. Structures and functions presented as separate components in the example configuration may be implemented as a combined structure or component. Similarly, structures and functions presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the subject matter herein.

The embodiments illustrated herein are described in sufficient detail to enable those skilled in the art to practice the disclosed teachings. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The detailed description is, therefore, not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

As used herein, the term "or" may be interpreted as an inclusive or exclusive meaning. Further, multiple instances may be provided for a resource, operation, or structure described herein as a single instance. In addition, the boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary and particular operations are illustrated in the context of particular illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of various embodiments of the present disclosure. In general, structures and functions presented as separate resources in an example configuration may be implemented as a combined structure or resource. Similarly, the structures and functions presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within the scope of embodiments of the disclosure as represented by the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims (15)

1. A computer-implemented method, comprising:

monitoring a first User Interface (UI) presented on a native application;

Based on the monitoring, determining a second UI that is selectable when the first UI is presented, the second UI being based on web components downloaded from a web server;

Authenticating a user for accessing the web server;

Selecting a web component associated with the second UI for preloading;

preloading the selected web components;

Detecting that the second UI has been selected; and

Causing presentation of the second UI by:

presenting the preloaded components on the second UI; and

The web component that was not preloaded is downloaded and presented in the second UI.

2. The method of claim 1, wherein the selected web components include static components that are independent of user parameters and dynamic components that are dependent on one or more user parameters.

3. The method of any preceding claim, wherein preloading the selected web components comprises: the static component is preloaded.

4. The method of preceding claim 2, wherein preloading the selected web components comprises: the dynamic component is preloaded for a plurality of values of one of the user parameters.

5. A method according to any preceding claim, wherein the preloaded web components are not presented until the second UI is detected to have been selected.

6. The method of any preceding claim, further comprising:

Detecting a selection to exit the second UI; and

After exiting the second UI, the web component of the second UI is saved in memory.

7. The method of any preceding claim, wherein the native application comprises:

A browser engine;

a native application manager; and

A loader manager for preloading web components.

8. A method according to any preceding claim, wherein the native application manager sends instructions to the loader manager to preload web components.

9. The method of any preceding claim, wherein selecting a web component further comprises:

identifying other UIs that can be selected when accessing the first UI;

Selecting which component of the other UI to preload based on one or more rules; and

The web component is preloaded for the selected UI.

10. The method of any preceding claim, wherein the rules comprise one or more of:

Selectable options available in the first UI;

an amount of space in memory available for storing the web component;

hardware capabilities of the device presenting the first UI;

the current CPU utilization of the device;

the cost of downloading the web component;

The benefit of preloading the web component;

A user history when using the native application; and

History of a plurality of users when using the native application.

11. A system, comprising:

A memory containing instructions; and

One or more computer processors, wherein the instructions, when executed by the one or more computer processors, cause the system to perform operations comprising:

monitoring a first User Interface (UI) presented on a native application;

Based on the monitoring, determining a second UI that is selectable when the first UI is presented, the second UI being based on web components downloaded from a web server;

Authenticating a user for accessing the web server;

Selecting a web component associated with the second UI for preloading;

preloading the selected web components;

Detecting that the second UI has been selected; and

Causing presentation of the second UI by:

presenting the preloaded components on the second UI; and

The web component that was not preloaded is downloaded and presented in the second UI.

12. The system of claim 11, wherein the selected web components include static components that are independent of user parameters and dynamic components that are dependent on one or more user parameters.

13. The system of claim 12, wherein preloading the selected web components comprises: the static component is preloaded.

14. A system comprising means for performing any of the methods according to claims 1-10.

15. At least one machine readable medium comprising instructions that, when executed by a machine, cause the machine to perform any of the methods of claims 1-10.