| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
@tsonevn It turns out this is not so easy as just passing a parameter to .showModal(). Some of the presentation styles require additional logic in order to make them work. I've already implemented some default logic for UIModalPresentationPopover and while I believe some default logic can also be implemented for most of the otehrs, UIModalPresentationCustom might be a little bit complicated withouth returning the view controller to the user. I will investigate further, but wanted to open the discussion here for further ideas. |
Sorry, something went wrong.
|
Hey there @surdu - thanks for you effort. Here are a couple of thoughts: DefinitionsFirst of all - all d.ts files should be clear of IOS or Android Specific classes(like UIModalPresentationStyle). The reason is that we don't want people to be forced to use tna-platform-declarations package in their apps. OptionsThe showModal API already has 3 optional parameters and this is making it little hard to use. Adding one more optional param will amplify the problem (what if you want to pass only the last one). My suggestion is to define a ShowModalOptions interface that you pass to the method. This way you can fill in only the options you care about. Furthermore you can have an ios and android portion of the interface that only deals with plat-spceific options (like UIModalPresentationStyle). You can also have a callback in the options - which will be called if they are using the an option, that needs to give the control back to the user for additional setup of a view-controller for example. PRSeems that this PR is not as easy as originally thought. What do you think of moving the discussion back to the issue (#6387). We might pick only the UIModalPresentationPopover values that are most useful - no point of supporting all of them if they are not going to be used. |
Sorry, something went wrong.
|
@vakrilov I've made the changes that you requested. Also wrote a test for my changes. I took another test for the modal and just changed the way the options are passed. The test is somewhat overkill, but I guess there was a good reason to implement the test I copied like this, so I went with it. There is one thing that I want to do but I didn't manage to figure out how (probably can't be done at this stage of execution): I want to get styling informations about the Page that is about to be presented at this point. It would be nice to get the Page width and height expressed by the user is css and resize the pop-up accordingly. Also need the background color few lines bellow. For the old version of showModal that receives the options as arguments, do you want to deprecate it or will they live alongside each other? |
Sorry, something went wrong.
|
test |
Sorry, something went wrong.
|
test |
Sorry, something went wrong.
| const view = firstAgrument instanceof ViewCommon | ||
| ? firstAgrument : <ViewCommon>createViewFromEntry({ moduleName: firstAgrument }); | ||
|
|
||
| (<ViewCommon>view)._showNativeModalView(this, context, closeCallback, fullscreen, animated, stretched, iosOpts); |
There was a problem hiding this comment.
Note to self: removed iosOpts by mistake
Sorry, something went wrong.
|
test |
Sorry, something went wrong.
|
test |
Sorry, something went wrong.
|
test |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Checklist
What is the current behavior?
Other than fullscreen or not, there is no way to set the rest of modal presentation styles for a modal on iOS
What is the new behavior?
You can now pass an extra parameter called iOSPresentationStyle to .showModal()
Implements #6387