About memory recycling and dialog switch

Question

Hi， EW team:

    The first confusing question to me is that by calling RemoveAll(), the memory used by removed dialogs is not recycled.

  To overcome the problem above, I limit the dialog switch operations to PresentDialog DismissDialog and SwitchToDialog. Then another problem comes out.

   For example,  I have 3 dialogs to switch, A1 A2 and B1. B1 has A1 as its background, so I use PresentDialog and DismissDialog to switch between them. A1 and A2 are independent, so SwitchToDialog is used. When I need to switch from B1 to A2, in order to maintain a manageable dialog stack，should I call DismissDialog first to A1 and then SwitchToDialog to A2? Is there any simpler way to do it? I tried RemoveAll first and then PresentDialog，but memory was not recycled.

     All of them are dynamically created and the 3 APIs are called in application context.

   Thank you.

 

Best regards.

Stephen.

Answer 1

Hello Stephen,

RemoveAll() is a lower level method to low-level control the view tree. Dialogs implement a much higher level of functionality including transition animations and state management. Simply removing a dialog from its owner is thus not sufficient. In contrast, it will probably result in a runtime error when the dialog is dismissed.

To overcome the problem above, I limit the dialog switch operations to PresentDialog DismissDialog and SwitchToDialog. Then another problem comes out.

This is the correct approach. There is no recommendation to use RemoveAll() in context of dialogs.

B1 has A1 as its background, so I use PresentDialog and DismissDialog to switch between them. A1 and A2 are independent, so SwitchToDialog is used. When I need to switch from B1 to A2, in order to maintain a manageable dialog stack，should I call DismissDialog first to A1 and then SwitchToDialog to A2?

I don't really understand this description. I try to interpret it:

1. you present dialog B1 using PresentDialog( B1, ... ) in context of the Application component.

2. Within dialog B1 you present the dialog A1. A1 is thus subordinated to B1. You do this by using PresentDialog( A1, ... ) in context of B1.

3. Now you want to switch from B1 to A2. That means B1 and its subordinated A1 should be replaced by A2.

If this is the case, you simply invoke SwitchToDialog( A2, ... ) in context of the Application component. This will dismiss B1 and present A2. Since A1 is existing in context of B1, it will disappear too. If there is no other reference to B1 nor A1, both objects are released during the next garbage collection.

If my interpretation was wrong, please describe the situation more in detail.

Best regards

Paul Banach

Comments

Hi, Paul:

     My design is as this:

   1.A1 is present  in context of Root component.

   2.B1 is presented over A1 by Root component with PresentDialog.

   3. Then I'd like to switch A1 B1 to A2.

   With my design, I have to manage A1 B1 in context of Root to avoid memory leak. Now I see how I should do it.

   Thank you very much.

 

Best regards.

Stephen.

---

Hi Stephen,

in such you will need to dismiss B1 before you switch to A2. Otherwise A2 will replace B1 and overlap A1. For this purpose you invoke DismissDialog( B1, ... ) followed by SwitchToDialog( A2, ... ). In such case the system will schedule the dismiss operation to be followed by the switch to dialog operation.

If your dialogs are not using any transition animations, the dialog transition will occur almost instantly. If you are using animations, you can set the parameter named aCombine of SwitchToDialog() to the value true. This will have the effect of the switch to dialog transition to be performed simultaneously with the preceding dismiss dialog. See also Perform several Dialog transitions simultaneously.

Best regards

Paul

---

Hi, Paul:

     Yes, I did as you suggested as invoke DismissDialog( B1, ... ) followed by SwitchToDialog( A2, ... ), But these 2 transitions will need more time. Now I have B1 presented and managed by A1, and have Application switch from A1 to A2 directly, and B1 is released with A1.  This is what your first answer suggested.

 

    Thank you.

Best regards.

Stephen

---

Hi, Paul:

    I found a strange thing just now. After A1 presented B1 with PresentDialog, B1 covered the whole screen. But buttons in A1 were still pressable in simulation, which disobeyed the rule that presented dialog will capture all user input. I do not know why.

 

Best regards.

Stephen

---

Hello Stephen,

please see the section Take a closer look at the Dialog functionality. It explains a peculiarity of how event handling is performed when component A embeds a dialog B. Summarized, the component A continues handling events. This is a desired behavior to allow superior components to switch/manage sub-ordinated dialogs.

To avoid this behavior the contents of the superior component need to be presented also as a separate dialog inside it.

I your case, as far as I understood it, it could be the simplest to present A1 and B1 in context of the Application component. When switching to A2, perform DismissDialog( B1, ... ) and then SwitchToDialog( A2, ..., true ). 

I hope it helps you further.

Best regards

Paul

---

Hi, Paul:

     I change back to the way A1 and B1 are both managed by application.

 

Best regards.

Stephen.