What is app shell Android?

Application shell (or app shell) architecture in an Android is a way to create a progressive web app that loads on your users’ screens reliably and instantly as you would see in a native application.

The app “Shell” requires a minimum of HTML, CSS, and JavaScript to power the user interface and ensures instant, reliable, and good performance for users who repeat when cached offline. This means that the application shell does not load from the network every time a user visits. Only the required content from the network is required.

For single-page applications with JavaScript-heavy architectures, an application shell is a go-to approach. This approach is based on aggressively caching the shell (using a service worker) to execute the application. Next, dynamic content is loaded onto each page using JavaScript. The app shell can be used to quickly get some initial HTML on the screen without a network.

In other words, the app shell is similar to the bundle of code that is published in the App Store when you create a native app. It’s the framework for your UI and the main components needed to keep your app online, but it probably does not contain data.

Table of Contents

When to use the app shell model?

Building a PWA does not mean starting from scratch. If you are developing a modern single-page app, whether you call the app shell or not, you are probably already using the app shell. The details may vary slightly depending on the libraries or framework you are using, but the conceptual framework is agnostic.

Application shell architecture is relatively unchanged with navigation but most meaningful for content-changing apps and sites. Many modern JavaScript frameworks and libraries already promote the separation of your application logic by its content, making this architecture very simple to implement. For a specific class of websites that contain only static content, you can still follow the same model, but the site is 100% app shell.

To see how Google Apps Shell Architecture was created, check out the Google I/O 2016 Building Progressive Web Apps. This real-world app started with SPA to create PWA that can pre-cache content using a service provider, dynamically load new pages, transition between views seamlessly, and reuse content after loading.

Benefits

Advantages of App Shell Android Architecture with Service Worker:

Reliable performance that is consistently fast. Often seizures occur very quickly. Static assets and UI (such as HTML, JavaScript, images, and CSS) are cached on the first visit so that they can be loaded immediately after repeated visits. Content may be cached at first but is usually loaded when needed.

Local conversation. By adopting the App Shell model, you can create experiences with instant, native-application-like navigation and interaction complete with offline support.

Economic use of data. Design for minimal data usage and be careful what you cache because browsers will download more data that is absolutely necessary by listing files that are not needed (for example large images not shown on each page). Although data is very cheap in Western countries, it is not in emerging markets where connectivity is expensive and data is expensive.

Requirements

The app shell should ideally be:

Load faster
Use as little data as possible
Access static assets from the local cache
Separate content from navigation
Retrieve and display page-specific content (HTML, JSON, etc.)
Alternatively, cache dynamic content
The app shell keeps your UI localized and pulls content dynamically through the APIs but does
not sacrifice the linkability and discovery of the web. The next time a user accesses your app, the
latest version will be displayed automatically. There is no need to download new versions before
using them.

Creating your App Shell

Build your app to clearly distinguish between page shell and dynamic content. Generally, your app should load as simple a shell as possible, but it should have enough meaningful page content with the initial download. Find the right balance between the speed of each of your data sources and the freshness of your data.

Jake Archibald’s offline Wikipedia application is a good example of PWA using the app shell model. It loads immediately during repeated visits but retrieves content dynamically using JS. This content is cached offline for future visits.

Example HTML for App Shell

This example distinguishes the core application infrastructure and UI from the data. It is important to keep the initial load as simple as possible so that the layout of the page is visible as soon as you open the web app. Some of them come from your application’s index file (inline dome, style) and the rest are loaded from external scripts and style sheets.

Using the Service Worker caches all UIs and infrastructure locally so that on subsequent loads, only new or modified data is retrieved rather than loading everything.

Your index.html file in your working directory should look like the following code. This is a subset of the actual content and is not a complete index file. Let’s see what’s in it.

HTML and CSS for the “skeleton” of your user interface with navigation and content placeholders.
Uses external JavaScript file (app.js) to store navigation and UI logic as well as storage mechanisms such as code and locally IndexedDB to display retrieved posts from the server.
Web App Manifest and Service Worker Loader to enable offline capabilities.

Final thoughts

The app shell that uses the service worker is a powerful model for offline caching, but it does provide significant performance successes in the form of instant reloading of your PWAs. You can cache your application shell so that it works offline and replenishes its contents using JavaScript.

Over and over again, it allows you to get meaningful pixels on the screen without the network, no matter where your content ultimately comes from.