I realize that preserving the existing implementation pattern is easier said than done, but the existing pattern is extremely simple and usable. The excellent sample in the documentation works with the architecture of Flutter and the Scaffold instead of working against it. The pattern of constructing TabBar, TabBarView, and TabBarController still makes all the dependencies that need to be provided clear, even though they depend on being built at different places in the widget tree to operate. This contrasts with the workflow for adding tabs to an app. This deviation from the established pattern sends the message that the collapsing appbar was not created as a first-class citizen in Flutter. They also need to know that SliverAppBar must be hosted inside of a CustomScrollView and that it must be provided as the Scaffold's body. They need to know that Scaffold asks for an AppBar but that dependency has to be ignored. The end-user of the framework now needs to understand how Flutter is implemented to know what to do. Instead, this pattern goes against the grain for how Scaffold is implemented. Now, the CustomScrollView is a dependency of the SliverAppBar, but the dependency is provided in the widget hierarchy instead of the parameters to the SliverAppBar.Īs a consequence, the development tools no longer help the app write itself. In the resulting code, the structure is no longer modular like it was previously, where every widget was able to define the things it needs to build. Your code should now look something like this: Make sure you keep your SliverAppBar at the top of the scrollview list, or you could get strange effects with the appbar showing up at the bottom of the page.There should no longer be a top-level appBar declaration.We will place a SliverAppBar inside the CustomScrollView with the script widget.We will remove the appBar field on the Scaffold.We will place our RomeoAndJulietScript widget inside of a CustomScrollView, and make the CustomScrollView the body of the app.To collapse the appbar, we need to go against the grain of the Scaffold interface, and remember a few more steps than we did to get started: While adding the drawer or the FAB to the app are steps that practically write themselves, making the appbar collapsible is more complicated. Now, let's give the user more screen space by collapsing the appbar when the user scrolls down. Part 2 of this tutorial would be a bit more complicated: The simple design and focused utility of this structure make Flutter very appealing to a first-time user, and the simplicity it affords was one of the essential motivating factors to convincing PMs and high-level stakeholders in leafy's organization that it was worth exploring as an alternative to native app development. More importantly, the interface to each constructor guides a developer through all the steps to build their app. Each widget is modular, so a change to the FAB affects the FAB and only the FAB, while a change to the AppBar affects the AppBar and only the AppBar, and a change to the Body affects the Body and only the Body. This example highlights the extreme simplicity and ease of use of the conventional Scaffold interface.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |