Advantages of the non-monolithic framework architecture of Flutter

[Raju Bitter]

What is the best way to explain the advantage of the non-monolithic architecture of Flutter? Here’s what I could come up with:

1) Supporting custom gestures

You mentioned usage of custom gestures. But that’s possible using https://developer.android.com/reference/android/view/GestureDetector.html for Android with Gesture Builder. I get that you can add custom gestures for both Android and iOS just using Dart, which simplifies things a lot.

2) Creation of custom frameworks

Another thing which comes to mind is the fact that it allows developers to create their own framework (instead of the functional-reactive one shipping with Flutter).

3) Create visual objects which are based directly on rendering layer APIs

Guess something like the Space Blaster game you created earlier based on flutter_sprites is a good example for that. Just out of curiosity, how difficult would it be to do something like flutter_sprites cross platform with the same performance for Android and iOS - without going to C/C++ level?

Thanks,

Raju

[Adam Barth]

On Thu, Jan 19, 2017 at 11:05 AM Raju Bitter <rajub...@gmail.com> wrote:

What is the best way to explain the advantage of the non-monolithic architecture of Flutter? Here’s what I could come up with:

From my perspective, the primary benefit of using a layered architecture is that it provides a good trade-off between expressiveness and complexity.

The lower layers for the system (e.g., the rendering layer) is very expressive, in the sense that you can write a RenerObject that has pretty much any behavior your can dream up.  The cost of that expressiveness is that working with render objects is complex.  There are lots of subtle rules you need to follow and there are many ways to shoot yourself in the foot.

By contrast, the higher levels of the system (e.g., the widget layer) are very easy to use.  You just plug together the widgets you want and the framework takes care of diffing the new build against the previous build, and many other aspects.  The cost of that simplicity is less expressiveness.  There might not be a widget that behaves exactly the way you want.

Having a layered architecture lets you achieve a better trade-off between these factors than you would otherwise be able to achieve.  When there's a widget that does what you want, you can simply use it.  When there isn't a widget that does what you want, you can dig down a layer and express what you want at the lower layer, albeit in a more complex way.

This pattern repeats itself across all the layers.  For example, if you like the abstraction offered by the gesture library, you can use it to easily recognize taps and drags, but if you want to express a more elaborate gesture that isn't provided by the library, the code is structured in such a way that you can dig down to that layer of the system and interact with the gesture arena in just the same way as the TapRecognizer.

1) Supporting custom gestures

You mentioned usage of custom gestures. But that’s possible using https://developer.android.com/reference/android/view/GestureDetector.html for Android with Gesture Builder. I get that you can add custom gestures for both Android and iOS just using Dart, which simplifies things a lot.

The difference is the abstraction provided by the gesture arena.  That mechanism lets you compose different recognizers without each recognizer needing to understand the universe of recognizers.  The implementation in Android just hard-codes the interaction rules for the specific gestures that it understands.

2) Creation of custom frameworks

Another thing which comes to mind is the fact that it allows developers to create their own framework (instead of the functional-reactive one shipping with Flutter).

Yes, although that's probably an uncommon thing for someone to do.  It's more common for someone to dig down and build a new render object that has some bespoke behavior.  For example, when implementing the Cupertino library, we created a new render object to the iOS-style slider that behaves in precisely the way the its supposed to behave.

Adam

[Raju Bitter]

Thanks for the detailed answer, Adam. Very useful and good info!

[Raju Bitter]

I have two additional questions, Adam:

1) What kind of knowledge and experience with Flutter and framework internals to successfully use the rendering layer - without breaking the amazing performance goal?

2) And would you expect that an experienced Android or iOS app developer feels comfortable with using the lower layers of Flutter?

Thanks, Raju

On Thursday, January 19, 2017 at 8:35:14 PM UTC+1, Adam Barth wrote:

[Adam Barth]

On Thu, Jan 19, 2017 at 3:19 PM Raju Bitter <rajub...@gmail.com> wrote:

I have two additional questions, Adam:

1) What kind of knowledge and experience with Flutter and framework internals to successfully use the rendering layer - without breaking the amazing performance goal?

Everything should be documented.  There's just more documentation to read than for the widgets layer.  For example, RenderBox should explain everything you need to know about creating a RenderBox subclass:

https://docs.flutter.io/flutter/rendering/RenderBox-class.html

If you have questions that aren't answered by the documentation, feel free to ask (either on this mailing list, on stack overflow, or on gitter).  We can try to answer your questions and improve the docs.

2) And would you expect that an experienced Android or iOS app developer feels comfortable with using the lower layers of Flutter?

I'm not sure how to characterize what sort of background would be useful.  I suspect someone who was interested in learning it could learn it regardless of their prior experience.

My guess is the ideal background would be someone who has previous worked on the internals of a browser rendering engine.  Many of the concepts (and names) are drawn from that tradition.  However, I don't think it's necessary to have that background.

Adam

--
You received this message because you are subscribed to the Google Groups "Flutter Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Raju Bitter]

Correction for question #1:
1) What kind of knowledge and experience with Flutter and framework internals would a developer need to have to successfully use the rendering layer - without breaking the amazing performance goal?

--
You received this message because you are subscribed to a topic in the Google Groups "Flutter Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/flutter-dev/TH4jYTlpfaw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to flutter-dev+unsubscribe@googlegroups.com.

[Raju Bitter]

Thanks, that makes sense. And I agree with you, I read through some of those classes. They are well documented and well written, like all the Flutter code I've seen.

The reason I was asking in the first place: I'm writing an article on Flutter, and the reviewer of the article asked me for a better explanation of the advantages of the layered approach. I didn't feel like I have enough experience with Flutter to provide the right answer. Appreciate your help, some of your answers made it into the article. ;-)

Thanks, Raju

To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev+unsubscribe@googlegroups.com.