Hello Stephen,
based on the provided information it is difficult to deduce what is the cause of the observer behavior in your concrete application case. I would therefore try to list the aspects which should be taken account in this case:
1. When using SwitchToDialog() to switch between dialog A and B, both dialogs will continue existing during the transition. This is because the old dialog A may perform a dismiss animation while dialog B performs a present animation. Once the transition is finished, dialog A is ready to be reclaimed during next garbage collection.
2. A dialog (or more generally speaking an object) is reclaimed during garbage collection only when it is not in use. An object is considered to be used when there is at least one reference to the object permitting an access to it. For example, when dialog B stores dialog A in some variable and dialog B itself is actually used, then dialog A remains accessible too. It can be accessed from dialog B and dialog B is still used.
3. Garbage collection usually is triggered after each screen update. This however can differ from target to target. In some cases, the developer may decide to trigger the garbage collection less frequently to save CPU power. In particular, when testing the application in Prototyper, the garbage collection can be delayed up to 10 seconds. This means that some objects continue to exist for this time even though they are garbage. See also Force the Garbage Collector to run.
How to deal with this peculiarity?
* If you observe the behavior during Prototyping only, then I would say you can ignore it. In the target the garbage collection is performed much more frequently.
* If you observe the behavior at the runtime in the target, possibly dialog A remains referred from some other object. In the past we have observed similar behavior when the method SwitchToDialog() or PresentDialog() was used incorrectly. When invoking SwitchToDialog() it is important to do it in context of the component which acts as owner of the actual dialog A.
Typical error case: being in dialog A you want to switch to dialog B. For this purpose you invoke SwitchToDialog( dialogB, ... ) in some method implemented in dialog A. This will have as effect that dialog B is presented in context of dialog A. Dialog A will therefore remain alive.
If this is your error case, then try following invocation Owner.SwitchToDialog( dialogB, ... ). See also Take a closer look at the Dialog functionality.
* If the dialog A is reclaimed correctly by garbage collection but it is essential to avoid that eventual notifications (or other events) are processed while dialog A is still alive and performing some dismiss animations, etc., you have to add following if-condition to the code triggered by the event/notification. This condition will detect whether the component is still an dialog or it has been dismissed (or is performing the dismiss animation). See also Identify the active Dialogs and avoid race conditions.
if ( !IsDialog())
return;
/* handle the notification, event, etc. */
* If your target system has not enough resources for both dialogs A and B to coexist, then you can't use SwitchToDialog(). In such case first dismiss dialog A, wait the next garbage collection and then present dialog B. Since the dismiss and present operations are themselves delayed the methods like DismissDialog() provide a possibility to pass slot method to trigger when the operation is finished. In this slot method you could start preparing the presentation of the other dialog. See also Handle the completion of a Dialog transition. Important detail: in the slot method use idlesignal to trigger another slot method. The method referred in idlesignal is executed after the next screen update which is after the garbage collection - usually.
I hope it helps you further.
best regards
Paul Banach
