Android Instant Apps, Part 2

In our previous article, we went through some basic information about this feature. Now we will take a closer look at what you need to have in mind when developing your application with this feature.

What you need to have in mind throughout the development:

• One app ~ one source code. This does not change whether you are building an Instant App APK’s or an installable application APK.
• Application modularity is necessary. Which means the whole project must be split into modules. Not only something like Rest, DB, and so on — but self-sufficient modules of all structures, screens, etc…. With applications often having their own UX flows, the whole implementation will now need to be modified with new side-entry-points with external access.
• Less frictions — access to the application made easier with fewer clicks. With a faster loading time, the user will be able to find the specific information they are looking for faster and easier than before. For example, your user flow may look like this: open a store, install an app, sign up or log in, click, click and I am ready to order a taxi, or see PS4 specifics, or anything else you can imagine. Now, the Instant Apps module will be downloaded on a hyperlink click, from some page context. This is what the Instant App is trying to focus on. Simplest ever scenario from side-entry-point, you also have to look at the fact that if your application has a restrictive login scenario, it is something which will definitely break down the whole idea of the Instant App feature.
• Installations. Due to the fact part of the application is downloaded and opened, it is possible through Instant Apps to ask the user if they are interested in installing the full version directly through the application.
• WH Dev Manager — a developer tool that lets you locally install and launch Instant Apps from your workstation (without using Google Play). It can also chain your hyperlinks with this Instant App host for testing purposes.

Compared to a Classic Approach

We already know how an Installable APK looks like. However, since the Instant App feature is integrated into a project, your Installable APK will became only a package of finite count of Instant App AAR’s plus one base module AAR, containing every shared resource or class across instant features. This means that your project is still going to be one source code, just split into finite instant feature modules, and shared.

Due to this structure, you can image that creating a new application can be quite fast and easy. According to the partners who worked on it before the public launch, Google argues that the improvement of a project running for several years can take 4–6 weeks. You will just need to change the whole architecture of the project.

The final application is of course faster as a result of it’s nice clean architecture, as well as it’s parts adding less weight. And yes, it does bring some architectural constraints, yet it maintains high quality due to the set structure.

Plus, this technical approach has one great benefit. Every Instant App opened on your phone will be stored in recent apps. Meaning, that at anytime, you can go back and look at it again. In addition, you can manage all of this through the Google settings found directly on your handheld device at your own convenience.

Good to know for architecture

Security and Privacy

Of course, there are some concerns regarding security. The Instant App has limited access to handheld device-spec info, fe. MMI, Mac address, etc. Access is denied automatically, so even as a developer, you cannot get access to this data. However, you will have full access to Android ID and Ad ID. Runtime permissions from Version 6 are also supported so if, as a programmer, you need to use any permission to work with something (eg Location Services), it will be possible. But keep in mind, requesting of permission if is denied in app settings.

Another security restriction is the Instant Apps does not heed to system broadcasts. It may sound a bit constrained, but no Instant App and API allow the code to find out whether it is now an Instant App or an app installed through the app store. Which means that you will need to have one screen for both types of users and modify the UX to focus on both possibilities.

Discoverability

Android App Links are used for chain app and web — meaning intent filters in the application manifest. What’s great about this is the Andoid App Links Assistant in AS 3.+. This is a guide tool that will help you in all three steps — a list of all domains and their screen accesses (eg Inloop.eu/about to access the About screen in our app). This click assistant generates an activity handler for all activities that eventually generate a site link — asset links file — which sets the primary domain, the app ID from which we will join, and the signing certificate with which we will sign an APK. An assistant generates the necessary files, generates everything into the project, and writes where in the server the file should be saved(one will be saved in the app, the other on the server, and they will then be paired later on)

Performance

As previously mentioned, this must be an extremely modular app. All Feature Modules should be flat, free from unnecessary dependencies, sources and resources. The more elements we add to the Instant App, the greater the download time. Of course, all shared sources, dependencies, and resources will be placed into one Base Feature Module. This Base Feature Module will then be used for all Feature Modules. So, it is thus recommended to use minify on the application.

We are aware that up to this point, we have used a few unfamiliar terms. For this reason, we will follow up with another post wherein you will be able to see a granular description of all the parts from the inside out of a potential project.