Farewell ProgressDialog, Long Live ProgressBar
If you’re like me and you have used the Android progress dialog in nearly every part of your app, here’s what you should know: The ProgressDialog
class has been deprecated in API level 26. Now before you jump and start using the @SuppressWarnings("deprecation")
annotation, pause and think about it. What could be the main reason why the Android UX team will consider to make this bold decision? It’s easy to see that they have conducted research and have discovered that the process of blocking the UI (including the back button) with a progress dialog while some long running operation is happening is not optimal for most scenarios. Users can change their minds at any point while using your app, they shouldn’t be forced to wait until the progress dialog is dismissed before they are allowed to use their device.
The
ProgressDialog
class has been deprecated.
I had noticed this shift in design on the Twitter Android mobile app a while ago. There is no progress dialog involved in the process of sending a tweet. They chose optimize the process by displaying the status of the sent tweet in the notifications tray. The user can continue with the app while the tweet is being sent. If it was sent successfully, the notification with the progress bar is dismissed. A tweet that couldn’t be sent will remain on the notification tray allowing the user to retry sending the tweet.
I like their approach, it is straightforward. However, one shoe size doesn’t fit everyone. That is why we have the option of using the progress bar. The progress bar is less obstructive yet it maintains the same standard of displaying feedback to the user. There are different ways a developer could use the progress bar to display feedback for a background task.
You may decide to display a circular progress bar near a view that has triggered that operation. For example if I you have a sign in view, the sign in button should have a progress bar in or near it so that whenever the user taps ‘sign in’ button, the progress bar is revealed. Note that to prevent rage clicks, you can manage the state of the button by disabling it while the progress bar is shown. If the sign in wasn’t successful, feedback is displayed and the button is enabled. This can be done using RxJava & Android’s Observable.
The progress bar is less obstructive yet it maintains the same standard of displaying feedback to the user.
You may choose to have a progress bar at the top of all your screens, this will be implemented easily if you had an activity and multiple fragments. The activity’s layout will contain the progress bar and anytime a fragment needs to signify progress, it will signal that to the activity so that the progress bar can be shown or hidden (this logic can be done with RxJava too).
Please don’t be limited by just these two options, there are other cool alternatives to using the progress dialog as we can see with what Twitter has done in their Android app when sending a tweet. Now that Android has taken the bold step of deprecating the ProgressDialog
class, I am hopeful that UX experts will come up with different methods that will help us achieve the same goal while allowing users to interact with their screen.
As an aside, it could be absolutely necessary that we need to prevent users from interacting with the whole UI when displaying your progress bar. This should do the trick:
getWindow().setFlags(WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE,
WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE);
When you are done you can undo this by clearing the flag:
getWindow().clearFlags(WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE);
Happy refactoring 👍.