Hello Aleksey,
I can be sure that after calling DismissDialog() the first screen object will not be on the screens stack and will then be garbage collected, right?
Let me explain the functionality more in detail.
DismissDialog() limits to schedule the affected dialog to be hidden and removed from the view tree (eventually with an animation if such has been configured in the parameters of PresentDialog() or DismissDialog()). The scheduled operation is performed with a short delay. That means, when the invocation of DismissDialog() returns, the object is still existing.
The object disposal is performed during the next garbage collection. In target system the garbage collection is triggered at the end of each screen update. In other words, the dismissed dialog will occupy RAM until the current screen update has been finished. Or if the operation is performed with animation, after the screen update of the last animation phase is done.
The disposal, however, can be suppressed if there is any variable in your GUI still referring the object of the dialog, or referring one of objects embedded inside it. Through such 'strong' reference the object in question remains accessible and garbage collection can't delete it.
If you worry about the RAM usage, you can track it at the prototyping time via the Memory (RAM usage window. This gives you a rough estimation. For more precise results you can monitor the memory usage in target system. Both approaches are very useful if you have the impression of increasing memory consumption due to e.g. growing chains of objects.
Best regards
Paul