ursus
10/25/2018, 4:55 PMrusshwolf
10/25/2018, 9:09 PMandroid.app.Fragment
in favor of the support library fragment. Has nothing to do with usage. They're actually encouraging people to use Fragments more and migrate toward a single-activity architecture.ursus
10/25/2018, 9:21 PMrusshwolf
10/25/2018, 9:22 PMgildor
10/26/2018, 2:16 AMProgressDialog is a modal dialog, which prevents the user from interacting with the app. Instead of using this class, you should use a progress indicator like ProgressBar, which can be embedded in your app's UI. Alternatively, you can use a notification to inform the user of the task's progress.
Exactly what I proposed, just use progress as part of your UI, do not use any dialogs for progressursus
10/26/2018, 6:26 AMgildor
10/26/2018, 6:44 AMImho dialogs have their placeDIalogs yes, but not loaders in dialogs
By that logic you shouldnt have modals everNo, modals make sense if you need immediate interaction with user. Loader doens’t have any actions, user can do nothing with it
put modal like views in hieratchy which is sillyExactly. In most cases loader should be showed in context of action, like loader instead button, pull-to-refresh, loader on place of some view etc. Loading overlays sometimes can be useful, it’s true but it’s minority of cases and usually view based solution still looks better. Also, one more common case that view-based overlay can block only Activity content and do not bblock toolbar and allow user to escape from screen, dialogs block ui and even if you allow to cancel it using “back button” it’s not so good UX And don’t forget about huge pain to control loader dialogs. You need some fields to keep current dialog to cancel it or check is it visible or not. Control view is so much simple. Also progress based on view works much better with state save/restore. So I see why progress dialog deprecated and it encourage developers to provide better UI and UX for their applications
ursus
10/26/2018, 2:48 PM