Future development of Flutter
Flutter is not without reference to Fuchsia, an operating system that has not yet been officially released. To quote Hiroshi Lockheimer, SVP of Android and Chrome, in a podcast about Fuchsia:
It’s not just phones and PCS. In the world of the Internet of Things, more and more devices need operating systems, new environments for software to run, and so on. I think there is still a lot of room for growth among many operating systems with different strengths and specializations. Fuchsia is one of them, so stay tuned.
Yes, Fuchsia is the operating system developed for the Internet of Things, or IoT for short, which is now being bet on all over the world, including Domestic companies such as Huawei and Xiaomi.
So what does Flutter have to do with Fuchsia?
Flutter is the only UI development framework officially designated by Fuchsia.
With so many iot operating systems out there, does Fuchsia have to stand out?
In my opinion, Fuchsia is the operating system of the Internet of Things that is most likely to develop, because apart from its own excellence, the biggest obstacle to the development of an operating system is actually ecology, and Fuchsia has natural advantages in ecology. A foreign report once said:
Google wants to seamlessly port Android apps to Fuchsia and has been doing so.
Imagine how other iot operating systems will compete once Google seamlessly ports its Android App to Fuchsia.
Here is a quote from the bottom of Google’s public account for you:
Inventing the future is better than predicting it
Flutter also has many competitors on cross-platform technologies, such as HTML5, React Native, Weex, fast apps, small apps, etc. I have detailed the development history, advantages and disadvantages of each cross-platform technology in the introduction to its development.
Will Flutter end other cross-platform technologies? I don’t think so. React Native hasn’t completely killed HTML5 over the years, because HTML5 has its own unique application scenarios, such as marketing campaign scenarios, news or blog details pages, that are perfectly suited to HTML5. Therefore, Flutter will not be the end of other cross-platform technologies, to sum up:
For a long time to come, there will be cross-platform technologies, but Flutter can be used in a much broader context.
Flutter nested hell
The most popular expression for Flutter on the Internet is probably Flutter “nested hell”. Why this phenomenon? In my opinion, the biggest reason is that most open source Flutter projects are written in this way (including myself in the past), which leads later beginners to think it is ok to write in this way. As the project becomes more and more complex, this nesting method brings great challenges to the maintenance of the project. Here’s how to avoid this nesting.
For example, to achieve the following effect:
Nested hell:
@override
Widget build(BuildContext context) {
return Column(
children: <Widget>[
Container(
height: 45,
child: Row(
children: <Widget>[
SizedBox(
width: 30,
),
Icon(
Icons.notifications,
color: Colors.blue,
),
SizedBox(
width: 30,
),
Expanded(
child: Text('Message center'),
),
Container(
padding: EdgeInsets.symmetric(horizontal: 10),
decoration: BoxDecoration(
shape: BoxShape.rectangle,
borderRadius: BorderRadius.all(Radius.circular(50)),
color: Colors.red),
child: Text(
'2',
style: TextStyle(color: Colors.white),
),
),
SizedBox(
width: 15,
),
],
),
),
Divider(),
// Write 6 for the same layout as above]); }Copy the codeThis is just the layout of the first item, and there are seven more, one of more than 30 lines of code, and seven is more than 200 lines of layout code, and this is just the layout code, if you add logic, it is unimaginable.
Maybe there’s a little bit of encapsulation thinking. Developers will encapsulate each Item as a method, written like this:
_buildItem(IconData iconData, Color iconColor, String title, Widget widget) {
return Container(
height: 45,
child: Row(
children: <Widget>[
SizedBox(
width: 30,
),
Icon(
iconData,
color: iconColor,
),
SizedBox(
width: 30,
),
Expanded(
child: Text('$title'),
),
widget,
SizedBox(
width: 15[, [, [, [; }@override
Widget build(BuildContext context) {
return Column(
children: <Widget>[
_buildItem(...),
Divider(),
_buildItem(...),
Divider(),
_buildItem(...),
Divider(),
_buildItem(...),
Divider(),
_buildItem(...),
Divider(),
_buildItem(...),
Divider(),
],
);
}
Copy the codeThis looks much better and basically solves the nesting hell problem, but there is a very big problem with this way of writing. Once one of the numbers changes, the whole page has to be rebuilt. A very important principle in Flutter development is to rebuild as few components as possible. Therefore, the component encapsulated in the method above becomes a Widget.
class SettingDemo extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Column(
children: <Widget>[
_SettingItem(
iconData: Icons.notifications,
iconColor: Colors.blue,
title: 'Message center',
suffix: _NotificationsText(
text: '2',
),
),
Divider(),
_SettingItem(
iconData: Icons.thumb_up,
iconColor: Colors.green,
title: 'I liked it.',
suffix: _Suffix(
text: '121',
),
),
Divider(),
_SettingItem(
iconData: Icons.grade,
iconColor: Colors.yellow,
title: 'Collection',
suffix: _Suffix(
text: '2',
),
),
Divider(),
_SettingItem(
iconData: Icons.shopping_basket,
iconColor: Colors.yellow,
title: 'Purchased booklet',
suffix: _Suffix(
text: '100',
),
),
Divider(),
_SettingItem(
iconData: Icons.account_balance_wallet,
iconColor: Colors.blue,
title: 'My wallet',
suffix: _Suffix(
text: '100000',
),
),
Divider(),
_SettingItem(
iconData: Icons.location_on,
iconColor: Colors.grey,
title: 'Articles read',
suffix: _Suffix(
text: '1034',
),
),
Divider(),
_SettingItem(
iconData: Icons.local_offer,
iconColor: Colors.grey,
title: 'Tag Management',
suffix: _Suffix(
text: '27'[, [, [, [, [, [. }}class _SettingItem extends StatelessWidget {
const _SettingItem(
{Key key, this.iconData, this.iconColor, this.title, this.suffix})
: super(key: key);
final IconData iconData;
final Color iconColor;
final String title;
final Widget suffix;
@override
Widget build(BuildContext context) {
return Container(
height: 45,
child: Row(
children: <Widget>[
SizedBox(
width: 30,
),
Icon(iconData,color: iconColor,),
SizedBox(
width: 30,
),
Expanded(
child: Text('$title'),
),
suffix,
SizedBox(
width: 15[, [, [, [; }}class _NotificationsText extends StatelessWidget {
final String text;
const _NotificationsText({Key key, this.text}) : super(key: key);
@override
Widget build(BuildContext context) {
return Container(
padding: EdgeInsets.symmetric(horizontal: 10),
decoration: BoxDecoration(
shape: BoxShape.rectangle,
borderRadius: BorderRadius.all(Radius.circular(50)),
color: Colors.red),
child: Text(
'$text', style: TextStyle(color: Colors.white), ), ); }}class _Suffix extends StatelessWidget {
final String text;
const _Suffix({Key key, this.text}) : super(key: key);
@override
Widget build(BuildContext context) {
return Text(
'$text',
style: TextStyle(color: Colors.grey.withOpacity(. 5))); }}Copy the codePackage into a separate component, will have a change of components as far as possible separate package, so that will not rebuild the entire control tree, enhance readability and maintainability, but also have a great improvement on performance.
A final conclusion:
Just because a Flutter is a component does not mean that everything should be written in a component.
Of course, this is just my personal opinion. If you have a better method, welcome to discuss with us. Start from me, standardize the writing method, and make a insignificant contribution to the development of Flutter.
communication
Old Meng Flutter blog address (330 controls usage) : laomengit.com