I am developing a Xamarin.Forms app with Prism in which I'd like to incorporate an onboarding page (more specific a top user benefits page, following the Material Design guidelines).
The app itself is structured around a NavigationPage to which I navigate with
NavigationService.NavigateAsync("/NavigationRootPage/MainPage")
in my App(). On the first start I'd like to show the onboarding page instead and I am having quite some issues getting it right.
My first approach was to navigate to MainPage with
_navigationService.NavigateAsync("/NavigationRootPage/MainPage")
from my viewmodel, when the user clicks the Get Started! button. This kind of worked by is also kind of ugly, since this absolute navigation will destroy the oboarding page immediately and not animate the transition. Furthermore at the moment the oboarding page is destroyed, the MainPage will be built, which will take a small, but noticeable, amount of time. In effect the user will notice the MainPage being built up, which does not look smooth at all.
My second approach was to navigate in a relative fashion from my viewmodel.
_navigationService.NavigateAsync("NavigationRootPage/MainPage")
This works way smoother, with the transition animation and after the animation is done, the MainPage is already ready to go. But again there is a major drawback. You can navigate back to the onbaording page, which we dont't want neither. And - to my knowledge - there is no (clean) way to remove the page from the navigation stack, too. I tried calling PageUtility.DestroyPage on my onboarding page, but this only worsened things, since it seemed to keep the page, but destroy the viewmodel, resulting in my onboarding page being shown without data when pushing the back button.
My third approach did not work at all, although it seemed promising to me. In my App() I pushed my navigation page with the main page then then my onboarding page modal
NavigationService.NavigateAsync("/NavigationRootPage/MainPage");
NavigationService.NavigateAsync("OnboardingPage", useModalNavigation: true);
and then in my viewmodel
_navigationService.GoBackAsync(useModalNavigation: true)
but this approach
showed the header of the NavigationPage although the onbaording page was supposed to be shown as a modal
refused to GoBackAsync - when calling this method, nothing happens
waiting for the first call to NavigateAsync did not change anything either.
Some other things I've tried
Implemented INavigationOptions in my viewmodel with ClearNavigationStackOnNavigation being true
Tried setting Application.MainPage after my NavigationPage was shown, but to no avail
I would have believed that this was king of a common requirement when programming an app. Is there something I've missed? Or will I have to live with one of those drawbacks?
I think you are overthinking this. If you want to show your Onborading page first then just navigate to it first.
`NavigateAsync("NavigationPage/OnboardingPage");
Or if you want to have the MainPage in the stack, then start the app with a deeplink
`NavigateAsync("NavigationPage/MainPage/OnboardingPage");
If you don't want to show the navigation header, just hide it for the onboarding page.
Don't use an absolute navigation unless you want to completely reset the navigation stack (equivalent to MainPage = new MainPage()).
I have found a solution, which is not the most beautiful one (it is actually quite ugly) but working.
In my MainPages viewmodel I implemented INavigatingAware and navigated to my OnboardingPage modally
public async void OnNavigatingTo(NavigationParameters parameters)
{
await _navigationService.NavigateAsync("LandingPage", useModalNavigation: true);
}
However, removing the moal page with
this._navigationService.GoBackAsync(useModalNavigation: true);
does not work as expected. The modal is not removed (although it should work this way from looking at the code, but I did not manage to debug with Re# generated PDBs). Hence I had to go the ugly (non-MVVM) way and create an event handler for Button.Click and remove the modal manually
private void Button_OnClicked(object sender, EventArgs e)
{
this.Navigation.PopModalAsync();
}
This will return to my MainPage smoothly with an animation and my MainPageis already up and running without being built up while already visible.
Still, I'd appreciate an answer on how to do it the Prism way.
Related
I have an app with four main pages, switched through a tab bar (no "back" button).
One page has a lot of content (ScrollView) and takes quite a few seconds until it's rendered. I handle that by showing a "loading" overlay while the work is done. But for that specific page I'd like to keep the view alive, so that when the user switches to another page and comes back later, the page is ready without loading everything again.
I'm not sure how to do that in MvvmCross, though.
I did read the documentation and from what I understood the View Presenter would be the right way to do it, since the docs say:
"Another kind of presentation changes your app can request through
hints includes clearing / modifying the BackStack, changing a root
while maintaining the existent views, … possibilities are really
endless. Once again your app is king here!"
I guess I would need to create a custom MvxPresentationHint for that, but I don't quite get it :(
How or rather where would I access and store/load the View?
I'm generally still quite unfamiliar with MvvmCross (how it works under the hood) and especially customization of Mvx classes, even though I've been using it for a while.
Any explanation and preferably code examples beyond what's written in the documentation would be extremely appreciated!
It isn't meaningful to attempt to "store" a view in MVVM. The XF view is a representation of what will be created with native (e.g. "Android" or "iOS") widgets. Creating and measuring/laying out those native widgets is what is slow. MVVM View Presenter won't speed up that logic.
Instead of "store", you need "keep alive":
For a ContentPage called MyPage, when you create it, store it in a static variable. Then re-use that variable. If you never need more than one of these, you can store it in the class itself.
Modify the "code behind", MyPage.xaml.cs:
public partial class MyPage : ContentPage
{
// Singleton Pattern.
private static MyPage _it;
public static MyPage It {
get {
if (_it == null)
_it = new MyPage();
return _it;
}
}
// "private", because calling this directly defeats the purpose. Instead, use `MyPage.It`.
private MyPage()
{
InitializeComponent();
}
}
To create it, whereever you would put:
new MyPage()
instead put this:
MyPage.It
For instance, you might do PushAsync(MyPage.It);
This will always return the SAME INSTANCE of MyPage. So once it has been created, it keeps its state.
IMPORTANT: Note that the constructor is only called ONCE. Any code that needs to be done each time the page appears, put in override .. OnAppearing() method.
LIMITATION: Views "expect" to be part of the visual hierarchy when they are manipulated. If you attempt to alter the page or its view model while it is not on the screen, you may encounter problems. Those are beyond the scope of this answer - create a new StackOverflow question with the details of any problem you encounter.
I cannot seem to get Chrome to pop up an "alert" page. The alert page has code in it, so it can't really be a DIV or I would just do it that way. It worked for many years, but likely do to a Chrome update it will no longer function. Still works fine in IE11, though.
The following code is used to pop up an "alert" page when there is an alert that is queried from a Database. It has always worked until recently (15 years and running)
CODE:
ClientScript.RegisterStartupScript(GetType(Page), "Alarm", "<script language='javascript'>window.showModalDialog('Alarm.aspx?ID=" & AlarmID & "', null, 'dialogWidth=460px;dialogHeight=310px;status=no;resizable=yes');document.frmA.submit();</script>")
I've tried a few things like windows.open and creating a hidden button on the asp.net page and then using the click event. Nothing works. I do not see a blocked popup in Chrome and I have even went into settings and did the following:
Set Safe Browsing to "No Protection"
Set allow pop-ups and redirects on the server name (http://servername and http://localhost)
As noted, near all browsers quite much have clamped down on popup windows. this makes things more difficult for web developers.
There are two good approaches. one I don't fancy at all is using bootstrap dialogs, but they tend to "sort of work all on their own" kind of deal based on class settings for divs etc. - really hard to debug.
Since near all sites these days include jQuery for your js code, then I quite much hands down recommend you introduce jquery.UI. It has a whole slew of nice things such as date pickers etc. But it also has a rather nice dialog pop option. They just work, and when you code them up? They follow "normal" like code approaches.
it not quite clear if your message/dialog pops after say a button click (and post back), and the at the end of that process, you need/want some dialog message to display. But all in all, I would high recommend jQuery.UI for this dialog/message that you need.
jQuery.UI in most cases expects the content you want to "display/pop" exists in a simple div in the current existing page. However, it also works VERY well if you supply the dialog another existing web page. The only REAL big issue to keep in mind? That dialog page you pop cannot handle multiple post-backs. (so, some buttons, or ONE post back in that dialog is fine - but you ONLY get the ONE post-back.
So, if that page display allows some input, or some interaction and ONLY requires ONE post-back, then jQuery.UI is again great. If that pop page requires several buttons and several post-backs, then you are in for a world of pain and hurt - jQuery.UI dialogs (like most) cannot survive or handle multiple postbacks. Any post-back means the dialog closes (collapses). So in those cases, you have to adopt ajax calls (web methods) if you need/have/want that page to have more then one active post-back button or event.
So, you could have/place a script in even your master page, and little function code stub that your register script can call.
Or, I suppose you could inject the whole script, but the script would look like this:
So, the pop page actualy is SHOVED into a div. So we have a div that "holds" the page.
The jQuery.UI code script then looks like this:
<div id="poppagearea">
</div>
<script>
function showpage() {
var mydiv = $('#poppagearea');
mydiv.dialog({
autoOpen: false, modal: true, title: 'My cool other page', width: '30%',
position: { my: 'top', at: 'top+150' },
buttons: {
'ok': function () {
mydiv.dialog('close');
alert('user click ok');
},
'cancel': function () {
mydiv.dialog('close');
alert('user click cancel');
}
}
});
mydiv.load('Default.aspx');
// Open the dialog
mydiv.dialog('open');
}
So, in above, we loaded "default.aspx" into that dialog and thus displayed it on the page.
So, I would consider jQuery.UI - but it does mean adopting a new js library into your existing project.
The pop page does gray out the full page, and you do get a title bar, and your own ok, cancel button. The above thus looks like this:
So, it does a great job - but as noted, that page can only have one post-back, and it can't be a general working aspx page with lots of buttons and post backs - but it will render and display rather well.
In PrismForms we got the problem, that the NavigationStack is empty after navigating to a new page. That means after using the hardware back-button on the SecondPage, the app is closed. Although the back-arrow in the header on Android isnt shown. If looking closely you can see the back-arrow for a short moment after the page is switched. I guess thats before the NavigationStack gets cleared.
To the first page we navigate with the following command in OnInitialized() in our App.xaml.cs which derives from PrismApplication.
NavigationService.NavigateAsync("NavigationPage/StartPage");
(If only Navigating to „StartPage“ here, the Stack doesnt get cleared.)
That has do to with PageNavigationService.ProcessNavigationForNavigationPage(...) calling
bool clearNavStack = GetClearNavigationPageNavigationStack(currentPage); and PageNavigationService.ProcessNavigationForContentPage(...) not.
From the StartPage to the next we navigate with NavigateAsync("SecondPage")“. Here the described behaviour appears.
For navigation we use a class which wraps the Prism NavigationService. We hold him as a property and get him via Unity in our constructor:
this.PrismNavigation = prismNavigation ?? throw new ArgumentNullException(nameof(prismNavigation));
The methods „NavigateAsync“ and „GoBackAsync“, etc. we just pass through.
This way we want to seperate our ViewModel-Project from references to XamarinForms to later be able to use the same ViewModels for for example a WPF-GUI.
Why is the stack beeing cleared by our own NavigationService? If we register the original Prism NavigationService in App.xaml.cs instead, navigating back works as expected again. We found the point in the framework and could avoid the clearing with a drity hack, but that’s against the navigation-logic implemented in PrismForms, but we don’t understand how to do it the correct way.
Every help appreciated!
We edited a few things to get it working after finding some interesting information by Brian Lagunas in the forlast-post here:
https://github.com/PrismLibrary/Prism/issues/591
Although the topic was about something else, it led to improvements for overwriting the Navigation Service.
Remember that in your viewModels the Navigation Service must be named "navigationService" by convention. Also we switched from just holding the Prism Navigation Service as a parameter to deriving from it as suggested in the link above.
public class MyNavigationService : UnityPageNavigationService
Lets say the first page in the app is the login page and then it takes me to do the main menu screen, is there a way to get rid of the back button in the main menu navigation bar, like get rid of the login page stack?
thank you
In Xamarin.Forms 1.3 and greater you can use
NavigationPage.SetHasBackButton(this, false);
In Xaml you can add:
<ContentPage ....NameSpaces etc....
NavigationPage.HasBackButton="False"
Title="MyPage">
</ContentPage>
You can avoid having the Back button if you replace the Navigation.PushAsync(page) to Navigation.PushModalAsync(page) in your login page's code. Post some code if this somehow doesn't apply
This has to do with how navigation works in the underlying OS (at least in iOS that's the case) - there is a Navigation Controller which serves for pages to transition between each other and have a trace of previous screen so the user can go back.
There are 2 ways to get rid of back button:
1) You can remove navigation bar from Xaml using Xamarin.Forms using below code
NavigationPage.SetHasNavigationBar (this, false);
Where this stands for current page / form instance.
2) Follow below mentioned steps
Navigate to login page when the app is loaded with Normal ContentPage instance of Login Page
Navigate to Main page from Login page using PushModalAsync and provide the main page instance as NavigationPage
And then from all the other pages, you can use PushAsync and it'll let you navigate to all the pages without any error.
Hope this helps!
By using CustomRenderer, you call this function in ViewWillAppear in your customized view controller
public override void ViewWillAppear (bool animated)
{
base.ViewWillAppear (animated);
this.ParentViewController.NavigationItem.SetHidesBackButton (true, false);
//remember to use ParentViewController to reference to the NavigationViewController (if your contentPage is direct under a navigation controller. I don't know why but Xamarin must have a bug with SetHidesBackButton. If you call with this.NavigationItem.SetHidesBackButton(...), it should not work.
... other implements here ...
}
I have a problem.
My app is a tab bar controller and its first view controller is a split view controller.
This seems to be not ok for Apple because documents say a split voew controller must be the root, so perhaps that is the reason of my problems.
The problem is that sometimes, willHideViewController from UISplitViewControllerDelegate is not called, so, for this reason, the upper/left button sometimes is not created, which is anoying.
I realised, to reproduce this error, try several times this:
-Landscape mode.
-Select a tab different to split view controller tap.
-Move the iPad to portrait in that tab.
-Go to the split view controller tab, and sometimes, willHideViewController is not called so you will not see the upper button. However if I rotate my iPad to landscape and after that to portrait, it's fixed.
I tried to force manually several rotations to work around this problem, but no luck.
I still have to try any split view controller clone class from github or similar.
Do you have idea what's going on or any work around?
Here I show you two examples working properly.
Thanks a lot for your help.
Where do you set the splitViewControllers delegate? Perhaps you can set the delegate when you load the tab. It sounds like you set it only when you have rotated once?
Otherwise, see this example
Here they have the TableViewController be the delegate of the splitviewcontroller. Perhaps you could do the same with the TabBarController?
I've concluded that this can't be done in any way that I consider 'sufficiently' legitimate. It's possible to get frustratingly close, but the issue of having the willShow..., willHide disseminated to the split view controllers under each tab remains.
The solution that seems most likely to work is,
https://github.com/grgcombs/IntelligentSplitViewController/blob/master/IntelligentSplitViewController.m
Though this code is undoubtedly clever, it's a bit too 'side door' for me. I suspect (but don't know) that just invoking the delegate methods is not sufficient. Surely the UISplitViewController itself needs to change it's internal state as well as calling the delegate methods? This method 'just' invokes the delegate methods when there's an orientation change.
So... I've decided on a more legitimate solution, which is to use the new method introduced in iOS 5.
- (BOOL) splitViewController:(UISplitViewController *)svc
shouldHideViewController:(UIViewController *)vc
inOrientation:(UIInterfaceOrientation)orientation
{
return NO;
}
So, the master menu is never hidden, and therefore the problem of managing the popover doesn't arise.
Of course, this is still not totally 'legit' as it still includes UISplitViewControllers that are not at the top level (the UITabViewController is at the top level, and the split views are on each tab)
Good luck with whichever solution you choose.
I'll update this reply when I've confirmed Apple will approve an app using this solution.