FRESHMVVM is super slow because It EXECUTES PAGEMODELS ON MASTERDETAIL
See original GitHub issueI already created ticket here but this ticket was closed by owner. I cant reopen it. that is why I am creating a new ticket and I believe this is a serious issue. Old issue https://github.com/rid00z/FreshMvvm/issues/44
when you have FreshMasterDetailNavigationContainer as below, it will execute through each PageModel (ViewModel) init and constructor and if you have some initial data loading your view, this will be very expensive on Start of the App. Is there a way to prevent this?
var masterDetailNav = new FreshMasterDetailNavigationContainer();
masterDetailNav.Init("Menu", "Menu.png");
masterDetailNav.AddPage<page1PageModel>("page1", null);
masterDetailNav.AddPage<page2PageModel>("page2", null);
masterDetailNav.AddPage<page3PageModel>("page3", null);
masterDetailNav.AddPage<page4PageModel>("page4", null);
masterDetailNav.AddPage<page5PageModel>("page5", null);
At the moment i have moved my getData functions on ViewAppering but this is not a good solution. We cant consider Appearing event as a solution, it has totally different purpose. It makes app quite inefficient if we load the data every time navigating back and forth. even it loads when switching between apps, as the name said whenever screen appears. It will be even executed when you lock your phone screen and unlock when app is on frontground. We seriously need a solution for this.
Issue Analytics
- State:
- Created 7 years ago
- Comments:15 (2 by maintainers)
Top GitHub Comments
There’s any news on this?
You’re right and I don’t think there’s any other event we can wire up to. Per Xamarin documentation there are 3 events for a page’s lifetime:
And
Appearing
“…indicates that the Page is about to appear.” It calls theOnAppearing()
method which “allows application developers to customize behavior immediately prior to the Page becoming visible.” The FreshBasePageModel (lines 66-70) class wires the ‘Appearing’ event toViewIsAppearing()
.To answer your question I think this is the right place because this method is called right before the page is even shown. The added bonus to this is that the DataContext for binding is set by this point as well. I think this is the best place to call data fetching methods because you can also show the user a loading icon to let them know that there is a long running operation in progress.
To alleviate the issue where the method gets called during different navigation scenarios I check the data before populating it again. @EmilAlipiev solution works but this method will also take care of cases where the app gets rehydrated from a state that no longer has that data populated. You can even place a time-elapsed check so you can always be sure the data presented is as fresh as possible.