Recently we have been working with Google to create an Instant App for our listings experience, so with the SDK being made publicly available at I/O this week we thought it would be a great time to share our experience.
So what are Instant Apps? Instant Apps allow Android users to run apps instantly in response to tapping a URL without having to install the app. An Instant App contains only the functionality required for the feature that the user is interested in.
The following screen shows an example Instant App experience for users who do not have our realestate.com.au app installed when they tap a URL for an on-market property:
Restrictions on Instant Apps
There are a number of restrictions for Instant Apps when compared to installed apps, a notable one being a 4MB APK size limit per Instant App feature. One of the reasons for this is to ensure that the user experience remains snappy. In practice this makes opening an Instant App comparable to the loading time of a typical web page. In our installed app, which is 8MB, a significant portion of our APK size is embedded assets such as images – but given the scope of our feature, these were not required. Once we packaged only the code required for our feature, it was not difficult to manage the APK size limitation.
Another restriction in Instant Apps is on the use of Content Providers. We use these liberally throughout our installed app to expose data stored in a local database. Fortunately, this access is abstracted behind an interface with consumers simply talking to “something that provides the data that I need”. This made it easy enough to switch out the implementation with something supported within the Instant Apps environment. Specifically, for the listings screen we simply needed to retrieve and cache data for one specific listing, hence using Shared Preferences was sufficient.
An Instant App can be comprised of multiple features and to avoid duplication all code should be shared with the installed app. To support this, a code base needs to be architected to have shared code in a common module with feature-specific code in separate feature modules.
We didn’t have this type of modular feature separation in our code base previously which made it difficult to isolate just the code required for the property listing section of the app. We did, however, have a significant amount of business logic in a separate “plain ol’ Java” module. Given the time constraints we decided that the best approach would be to re-use that which was already re-usable – the business logic module – and extract the code specific to the property listing screen into a new Instant App specific module.
Whilst this resulted in us essentially forking a part of the code base it did allow us to produce an experience very quickly, and focus on integrating the Instant Apps build and deployment process into our CI to be ready for I/O.
In an ideal world the installed application would essentially be an aggregation of the Instant App feature modules with a sprinkling of functionality only available to installed apps – re-engagement notifications, for example. This is the world we’re moving towards where we have full re-use of code across both the Instant App and installed experiences. So a side effect of supporting Instant Apps is an improvement in the modularity of the code base, where coupling between features becomes an explicit consideration and enables reuse of components across other projects.
We’re really happy with the experience our Instant App provides to our users. It gives them the best possible native experience for the use case without the friction of app installation.
Technically the constraints on Instant Apps encourage what we consider good architectural patterns. So whilst it might be a little bit of effort up front to refactor an existing application to the required multi-module structure, the end result is an application composed of cohesive, independent modules.
We’re excited about the future of Android Instant Apps and the new ways they allow users to consume our app.