- 09 2月, 2017 1 次提交
-
-
由 James Robinson 提交于
-
- 08 2月, 2017 5 次提交
-
-
由 Collin Jackson 提交于
-
由 Chris Bracken 提交于
Ensure that the text input keyboard is reloaded if the view keyboardType changes.
-
由 Chinmay Garde 提交于
-
由 Chinmay Garde 提交于
-
-
- 07 2月, 2017 2 次提交
-
-
由 Chris Bracken 提交于
Added: * UIRequiredDeviceCapabilities=[arm64] * MinimumOSVersion=8.0
-
由 Jason Simmons 提交于
-
- 04 2月, 2017 3 次提交
-
-
由 Jason Simmons 提交于
-
-
由 Jason Simmons 提交于
-
- 03 2月, 2017 2 次提交
-
-
由 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.
-
由 Jason Simmons 提交于
-
- 02 2月, 2017 5 次提交
-
-
由 Michael Goderbauer 提交于
-
由 Chinmay Garde 提交于
-
由 Chinmay Garde 提交于
-
由 Chinmay Garde 提交于
* [iOS] Ensure FlutterMain is called before interacting with the engine in any way. * Licenses
-
由 Jason Simmons 提交于
-
- 01 2月, 2017 5 次提交
-
-
由 Michael Goderbauer 提交于
-
由 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 提交于
-
由 Michael Goderbauer 提交于
-
- 31 1月, 2017 2 次提交
-
-
由 Chinmay Garde 提交于
-
由 Jason Simmons 提交于
The Dart tests were migrated from the flutter/test/engine suite in the framework repository
-
- 28 1月, 2017 3 次提交
-
-
由 Jason Simmons 提交于
-
由 Jason Simmons 提交于
-
由 Jason Simmons 提交于
This is intended to match the exit codes returned by the Dart command line tool
-
- 27 1月, 2017 5 次提交
-
-
由 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;
-
由 Ian Hickson 提交于
-
由 Chinmay Garde 提交于
[content_handler] Make RuntimeHolder convey its viewport metrics to the direct input instance. (#3367)
-
由 Chinmay Garde 提交于
-
由 Jason Simmons 提交于
SkTypeface::MakeFromStream takes ownership of the passed SkStreamAsset* Fixes https://github.com/flutter/flutter/issues/7657
-
- 26 1月, 2017 3 次提交
-
-
由 Chris Bracken 提交于
* Roll Dart SDK to ed00447138f95ea4ba612509a244ca8205735372 Make the VM happy with a spurious instruction snapshot. * Revert "Snapshots: Don't use an empty array where a NULL array is expected. (#3361)" This reverts commit 275ffdce. Broke iOS simulator builds; should no longer be necessary after rolling the Dart SDK to ed00447138f95ea4ba612509a244ca8205735372. On iOS simulator builds, we were seeing DartLookupSymbolInLibrary return a pointer to a address of the snapshot data rather than the address of the snapshot buffer itself. On simulator builds we don't build the snapshot data into a buffer in app.dylib (kDartVmSnapshotData) but link it statically into the engine itself.
-
由 Jason Simmons 提交于
-
由 Chinmay Garde 提交于
-
- 25 1月, 2017 4 次提交
-
-
由 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
-
由 Ryan Macnak 提交于
Fixes dart-lang/sdk#28504
-
由 Jason Simmons 提交于
-
由 Ian Hickson 提交于
-