md-dialog: One should be able to open multiple "full screen" dialogs

[asans]

Feature Enhancement Request

Considering that Material Design specs allows the use of multiple dialogs to be open on top of one another, I believe this should really be supported. One use for this is when one wants to open up a full screen dialog and still show some dialog alerts or confirmations. The other use is the way one can open one full screen dialog on top of another on top of another. Canceling/closing the dialog will take you back to the previous one without having to reload the view, which will force one to lose context and lose track of where we were before.

A great example would be the list-to-detail view. You load a list of items and as you scroll down and see one you like to view more details of (ie. an order), you click on it to open up a full screen dialog to view the details of the order. After you view it, you will want to go back to where you were before and continue. This is also the case with reading news stories or even cards. If we had to go back by refreshing, we'd have to first load all the entries up to that point and then scroll to where we were. This is far less efficient than just allowing multiple dialog screens.

The above scenarios are frequently encountered and well implemented in the android UI (see settings and even some of the android apps like Facebook or Google+).

[dgavigan]

this sounds like two request.

1. support fullscreen dialog, which there is already an issue for adding fullscreen option for mobile to $mdDialog #2148
2. support layering dialogs? not 100% sure on whats being described.

[asans]

#2148 covers the full screen dialogs, which is used to describe the scenario here. Since my example is a bit confusing, let me copy verbatim the text from Material Design Specs about Full Screen Dialogs.

The bits that I want to emphasize is in bold below:

---

Usage

Full-screen dialogs group complex tasks that require explicit action, such as save or create, before changes are committed or discarded, as in a calendar entry.

Full-screen dialogs enable complex layouts, minimize the appearance of stacked sheets of material (dialogs above dialogs) and increase the app’s perceived z-depth. They enable individual tasks to launch simple menus or simple dialogs as part of the complex operation.

Consider using a full-screen dialog when the content or process meets any of the following criteria:

The dialog includes components like pickers or form fields requiring an input method editor (IME), such as a keyboard.
When changes are not saved in real time
When there is no draft capability in the app
When performing batch operations or queuing changes prior to submitting them
No modifications and selections made in the full-screen dialog are saved until “Save” is touched. Touching the “X” will discard all changes and exit the dialog.

---

So better to say that it's "dialog above dialogs" should be a supported feature in the future instead of just allowing only one single dialog to always be open at any one time.

[dgavigan]

Gotcha. Sounds useful indeed.

So, this looks like to be coming in v0.10 as mentioned in #698 by @ThomasBurleson

it [fullscreen/stacked] is a new feature that we will try to address in 0.10.

[naomiblack]

We agree this needs discussion, but unfortunately, we will not be able to add it before beta.

[prasannapattam]

Is there a timelines when this will be implemented (1.0-beta1)