We’re excited today to be releasing InstantSearch Android,  a library of Views and helpers to help you build the best instant search experience on Android. It is built on top of Algolia’s Android API Client to give Android developers a powerful solution to quickly build the right search experience to delight their users.

Before we dive into how InstantSearch works, I’d like to talk about why we invested so heavily in the Android developer ecosystem.

Implementing Search on Android today: not for the faint of heart

Creating great search for your Android app is hard. Search is a complex problem in general, but, for an Android developer, adding search to their application comes with unique challenges: some are common to all mobile app developers, but the Android platform brings a few hurdles of its own.

Limited Resources

The first source of difficulty comes from the constrained resources of mobile devices themselves. Because many apps are fighting for a limited amount of RAM, you won’t be able to keep all your data in memory. You cannot afford to put thousands of products in your user’s RAM if only a few are relevant to them, and you can’t store them in the device’s storage either, as it suffers from the same issue: tens if not hundreds of apps are squeezed in the small hard drive of a mobile device. This limitation hinders your ability to store data on your user’s device, which makes it more impractical to build a local search solution.

Even if you don’t have a large dataset, you won’t be able to implement all the advanced features that a powerful search needs (typo-tolerance, synonyms handling, …). With the CPU constraints of a mobile platform, most complex processing logics cannot be implemented locally if you build from scratch – at least not easily or quickly.

Network Stability

The previous performance limitations are easily removed if you use a hosted search engine, as you can offload space and computational resources to your provider.
However, mobile devices are used in a specific context: your users move from a network to another, connect and disconnect to Wi-Fi networks, lose connectivity when passing under a bridge. This mobility context brings two difficulties to mobile app developers.

When the user moves around or simply has bad connectivity, their device suffers long latency. The network requests can suddenly take a very long time to resolve.
Moreover, even when the connectivity is good, the network bandwidth can still be pretty small. Although a request can be sent quickly, the response’s payload can take a long time to load.

These two network effects will have a negative impact on your app’s UX if you don’t consider them when developing.

Real Estate & Screen Constraints

The main challenge of designing great mobile apps comes from the available screen space of the devices. At best, a tablet will offer around 10 inches of screen space for your apps, but most mobile devices will only have a few inches of screen space (on average 4.5”.)

This small space for your application’s interface will limit what you can display on the screen at any given time, which makes developing complex interfaces like a search UI even harder on mobile.

It is even harder if you consider the “Fat Finger Effect”: because it is hard to tap precisely with a touch-screen, small buttons are hard to action and nearby commands are easily mistakenly clicked. This brings another layer of complexity when designing your interface.

Android developers also have to address the platform fragmentation. You want your app to display nicely on a variety of devices, each with different dimensions and resolution. It complicates further the testing of your interface and the development of new UI components.

Lack of framework for search interfaces on Android

One of the more peculiar parts of building on top of the Android platform is that there are no building blocks for creating beautiful search experiences on Android.

The Search Overview Guide will tell you where you should perform the search, but not how:

The process of storing and searching your data is unique to your application. You can store and search your data in many ways, but this guide does not show you how to store your data and search it.

The only practical solution that this guide tips at is using a full-text search algorithm if your data is stored in a local SQLite database. But what if your data is not stored like this, or if you want more powerful search capabilities like typo-tolerance, prefix search, or query processing?

Developing a great search interface for an Android application is therefore difficult. You will face harsh performance and design constraints, user expectations of advanced functionality from your search engine, and your design needs to work across the various screen sizes and network conditions that encompass today’s mobile ecosystem.

 

Algolia: Improving the Android developer experience

At Algolia, we seek to provide every developer with the best tool for their job.
In 2015 we brought such a tool to web developers with instantsearch.js: a widget-based library that abstracts the complexity of building a search interface and powering it with Algolia.

Instantsearch.js fulfilled a real need, as the community reaction has quickly shown: today the project is used by 1530 projects and has almost 1,500 stars on GitHub!

This works great for web developers, but Android developers need their own native solution.

Introducing InstantSearch Android

Let’s dive in and see what InstantSearch Android does for developers.

With the Algolia engine under the hood, your app can leverage powerful features like typo-tolerance or geosearch, without bearing the CPU and storage costs that would come with an embedded search engine. We’ve also got you covered for RAM consumption: InstantSearch Android has been optimized so your app can run seamlessly on any Android device, using various memory optimization techniques like View recycling or LRU Caches when relevant. Your users will be able to enjoy your app’s great UX without sacrificing their precious RAM!

Prepared for adverse Network

With the hundreds of mobile applications using Algolia, we have had our fair share of network issues and limitations to work with. We leveraged this experience while developing InstantSearch Android, which includes the most useful tools for handling bad latency or low bandwidth easily: out-of-the-box progress indicators to let your user know that you did process their query, customizable caches to avoid sending queries when it is useless, and parameters to ensure the server’s response only contains the data that you need.

Designed for Mobile

We’ve distilled down our experience building search into mobile apps to bring you optimized components for building your own search experience – if you’d like to learn more about Mobile Search Patterns, you can check out this talk we gave earlier this year at Mobile World Congress.

We released InstantSearch Android with a set of Widgets: UI components to help you build faster your search interface. A widget is based on an Android View, made aware of the surrounding search interface and configured to follow the best practices of mobile search.

Each widget follows the recommendations that are common to all mobile apps so you don’t lose time, while leaving you the room for customizing its look and feel for your users’ exact needs.

You can enable autofocus on a SearchBox in one line, or make it so that scrolling the Hits can automatically close the keyboard: we want every pattern that is useful to app developers to be a no-brainer with InstantSearch Android, so you don’t waste time on mundane things and can dedicate your time to what makes your app awesome.

This toolbox is now open-sourced and available on GitHub: you can start using it today to build great search interfaces in no time!

To give you an idea of what you will be able to build with InstantSearch Android, we created two example apps based on some well-known search interfaces : the Media app will show you how to build a video search interface while the Ecommerce app shows a more  complex e-commerce search interface.