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.
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.
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.
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.
Advantages of App Shell Android Architecture with Service Worker:
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.
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.
Web App Manifest and Service Worker Loader to enable offline capabilities.
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.