Start Before You Finish
Let’s take “a trip down Memory Lane” and talk a bit about API design, using as an example a common thing in Android: starting and finishing activities.
Particularly in activity-centric UI architectures, there may be cases where we want to show an activity, then switch to a different activity, where the first activity is no longer needed in the back stack. A common example of this is the splash screen:
If the user is in Main and presses BACK, we do not want the user to wind up in Splash — instead, they should exit the app and return to the launcher (or wherever they started from).
So, in Splash, we could call
startActivity() to start Main, plus call
to remove Splash from the task.
However, do we:
- Do either of those, as the order of calls does not matter?
Vitaliy Khudenko decided to research this topic,
and he concluded that the right answer is to call
In the scenario that I just described, where Splash is the only
one in the task, if we call
startActivity(), Android will
FLAG_ACTIVITY_NEW_TASK automatically to the
Intent used in the
call. If we call
startActivity() first, Android does not add this flag.
And, it is possible that this flag may have an impact on the behavior of the
activity being started.
The Knowledge Gap
This behavior is undocumented, as far as Vitaliy and I can tell. Vitaliy filed an issue to try to get this covered.
From an API design standpoint, though, could we do better?
Clearly, we need to be able to call
without always finishing. Similarly, we will have cases where we need to call
without starting another activity. As a result, we need the two existing primitive methods.
However, in cases where you have a pair of simple calls, where there is a preferred way for them to be used in combination, consider adding something to the API that helps developers “do the right thing”. In this case, that could be:
A flag on
startActivity()to indicate if the current activity should then finish
startActivityAndFinish()method that does both actions in the typical order
ActivityStartContinuation, on which there is a
thenFinish()function, so we can write
And so on
Now, the Android SDK is vast, and adding these sorts of things makes it even more vast (vaster?). In that case, going the documentation route may be preferable. And of course there is nothing stopping you from adding convenience methods and documenting the reason for them.
But, ideally, your SDK calls out scenarios like this and helps developers easily do what most developers would want, with the flexibility of supporting other, less-common options.
Many thanks to Vitaliy for pointing out the problem!
Interested in learning Kotlin? Check out the Klassbook for Kotlin language lessons that you can run right in your browser!