Several issues such as Mini view position on ipad pro

[wxyjay]

Hi, thanks for your library.
I reported some issues with swipe gestures before, and it works fine now.
Right now I'm getting a project to work on an ipad and have run into a couple of tricky issues.

1. In the Mini state, use stage manage to adjust the zoom app, the miniView will be offset downward (so that it may not be visible). (appears in a floating state or when stage manage is enabled and not full screen)

2. In the expanded state and the App is not full screen, there will be some gaps at the top of the Expand View. (It is normal in regular split screen, open stage manage to appear)

3. In the full screen state, there will be a little gap at the bottom of the Mini View, just a little bit. (Any situation will occur, whether it is landscape or portrait)

My screen recording---->https://drive.google.com/file/d/1c0IzJTdrOnbllNE-osjXOidhzbzlEvyx/view?usp=sharing
Device: iPad Pro 2020 11-inch
OS: iPadOS 16.1

It's worth noting that everything works fine on my ipad Mini 5th generation (of course it doesn't support stage manage)

[DominikButz]

Hi,
thanks for reaching out to me. Actually I don't have an iPad that can run stage manager but with a workaround I made stage manager run in the simulator and the result looks worse than in your video :-). I think I was able to make some improvements, please update to v2.4 and see if it works (there is one breaking change: you need to remove geometry from the initialiser). Important: check out the example project. the problem with the gap when resizing the window on iPad is probably caused by a tab bar height that changes while resizing. However, minimizedBottomMargin is probably never changed in your project. This can be fixed by updating minimizedBottomMargin with the help of the TabBarAccessor as shown in the example.

[wxyjay]

Thank you so much for your effort, I'll test it right away.

[wxyjay]

Hi, I am currently testing version 2.4.
The height of the Mini View is now no problem, split screen on any iPad or on stage manage works fine.
But I found a small problem when I tested it on the iPhone, it will only appear on the ios15 system. Everything works fine on ios16.

Description: My project is a music player, and MinimizableView is always on. So when the tabView is initialized I have been:

struct: TabView: View {

init(){
self.miniHandler.present()
self.miniHandler.isMinimized = true
}
}
He didn't have any problems before, but when I updated to version 2.4, when the App exited the background and reopened, the tabView would be reinitialized, which was equivalent to my player view being expanded before I exited the background. When I exited the background and reopened it The tabView will be reinitialized, meaning "self.miniHandler.isMinimized = true". I tested two iPhones with ios15.7 and they will appear, but the 16 system is all normal, and it will not initialize repeatedly.

I recorded a video, please check it out if you have time. thank you very much!

Link: https://drive.google.com/file/d/19BkcI9iiy16Lnuj8VSLaJ9sekXqZ8lES/view?usp=sharing

—————————

There is also a small suggestion, if you think it is suitable, I hope you can add it.

describe:

For some projects, minimizableView always needs to be opened and does not need to be hidden (similar to Apple Music). If you can add an optional configuration to the initializer, similar to 👇:

.minimizableView(
....
,minimizableViewAlwaysOn: true
...
)
, When turned on, MinimizableView initialization does not need to be manually turned on

[DominikButz]

It doesn't look like this is related to MinimizableView but rather to SwiftUI's changes from one version to the next.
Why don't you attach an onAppear modifier to the TabView?
If miniView should be presented and in minimised state, you don't need to call the present() and minimise() functions, you can set the properties to true right away.
Since there will be probably only one minimizable view per app, I also don't see the need to add that "always on" property. You can just do it as shown below, even in the RootView of your app. The user can't dismiss miniView if there is no logic in the content allowing dismissal. In that case it will always be in presented state at runtime.

                .onAppear {
                    self.miniHandler.isPresented = true
                    self.miniHandler.isMinimized = true 
                    
                   
                }

[wxyjay]

After I debugged repeatedly, I found the problem, because in the ContentView I obtained the state of the device landscape and portrait by observing [UIDevice.orientationDidChangeNotification]publisher and changed the State value, which caused the View to redraw, which is indeed not the same as "MinimizableView". any relationship. Now I'm adding Observer inside the Class to modify the state so that it doesn't cause the View to repaint without needing to update the state. All is well now, thanks a lot! Oh yes, I actually tried putting the code in "onAppear" before, but it didn't work as expected, so I put it in the initialization.

There is another question about Swift UI, I want to ask you, very headache.

On swiftUI, create a swipe gesture, and modify the state of the View by sliding some values, similar to "self.miniHandler.draggedOffsetY = value.translation.height", I think this is a matter of course; but in support of promotion high refresh rate The device does not achieve high frame rate and the experience is worse than that of the device with 60Hz screen. Compared with the modal sheet I tried to create and the system's native sheet, you will clearly feel the difference in frame rate. I recorded a video (it may be difficult to perceive the difference in the video).
https://drive.google.com/file/d/1mkAjZCIRaJsiV4ectyua58R4qTilYagT/view?usp=sharing

I've googled related questions, but none of them have clear answers. I also tried the high refresh rate request "promotionRequest = FrameRateRequest(preferredFrameRate: 120, duration: 0.45)", but there is still a significant gap in the experience. Specifically compared to AppleMusic's Now Playing modal view. Not very good to describe. . It will only be obvious if you swipe on the phone yourself.

I created a sample if you have a Promotion enabled device so you can test it: https://github.com/wxyjay/SwiftUIModal-master

[DominikButz]

Yes, I agree - SwiftUI has a lower performance than UIKit. I don't know how SwiftUI sheet works exactly, however, since this modal sheet (same as fullScreenCover) is always presented on top, no matter where you attach it in the view hierarchy, I think it is a UIKit ViewController under the hood. It seems SwiftUI is still running inside a UIHostingController and the sheet is then presented modally above the UIHostingController. I'm closing this issue now. In case you have any suggestion for a code improvement of this package, let me know by opening a new issue or sending a pull request.