Understanding ADF Task Flow Page Flow Scope Lifetime

I would say its a bit confusing to understand - how long objects stored in Page Flow Scope really reside in memory. This is a reason I implemented small sample application and did a test. Summary for the results (see detailed description below):

1. Every ADF task flow instance is granted with its own Page Flow Scope

2. Page Flow Scope is not destroyed when you navigate away from the task flow, unless you use Task Flow Return activity and finalizer is invoked

3. You can access previously left Page Flow Scope only by using Task Flow Return activity

This allows me to presume that is not really good to have many small ADF task flows in the system, as theoretically there will be a lot of wasted Page Flow Scope entries, especially when navigating without retuning back. On contrary, when using larger ADF task flows and less of them - there will be less Page Flow Scope memory wasted - since less different Task Flows opened. On other hand, you should not implement just one big task flow - there must be proper reuse on design time, proper architecture requires clever separation into task flows.

There is nothing wrong in using multiple small ADF task flows, in this post I'm pointing out about lifetime of Page Flow Scope. You should clearly understand - Page Flow Scope is not destroyed when navigating away from ADF task flow. You should use shared Data Control as much as possible and avoid storing too much of temporary data into Page Flow Scope and pass it across different ADF task flows.

This is very true for UI Shell type of architecture - many task flows are opened from the menu, without really closing them. You should be aware of this and store variables in Page Flow Scope when its necessary only.

Sample application is available for download - PageFlowScopeApp.zip. It implements two ADF task flows. Task flow A contains one fragment, task flow B call and return activity:

Task flow B contains one fragment, return activity. There is one trick here - task flow B contains a call to calling task flow A. This is done on purpose, to simulate second instance for the task flow A:

Task flow A defines input parameter - backRendered. This is needed to distinguish, if task flow instance is opened from task flow B or no:

Task flow A call from task flow B sets parameter value:

Based on this parameter value, we can render components conditionally in task flow A fragment. For example, Back button is hidden if parameter is not set (which means A task flow instance was created not through a task flow call from B):

Below are the steps for the test. Task flow A is loaded and fragment is rendered, here user types some text and saves it in Page Flow Scope:

Press Navigate button to open instance of task flow B:

Page Flow Scope for task flow B is created now. You are in the task flow B Page Flow Scope, set text here also:

Press Next to open second instance of task flow A, new Page Flow Scope is created:

In the second instance of task flow A - type different text, not the same you was typing while in the first instance initially:

You should notice Back button rendered, this is because of passed parameter. Now when different text was set, what would you expect to see when coming back to the first instance of the same task flow? As every task flow instance maintains its own Page Flow Scope - you should expect to see original text. Press Back button - this will navigate to calling task flow B:

Task flow B still displays previously set text - this means when you navigate away from task flow - page flow scope is not lost and remains in memory. You should keep this in mind when designing ADF task flows, implementing your forms - make sure you don't store garbage in Page Flow Scope - this may waste memory, especially when having many ADF task flows and navigating between them, without returning or opening from UI Shell. Page Flow Scope from task flow B keeps its value, press Back button to navigate to the first instance of task flow A:

Task flow A keeps its original Page Flow Scope - text value is saved and displayed:

This means - we can return back through task flow return activity and access previously initialised Page Flow Scope - it is not gone.

If you press Navigate button in the task flow A and go to task flow B - new instance of task flow B will be created with new Page Flow Scope:

If you open task flow A by task flow call from task flow B - new instance is created for task flow A, new Page Flow Scope is initialised:

Navigate back to the task flow B and from task flow B to the original task flow A instance:

You will see that Page Flow Scope of original first task flow A instance is available:

Summary - it seems like Page Flow Scope is nothing more as more advanced Session Scope extended with Hash Map. This Hash Map contains references to Task Flow instances, entries in the Hash Map can be cleared only when calling Task Flow Return activity.