Trigger Activated on GoBack w/ hierarchical navigation

How-to Discussions
1

So I am using the <Activated> tag to set text to show what page I am currently on. However, during hierarchical navigation, it sometimes is not triggered from a <GoBack>. I am not sure this is a bug or if I need to define things another way. The goal is to write the name of the page to a top bar that all these pages are contained in. See below code for a sample of the problem. The ‘Search Options Activated’ does not get written after the <GoBack> from the Item page.

<App>
	<Router ux:Name="router"/>
	<Navigator DefaultPath="search">
		<SearchPage ux:Template="search" router="router"/>
		<Item ux:Template="item" router="router"/>
	</Navigator>

	<Page ux:Class="SearchPage">
		<Router ux:Dependency="router"/>
		<Navigator DefaultPath="options">
			<SearchOptions ux:Template="options" router="router"/>
		</Navigator>
	</Page>

	<Page ux:Class="SearchOptions">
		<Router ux:Dependency="router"/>
		<JavaScript>
			module.exports = { pushItemSummary : function pushItemSummary(){ router.push('item');}}
		</JavaScript>
		<Activated>
			<DebugAction Message="Search Options Activated"/>
		</Activated>
		<StackPanel>
			<Text Value="Search Options Page"/>
			<Button Text="Go To Search Results" Clicked="{pushItemSummary}"/>
		</StackPanel>
	</Page>

	<Page ux:Class="Item">
		<Router ux:Dependency="router"/>
		<StackPanel>
			<Text Value="Item Page"/>
			<Button Text="GoBack">
				<Clicked>
					<GoBack NavigationContext="router"/>
				</Clicked>
			</Button>
		</StackPanel>
	</Page>
</App>
2

I think this is what happens:
<Activated> is triggered on a state change, e.g. when its parent becomes the active page inside a Navigator or when it’s rooted / initialized.

So, the first time you get to SearchPage the message is printed because SearchOptions is initialized at that point.

However, when you go back from Item to SearchPage the message is not printed because SearchOptions has not changed its active-state. It has been the active page inside the 2nd level Navigator (the one inside SearchPage) all the time.

In other words: <Activated> reacts to changes in state for the nearest Navigator in the hierarchy and that doesn’t change at all in this scenario.

I’m not sure what’s the best solution to achieving the desired result. Perhaps to store state hierarchically in the tree? E.g. SearchOptions (and its future siblings) update a local state inside SearchPage, which SearchPage then passes on to the top level when it itself becomes active.

3

I think that makes sense with what I am seeing. I will try to keep the active state stored in the top level like you suggested and see if that can achieve what I want. Thank you very much for the reply.

4

I’m having a similar problem shown in this gist: https://gist.github.com/jsbeckr/d3d455d1e10b66a298f7c880306b36bc

I can understand the technical side of things. Still it would be nice to have a trigger that fires when a page is becomes visible to the user again, even in a nested hierarchy. In my example I can’t detect (in a non-hackish way) when the user navigates to a nested page, which is quite a crucial functionality to have.

5

Hi Jens,
I definitely see your point. I’ll add a ticket to explore the possibility of a trigger for this.

In the meantime, this approach (while not explicitly non-hacky) might be of help: https://gist.github.com/anonymous/4a56240b9160374057cac688e1123da2

It’s based on the fact that child pages will also be disabled when the parent is, therefore using WhileEnabled rather than checking for activity, together with a subclassed Page-type which sets itself to disabled whenever its inactive.

I’ve explicitly set your top-level second page (the wrapper) to disabled here, to avoid the two sub-pages being activated when the app is originally initialized.
I suspect that behavior is due to initialization order when your top-level is in a pagecontrol and / or the lower level uses instantiated pages instead of templates inside the navigator.

So, while this isn’t really a solution I hope it can help out to simplify some real-world use cases until we come up with something better. :slight_smile: