The lint ensures that the prefix you use in your "import ... as"
directive conforms to lowercase_with_underscores style. However,
generated code often doesn't, since it may use preceding underscores
for collision avoidance, or directly use locale codes in the
prefixes.
Minor fixes throughout, e.g. removing trailing commas from the end of sample code expressions, changing headings to "sample code" more consistently, removing stale todos, fix typos in a private method name, minor grammar fixes, added some clarifications to CircularProgressIndicator, LinearProgressIndicator, CrossAxisAlignment, added some cross-references to various members, made it slightly clearer that layout algorithms are implementation details.
Clarified "elevation" throughout.
Added docs to InkResponse and InkWell.
Added sample code for: SliverAppBar, Card, ListTile, EdgeInsets, Row, Column, CustomScrollView, ListView, SliverFixedExtentList, and SliverGrid.
Fixes#10317.
Fixes#10316.
Fixes#10267. (sort of, see comment therein)
Fixes#9331. (sort of, see comment therein)
Fixes#9407. (sort of, see comment therein)
Relocates two tests alongside other related tests:
* moved code_signing_test.dart alongside other lib/src/ios tests
* moved terminal_test.dart alongside other lib/src/base tests
* Add more tests of toStringDeep.
These tests will help ensure toStringDeep behavior is not regressed
by refactoring toStringDeep to support structured data.
Makes debugging semantics easier (e.g. which RenderObject has semantics, where is a SemanticNode seen in the semantic tree comming from, etc).
It's only printed if accessibility is turned on.
* Rolls the engine to 75c74dc463d56e17be10315cfde409010fd8f90b.
* Adds framework support for the `AppLifecycleState.inactive` and `AppLifecycleState.suspending` states.
What are the new states?
------------------------
* `AppLifecycleState.inactive` is emitted on iOS only and corresponds to iOS's foreground inactive state. Current iOS state transitions are:
`resumed` <--> `inactive` <--> `paused`
* `AppLifecycleState.suspending` is currently emitted on Android only and corresponds to the
transition to Android's stopped state. Current Android state transitions are:
`resumed` <--> `paused` --> `suspending` --> `resumed`
These transitions may change in future.
This is a breaking change on iOS
--------------------------------
This changes the semantics of the `AppLifecycleState.paused` state on
iOS. The behaviour associated with this state is unchanged on Android.
For background on iOS application states see the state transition
diagram in the [App Programming Guide for iOS](https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW6).
On iOS, prior to this change, `AppLifecycleState.paused` corresponded to
a transition to the _foreground inactive_ state. It now corresponds to a
transition to the _background state_. The newly-added
`AppLifecycleState.inactive` state now corresponds to entering the
_foreground inactive_ state, which (currently) has no exact analogue on
Android.
Briefly, the _foreground inactive_ state is the state entered when
switching from an app to the app switcher, receiving a phone call, or
responding to a TouchID request. Apps are permitted to continue
animating/updating views in this state if desired. From the _foreground
inactive_ state, the app may transition back to _active_ (e.g., entering
the app switcher then resuming the app), or to the _background_ state
(e.g., switching to the home screen or another app).
What to change
--------------
If your app does not handle the `AppLifecycleState.paused` state in a
`WidgetsBindingObserver.didChangeAppLifecycleState` implementation, no
changes are required.
If you do handle `AppLifecycleState.paused`, you may additionally wish
to also handle `AppLifecycleState.inactive`. For example, games should
probably pause on entering the app switcher rather than wait to be
backgrounded.
More details
------------
For background on Android application states see the state transition
diagram in the [Android Activity Lifecycle docs](https://developer.android.com/guide/components/activities/activity-lifecycle.html#alc).
* Revert "Test installation status when ideviceid is not installed (#10254)"
This reverts commit 0e5d4a87715100076c17a5bfcace8c8b583ec85b.
* Revert "Partial rollback of #10204 (#10256)"
This reverts commit b291bf5d6a9bf5a15717763d2b95a2c283f2fc5e.
Our emulator detection was based on a simple heuristic that was
failing for the Samsung Galaxy S8. Any heuristic is flawed since
Android devices can report whatever they want to adb, but this
change attempts to tighten the detection by listing known models
(by their ro.hardware property). Again, these values could be
spoofed by emulator system images, but it's less likely to be
an issue than with our previous (and fall-back) heuristic.
Fixes#10203
Related: #10248
* Remove '\n' from terminal input.
* Use trim instead of replaceAll
* Add unit test
* Cleanup the test
* Fixed lint
* Style adjustments
* Forgotten @override
* Revert "Forgotten @override"
Accidently added extra files.
This reverts commit 0aba24fc8ea321b3a4d0cd8aed7f589378393d96.
* Just @override change
* Let Theme insert an IconTheme into the widget tree
* flip the order, no real reason
* Let icon theme use its own fallback
* review notes
* more review notes
Eliminate the implementation detail of which function is called to
trigger vibration on iOS, instead report the vibration constant.
Also note that not all iOS devices support haptic feedback (e.g., older
iPod touch devices).
IDEA users sometimes want to create multiple Flutter modules
in the same IDEA project. See discussion:
https://github.com/flutter/flutter-intellij/issues/1014
In this case, we will actually have pairs of modules,
one for Flutter and one for Android. Renaming the
android module to make the relationship obvious.
But, don't delete the old file yet to avoid breaking
existing users. We can do that after the next
Flutter plugin release.
