Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should INavigatingAware be changed? #1724

Closed
dansiegel opened this issue Mar 1, 2019 · 6 comments
Closed

Should INavigatingAware be changed? #1724

dansiegel opened this issue Mar 1, 2019 · 6 comments

Comments

@dansiegel
Copy link
Member

Description

When support for INavigatingAware was added, the intent of the API was always about ViewModel initialization. This later bloomed into some support that is counterproductive such as trying to support OnNavigatingAware when Navigating back to a given View. This is beyond the scope of the API's original intent, and cannot be fully supported particularly in cases where Navigation has occurred outside the context of the NavigationService such as from the Hardware Back Button.

In the next release of Prism the behavior will be fixed to restore the original intent of this API. This leaves the question of whether the Prism team should leave the API named INavigatingAware.OnNavigatingTo or whether we should rename this to make it easier to understand the intent.

https://twitter.com/prismlib/status/1101535125534208001

Also worth noting that we are looking at adding Async support either way.

Spec

public interface INavigationInitialize
{
    void OnInitialized(INavigationParameters parameters);
}

public interface INavigationInitializeAsync
{
    Task OnInitializedAsync(INavigationParameters parameters);
}
@sb34000
Copy link

sb34000 commented Mar 14, 2019

Hi Dan,
I Wonder why on the rework of INavigationAware, the logic of the suspending bool disapeared.
We intensively used it in our LOB UWP app to unsubscribe to event handlers and other specific contexts to prevent memoryleaks. This bool was used to apply different logic when leaving a page on a normal navigation (in that case we clean all the handlers) but when the navigatedfrom is called by lifecycle events, we need to keep all handler subscriptions because the constructor will not be called on resume.
What is the proposed logic in remplacement ?
I'm afraid it means a lot of breaking changes if we try to migrate from Prism 6.3 to 7.x ?
Thanks for your help
Seb

@bartlannoeye
Copy link
Contributor

Hey Seb, thank you for your feedback.

There will be breaking changes for UWP between 6.3 and 7.x, that's why it's a new major version, but we have our own large LoB apps to test the release on and will do our best to keep functionality and document all changes.

We also notice the difference in UWP (desktop) and XF (mobile), even though you can do UWP with XF. It's something we're currently looking into and discussing with Microsoft and some partners.

@sb34000
Copy link

sb34000 commented Mar 16, 2019

Hi Bart,
Thank you for your answers. I understand the need of breaking changes. Will the Adventure works sample updated with 7.x to help us understand how to deal with new behaviour. Do you have any doc or sample for UWP ? The sample in the sandbox are so basic...
Thanks,
Best regards,
Seb

@bartlannoeye
Copy link
Contributor

The samples and documentation will be rewritten once we land on a v7 release.

@brianlagunas
Copy link
Member

We changed it

@lock
Copy link

lock bot commented Jan 28, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants