Previously Google advised against using a splash screen for your application. Nowadays it’s increasingly common to need to do some warm-up ‘work’. It may be a number of things, be it network pre-fetching, font initialisation, or cache cleaning. The first of Google’s applications I noticed doing this was YouTube. iOS is another story. Every app is required to have a splash screen while your application launches. Their ecosystem is used to it. Companies there have experimented with splash screens which show a skeleton of the eventual layout.
This is all in the name of responsiveness. Telling the user you’re doing something that prevents them from using the app for a short time. For example, with UIs becoming increasingly richer you’re ever more likely to need to load your fonts before rendering the view.
Occasionally your application launch-task may be short enough to not warrant displaying a splash screen, even for a brief time. The initial view a user sees is a white background while your splash screen loads. Combine this with a transition to another screen, with an animation, and you see a ‘jolt’. This ‘jolt’ may be what your users first see upon launching your app.
You can provide the illusion of a faster launch differently through the use of an invisible activity. From here you could determine the need to display a splash screen, or route the user to the desired screen. With techniques like reactive programming it’s possible to implement a minimum display time of a splash screen, which would allow the user to take it in. But this artificial lengthening equates to wasting the user’s time. Here we’re after the minimum delay, and fastest time to using the app.
Using an example of an application with a login screen. The user would likely only come across this once; this is your chance to capture their attention and draw them in to engage with your application. Needing to sign up adds friction after all, so minimising this friction is paramount.
If you’d chosen to go without a splash screen you could likely assume that the logged in Activity would be most common. The temptation here would be to launch with that Activity, then check your condition for whether a user is logged in before displaying the contents of the login screen. But this would result in the ‘jolt’. The reverse of this would be a smooth first launch. But sequential launches after login begin with the jolt. Just how these animations and transition appear to the user is largely subject to the launcher application and operating system.
Result
How it’s done
Firstly the launcher activity AndroidManifest entry needs some adjustment. By applying the right theme here we can have an activity launch full screen, but be invisible to the user, not taking up valuable MainThread time drawing a needless screen.
Notes and motivation
I’ve battled time and time again with OEM versions of Android and their insistence on forcing the activity transition animations they think is best. This often resulted in a weird blip at the start of an animation before mine kicked in, if my animation kicked in at all. Sometimes it appeared to be a bug with a version of Android, others it’s definitely been as a result of the UI choices of a certain highly popular platform, which Android developers seem united in about.
This is predominantly an opinion piece. Some users may love splash screens. But having used an Android device for many years users may find it frustrating. After all it’s slowing them down from performing the action they launched your app to do. There are times when a splash screen really is needed, but where possible I’d ideally avoid using them. The illustrated example is just one way of doing this.
I’ve seen many apps flash a splash screen and animate to the next activity. It may only be a total of 250ms added, but this adds up as the usage increases. This is also barely enough time to take in what is on the screen. That lovingly designed screen may be a bit short-lived. Occasionally a design for this screen is also quite resource-heavy and in itself takes time to initialise.
This was an interesting challenge. I was keen to see just what an invisible Activity actually looked like to satisfy my curiosity. I’ll experiment with this more, perhaps with some timings and performance metrics in the future if it’s suitable.
