The Android and iOS versions of this function had diverged. This patch
makes the iOS version match the Android version (and what the framework
expects).
Fixes https://github.com/flutter/flutter/issues/8878
Breaking change: removed facilities for JSON and string messaging from FlutterView/FlutterViewController, leaving only binary messaging there. All other use of flutter communication now goes through FlutterMessageChannel and FlutterMethodChannels. Retained use of String and JSON codecs for now.
Companion flutter PR: flutter/flutter#8837
* Perform all iOS logging through ASL
As of iOS 10, ASL is deprecated and replaced with os_log. ASL calls
continue to result in logging but as of iOS 10.3, only ASL_LOG_NOTICE
level and above are logged.
This change partially reverts 2937f06a15cecf5e9398334617ca156316dae52b,
adding back stdout and stderr redirection, which resulted in loss of
some direct writes to stdout that were necessary for debugging.
This change replaces the direct use of syslog with ASL on iOS, which
Apple has stated will continue to log on iOS >= 10. This eliminates the
need for the previous fwd-declaration of syslog.
ASL is deprecated and replaced by os_log() on iOS. As of iOS 10.3,
calling this function breaks our logging altogether. os_log isn't
available pre-iOS 10.0. Rather than implement version checks and
conditional logic, this change eliminates the existing redirection
altogether. All engine code should be logging via the syslog redirection
implemented in Logger_PrintString in dart_runtime_hooks.cc.
Since stdio redirection is eliminated, we eliminate the flag that
controls whether such redirection is enabled.
* Add podspec to Flutter iOS framework.
Flutter iOS apps are already pod-enabled, so we might as well turn the
engine framework into a pod, so we don't have to manually copy the
current Flutter.framework into the app directory on every build, but
rather let Cocoapods wire things up for us.
For that to happen, we need a pod spec for Flutter.framework. This spec
will not be published, but rather downloaded as part of the engine
artifacts, and the app's Podfile will have a local path dependency on
it.
* Update licenses_golden...
This change eliminates two previous assumptions:
1. If a Flutter view is embedded in a parent view, that the parent view
controller would apply any status bar padding necessary.
2. That we should not apply padding unless the flutter view is
fullscreen.
A simple case where the first assumption fails to hold is a Flutter view
embedded in a UINavigationController with a hidden toolbar. A simple
case where the second assumption fails to hold is a view in a window
whose top overlaps the status bar but isn't fullscreen.
I had added this initially as a means of making it easier to deal with OpenGL directly in Flow. However, we are moving away from dealing with the client rendering APIs directly. Instead, delegating everything to Skia. Besides, we only ever used this to log the GPU description in case of context setup failures. This has not proved to be useful so far. Also, having this in place is making it difficult to remove all dependencies on GL in Shell.
Provide a default status bar tap handler for FlutterAppDelegate.
By default, taps are passed to the key window's rootViewController if
it's a FlutterViewController. Apps with custom app delegates can
customize this behaviour to send the tap to the FlutterViewController(s)
they prefer by overriding touchesBegan:withEvent.
The PlatformView superclass constructor was posting a task to the UI thread
that adds the view to the shell's global list. This could result in UI thread
operations seeing PlatformView instances that are not fully constructed and do
not yet have an engine.
This was happening in https://github.com/flutter/flutter/issues/7735
On iOS, when a tap is detected in the status bar, provide a means to
pass that touch event through to one or more FlutterViewControllers to
trigger a scroll to top. In iOS apps, scroll to top should occur under
the following conditions:
1. There is one and only one UIScrollView visible with
scrollsToTop == YES.
2. The status-bar is in standard height mode, not in double-height mode.
In double-height mode, the expected behaviour is to trigger a switch
to the application associated with the double-height status bar.
3. A tap or a drag gesture occurs that is entirely constrained to the
status bar frame. (We currently only handle the tap scenario).
Unfortunately, AppDelegates only get touchesBegan events for status bar
taps, though get get touchesBegan and touchesEnded events for drags
within the status bar frame. As such, we currently synthesise the
touchesEnded event for taps.
All samples and the 'flutter create' command now use a project-specifc
app delegate.
Any projects that still rely on FlutterAppDelegate should create an
empty delegate that subclasses UIResponder<UIApplicationDelegate> and
defines:
@property (strong, nonatomic) UIWindow *window;
* Apply iOS status bar padding only to fullscreen views
Previously padding was applied to account for the status bar, whether in
standard or expanded 'in-call' geometry only if the current view was not
a subview of a containing view. This didn't cover the case of root views
embedded in other windows (e.g. dialogs).
We also ensure that the window is fullscreen to account for cases like
small dialogs centred on the screen.
* Do not apply padding if we're a subview in a containing view
* Handle double-height status bar on iOS
In certain cases, iOS displays a double-height status bar (e.g., when an
application is using device location or while in a call). In such cases,
iOS offsets the app view origin by 20px, reduces view height by 20px,
then overlays a 40px opaque status bar: 20px covering the newly opened
20px gap at the top of the screen, 20px covering the top 20px of the
view, which had previously been under the standard-sized status bar.
Flutter previously set top padding to the height of the status bar,
which resulted in 40px padding with a double-sized status bar. However,
the padding should match the portion of the status bar overlapping the
view, which is 20px.
Note that the final case is the one in which no status bar is shown and
padding should be zero.
* Only apply status bar padding on root views
