Make integrating tap-status-bar-to-scroll-to-top easier

[xster]

Currently, you have to copy-paste some lines into your AppDelegate and forward a call to one specific instance of a FlutterViewController

[gaaclarke]

I looked into this. I'm not sure what work needs to be done. Here is related stuff I was looking into:

• Let CupertinoPageScaffold have tap status bar to scroll to top #29946 - Let CupertinoPageScaffold have tap status bar to scroll to top
• https://api.flutter.dev/flutter/cupertino/CupertinoPageScaffold-class.html CupertinoPageScaffold documentation

@xster is OOO so I'm not sure if we can get clarification on this.

[xster]

It's from the engine side. https://github.com/flutter/engine/blob/master/shell/platform/darwin/ios/framework/Source/FlutterAppDelegate.mm#L52 has some status bar touch plumbing hard-baked into our app delegate (which add-to-app users probably won't use). We should make it easier for the framework-side tap status bar to scroll to top work without having to do custom app delegate plumbing in the engine.

[gaaclarke]

This is going to be tough. I see a few options:

1. Swizzle the implementation of the AppDelegate's touchesBegan:withEvent: -- This is pretty hacky. We could swizzle the UIWindow's implementation instead... still hacky. We'd have to make sure we don't double swizzle which could result in double events.
2. Use a custom subclass of UIWindow -- Unfortunately the AppDelegate has to create the window, we can't force it to be used and a client might already be using a custom subclass of UIWindow.
3. Wrap up the functionality with a very clear function so people that want status bar taps can call FlutterForwardStatusBarTaps(touches, event) in their app delegate's touchesBegan:withEvent:.
4. Use undocumented NSNotifications -- This is WAY too hacky, even for me. This could get apps rejected.
5. It looks like you can get the functionality by using a UIScrollView too, inserting one underneath everything. This would be very hacky too since it will show up in the view debugger and potentially undo the work we did to handle extended status bars.

I guess I'm leaning towards 3 since it is the most straight forward in terms of implementation. The downside is that it isn't magic enough to not be a concern for Flutter clients. We might be able to swing 1. A combination approach would swizzle but only if the client explictly asked for it, with a function like FlutterEnableStatusBarTaps(). @jmagman, penny for your thoughts?

[jmagman]

@gaaclarke I don't know how the responder chain is set up, but does the FlutterViewController not also get the touchesBegan:withEvent: call? Meaning, can FlutterViewController directly override touchesBegan:withEvent:?

[gaaclarke]

@gaaclarke I don't know how the responder chain is set up, but does the FlutterViewController not also get the touchesBegan:withEvent: call? Meaning, can FlutterViewController directly override touchesBegan:withEvent:?

Nope, the view controller doesn't get events from the statusbar, the AppDelegate seems to gobble them up. I just verified for myself. I haven't tested if a custom UIWindow can grab them. Here is a stackoverflow where people are suggesting how to get the events: https://stackoverflow.com/questions/3753097/how-to-detect-touches-in-status-bar

[jmagman]

This is going to be tough. I see a few options:

1. Swizzle the implementation of the AppDelegate's touchesBegan:withEvent: -- This is pretty hacky. We could swizzle the UIWindow's implementation instead... still hacky. We'd have to make sure we don't double swizzle which could result in double events.
2. Use a custom subclass of UIWindow -- Unfortunately the AppDelegate has to create the window, we can't force it to be used and a client might already be using a custom subclass of UIWindow.
3. Wrap up the functionality with a very clear function so people that want status bar taps can call FlutterForwardStatusBarTaps(touches, event) in their app delegate's touchesBegan:withEvent:.
4. Use undocumented NSNotifications -- This is WAY too hacky, even for me. This could get apps rejected.
5. It looks like you can get the functionality by using a UIScrollView too, inserting one underneath everything. This would be very hacky too since it will show up in the view debugger and potentially undo the work we did to handle extended status bars.

I guess I'm leaning towards 3 since it is the most straight forward in terms of implementation. The downside is that it isn't magic enough to not be a concern for Flutter clients. We might be able to swing 1. A combination approach would swizzle but only if the client explictly asked for it, with a function like FlutterEnableStatusBarTaps(). @jmagman, penny for your thoughts?

We should not be swizzling anything in the app lifecycle for add-to-app, and we don't want to override any pre-existing touch event logic. So #3 sounds best to me, too.

iOS 13 has some interesting UIWindowScene/UIStatusBarManager APIs. Are you able to do something more legit when @available(iOS 13, *) so the hacks slowly phase out?

[gaaclarke]

iOS 13 has some interesting UIWindowScene/UIStatusBarManager APIs. Are you able to do something more legit when @available(iOS 13, *) so the hacks slowly phase out?

I read through them. I'm not seeing something that will help us unfortunately

• https://developer.apple.com/documentation/uikit/uistatusbarmanager?language=objc
• https://developer.apple.com/documentation/uikit/uiwindowscene?language=objc

[gaaclarke]

We should not be swizzling anything in the app lifecycle for add-to-app, and we don't want to override any pre-existing touch event logic. So #3 sounds best to me, too.

As part of swizzling we could always call th'e clients implementation as part of our implementation. I'm not advocating for it since it could be really confusing to clients, but that would be possible.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.