Right now, even though I'm showing a page with the action bar tags, the action bar is hidden.
Same as android
anything new ? still can't show the actionbar in modal dialogs
Any updates on this one, guys?
This issue has been open for quite some time now and at least for iOS (where the modal page opens in fullscreen by design) this seems like a limitation and functionality that should be provided out-of-the-box.
The native iOS experience of Settings > Maps > Transit seems like an use case that I would address with modal pages (on Android the native experience is modal dialog) and it has the action bar with title and back button by default:
@rclai , @danieloprado , @ryanzaatari , @manoldonev
This feature is planned for NativeScript 3.2 as logged in our Roadmap page (navigation in modal pages)
hello guys, any update on that?
Has then been released yet? As i still am unable to view an actionBar on a Modal page
@wiperez @LorenDorez
I think this will be available with NativeScript 4.0 which will be available in April 2018 according to the current plan.
This should be possible now with 4.x, shouldn't this be closed now?
Doesn't seem to be added in TNS 4.x. I've upgraded a project to 4.1 and still actionbar is hidden in the modal (iOS)
This is possible with the flexible frame composition feature introduced in 4.x. Basically the trick is that you need frame as a modal root for this to work on iOS:
home/home-page.xml
<Page class="page"
xmlns="http://schemas.nativescript.org/tns.xsd">
<ActionBar class="action-bar">
<Label class="action-bar-title" text="Home"></Label>
</ActionBar>
<GridLayout>
<Button text="Show Modal" tap="onModalTap" />
</GridLayout>
</Page>
home/home-page.ts
import { Button } from "ui/button";
import { Frame } from "ui/frame/frame";
export function onModalTap(args) {
const frame = new Frame();
frame.navigate("home/second-page");
const buttonOwner = <Button>args.object;
buttonOwner.showModal(frame, {}, (result) => console.log(`modal close: ${result}`));
}
home/second-page.xml
<Page class="page"
xmlns="http://schemas.nativescript.org/tns.xsd">
<ActionBar class="action-bar">
<Label class="action-bar-title" text="Second Page"></Label>
</ActionBar>
<GridLayout>
<Button text="Close Modal" tap="onCloseTap" />
</GridLayout>
</Page>
home/second-page.ts
import { Button } from "ui/button/button";
export function onCloseTap(args) {
const buttonOwner = <Button>args.object;
buttonOwner.closeModal("with result");
}
@manoldonev , I think this should be exposed as a core module function (like we have showModal
) so it can easily be reused. May be just add another optional parameter to the current function whether or not to show action bar?
Or at least there should be an article in the docs explaining this as not many users are searching through GH issues to find an answer to their question 馃槈
I mostly work with Angular and I'm sure there is a complete example attached in the docs. There seems to be something explained in the core docs too. When Frame is the root of modal, using an ActionBar is just as same as what we do in normal pages.
@manojdcoder , well I mostly use clean NS, so I haven't looked at the NG docs 馃榾 But in the core NS docs this is described very vague at best. It mentions only if you want to do navigation inside modals. In my case I don't want navigation, I just want the ActionBar
with some buttons in it. So how am I supposed to figure out that in order to show the action bar I need follow the same steps as if I want navigation? And this comes from a user that used NS from the early alpha days, imagine what would it be for a user just embracing NS...
@PeterStaev Yes, that is a valid point and it's not only limited to Modal, if you define a View / Layout instead of a Frame at root level, then you can not have a ActionBar even there.
May be the docs could make it more clear that Page & ActionBar components are valid only inside a Frame.
@tsonevn Can we describe this scenario explicitly in the core docs?
@PeterStaev not sure about the optional parameter in this case -- I think we will hide too much internal implementation details behind a single flag (the code above) and it will work like magic... till it doesn't e.g. if you set this flag we will have to create a frame for you but you might try to open another frame as root of your modal and nested frames are currently not supported.
@manoldonev I won't agree with you on this one. Like you said, the user has to repeat all those lines of code in case they need to show action bar or use navigation inside a modal. Imagine 100 apps with 100 modals. I deffo don't want to repeat that code over and over again. I would prefer things to work like magic 馃槃 As for the problem of passing a frame instance - this can easily be avoided by adding a simple check here:
https://github.com/NativeScript/NativeScript/blob/0fc1547a19e29efba9e88d84dd24118262fdd18a/tns-core-modules/ui/core/view/view-common.ts#L228-L229
Actually since having a frame inside the modal brings only pros and there are no cons, I even think this should be the default behavior.
Anyways, final decision is yours, but if that doesn't make it in the core modules, I would definitely create a plugin wrapping those 4 lines of code 馃榾
I agree with @PeterStaev on this one. In the meantime, I'll wrap that logic up as a FramedModal type. At the very least, it would be good to add this point to the NS doc page for Modals (or a more general page about views, with an out-link on the Modal page since it seems like it might be a common case).
@PeterStaev @nickcabral I think the reason we decided this cannot be the default behavior is due to breaking change considerations. If we automatically created a Frame
and navigated it, the Page
wouldn't have the modal close callback, which prior to 4.x was the only way to close the modal. Besides, I disagree that the navigated/action-bar modal is the most common case for modals. They are usually used for user input like in forms and such and especially for Android where the default behavior is not full screen it would look funny. Also, the initial navigation itself is a performance overhead. The idea of having a separate method for opening a "FramedModal" isn't so bad.
I think what is not clearly communicated is that the ActionBar
component is tightly coupled to the Frame
and the navigation. This is because of the iOS native implementation. The ActionBar
as we know it is actually UINavigationBar
in iOS. This was not so important/necessary/obvious prior to 4.x because the Frame
component was implicitly created as the root of your app and you would always have an ActionBar
.
I think the bottom line is that with 4.x the framework works less like magic, but lets you do more navigational patterns. This was an intentional trade off was made based on feedback.
Thanks for the clarifications @MartoYankov . Since there is a performance hit when using a framed modal instead of a normal one, as well as the navigation callback removal, I think adding a separate method would be 馃挴
Here is the function I added in my apps so I can have the ActionBar
visible:
export function showFramedModal(
parent: View,
moduleName: string,
context?: any,
closeCallback?: (context?: any) => void,
fullscreen: boolean = false,
animated: boolean = true,
) {
const fr = new frame.Frame();
let view: View;
fr.navigate({
create: () => {
view = createViewFromEntry({ moduleName });
return view;
},
context,
});
const pipeModalEvents = (args) => view.notify(args);
fr.on(View.shownModallyEvent, pipeModalEvents);
fr.on(View.showingModallyEvent, pipeModalEvents);
const frameCloseCallback = (returnContext?: any) => {
fr.off(View.shownModallyEvent, pipeModalEvents);
fr.off(View.showingModallyEvent, pipeModalEvents);
closeCallback.call(undefined, returnContext);
};
parent.showModal(fr, context, frameCloseCallback, fullscreen, animated);
}
Is there any example of how to present a framed modal using Angular? The docs don't seem to cover this well.
It's covered here along with a Github example.
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.
Most helpful comment
@rclai , @danieloprado , @ryanzaatari , @manoldonev
This feature is planned for NativeScript 3.2 as logged in our Roadmap page (navigation in modal pages)