Don't use ProgressDialogs

[SUPERCILEX]

@samtstern I started compiling some of my projects for O and I noticed that ProgressDialog is deprecated. Ouch. It makes sense because having a whole dialog just for loading is a bit jarring and I can see how the UX would be improved by having loading spinners integrated directly into the views. However, this is going to be a very painful transition for us since we use the ProgressDialog for everything async. 😕 Could you get some designers to take a look at our loading spinners and figure out where we should put them? I was thinking directly into the button the user presses, but I have no clue. 😄

[samtstern]

Yeah I've noticed that too ... ProgressDialog has one nice property in that it blocks further interaction while the async action happens. But I agree, it's a big hammer for a small nail.

We can put some more thought into this after 2.0

[SUPERCILEX]

@samtstern Yeah, we'll have to setEnabled(false) all the views and things will probably get messy really fast, but it has to get done at some point, preferably before the final release of O to AOSP. Do you think that's a reasonable target?

[CarsonBradshaw]

I think it'd be good practice to get rid of the ProgressDialogs as well. The dialog that fires immediately after calling AuthUI.getInstance().createSignInIntentBuilder().build() was the primary factor in deciding not to use Auth-UI for me personally. Because this intent must be fired with startActivityForResult, the firing activity cannot call finish() on itself immediately as it must wait for a result. This alone causes enough of a "hitch" in the interaction and adding a dialog which appears for a split second then disappears does not make that interaction any more seamless.

[samtstern]

Special note about #1052, which may be a sub-case we can fix sooner.

[samtstern]

This has been fixed and released in 4.0.0