Introduction
- Instant apps is a new feature from Google on Android Platform.
- Native Android apps, without the installation.
- Access From Anywhere.
- Works on the Latest Android Devices.
- Slim down your application
- Support deep linking and App links.
Google recently released Instant Apps to developers as part of an effort to help kickoff the next big enhancement to the native app experience in Android. Instant Apps aim to help bring users into the best native app experience as quickly as possible by downloading only parts of an application when they need them. This makes it fast and easy to engage users with great mobile app experiences, even though they do not have the application installed on their devices.
Access From Anywhere:
Instant Apps are triggered by URL intents, meaning that they can be started from anywhere including, search results, social media shares, messages, beacons, NFC and other applications or even other Instant Apps — without needing to install your app first.
URLs mapped to your app features must belong to domains you own. Google verifies its links with a DAL(Digital Assets Link) file, that must be stored in your website, so as to avoid apps to be connected to domains they don’t own in the first place.
Works on the Latest Android Devices:
Android Instant Apps supports the latest Android devices from Android 5.0 (API level 21) through Android 8.0 (API level 26).
Slim down your application:
With Instant Apps, having a lean app is more important than ever before.
Each feature of your Instant App must be under 4MB in size.
reconsidering what your success factors are as well as how you track them; removing unused code; optimizing resources; and properly proguarding your modules can really help slim down your application.
Modularize and refactor your application:
Instant Apps requires developers to split their builds into multiple modules called features. Each feature represents a part of the application that can be downloaded on demand.
Feature modules - are modules that applies the new com.android.feature Gradle plugin. They are simply library projects, producing an aar when consumed by other modules. It’s worth noting that they do not have application IDs because they are just library projects.
gradle:
apply plugin: 'com.android.feature'
android {
...
}
dependencies {
implementation project(':base')
...
}
Manifest: The feature module’s manifest is also worth noting because since it is functionally only a part of the full app, its manifest will be merged with others when the project is assembled. So feature module manifests should contain things like Activities that are contained in the module. Each feature manifest should also contain a unique package name for the module.
Base feature module - Every project that uses feature modules must have exactly one base module and every feature module must depend on the base module.
The base feature module can be thought of as the root of your project. It contains the shared code and resources to be used by other modules. The base feature differentiates itself from other features with the property baseFeature set to true.
apply plugin: "com.android.feature"
android {
baseFeature true
...
}
dependencies {
feature project(“:feature”)
application project(“:app”)
...
}
While not mandatory, it’s recommended that your base feature manifest contain an activity tag that references an activity that implements a default-url metadata.
This tells Android which activity to launch in the event that your Instant App is not opened from a deep link but somewhere like a launcher instead.
APK module - This is the normal build module that we are all familiar with. Now it’s setup to consume the base and feature modules in order to output an apk to be installed on user devices. Since it aims to output an installable artifact this module does have an application ID.
apply plugin: 'com.android.application'
android {
defaultConfig {
applicationId "com.example.appname.apk"
...
}
...
}
dependencies {
implementation project(":my-base-feature")
implementation project(":my-feature")
}
The application manifest here is the result of merging all of the other manifests that it inherits from the other feature modules. As a result its manifest is pretty sparse.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.appname.apk">
</manifest>
Instant App module - implements the com.android.instant plugin. The consume feature modules and produce a split APK zip containing all of the features that will go into the Instant App. It’s pretty much an empty shell of a project without a manifest that only implements other features feature modules in the project.
Here’s a sample of an Instant App module build script.
apply plugin: "com.android.instantapp"
dependencies {
implementation project(":my-base-feature")
implementation project(":my-feature")
}
Conclusion:
Instant Apps unlock a whole new range of user experiences that Android developers can explore in their apps. Building on this new way of interacting, it’s possible to improve the experience of existing users, as well as expand your reach, attracting new ones. What’s more, complete new use cases can be created. However, it’s important to consider the specifics and goals of each app/business, and how an Instant App can be helpful indeed. Time and effort required to make the necessary changes to the code structure should also be taken into account. Next blog will help you to build your first Instant app.
Thank You.
References:
Comments
Post a Comment