Call goto screen transition function from presenter>activate()

Dfarr.1 · ‎2021-03-24

I'm trying to redirect away from a screen during activate() based on some model state information before anything is shown on screen. But I've only managed to get it working on some screens and not others even though I'm following the same pattern everywhere (call function defined in modelListener>call model defined function> call FrontEndApplication::gotoScreenNoTransition() ).

I feel like I'm missing something here. Is there an intended way to do this?

Dfarr.1 · ‎2021-03-25

I've pinpointed the problem. And settled on a solution for the time being.

This is a limit imposed by tGFX. You cannot make "nested" screen transition calls because the screen transition handler only stores a single pointer to represent the active/pending transition. You can't then change that pointer in the middle of a transition. I suspect this would have had to have been implemented as a stack to get around this limitation.

The problem is that I'm requesting a screen transition before the active pendingScreenTransitionCallback->execute(); has terminated. Once that call terminates, and before evaluatePendingScreenTransition() gets a chance to evaluate my newly submitted screen transition function pointer, the pointer gets cleared. presenter.activate() and view.setupScreen() are called by the screen transition execute(), so any transitions requested inside those two functions will get wiped out and ignored when the screen transition terminates.

The solution I chose:

define actions in each screen which is an entry point to the password protected screen.

override those actions in the view and test the authentication state of the model before calling the appropriate screen transition.

This means I have several screens where this logical test is being performed. But its the only way I found to perform the redirect before drawing the intermediate screen at all.

There was 1 special case, which was the password protected screen itself. I have implemented a stack for navigating between screens and returning to previous screens. I store function pointers to the gotoScreenNoTransition() functions from FrontEndApplication on this stack. So if I my protected screen is the "previous screen" and gets popped off the stack, the authentication check doesn't happen because that gotoScreenNoTransition() call is way above my overriden view action in the object hierarchy. I've had to compromise and use the "Screen is Entered" trigger on an interaction and tolerate the brief flash of the protected screen before it redirects to login. Not ideal.

I will definitely consider the ModalWindow widget next time I implement something like this.

View solution in original post

Alexandre RENOUX · ‎2021-03-24

Hello Dfarr.1,

If you want to change screen according the state of the Model before the current screen is displayed. An easier and probably safer way to do it is to get the current state of the Model in your ScreenView using the MVP concept and then perform the screen transition accordingly either in the constructor of ScreenView or in the initialize function before calling ScreenViewBase::initialize().

/Alexandre

Dfarr.1 · ‎2021-03-24

It was my understanding that the view isn't intended to "pull" data from the model. Nor should the view store data other than what it's currently displaying. As created by designer, the view doesn't actually have a handle to the model. The view doesn't even have a presenter handle it can use to daisy chain function calls down into the model to request state information.

I don't think I follow what you mean.

Dfarr.1 · ‎2021-03-24

I just found the presenter handle in the view. I haven't been using it!

My application relies on hardware events passed to the presenter which cause model state changes which are then bubbled up to the View. I haven't yet needed the view to drive model changes, nor directly request model state (no touch screen, all hardbuttons). I've only been using the presenter in one direction!

I've been initializing my views in the presenter activate() function, which is why I started there to create the screen redirect behavior.

I've now created a presenter function, called it from the view to retrieve the model state during view.SetupScreen(). Then it calls application().gotoScreenNoTransition(). But this still doesn't cause a screen transition. Am I missing a step?

Alexandre RENOUX · ‎2021-03-24

Hello Dfarr.1,

Please follow this tutorial and you should understand that the View can definitely request info from the Model through the Presenter. That's the core of the MVP concept.

/Alexandre

Alexandre RENOUX · ‎2021-03-24

For faster support, could you enclose your project ?

/Alexandre

Dfarr.1 · ‎2021-03-24

Unfortunately no.

Dfarr.1 · ‎2021-03-24

That tutorial suggests creating interactions from designer to trigger screen transitions. Its geared squarely towards touchscreen applications (which mine is not). Do you have a code example of a screen transition triggered from a view?

I'm getting the feeling my problem is that I'm requesting a screen transition while the transition onto the current screen is still in progress. But that's just a hunch.

Alexandre RENOUX · ‎2021-03-24

Hello Dfarr.1,

You need to use the action and trigger concept.

You create an action called changeScreen for instance and then you create an interaction that is triggered when this action is called. This interaction will initiate the screen transition. Then you just need to call changeScreen() in your View according to the state you received from the model.

/Alexandre

Dfarr.1 · ‎2021-03-24

Ok I created an action to trigger a change screen interaction in the designer. I'm calling that action in the view based on model state. This still doesn't cause a screen transition. No surprise really, since the interaction simply wraps application().gotoScreenNoTransition() which is what I was calling in my last attempt.

I can make screen transitions from just about anywhere without issue. Except presenter.activate() and view.SetupScreen(). Is some special consideration required when executing screen transition from these locations?