Tim Sneath, product manager for Flutter and Dart at Google, discusses what Flutter is, why it was created, and where Dart came from, as well as what the different layers of Flutter are and why it’s so popular. Host Gavin Henry spoke with Sneath about the “Architecture of Flutter,” what cross-platform development is and platforms supported, Dart, FFI, platform channels, threading, widgets, android, iOS, Windows support, web support, dart to javascript, why it’s different as well as what the future holds for Flutter, how big the team is at Google, and how widely it has been adopted within Google.
Show Notes
Transcript
Transcript brought to you by IEEE Software
Gavin Henry 00:00:54 Welcome to software engineering radio. I’m your host Gavin Henry. And today my guest is Tim Sneath, Tim Sneath is lead product management for flutter and dark working from Google’s office in Seattle. He joined Google in 2017. After 17 years leading client platform and developer teams at Microsoft in his spare time. He tinkers with various retro computing projects bottles with the New York times crossword or the 10th brother that customers aren’t out to get her Tim, welcome to the software engineering rigor. Is there anything in your bio that I missed that you’d like to add?
Tim Sneath 00:01:30 No, I think you, you hit a lot of interesting things there. Yeah, I’ve been playing with computers since I was a little boy, wee boy, I grew up in England and my very first computer was, an X 81. And it’s, it’s funny cause I still have that computer literally in my drawer and every now and again, I get it out and just Marvel at how computing has changed so much over the last years. We’vre living through an incredible time of, of, revolution that I think in a hundred years time, people will look back and Marvel that. So yeah, retro computing has been my thing for a little while.
Gavin Henry 00:02:10 And on retro, it doesn’t really take that long to become retro nowadays does it?
Tim Sneath 00:02:14 That’s very true. it seems like, there’s, there’s a growing lifespan for computers with, the decline of Moore’s law and with the way that various different efficiencies are shifting in terms of what performance looks like. It does seem that, people have computers that are seven years old and that wasn’t the case, at any other point in my life, it’s interesting to see how, how things are shifting and probably will continue to shift.
Gavin Henry 00:02:47 So during the show, we will mainly be talking about the architecture of flutter. However, I’d like to start with an overview of cross-platform development, flutters history and the dark programming language. So Tim, what is cross-platform development?
Tim Sneath 00:03:00 Well, that’s a very broad space of course, because people have been building software that runs across multiple platforms for almost as long as software has been around. Right. I mean, Unix is was a cross-platform or was written to run on different computing architectures and hardware. So the broad, the broad scheme of things, all we’re talking about here is, is writing software that isn’t tied to a single operating system or device, as we think about a flutter though, and we think about mobile technologies and cross-platform in, in this specific domain really what it means is that when you’re building, UI, when you’re building a user experiences, being able to take take those experiences to different kinds of device and platform and for, for us in, in flatter, that means building apps that run on iOS and Android on mobile devices, building apps for desktop that’s, obviously windows, Mac, iOS, Linux, and building apps that also support the web and being able to do all of those things from a single code base, being able to do them all from one, one set of code, which in the case of flutter is people write their code in, in dots. and that targets all of those different devices.
Gavin Henry 00:04:26 Do you think we should maybe tighten up the phrase or term cross platform development for cross user interface platform development in this?
Tim Sneath 00:04:36 Yeah, I, I don’t hugely like cross-platform as a term because it’s implies or historically has, has implied some kind of lowest common denominator or an experience that’s that is limited. We sometimes describe it from our side as, as a multi-platform because that sort of implies, slightly different range of optimizations and that’s, but, but every word is overloaded in the computing industry. I guess
Gavin Henry 00:05:09 It doesn’t actually make more sense to say multi platform does it multi-platform development.
Tim Sneath 00:05:14 Yeah. Multi-platform, multi-device to an extent, we, we, we go with the lingo, the domain creature that exists out there and we everything is built on something else. Right. So I think of flutter is cross cross platform development without compromise.
Gavin Henry 00:05:32 That was a much better definition. Okay. So if we, if we take the various components that we’ve mentioned there, windows, Linux, Mark Webb. And so I bring it back to just mobile for a few questions in minutes. So there’s been quite a few different, I don’t like using the word attempts, but a different of quite a few different frameworks over the past 10 years or so targeting. so you can have one code base and it’s, but so a version for iOS and Android windows, why do you think there’s been so many attempts and which brings me on to where did flutter come from and dark as well?
Tim Sneath 00:06:12 Yeah, well, I think there’s an immense, it’s an immensely attractive proposition to be able to build an application that can get to all of your customers at once is, is like one of those Holy grails for developers through the, through the years, you’re a startup, right. And you’re trying to prove that your great idea is, is viable. It’s, it’s critical that you’re not artificially limiting your access to customers, to just those that are running a particular operating system or have a particular brand of phone, or you’re an enterprise. And you’re trying to get your customer experience out to every customer at the same time with a consistency of experience and quality. again, it’s a very unusual environment that I can’t think of any, almost any other scenario that you’d say to somebody, Hey, we’re going to build three separate parallel payroll systems, for example, that are all going to be developed, have the same features and run in parallel with one another.
Tim Sneath 00:07:18 So, UI is one of those areas where we want people to be able to have that same consistent experience at least in terms of releases and time to market and quality without the sacrifices that sometimes come from that kind of experience. And that’s, that’s really the value proposition to use business language for flatter to give you that’s that ability to get a higher quality high-end experience to all of your platforms. simultaneously a little bit about where flutter came from and dart, which is the language that you built fluster applications with they both STEM from the web. Actually, there were two separate parallel teams working on different problems associated with web performance. and if you go back five, six years ago, both the flutter team and the dart team were exploring, how can we build a better way of how can we create better software delivery environment and for the dart team that came from explorations around Java script and virtual machine technology for the flatter team that came from explorations around UI presentation models and some of the limitations of at the time HTML and CSS as they then were.
Tim Sneath 00:08:38 And some of those experiments were focused on exploring what would happen if we deliberately broke backward compatibility. If we set back backward compatibility, wasn’t a goal for the web. What could that provoke in terms of disruptive insights to how the web is, is created and, not with a necessarily a goal to break the way, but, but more to understand where the limitations and barriers are in the web as we currently have it. And that led to a whole bunch of different insights from which came both flatter and data’s as a UI framework and a programming language, and also improved the web itself generated insights that’s create a better web platform for all of us to build on. And that is of course the web that we have today with, with a higher high quality pervasive experience. So that’s a little bit about the story of, of flushing it out to date.
Gavin Henry 00:09:38 And where did the name flatter and dark come from? Who, who has that?
Tim Sneath 00:09:43 Ooh, that’s a good question. Where did they come from? I think a flatter came from in part a company that we, we bought. it’s, it’s very hard to come up with the brand names and trademarks that don’t already exist. And so flatter I think we, we, we hadif you likename on the shelf that we had already been through, some of our trademarking and, domain name purchasing. And so that’s, that’s where I came from. actually didn’t know where dart came from as a, as a name. It had an an earlier name of dash, and then it became data that I actually, that’s a great question. I don’t know the Genesis of that piece. It predates me on the door,
Gavin Henry 00:10:26 I’ll Google after this, and I’m sure it links to the show notes. Yeah. So that was a really interesting comment you made about forgetting, see if I’ve got this right, forgetting the web as a sort of primary platform and imagining it wasn’t there and seeing what you could do, because I understood the, when you write the single code base and Darren flatter that the web output as it were of that code, when you build, it was quite a recent hard-on and only in the, in the beat of oceans, but the way you described it there, it was one of the first goals. Or if I misunderstood,
Tim Sneath 00:11:06 Yeah, it’s really funny. We’ve kind of come full circle, right? Because we started with this sort of presumption at least as a, as a presumption for, for the project. That’s the raking compatibility with the web was the only way to deliver the beautiful high quality experiences that we wanted to be able to bring to different platforms. but then as we got closer and further into the process, the web itself has continued to evolve. And so now we’ve kind of come back full circle and looking at how do we bring flatter back to the web? How do we take the UI that you create with flatter and translate it back to run on the web platform? And of course the web has progressed significantly over this period of time. We’ve, we’ve made a lot of progress in how the web has evolved and the web has improved in its own access to the underlying operating system, web continues to improve in terms of performance. And so we’re seeing that that’s starting to also have its impact in terms of how, how flutter is able to target that. and so as you say, we, we have started with flutter on, on mobile we’ve we added early support for desktop and web over the last year in a preview mode. And we’re starting to find that some of the improvements on the web are enabling us to build surprisingly high quality experiences. And that’s using things like , which is that sort of binary compiled station for for the web
Gavin Henry 00:12:38 Yeah. That’s web assembly, isn’t it.
Tim Sneath 00:12:41 The web assembly experience. and then canvas kit is a port of skier, the 2d graphics engine to ASM, and that lets us get that full kind of open GL like sort of experience for the web without sacrificing the performance that inevitably comes from all the other layers of things like the Dom and having to go through the traditional document orientated model.
Gavin Henry 00:13:11 Yeah. I was going to touch on skier later on in the show because that support the rendering part of flatter is if I call that right,
Tim Sneath 00:13:20 It’s if you drill down through the layers of flatter, what flutter is essentially is a UI framework that sits on top of a graphics engine and skier is the graphics engine. And that in turn is what writes the GPU instructions to actually physically read that,
Gavin Henry 00:13:36 That ties us back actually to assure we, we did I haven’t gotten to know the number, but it’s the one about writing software with Yuval Lowy, cause he speaks about architecting your software. So all the different bits or components, and that’s what you beat you basically did with flatter as, rather than have a primary target. You just made that a possibility, the webs of possibility that desktop support possibility, right?
Tim Sneath 00:14:04 Yeah. The shift is, is, is like historically, when you start a new software project, your very first question historically would be, well, what am I building, right? Am I building a web app or an iOS app or a windows app? And we want to literally turn that question on its head. We want you to start with the question of what I want to build. What is my grand idea? What is the design that I want to create and make that a question about and what platform does it run on? We want to make that literally, always the last question you ask and the packaging phase of your software development project, and that’s a, that’s a huge kind of paradigm shift, right? It’s a very significant disruptive idea, but with tremendous potential for shifting how apps are built.
Gavin Henry 00:14:46 Yeah. Cause normally it’s probably from building a mobile app, I need to do that way if I’m doing a web app idea that way, and it’s completely not the right question to ask you, like you mentioned earlier, it’s, what’s the, what’s the business need or the consumer need here and then the rest are so it’s a bolt on, right. I just wanted to reinforce a comment you made about creating the code base and then it works on the web. So I’ve been doing some flatter ups, just to get ready for all this and did one and then run it. So it spot out version for Google Chrome and it just worked immediately. I was like, Oh my God, this is amazing. I think when someone just picks up flutter and runs the demos and reads the, the high quality Ines of the documentation, I think not penny just drops and opens a whole.
Gavin Henry 00:15:36 I’m totally biased because I love it. But that’s the benefit of being a host. You get to pick the topics you want to talk about. So I think we’re almost finished my, the introduction section. We’ve got a few more minutes just to get a couple of questions in before we start to roll up our sleeves and get into the architecture. So could you give me a couple of minutes on if dart was created at the same time or flood as flatter or they were just parallel projects and you tried a few other things, what would you say dart is similar to you and why was it chosen?
Tim Sneath 00:16:07 Yeah, darts have very interesting language for a couple of reasons, it’s, it was very much a parallel projects to flatter it. They, they, they didn’t start at the same time. In fact, the very, very earliest prototypes of flutter use JavaScript as the programming language behind it. And dark was really very much a distinct project going on in a very different part of Google. It was developed in Denmark by our team in our in in Denmark and
Gavin Henry 00:16:40 The uniqueness of Google then, or?
Tim Sneath 00:16:42 Yes. Yeah, just, just a different physical location way outside of, of, the, the mountain view campus as it were. the things that are unique about data are really architectural and relate to its technical envelope. Typically language is focused on picking a particular, again, a particular niche. every language has its technical envelope, the space with which it’s perfectly suited, go, for example, has been very much driven by the needs of server development JavaScript of course, driven by the web Java. originally built around this, this JVM the Java virtual machine that has proven to be tremendously valuable over the years, but they all impose their own restrictions, constrictions specialties. And, and for, for dots, the things that are pretty unique about the dark technical envelope relate to two things that I consider some of the secret source of, of flatter.
Tim Sneath 00:17:46 Firstly dart is designed not around a single targets compilation environment. So dart supports both production, JavaScripts transportation and completion to native machine code, whether that’s arm or entail like 64. so that ability to target all of those different platforms gives data great deal of versatility. And then the second aspect of dart is that it’s both designed around a high quality development experience and a high quality run-time production experience. And so we have these two different compilers or two compiler modes for dots. During development time, we ship a small VM to the development targets, and that supports features like a stateless stateful hot reload in flatter, which means I can make changes to my father code and I can just patch the running code with the Delta and the VMs able to just accept the, the patch and continue running the code in real time.
Tim Sneath 00:18:55 And there are other languages that do that, right. JavaScript allows you to iterate and to make changes in real time. But what it doesn’t have is that production compilation modes JavaScript is pretty much designed around the Egypt, compiler that is there and is presence interpreting your code. And so that’s sort of one of the unique sort of strengths of, of, of data’s language. It, it has this matrix of both web and native compilation and developer and runtime execution. And, and it’s that, that, that two by two, if you like of those two different things that gives dots on envelope that is really quite unique compared to other languages. I can’t honestly think of another language that offers production quality support for, for all of those areas. There are, there are languages, that, that, that supports experimental modes there. For example, I think C-sharp has a an experimental transpired that to Java script, but there are very few that have that production tested quality for both of those two things.
Tim Sneath 00:19:58 And the fact that dart itself is used by Google’s ad framework. For example, our, our, our ad team uses dots for, for processing, for, for the, for the work to enable advertisers to, to, to bring ads to different devices. That means that we’ve, we’ve already demonstrated millions of lines of, of production quality code transpiles to the web. similarly we have, of course now hundreds of thousands of, of flatter apps that are compiled to native machine code. So again, that’s kind of the uniqueness of, of data as a, as a language. And it’s a, and it’s opportunity.
Gavin Henry 00:20:37 An odd portion of Google is not a trivial portion. So that kind of highlights the, the quality of the, of the chosen language. do you have comments on the long-term goals or plans for flutter at Google or is that just not something? Yeah, I mean, one of the,
Tim Sneath 00:20:57 I think one of the, one of the kind of core principles of Google one of those classic statements is if we focus on the user, then the rest follows and that’s very much been our organizing or sort ofcultural principle for, for flatter. We want to build software that, that people love and use and develop its roadmap and direction based off how people are actually using it. So we continue to invest in, in this broadening out across different devices. We’re seeing a lot of excitement about Flatiron, desktop, for example, lots of cool samples I’m seeing and prototypes that people are starting to build their, the web similarly. so we develop in the open, of course we have an open issue log. We look at the top issues. We look at real customers and how they’re using flutter and dots and, and evolve based off that. So I, I think, you can expect to see us continue to evolve the product based off of those needs. Our immediate focus is of course, to get the various difference announcements we’ve made so far to staple quality, and those are desktop and web on the flatter side. And sounds no safety on the dot side. And so those are the big immediate element
Gavin Henry 00:22:22 It’s in that roadmap. Yeah. Cause you mentioned sorry. Yeah, I know it just window support what, two weeks ago or week or week ago
Tim Sneath 00:22:30 The, the, the, the alpha for, for windows support.
Gavin Henry 00:22:33 Yeah. That’s right. No safety. Can you touch on that for a minute?
Tim Sneath 00:22:38 Yes, of course. Yeah, no safety is is that again, one of those kind of classic sort of language features that that seems to offer a tremendous promise of being able to control where the variables are, are nullable or not. and there are quite a few languages that offer support for non-availability being able to prevent or being able to express in the type that a variable is, is it cannot contain a null value. And the goal here is, is primarily minimizing errors, right? That no reference exception that people will be familiar with in many languages has been the source of countless bugs over the years. I think it’s been described as the, as the billion dollar mistake in the past. there are, there are good reasons for another ability, but, but being able to protect against that in guards against a NOLs appearing where you’re not expecting them is, is clearly valuable.
Tim Sneath 00:23:42 And again, one of the things that’s rather intriguing about DOT’s implementation is that it’s not just expressed in the code, but it’s, it’s a sound express an expression, meaning that’s the type is, is re ified throughout the lifetime of the code. We’re able to prove obli in-force non-availability throughout the code. So as, as your, as your th the flow of the pro programming logic goes, we can assert at the compiler level that there can not be a Knoll field in this type and many language implementations, particularly those that have retrofitted Notability or not availability not not sound, they, they support it, but at runtime, they still have no detection in there because for reasons like reflection or other language specification gaps, they’re not able to able to prove an assert that’s that’s, there cannot be a Knoll in a particular variable, and we’re just getting this word mainstream just literally last night, as we record this, we have completed the work to bring now safety into the flatter framework and our very, very, very early experiments with simple examples of sharing performance improvements of the five to 10% range and the same for reducing size of the code, because we now no longer need the instructions to guard code against another ability.
Gavin Henry 00:25:18 Well, I look forward to having a play with that and possibly doing another show on dark by itself. Okay. I bet move us on. So we’re gonna dig into the architecture of flutter. Now, the guts of the show, we’ve covered flatters history where its named came from why dark was chosen, how that developed. And I won’t say cross platform development, we’ll say multi. So I’d like to get down to the nitty gritty of what makes flatter tech. So what are the architectural layers of flatter?
Tim Sneath 00:25:51 I should preface this by saying I’m a product manager, not a software architect. So I kind of feel humbled by your some of the other guests you’ve had on the show, but certainly deeper than that I am or have.
Tim Sneath 00:26:08 But yeah, fundamentally at a high level, flutter is, is built with what’s in Hixson. Our technical lead likes to describe as the mahogany staircase. And the, the principle here is that we’ve built it as a, as a series of layers. And each, each step is a self self-standing in its own, right? It’s something that does not have privileged access to the layer below. And so every layer is theoretically optional and replaceable. So from the, from the ground up, of course, every platform has its own core primitives whether it’s something like open GL or direct tax or the, the layer that’s physically is responsible for the interaction with the underlying hardware, with flutter, we have a layer which we call the embedder and the embedder is responsible for setting up the application platform creating the interleaving the application with the underlying operating system, setting up Fred setting up the event loop handling the creation of a render surface and passing that across to the higher level layers handling things like passing mouse input and the touch input, depending on what device to the, to the higher levels,
Gavin Henry 00:27:28 Just to ask a couple of questions about that level. So there’s three layers in this, I would say after some research and then better, it’s probably the biggest obstruction layer. So it allows you to work with all the different things that you’re targeting is that
Tim Sneath 00:27:48 Yeah, the, the embedder is, is, is platform specific. So we have one of those for every platform we target, on windows, of course, the, that is written in C plus plus on iOS it’s written in objective C. and, and so you inevitably, that is the piece that is, is utterly specific from platform to platform
Gavin Henry 00:28:08 And on the bottom level of this framework, right? Yeah. Okay.
Gavin Henry 00:28:51 And is the embedder similar to, well, we’ll speak about the elephant in the room, react native, is that similar to those types of frameworks where they have JavaScript thought breaks into the bottom layer through channels or plugins need to plug in and does it work?
Tim Sneath 00:29:10 And I’m obviously no expert in, in react data. My understanding of how they work is that they provide Java script as a, as a language to target the underlying operating system.
Gavin Henry 00:29:25 Which would be similar place in the stock to where Doris possibly.
Tim Sneath 00:29:28 Well, I imagine it’s somewhat different because in, in react native, you create, for example, a button but react native. Doesn’t provide that button. the JavaScript code is telling the operating system to present a button, but I have no real concept of how that happens.
Gavin Henry 00:29:47 It’s it’s it’s probably a bad point to bring that in. I just wanted to highlight that the ambassador is the bit, that sort of platform specific, like you said, excellent. On the layer up from that.
Tim Sneath 00:30:00 Yeah. So then, so the embedder is, is again, is, is literally kind of like the bootstrapper if you like for the, for the application, the actual rendering takes place using the flatter engine, which is in the desktop and mobile versions is a C plus plus layer. You can see it if you could fill out the top layers, but that’s, that’s kind of the middle layer if you like the engine. So if you go to guitar, you can see there’s actually a repo for the engine itself. And it’s, it’s mostly C plus plus code. The engine is responsible for the actual physical kind of frame by frame composition for, for flutter code. So it takes the, the, whatever you write at the top level, which we’ll talk about in a moment and is responsible for compositing onto a physical surface.
Tim Sneath 00:30:53 So it handles things like, it’s time for a frame to be painted. I need to go and take the, the various different elements, the render elements, and physically composite them on the screen at the right resolution. I need to grab for example, assets, or I need to do the font layout and text layout, and rendering. I need to be able to handle an event like a mouse or a touch event and detect which, which element that, that, that affects. So I can bubble it back up to, to the higher level. So that’s the engine and say, that’s, that’s the native code. That’s C plus plus compiled code is, is a core part of, of the flatter engine. You, you, as a, as a flutter developer, never touch that. Of course it’s the low level implementation that implements the work that’s you, you, right.
Gavin Henry 00:31:51 So the, yeah, the developer works in the framework layer,
Tim Sneath 00:31:56 Right. Which is the third layer that’s right. So if the framework is the actual, the dot code that you can typically see if you’re using an ID like Android studio, visual studio code and you, you, you click into something like a button or, or a material app, or a, an animation, a widget that’s, that code is written in dot and that’s again, compiled because the dark code is compiled into the underlying machine code. And the framework is responsible for representing the engine to, to use a coat. and so that’s that level that has the, the core, if you like develop a like animation or gestures or the widget library, we often sort of say in flatter, everything’s a widgets and building blocks of everything that you see in, in flatter. And so, so you can see that code it’s is responsible for the, the orchestration of of high-level widgets, like a button into the lower level, widgets that’s or elements that are responsible for rendering that, which of course includes, maybe a background rectangle and some texts that it renders on top of that rectangle and perhaps a shadow or something like that.
Tim Sneath 00:33:17 and that’s what, that’s what the framework level provides in flatter.
Gavin Henry 00:33:21 Okay. I’ll just stick this all together so we don’t get lost. So we’ve got flutter, which has all of those three layers, and the three layers would be the top, which is the one that you work in day to day as a developer, which is the framework, which is pretty much dark, dark, all dark, but it’s confusingly called the framework when actually flutter is the framework of everything, right? So that star, and that’s where we saw live and breathe. Normally, then the next layer down is the engine, which is written in C and C plus, plus I’m not responsible for speaking down to the next level, which is the Embeda, which is the platform specific ones with our house objectives, C5, iOS, is it Java for Android or iPhone, Android? And then windows will be C-sharp Same for Linux as well. And those three layers make up the fluff tar name as it were. So in the dark framework, we’ve spoken about jets, as I understand the widget, it’s a name, and it has various promise to that name. And it does something. So how you would describe a widget.
Tim Sneath 00:34:40 Well, so a widget is really the unit of composition for, for flatter. It’s the, it’s essentially the building block of, of a flutter UI. So it’s, it’s essentially a declarative component that everything in flatter is built on. So again, if I think of like, a typical, the hello world app, if you like for flatter, typically there’s, there’s a material app, which is this, if you like the host application widget there’s a scaffold which provides the kind of classic, like a title bar, and you may be some, some, some tool bars at the bottom and the sort of the campus
Gavin Henry 00:35:21 Material we’re talking about, the material user interface, guideline, right.
Tim Sneath 00:35:27 Material design system, which is, which is one of of, of a couple of different ways you can build apps in, in flatter. But again, it’s the default. So I just picked that one up. So if it’s your lab scaffolds, that, that itself is a host for an app bar, which might appear at the top the canvas itself of the, the main sort of body of the app, and maybe, some buttons at the bottom, every one of those things are widgets. But then if I take something like that tool tab bar at the bottom, right, that is health is probably a combination of, four or five buttons that themselves, the widgets, along with a parent container that is itself a widget. And then if I drill down into the button itself, the button is, is probably composed of itself, multiple widgets, you know an icon and some supporting text and a background.
Tim Sneath 00:36:16 so you get the idea here, right? Really what we’re building up is is this sort of hierarchy of composition. And it’s the, so that’s the kind of core organizing principle for, for everything you build in flatter. when you create a widgets you’re responsible for overriding the build function to return a new element tree. And so if I create my own custom widget or I create something like, again, a material app, what I’m really doing is I’m representing the builds method. And that method is called whenever there’s a change in the state of the application to update the elementary, that then flutter itself is responsible for rendering. Yeah.
Gavin Henry 00:36:55 Yeah. So if you, if you imagine you’ve got, let’s take a mobile platform and Android simulator, you’re looking at the screen, or you’re looking at your phone. If you imagine every bill on that screen has got a little rectangle around it, that would be each one of those would be a widget and other languages. They call them components as well. And that’s made up of several widgets. And the tree is that starts from the bottom layer all the way up, or is it top down? How does that tree work?
Tim Sneath 00:37:22 Yeah, it’s, it’s kind of complex, but there’s obviously you can, th the nice thing is you could actually look at all the source code because it’s it’s, it’s, this is all dark code, right? So you can literally step through every element of this, but what’s going on is when you call the build methods in, or flutter needs to reg render something, it calls the builds method, and that returns the sub tree of, of widgets for that part of the UI. And as flutter does that build, it translates that into what’s called an elementary, which is the actual tree for, for the flutter sort of work site. And so each of those widgets themselves have a mapping to a corresponding element objects and some of those are what we call components, elements that are themselves that are hosts for other elements that gradually kind of get broken down.
Tim Sneath 00:38:13 and some of them are what we call render objects, elements that are elements that’s participate in the layout or the painting phases. So that might be something like a raw image which is, which is physically an asset to be rendered on the screen. And flutter is responsible for doing that work of translating all of those elements into gradually into the walking the tree until it gets to the lowest objects of a render objects, which provides flatter all it needs then to say, okay, now I can render this tree in real time. And so if you go into the flutter dev tools, we’ve built some tools that let you break down the tree and to see all of these, see the hierarchy of widgets and how they gradually are translated into, into elements. But it’s fundamentally that render tree of the, of the constructed lowest level primitives that are responsible for, for the actual painting of, of the, of the tree.
Gavin Henry 00:39:13 Yeah. The development tools are a joy to work with. And like you said, when you’re using one of the cuvees, you can sort of just click one of the widget names and drill down as deep as you want. It. It’s really nice. before I move us on to some other questions, can we do a quick example of say, you’ve coded up a button, you click it, and it launches the fingerprint biometric, or a face recognition part of your app. And you’re using that type of plugin. Can you just take us down from clicking that button, what layer that saw what it does in the engine layer, and then what happens in the embedder? Not too deep, but just to highlight the transition between the three. Yeah,
Tim Sneath 00:39:58 Well yeah, and you’re sort of probing me to sort of the edge of my sort of architectural sort of knowledge a little bit here, but I think you’re touching on a couple of points there. One is sort of how that transition sort of occurs, but then the other part is how it talks to the underlying native.
Gavin Henry 00:40:15 Yeah. Just honestly, for the listeners of how it speaks to this of part of the platform specific, but
Tim Sneath 00:40:23 Yeah. Yeah. So we have this sort of concept of what it did, and there are multiple ways to do it, but, but we have a couple of ways to talk to the underlying platform. One is something we call platform channels and platform channels provides a way for flatter code or written in dots to talk to platform specific code that might be written in something like Coppin or Swift or C plus plus. And what that, what that platform channel model provides is essentially a pathway for those two components to talk to each other. So my, my, my customer co dot code consent, essentially, a binary message that is, is essentially a serialization of the dots a parameter that I might want to send. And that is picked up on the other side by the custom IO coded through from the other end of this method channel.
Tim Sneath 00:41:15 So that custom Android code would typically have something like a an event handler for when I received this method call, then do this th this working in Kotlin or Java. and so that provides a relatively efficient mechanism for passing States and um calls from, from dots to the underlying Android or iOS or windows code, and then returning obviously back to the, to the flatter side. and so typically you’d use that in, in a, in a mobile way. If you look at our package ecosystem, we have, I don’t know, 15,000 packages that are built for four flatter. and typically that’s how they do things like, as you say, fingerprint reader or Bluetooth, or camera access, or any of those underlying things. We also have a second model that is designed for, for C API APIs, which is called FFI or foreign function interface.
Tim Sneath 00:42:19 And that provides a path for dark code to, to literally from the same thread be able to access, um C or C plus plus code by getting access to the, the memory store, if you like on the, from the dark side to be able to interact with C code. So for example, I can create a struct or something like that, that, that includes some, some state and pass a reference to that structure, to the C code and, and vice versa. and so that’s kind of like a deeper version of this.
Gavin Henry 00:42:52 That’s perfect. I just want to help the listener translate that last level of how it hooks into shell, that base layer. Okay. So I’ve got quite a few questions to dig in to now we’ve done the overview. How does the framework guarantee 60 frames per second? Because that’s something that I’ve always read as the sort of main selling point.
Tim Sneath 00:43:13 Yeah. In fact, the, the, the framework itself doesn’t make a guarantee there. What happens is that whenever a frame is whenever the phone or whatever device calls for a new, a new frame to be rendered flatter takes that call and executes this build process that I’ve sort of briefly touched,
Gavin Henry 00:43:35 And that’s the build function of the widget, isn’t it?
Tim Sneath 00:43:37 That’s right. That’s right. Yeah. And, and, and so everything comes down to a fast response to that build request, right? Assume just to simplify things greatly assume a 60 frames per second, as a fixed frame rates. That means you have what 16 milliseconds is that right? 16 times 60 is 1,016 milliseconds for everything to occur from receiving that, to having a new frame in the pipeline for the, the GPU to render. And so if you, if you miss your window there, if it takes you longer than 16 milliseconds, the train left the station as it were you’ve, you’ve missed your moment. And that’s what generates, sometimes people call jank or, or that sort of that delay or glitching
Gavin Henry 00:44:22 Yes. To screen, isn’t it a junk, right.
Tim Sneath 00:44:26 That’s right. And so, so for flutter to be efficient, and it has to do that, that stage fast. Now, of course, we’re calling a client code. If you say, to put a thread sleep in there, you’re not going to be done in 16 milliseconds. but, but we have a whole bunch of like a lot of the smarts in flutter is, is around efficient tree diffing to know what needs to be re rendered in that 16 millisecond slot. And so if we’re able to guarantee the only, the, the button that you’ve pushed for example has, has changed, then that’s the only bit of the build method we need to call. If we’re able to, to be very specific around only repainting the, the elements that have changed, we can be, we can be fast and, and that fast, that speed isn’t necessary. 60 frames a second, it could be 120 frames a second. It just comes down to the performance of, of the code and the refresh rate of the phone. And,
Gavin Henry 00:45:22 And that’s why the general advice is to keep widgets broken down into small widgets, with smaller build functions or the framework, and figure out not to change that, but I’ll rebuild it,
Tim Sneath 00:45:33 Right. There’s endless optimizations that you can make or not make it’s possible to build a bad application in flatter, just like any other framework. but we provide you with both hopefully good signposting and primitives to encourage you to build a performance app, and also provide you with tools to be able to see, you, you can actually observe your, your running application, you can profile it and see when when you miss the frame window, you can drill down and see, okay. I can profile it and see what it was, this particular widget that took longer to render that pushed me over the limit. And typically what you discover is that
Tim Sneath 00:46:16 Opportunities to make significant differences to how your code red that’s. For example, if you have a key and it’s possible to show, okay, this, this, this is the same as this from frame to frame to, that makes the diffing much more efficient. I now know that these two are the same things. So I don’t necessarily have to rerender everything from scratch, or if I have a state list widget that contains stateful widgets, and it’s only the state itself that it changes very irregularly, then flutter knows, okay, that’s the only bit I have to worry about. And so that’s where a lot of the magic really comes down to it as an architecture.
Gavin Henry 00:46:51 Well, and that’s two key important bits I’ve neglected to ask about is, is a stainless widget and a stateful widget.
Tim Sneath 00:47:00 This widget is simply a widget that has, has no changing States. it may have things on it, like, a text, a box that might contain some texts. But if we know that that takes is not going to change, there’s no it’s a label. We don’t have to worry about, every frame asking it, have you changed? And so that’s, that’s what a stateless widget is a state forage. It is essentially a widget that has some mutability in T in terms of the actual state. the, the mutability is, is stored outside of the, the widget, because as I said earlier, widgets themselves are immutable, but you can call funk flatter with a set state methods to essentially signal the framework that this widget now needs rebuilding. And that’s what gives that that flexibility there.
Gavin Henry 00:47:48 I understand. And we’ve, we’ve touched on platform channels. That was one of my questions. I’m not seeing the, the middle layer, the engine I wanted to ask about a dark isolate, where does that fit in compared to a platform channel?
Tim Sneath 00:48:02 Yeah, so I still it’s our, how dot does it’s, it’s a threading if you like. And I, this is what all the dark code runs in. It’s essentially space on the, on the machine with its with a single thread running an event loop and many, many dot apps actually just run everything in a single single isolate, but you can, you can create multiple isolates if you, if you want to. And they, the thing that is sort of fairly unique about dart is that each isolate is isolated, right? The name is it’s the clue there, we try and kind of create, um a suitable sort of firewall if you like between isolates. so that’s there’s, you kind of avoid some of the, sort of the dead blocking and sort of concurrency challenges that typically come from multi-threaded programming. So in, in flutter, there’s a function which is called compute that lets you run expensive functions in a byte background, isolates and returns the results. So for example, if you’re, you’re doing some number crunching or you’ve got an image that you’re processing, you can move that work to a separate separately.
Gavin Henry 00:49:13 I just wanted to highlight that sort of threading as possible and not layer. Absolutely. Which parts of these three layers would you say does the most work and which part cause the hardest to get right from a flatter developer’s point of view, not the user as in me, but for you guys.
Tim Sneath 00:49:34 Oh god, that’s an incredibly difficult question to, to answer, I guess I mean the embedder itself is fairly simple. That that is, that that is, is it’s goal is to kind of get in and get out as fast as possible. That’s that bottom level. Yeah. And so that’s, that really is just setting up the the run loop as it were, the idea of the event better is, is, is not that it’s sort of integrated and, and, and doing a lot of work each cycle right in windows, that might be, for example, the thing that sets up the message loop, there’s this sort of classic sort of dating back to the early 16 bit days of windows of a WM message loop that is passing messages. And so the embedded response responsibilities to handle, the WM mouse button down event say, or something like that, pass that onto the engine, but that’s all the engine has, has all the deep machinery, if you like, of, of, of flatter.
Tim Sneath 00:50:31 And clearly there’s a lot of smarts in the engine. The framework in some ways is, is a little bit higher level just by definition, right? It’s, it’s, it’s leveraging the primitives of the engine itself, but it’s a lot of code, right? That’s, that’s where a lot of the, the magic comes from flatter in terms of the actual, like everything that you experienced, a flatter, the, the, the primitives, the principles of the flutter they come from from the, from the framework. And so, there’s, there’s a lot of interesting aspects there. And when you, when you shift to the web, I haven’t really talked about the web much and how that’s, um engineered, but in the web, it’s just a little bit different because the framework again is literally the same framework. We don’t split the code base there. Your, your code is not the only code. That’s the same across multiple platforms. Our framework is itself fundamentally the same framework, but what’s different is, is there’s no C plus plus engine, there’s no kind of active X control to use old technology on front of the engine in the web view is, is simply an abstraction over the underlying browser platform, the web browser, API APIs. And so the web version, that’s all the code that exists that is unique to the web is, is exposing the web platform engine to the flutter dot framework.
Gavin Henry 00:51:54 Well, that’s a good enough explanation for me. So what do you think, or what do you know can’t be done at the lowest level of flatter? So the better, is there anything that you’re still working on or just doesn’t possible? Does that make sense?
Tim Sneath 00:52:08 I don’t think there’s anything that’s not possible in as much as we flatter really is the native experience. Right. So everything that we do is using the same APIs that you were built, if you’re writing any other kind of native application, if I’m building a windows application in, see I’m talking to exactly the same API is that I’m using from flatter and I can use from FFI with, with dart. So, we’ve, we built sort of samples that use a calm when the windows run time, those kinds of like a fundamental sort of windows, API constructs from fatter, you can build all of those different pieces, the pieces we’re still working on are exposing some of those things, more natively to dots. So for example, you mentioned things like touch or fingerprint recognition, you can call directly any of those system services from, from dot code, but it sure would be nice if there was some abstractions of those features to you as a dump dark developer. So you don’t have to know the underlying way that iOS or Android or windows for that matter implements, fingerprint readers. and so that’s, that’s really as we, the platform and extended that’s where the package ecosystem comes in with those $15,000 packages that’s provide common realized abstractions or API representations of those native,
Gavin Henry 00:53:38 And are those types of things done through the platform channels, or if you’re doing it in dark, does that utilize the foreign function interface, or how would that work?
Tim Sneath 00:53:47 You can use either typically if it’s API in a higher level language like Kotlin or Swift you’ll use platform channels to do them if it’s sees C plus plus then FFI is is a very viable technique. And so my little fun sort of evenings and weekends project outside of my job as a, as a product manager has been writing some of that abstraction logic for windows, given my history as a, as a Microsoft sort of windows kind of person. so I’ve taken the hundreds of API APIs for some of those core aspects in, in 32 and written data FFI primitives and any of your listeners that are a C sharp developer will be familiar with things like P invoke. And there’s a website called P and poke.net that provides a translation. If you like from a C to C sharp, that’s essentially what my wind 32 package does is provide that same level of of binding from dots to the underlying windows logic.
Gavin Henry 00:54:53 That explains why you were so excited when you did the windows about TV.
Tim Sneath 00:54:59 It’s fun to see these different parts of my career joined together at last.
Gavin Henry 00:55:03 Hi. Yeah, it must be, yeah. A real sense of achievement. A couple of these questions we’ve covered, which part of flutter creates JavaScript for the web version. That’s just the better, I think now that you’ve explained it
Tim Sneath 00:55:16 Actually, it’s a little more than that, because, because again, the framework, when you build a flatter app, like when you said you did your flatter run dash D Chrome, what’s happening is we’re actually taking the entire flutter framework and compiling it to Java script, along with your dot code for your own application, all of that gets compiled to JavaScript. And we do this thing called tree shaking, which is essentially to discard all the bits of the framework that your app isn’t using. So, if you’re not using, let’s say animation in your app, then we discard all that stuff. And we only compile the bits that you actually physically have in your app. And that sort of creates this minified JavaScript source file.
Gavin Henry 00:55:54 Wow. That’s that’s no, I was thinking how it worked. Excellent. So what part of those layers, which I think we’ve answered already, should developers really get to know to build a production flatter application? Yeah.
Tim Sneath 00:56:07 Yeah. You don’t need to know the engine for sure. Right. I mean, that’s sort of, that’s the, the swamps, the Swan swimming on the pond, that’s the legs flapping frantically underneath the water. The bit that is well worth, getting to understand is the framework itself. And, again, that’s sort of like one of the, one of the little benefits of fluster itself being written in data is that all of that code is very much exposed to you. So you, you never have to kind of second guess what is the button doing? What is a widget doing? You just read the source code and indeed we encourage you if widget doesn’t do what you wanted to do. we encourage you to just take it and copy it. And for kids rather than necessarily trying to do some awkward sort of sub classing sort of kind of model. So, if you, if you need a button that’s, pivots in 2.5 D space and does fireworks when you press the press, the button, you can, you can do that and all the sources there to do that. So you don’t have to, wonder if the button itself contains extensibility mechanisms for fireworks.
Gavin Henry 00:57:12 Yeah. So I’ve said that a few times already, but it was a really lovely experience when you’re using a part of the framework. And then you can just click through to that layer and through to the next, because it’s all there and just some really nicely written code and as well, I’ve got some ideas. Yeah. I think that sort of closes off for me, all the different layers and how they fit together. I’ve got a few more questions left over, and then there’s a couple, I’ve not done this on a shoe before, and I did give you a heads up, but I put a request out to the flatter community to say that I was going to have a chat with you, and if they have any questions, so I’ve picked a couple of other, but just before we go onto that last bit, I saw your tweet last week, I think about Google pay, getting rewritten, that’s been rewritten in Florida. Can you take me through any challenges you heard in relation to the architecture flatter or in general, but just maybe two to five minutes on it so we can, yeah, sure.
Tim Sneath 00:58:14 a couple of things that are interesting about that, and of course, they’re a separate team. we’ve, we’ve
Gavin Henry 00:58:20 Personally I use Google pay app every day. So it was it was going to be really interesting to hear.
Tim Sneath 00:58:26 Yeah. Yeah. so pay started some of this work by pulling together a couple of different apps. They had a slightly different experience for a couple of their, their markets in, in Asia, I think India, Singapore and there, there was a separately branded product originally called Taiz to easy or to ease it, I should say. that was was, was specifically targeted at the India market. And they, they worked working on bringing these different variants of Google pay together. and originally they started a small project to look at whether they could add flatter sort of step-by-step incrementally to their existing app. And they did a pilot project to see how that would play out. And it was one of those experiences where it’s a bit like the drug that is successful enough that you stop the trial, or you shift you shift Blake sort of how the trial works.
Tim Sneath 00:59:27 they discovered that they were actually getting so much done in flatter that they decided rather than do an add to act incremental migration approach. They decided no we’re going to bite the bullet and we’re actually going to rewrite the app in flatter. and so they pause the ad to app experiment and switch to a full rewrite of the project, which on the surface seems like a luxury, but really what they were trying to get was that agility of, of development to be able to build new features faster. and so what you’re seeing right now at least at the time of recording this in October, they are in open beta, I think in India, I think they’ve shipped the the new version in Singapore and they’re still rolling out to other countries. so if you’re in the UK or the us, you’re probably still using the, the original version of the app. although I don’t know, by the time this comes out, maybe you’re you’ll have it, but it’s a, it’s a full rewrite that they’ve updated user experience for the latest material design experiences. And as you mentioned, they wrote an article about it. They’ve been very, very happy with her experiences about this. And maybe we’ll, we’ll write a little bit more about how they built it.
Gavin Henry 01:00:39 Yeah. I look forward to those articles. So thanks for that. I’m going to move us on to some of the community community questions in the last few minutes of the show. So one of the major things that you have to deal with every year is new versions of Android and new versions of iOS and either in them or catching up with them. So that was one of the questions for the community, but that was probably about month ago. And it’s now the latest version of flutters out with, with iOS 14 support. Is there anything left in the iOS iOS 14 ecosystem to support in photo?
Tim Sneath 01:01:20 There’s always stuff left. I think it’s true of fluster as a whole. There’s always more things that we’re sort of, we’ve got a list of features to improvement capabilities that we want to support the but every, every release, I mean, we’re, as you say, there’s, there’s new things that come out for flatter and that we need to implement in flutter. I should say for, for those target platforms, we, we pay good attention to both sides. and now of course, windows and Mac and others and usually there’s a little bit of a bumps notice on, on Android. Of course, we get significant to downstate this cause turns out they they worked for the same company. we work pretty closely with, with Android, where we we’re tracking what’s what’s next.
Tim Sneath 01:02:14 Um and on iOS, we, we, we find out at the time that everybody else does, but Apple gives, a good few months notice of changes typically dumped up DC. And so we have a team that’s focused on adding those features, as you mentioned, in iOS 14, they added some new features like app clips which are a bit like the Android instant app supports. they made some changes to the UI. and we, we work on that. It’s, it’s a not insignificant amount of work but we need that work anyway for our own apps, like G like Google pay. And so our goal is to get that work done so that you, as an end user, don’t have to worry about about that. And one of the nice things about flutter is because again, we, we paint every pixel ourselves, we have control over the environment you get that supports sometimes going back as well. So, sometimes, material will introduce a new component for example. And it’s a nice thing about flattery is that component becomes available as we implement it for every version of Android. That’s, that’s out on the market, not just, the, the version, the very latest version. And so that gives us, I think, a lot of resilience for, for the apps that are built.
Gavin Henry 01:03:36 Yeah. Cause normally the argument for going native is that it will get a look and feel refresh instantly, or you’ve explained there. So you can bring a modern look all the way back to an older Android, is that right?
Tim Sneath 01:03:48 Right, right. Yeah. And in particular, you know bugs that are fixed or changes or just those differences that occur as, as, as technology moves on, you’re targeting and consistent platform across each of those different devices. And as long as the device itself supports, the, the core engine primitives, the skier sort of primitives, et cetera, that that gives us significant flexibility to be able to push back was a, was, I would just say quickly though, that, we do want to encourage developers to use the latest versions of flatter itself. Right? So as a flutter, one 22 came out. For example, we added support for some new system requirements in Apple apps for example, relating to text fields, there were some changes in how they implemented that. And so by upgrading your app to flatter one 22, even if you don’t actually make any changes to your code itself, you just recompile with flatter one 22, you’re going to get some additional advantages and some performance improvements on, on the latest releases.
Gavin Henry 01:04:49 Yeah. That’s something that I do. I did an art plast year and almost finished one this year and then just rebuilding it with the latest makes tons of improvements over the previous one. Okay. So summary of the is you’re happy with IMS 14, there was, there was a lot of questions about the demand or the wish for flutter to work with Golan. Is that something you’ve heard about brackets I’ve got here goes first-class targets. Is that something that you’ve heard in the, or it means nothing.
Tim Sneath 01:05:19 Yeah. it’s funny. My very next meeting after we’re done with this is connecting with my colleagues over in the go team. We see them as kind of quite complimentary because again, as, as dart is, is we’ve explicitly described it as a client optimized language. I don’t go with would be quite so explicit and calling themselves server optimized, but they certainly, it’s a, it’s a strength for them. and so we, we see those two as being very interesting as as
Gavin Henry 01:05:55 A combination of something we should keep an eye on
Tim Sneath 01:05:57 Maybe I think there’s been some interesting experiments also. I’ve seen go, somebody implemented some embedded for flutter using go to try and again, hit that breadth of, of platforms. So there’s, there’s all kinds of little interesting, interesting things as part of that sort of interplay between the two technologies.
Gavin Henry 01:06:17 Excellent. here’s the last, very specific question from a community member? Will there be a tool to move components from angular, dark to flatter web?
Tim Sneath 01:06:26 Oh, interesting. Yeah. Angular dart is something we use a ton internally. you mentioned ads right at the ad center. I forget the name of the ad administrative console. That’s all angular, darts app. the play store is built with, with angular dart. It’s a framework that we use primarily internally for those kinds of things. we make it available externally as well. although it doesn’t have the same level of community support and interaction that we have for, for flatter when we sort of somewhat throw it over the wall. we, we, we make it available to the community, but our aspirations Frank and adapt is not that it sort of becomes a flutter, like sort of broad, open source project, but for those apps that are angular dots, that integration becomes very interesting. and so, yeah, we’re exploring ways to maybe be able to embed a flutter web components in angular dots or protect potentially vice versa. I didn’t about tool for automating translation from one to the other. They’re very different in terms of frameworks, but, but, but I think, as particularly as flutter web starts to take off, you’ll see a shift and support and componentization to make interplay between those two easier.
Gavin Henry 01:07:49 It’s like anything that open source, if it’s out there, someone, if they’re interested enough, we’ll do something over a weekend and, it will blow everyone away.
Tim Sneath 01:07:57 People do crazy things. It’s just, I mean, even for flutter, I’ve seen examples of flatter running on X boxes and flutter running on embedded devices. I know there are companies that are using flutter in things like fridges and microwaves as, as the way show the smart displays on there. So yeah, I love that people do crazy things and sometimes we look at those and we’re like, okay, that’s actually a really good idea. We should, we should build deeper support for that in the framework itself.
Gavin Henry 01:08:28 Ah, look forward to reading some more about those. Okay. Tell him we’re to start wrapping up, although we can talk for ages on this type of stuff. So obviously flatters extremely important for Google and has a very exciting future. But if there was one thing a software engineer should remember from our show, what would you like that to be?
Tim Sneath 01:08:47 I think I would encourage people to listen to smarter people than myself. there’s some great talks from folk like Ian Hickson, who I mentioned already that talk on the mahogany staircases are fascinating.
Gavin Henry 01:09:01 Oh, okay. Sure. No, if you can drop me an email after
Tim Sneath 01:09:04 Yeah, absolutely. fascinating guide to, to, again, the sort of, some of the underlying architectural design constraints, but most fundamentally, I think I would just come back to that original sort of comment. Right. our goal is to do something a little different to what other historical frameworks have done whether they’re sort of system frameworks or traditional cross-platform frameworks, this, this fundamental shift of trying to build an native high quality experience for multiple platforms. shifting away from starting with your target platform, to starting with the application and trying to give you the tooling to create that native high quality experience on multiple platforms is the thing that we see as our guiding vision for flatter. it’s a big, in some ways risky bets, so far evidence has been promising but we continue to build on that and being open sources it opened a whole world of interesting ideas for that. And hopefully we’ll continue to develop that along those paths for many years to come.
Gavin Henry 01:10:13 And was there anything we missed that you’d like to mention or thought that would be mentioned?
Tim Sneath 01:10:17 I think you’ve done a great job of pulling out a lot of those interesting areas. maybe one thing I’ll just call out is the community. I think, one of the things that’s for us makes flutter such a pleasure is this isn’t a Google projects per se. It’s a Google sponsored open source project. and so some of the best aspects of flutter have been things that are seeded from the broader open source community, the Knoll safety work that’s going on as being largely driven in terms of the migration itself by a non Google contributor. And there are many other examples of that from big companies like Alibaba to tiny a single individuals with a great idea that they’ve implemented. And that, that makes flutter bigger than anything that Google can break into the majority of, of contributors to the latest release of flutter came from of Google.
Tim Sneath 01:11:14 And I hope that that continues along worlds com. I did like that when you do, I think you’ve been doing it for a while, where you do the release announcement and that lists the sort of top 10 contributors. It’s always really impressive to see that there are not people. Yeah. Yeah. Oh, just one question before we go, how big is the team within Google for flatter and dark? Is that something you’re allowed to share or, yeah, I guess we have about a hundred people across flutter and darts spread across engineering, product management, marketing, developer relations spread across flatter as a framework. Data’s a language and a runtime, probably about a hundred people. And what’s really cool. Where can people find out more? obviously they can follow you on Twitter, but if someone wanted to get in touch, what would you recommend? Yeah. a couple of places of course, again, being open source, all of our source code is on guitar, our roadmaps, our issue, logs, all those things are there.
Tim Sneath 01:12:19 And that’s where the team spends most of our time. It’s what drives everything we do. We don’t keep a separate, backlog that isn’t the published get hub backlog. Everything that we do there is, is visible. Also we chat, you can find us on discord where we have our various different engineering chat rooms. And that’s sort of the place if you’re physically contributing towards flatter or you have a a question about a feature you’re trying to add to flutter. that’s a great place to, to go. Okay, Tim, thank you for coming on the show. It’s been a real pleasure. This is Gavin Henry for software engineering radio and thank you for listening.
[End of Audio]
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected].
Related Links
- Episode 428: Matt Lacey on Mobile App Usability
- Episode 427: Sven Schleier and Jeroen Willemsen on Mobile Application Security
- SE-Radio Episode 300: Jonathan Stark on Mobile App Development
- Episode 409: Joe Kutner on the Twelve-Factor App
- A Clean Approach to Flutter Development through the Flutter Clean Architecture Package
- Flutter
- Flutter Architecture
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
