* Support thinning iOS frameworks to supported architectures
When building against frameworks that are distributed as
multi-architecture fat binaries, we want to strip the frameworks we
distribute down to only the architectures specified in $ARCHS.
This patch adds:
* The ability to specify commands to xcode_backend.sh (if none is
specified, run BuildApp for backward compatibility).
* A 'thin' command that invokes lipo to thin down the distributed as
described above.
* Add framework thinning step to iOS build
Invokes xcode_backend.sh thin on the build application.
* Limit architectures to arm64 in Xcode template
Flutter does not yet support armv7 iOS devices. Limit the $ARCHS build
variable to arm64 until then.
Also, move the creation of the ScrollPosition to ScrollController.
Finally, remove TestScrollable in favor of CustomScrollView, which is the
production version of this widget.
If you pass a ScrollController to a Scrollable2, you can use the controller to
read and write the scroll offset without having to find the Scrollable2State
object.
* Small Flutter strong mode cleanup fixes.
These are cases where strong mode down cast composite errors
generally indicated cases that would performance or correctness
issues if Flutter code was run in a strong mode VM.
* Fix Command API so that it is always in terms of Map<String,String>.
* Fix typedef
This patch converts the Shrine home page to using a sliver-based grid.
This required using a CustomScrollView to mix the block at the top with
the grid below.
We now create a GridLayout object that memoizes the layout information
for a given SliverConstraints. This approach is both more efficient
(because the delegate no longer needs to re-solve its layout for each
child) and allows for more code sharing between delegates.
The SliverGridRegularTileLayout will also be useful for the date
picker.
Also, document the grid delegates.
This patch moves the resonsibility for wrapping repaint boundaries
around children to SliverChildDelegate, which means delegates can choose
whether or no to use repaint boundaries.
Also introduce SliverChildBuilderDelegate to make it easier to use the
builder pattern with sliver lists.
This functionality will be used by date picker, which wants to use a
SliverGrid but doesn't need a repaint boundary around every day in a
month grid.
Someone on stack overflow was mutating the list of recipes and getting
confused about why the UI didn't redraw. Making kPestoRecipes a constant
might help avoid that confusion.
* allow mulitple observers for Navigator and MaterialApp
* add test for the navigator observers
* fix style
* add test for adding/removing a navigator observer
If ensureDirectoryExists fails -- e.g. because a file file of the same
name as the directory to be created exists, ensure that we exit cleanly
with a useful error message.
This patch makes Scrollable2.ensureVisible with SingleChildScrollView. A future
patch will extend the implementation to work with slivers. (Although the patch
does include some of the infrastructure for that part of the implementation as
well.)
This patch makes a number of changes to how you can configure a
Scrollable2:
- The ScrollPhysics is now responsible for creating the ScrollPosition.
You can override the ScrollPhysics by supplying a `physics` argument
to `Scrollable`, and the new physics you supply will be applied to
the default physics inherited from the ScrollBehavior.
- This patch removes the ScrollPosition/AbsoluteScrollPosition split as
all clients were operating in pixels anyway and the split made the
code very difficult to follow.
- ScrollPosition no longer depends directly on Scrollable2State.
Instead, it depends on an abstract interface that Scrollable2State
implements. This change has two benefits:
a) It removes the circular dependency between ScrollPosition and
Scrollable2State, which lets us split the code for these classes
(and several other classes that got wrapped up in that cycle) into
separate libraries for easier maintenance.
b) ScrollPosition is no longer bound to Scrollable2, which means you
could use the behavior machinery to drive other sorts of widgets.
For example, we could use it to drive Scrollabe1 if we wanted.
Subclassing FlutterAppDelegate is not required for real-world apps, but
it's what 'flutter create' generates, and applies the default behaviours
that most real-world apps will want.
This widget is a start towards replacing PageableList. There are still a number
of features that we'll need to add before this widget can replace PageableList.
