- 29 3月, 2017 1 次提交
-
-
由 Mikkel Nygaard Ravn 提交于
-
- 23 3月, 2017 2 次提交
-
-
由 Chinmay Garde 提交于
-
由 Mikkel Nygaard Ravn 提交于
-
- 22 3月, 2017 2 次提交
-
-
由 Mikkel Nygaard Ravn 提交于
This reverts commit 7932ba76.
-
由 Mikkel Nygaard Ravn 提交于
-
- 19 3月, 2017 1 次提交
-
-
由 Adam Barth 提交于
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
-
- 17 3月, 2017 1 次提交
-
-
由 Mikkel Nygaard Ravn 提交于
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
-
- 15 3月, 2017 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 14 3月, 2017 2 次提交
-
-
由 Jakob Andersen 提交于
Names matter, and I apparently forgot to test after adding ' Engine' to the name. Names can't contain spaces, and must match the filename.
-
由 Mikkel Nygaard Ravn 提交于
Flutter channels now also supported on iOS. Use FlutterMessageChannel or FlutterMethodChannel with binary/string/json/standard codecs.
-
- 08 3月, 2017 1 次提交
-
-
由 Jakob Andersen 提交于
* 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...
-
- 07 3月, 2017 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 25 2月, 2017 1 次提交
-
-
由 Chris Bracken 提交于
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.
-
- 23 2月, 2017 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 08 2月, 2017 2 次提交
-
-
由 Collin Jackson 提交于
-
由 Chris Bracken 提交于
Ensure that the text input keyboard is reloaded if the view keyboardType changes.
-
- 07 2月, 2017 1 次提交
-
-
由 Chris Bracken 提交于
Added: * UIRequiredDeviceCapabilities=[arm64] * MinimumOSVersion=8.0
-
- 03 2月, 2017 1 次提交
-
-
由 Chris Bracken 提交于
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.
-
- 02 2月, 2017 1 次提交
-
-
由 Chinmay Garde 提交于
* [iOS] Ensure FlutterMain is called before interacting with the engine in any way. * Licenses
-
- 01 2月, 2017 3 次提交
-
-
由 Jason Simmons 提交于
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
-
由 Chris Bracken 提交于
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.
-
由 Chinmay Garde 提交于
-
- 27 1月, 2017 1 次提交
-
-
由 Chris Bracken 提交于
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;
-
- 25 1月, 2017 2 次提交
-
-
由 Chris Bracken 提交于
* 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
-
由 Chris Bracken 提交于
* 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
-
- 12 1月, 2017 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 04 1月, 2017 2 次提交
-
-
由 Chinmay Garde 提交于
-
由 Chinmay Garde 提交于
-
- 02 12月, 2016 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 30 11月, 2016 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 29 11月, 2016 2 次提交
-
-
由 Todd Volkert 提交于
-
由 Todd Volkert 提交于
-
- 23 11月, 2016 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 18 11月, 2016 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 16 11月, 2016 1 次提交
-
-
由 Adam Barth 提交于
These are implemented on macOS and Fuchsia.
-
- 04 11月, 2016 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 29 10月, 2016 2 次提交
-
-
由 Adam Barth 提交于
After this patch, we no longer link with Mojo. We still use some gn definitions from //mojo to create Dart packages.
-
由 Adam Barth 提交于
We no longer use mojom to transport messages. We still use the Mojo EDK to spin the event loop, however.
-
- 28 10月, 2016 2 次提交
-
-
由 Chinmay Garde 提交于
-
由 Adam Barth 提交于
Now we just pass the data directly.
-