An Introduction to Google's Flutter


Jason Jerome

A software consultant; A lifelong learner. A developer of Android, iOS and React-based applications.

Updated May 10, 2019

Flutter is an emerging multi-platform application platform developed by Google, centered on Material Design and featuring aggressive composability with the Dart programming language.

Since the early days of computing, when software developers lived in caves, application platforms of all varieties were created in pursuit of the elusive dream of “write once, run anywhere”. Google’s new Flutter platform is the latest bid to achieve a cross-platform, high-quality user experience for mobile devices (and even the web, too!) It follows in the footsteps of the likes of Facebook’s React Native and Microsoft’s Xamarin, which in our opinion, have generally failed to deliver an acceptable level of quality in the user experience. So will Flutter meet its ambitious goal of becoming competitive with the true-native UI libraries for iOS and Android? Only time and testing will tell.

In the meantime, GenUI’s Jay Jerome covers the basics of this well-designed, clever, and fascinating new platform.

The following is the transcript of the above video from tech talk was given during lunch at GenUI on May 10, 2019

[00:00:00] OK. So, Flutter what is Flutter. Well it's supposed to be a single code. Single code base for iOS and Android. But it can also do web and some desktop stuff too. And that's all because of the Dart programming language.

[00:01:00] How is it built? It uses C++. I think like all these things always go down to C and C++, but it has Dart and then uses this 2D rendering engine which you may have heard of which I had never heard of called Skia. OK great. It's a 2D rendering engine. Happens to be used in Chrome as well. And since this is all Google based it makes some sense it is shipping with a modern framework. If you know React a lot of these like high level conversations start to make a lot of sense you start looking at the code and it'll start making sense what they what things are. They have different names, but they are very similar. And it is designed to be layered and customizable.

[00:01:55] So to do that they do this thing for performance called aggressive composability which I've been practicing for the last twenty-four hours. What that basically means is everything is a widget which would be like a component in React and everything is built of other widgets and there is just a widget of widget of widget all the way for this entire page. And they keep those widgets very simple and it makes it easy for them to traverse this tree and compile everything for the page. Example is the padding widget maybe on Android iOS you may have a TextView that has a padding property or something. You don't have that in Flutter. You have another widget called padding and that wraps your text view so that you can add padding. I have a little bit of code to show you. There it is. These are all are different widgets. This is a class. We've all seen classes before. At this level it is a stateless widget. It doesn't have any state. You override your build which returns surprise a widget. Material app is a designed widget for material style apps. They have another one for iOS called Cupertino that you can use as well. Here is a simple title, the home and scaffolding is your basic scaffolding is your basic app which has a title at the top and your body which is here's your app bar which has an app bar widget which needs a title which is a text widget and for your body. Here's a sensor widget with hello world right in the middle. We all love Hello world.

"...everything is a widget...and everything is built of other widgets and there is just a widget of widget of widget all the way for this entire page. And they keep those widgets very simple and it makes it easy for them to traverse this tree and compile everything for the page. "

[00:03:57] How is it packaged? So, for Android. They compiled their code down to a NDK project and then put that into an Android project for an APK An APK is the executable of the Android land world right now and iOS they do the same kind of pattern where they compile down to an ARM library and put it into a runner iOS project and put that into an IPA which is an executable like for iOS. So, when this app is launched the Flutter library loads the code and controls things from there. This may sound familiar. If you're in the mobile land this is similar to a game engine. When you write a game with C++ or something, you'll have a like a parent app that will load your code for you so that you can do that and that's where Google's really focusing is like, this is very similar to a game engine.

[00:05:00] Is the DART code compiled or interpreted?

[00:05:05] It is compiled for when it's on the app, but it can do both. I believe I did my homework correctly.

[00:05:13] Dart is the next topic. Dart is this modern and concise object-oriented language. When they first started writing Flutter, they actually used Swift and they were very afraid. This is where I always say like licensing and money come into play with code. They were afraid that this is before Apple open sourced Swift and they were afraid that if Apple found out what they were doing that they would get in some trouble like Apple would do something to mess up with them. So they just picked something else and they ran across Dart which is a Google language and they didn't even tell the Dart team they were doing they would just casually start writing questions and before they got to 1.0 like there were some like styling issues where like we don't know why the Dart team is doing this or does kind of ask them here and there and there was some bugs they introduce when they were like Oh really they really did know what they were talking about and we should have done it this way and they had to reverse. So, it's extremely similar to other languages and it does optionally type. Kind of like a JavaScript kind of thing. It compiles both ahead of time or just in time. Flutter uses both ahead of time would be you take all your code you package that together so it could run on the app itself. Just in time for at least for Flutter would be you're actually writing code it's running in the app and you add as you are writing it is updating the app in real time so that you can see what you're doing right. Right in the app I'm sorry on the phone while you're writing. Supports asynchronous program very nicely and has factory constructors which I find really kind of cool. I had not really seen that before. Darts subtext is usually like they're all they're all about just. We'll let you do what you want to do and we're going to get out of your way as fast as possible and it makes for some rapid stuff. So, a factory a factory constructor is you have this instance of this login service class here. So, we have this login service class. We have this instance when it first is loaded. It doesn't have a value it runs into this login service class factory constructor and it says OK if it's equal to null I will create an http service for you. And then I will call this private constructor down here and set it. And why would we want to do this? Because you can test this way you can mock. You can create your own http service which is complete mock run this class. It will nod. It will avoid this completely. You can call this directly and that's pretty cool. I really liked how that worked.

[00:08:13] Another thing you can do. They have Rx built in and they use this thing called the BLoC pattern which stands for business logic component pattern. I've got to think that somebody at Cisco came up with that. So, you're basically a quick Rx for them is you have this you have this pipe or stream which is a anything that goes in one side comes out the other. So, the input of that is a sync and output is a stream with a block pattern class. You give it no other way of accessing this class it is all by itself and you can only access it either by a sink or an output stream and to use it within Flutter we would use a special widget called a stream builder. This gets technical. I'm sorry. So, this is a, we're going to pretend like I'm doing a login here and I've already clicked the button to login. I have a class instance here called a login block and it's going on the out stream just like we would have an output here and then this builder is taking a snapshot of anything that comes down through this pipe and it gets there. It'll tell it's going to try to handle anything new that happens. So, when it first comes in you've hit the button it gets the snapshot immediately. It checks to see oh data is loading. It's not. It doesn't have anything yet. So, it's going to show this circular progress indicator. While we're waiting. Eventually the AUTH system gives you a login it puts it down in the same stream again. This thing is listening for that. It gets a new snapshot this time it comes in and it's like I am not loading anymore I have data. So, there it gets it's AUTH token and it moves away. This is really cool in Flutter worlds with state when you change your state you might have to rerun the whole page a stream builder does not follow that pattern it actually can render itself completely separate from the rest of the state which is a little bit more inside Flutter land but it's trust me it's cool.

[00:10:30] OK so demo this is where I try to figure out how to get out of here. And I have many things open. This is a standard, I wanted to do just a basic Flutter application and then I decided that I'm going to show you the example. So, when I first came into this, I started my own project that had like one or two examples and then as I learned more and more, I would add to that example. And then I had a big list of things that I wanted to show. I hate how that works. Every time I try to hit my play button it tries to tell me information about the screen share.

[00:11:23] So if I run this.

[00:11:53] Oh OK. It's already running. Here we go.

[00:11:59] So we have a bunch of different little examples of different things you can do. I'm going to go through some of this can you see this code. OK.

[00:12:12] Let's do this. We'll get the presentation.

[00:12:20] So at the top of our class. We have a, this is like your standard you are going in to run an app. You set a main function. And here is my main stateless widget my app which is the same app that I'm creating here and I'm just creating a material app and I'm going to cause this my home my home app page to run. I did do something a little fancy here where I set up some routes beforehand just so I could do a name I could just call a name and then have that run that that particular class for me. And if I go down here to my build function I just have to see here. Some these are just regular standard functions that are trying to help me do some stuff. But I'm going to go all the way down to my scaffolding and show you this is an Android, just doing a standard list view you might have to have a couple of different things set up in Flutter. It is literally just like a list view and it handles everything for you. It's very nice and I just have some of these functions that I passed by building these rows which are they go out of here are what we see on the screen. That brings us to here. If I can do all types of different little things if these work great. That’s a simple fade in fade out on based on the state value and if I go. Who doesn't love dogs?

"It is literally just like a list view and it handles everything for you. It's very nice."

[00:14:04] I have an API call to a dog API that just gives you a list of dogs and looking at that code they go back here.

[00:14:18] This dog widget thing is... So here I have a simple list of dogs.

[00:14:29] It's just an array of strings. These are going to be the URLs as soon as I come into my app. I'm going to call this load data class. I'm setting it to asynchronous which is really cool I have async await and it's very well I just find this fascinating. Coming from the Android world I had this thing. I'm making my call home a URL. I'm waiting for the data to come back. I do a set state which if you're using React you should figure out that there's a set state where you can make a change. And here I'm just decoding the URL decoding the JSON I'm getting each URL and I'm adding it to this dog's this dog's array or list. And then while it's waiting it's showing a progress dialog and then it builds, and it just builds a with a simple list view. But this was put together very quickly.

[00:15:24] This is pretty cool. Hello.

[00:15:27] How did this the other thing I wanted to show things that I really liked was so I could ask for things specifically on Android or iOS and I would do that using what's called a method channel and method channel is just this communication layer where I can go to Android or iOS and ask it for data and it will pass it back to me. So, at any point in a Flutter project you can you can go into Android Studio for it. It all is always building an Android project and it's always building an XCode project that you can always go into and use on your own. And so I have this getting battery state which is just setting up a method channel and waiting for when, when I ask for that call to give me give me battery if I go here and just say here's my battery level my battery level and it said Well it's a hundred percent. It's an emulator. If I go into something like let's go into XCode this is where I don't know how to zoom but there is a battery channel call right. I'm grabbing the method channel call from Flutter. And if it's matching up correctly with the call, I want to make it will make the call to iOS to get the battery level and then return that as a result. And it's pretty straightforward it's pretty cool how it connects back up. I feel that I have shown a lot of code so I would want to move on. Are there any questions about the code in particular?

"So, at any point in a Flutter project you can you can go into Android Studio for it. It all is always building an Android project and it's always building an XCode project that you can always go into and use on your own."

[00:17:20] Can I ask like a high-level question? I guess so with your experience with Flutter What didn't you like about it compared to like writing it native Android.

[00:17:29] I would love to answer the question, but I think you need to stick around for the latter half. I mean you wouldn't want to miss out on anything.

[00:17:39] That would be my hint as soon as I can get to the back to the presentation

[00:17:56] Annoyances- they just got to release it release version 1.

[00:18:05] I think they're now. I think that check this morning at 1.2. They before one they had a few breaking changes that were really annoying that you would just be wondering why things were broken all of a sudden and then you'd find out that they had had some sort of thing that they had to break. When I checked this morning, they did. They are very organized about it. So, if you're not lazy like me who just continues wondering why it doesn't work and you actually go to their help, they actually do have a section where they're saying here's all these things that we change that are broke. You are limited to what Flutter project builds you. It is using that rendering engine to do all this stuff. They are not calling native anything on iOS or Android. The joke I heard originally was that they were using a microscope to figure out all the pixels on an iPhone. And then I met somebody at Google, and they were like that is true. And so that's what they do. So, if something new comes around they're going to have to wait for another release for them to add that in there. Platform stuff at the same pitfalls apply as a lot of these other ones. There is going to be things that are going to be problems. The big one I always come up with is it's not 50 percent less work maybe 20 percent less work. You still have a lot of things that you have to pay attention to. I always say mobile development is very hard and it's easy to say it's easy until you have to actually build something that looks good and behaves well and doesn't suck and then it gets very hard very quickly. In this plat, in this example also I would say it's really easy to say I have one code base and I can do it but then you know it's very hard to deploy to both stores and just to deploying to one store is hard enough going to both. That's a lot of work. And some third-party libraries act differently between platforms. At Level 11, they had they used Auth0 for their login and all it's doing. You log in and it gives you a key back and which long string and that's all you need. Their Android they had an Android side and an iOS side and the iOS side if user goes into log in and they cancel you get a message back a call back saying that they canceled. On Android, they don't they just assume that you're timing out. And I went into GitHub and I started talking on one of their threads and they were like We don't see how this is a problem on Android you should just you should just wait for it to, time out. And I'm like, I'm not on Android I'm on Flutter so I'm showing some sort of circular dialog and then I. It's kind of a bad experience why can't you have these two platforms work together. It is things you have to work out for there's different kind of bugs.

"I always say mobile development is ... easy until you have to actually build something that looks good and behaves well."

[00:21:28] You're saying like Flutter like as an API as opposed to abstract away kind of the internals of how those two things might act differently. But you're forced to handle them both. Even though maybe you shouldn't.

[00:21:41] It's more of like it's just a different thing you have to think about. If I was writing just an Android app then I would know, that's the behavior of their API. But I am I'm writing this app that is going to hit both in it's going over to the native iOS code and it's dealing with a different team than the Android codes are both the same library and they've never thought of until now it seems that somebody might want both of those to act exactly the same. And it's just something to think about. It was a bug that we were wondering about for a while and then I was like This is why I'm here. I know a little bit of both.

[00:22:20] I can see why this is a problem.

[00:22:26] The other thing I wanted to say about this real quick was the rumor is that Google is going to use Dart and Flutter for their next Android thing which is called Fuchsia. It's apparently already set up for that. We'll see if that actually happens but.

[00:22:44] This gets into use cases for General UI. Rapid prototyping. It's very easy to build stuff very quickly. When I interviewed for Level 11 that asked me about mobile development, they were like Give us your favorite app to use. I was like you know not my favorite app to use because I don't have enough money, but I really like to BECU app. I think it's beautiful. They have this like translucent background there's this image behind there. In a way these like the way that you scroll through is just great. I can't even show you that without showing you how much money I don't have. But so, I explain this whole thing to them and they're like oh you ever try to like mimic that sounds like you know. I've always thought about it, but I never really did it. Android is fine. And after the interview I went home, and I was like I already know a little bit about Flutter. Let me just go ahead and it was like two hours later I had this app that looked very similar to the BECU app and it was very impressive how quickly you can get up and going. The async stuff is very straightforward the list view stuff is very easy. It's another use case would be easy to build custom widgets. One of the things that Google has said that you might not might not necessarily want to build an app that looks like it belongs to iOS or Android you might want to build something that more artistic that looks like neither platform and you can get away with that. They said one of the things that they always notice was a designer will say we want to have some by date chooser that looks like this particular way and then always the dev team comes back and says Can we use a native component because it's a lot easier we can get that done right away. And then the designer walks away thinking like every time I try to do something creative; I can't do that because we always want to use these native components. This actually opens the door up for them and there's ways of importing in animations and other cool stuff which I don't understand to make this work right within the platform.

" might not might not necessarily want to build an app that looks like it belongs to iOS or Android, you might want to build something that more artistic that looks like neither platform and you can get away with that."

[00:24:56] And they have tools to do that.

[00:25:00] So I'll just back that up. You know my day job; well this is also my day job and I got to do so by my Imikimi Web site and now Zo stream is all a platform like this. That one code base that deploys to everything and a lot of the arguments like you want each app to feel native on each platform. And I think there's definite justification that people will expect to be on their phone and have everything feel like it was their phone. But there's a strong counter argument which I make which is that well I really want that app to feel the same no matter where I am. If I'm on desktop or if I'm on mobile if I switch to a different mobile device I want when I go to BECU app. I want it to feel like a BECU app because that's why I'm interactive I'm not interacting with Google when I go to BECU. I want to interact with that. I want to have that a consistent experience. So, I definitely like that way of thinking. I argue that direction often.

[00:25:46] It's pretty neat is pretty neat how they are able to us to put that all in there I didn't get a chance to do that as much as I would have wanted but I know that they had I mean they had a designer that wanted to make some calendar that was like in dark mode and it looked ugly as sin and we were like maybe you shouldn't do it this time but it was pretty cool that they were able to do it and people, one of the guys that I worked with was able to implement the whole thing which was pretty cool. And then you have you don't have a single code base, so you do have you know enough management and wherewithal to stick to it. You can make this work. It's not 50 percent less but it can, it can pay off. And I believe that is everything I have. Let's find out. The next slide is not going anywhere.

[00:26:40] You can drop in the native anytime you want. That is super cool too.

[00:26:46] Quick question. So, I know we prototype like for mobility the React native. Right. And I wasn't about in the very beginning I was Flutter even ever mentioned. I mean like the app that they have us built is so simple. Would you think. Would you suggest like if you few if previous you would've been here sooner would you have suggested hey this is like a good candidate or Previous me one week into this project said that Flutter would have done it.

[00:27:14] That's why the reason to pick React Native it wasn't it was just to see if that's possible the experience I had and that was that it felt like it was to get a more polished experience like UI wise it was very hard. You can make a basic app which does all that stuff fairly easily and pretty straightforward. But as soon as you start putting in like the final touches to make the UI look great then it becomes exceptionally more challenging and you end up spending way more time in doing that stuff. for React Native at least. I understand from React Native is they create a lot of stuff that is hooking into native components and that gives them some problems from what I understand. And that was one of the reasons I believe Google wanted to stick to their rendering right to the Skia engine. They're staying away from their staying away from native components, so they have a lot of freedom for animations and for polish they stress that quite a bit.

"I understand from React Native is they create a lot of stuff that is hooking into native components and that gives them some problems from what I understand. And that was one of the reasons I believe Google wanted to stick to their rendering right to the Skia engine."

[00:28:32] I would argue that they could probably mean the ones that the ones that I worked with were we're looking pretty good. And that was before and they were looking pretty good before we even got to before we even got to polishing stage and I now I'm off script and I'm pretty sure that I have I have some of their this one was a bad example because this isn't black and white. App you got to log in here.

[00:29:03] They have this is actually the AUTH flow I'm not going to be able to show you this because I don't remember the password.

[00:29:14] Jason like you have you have a history and previous history with writing web apps like with react right. Mm hmm. And you also written mobile or attempted Mobile With React Native. Ah no not yet.

[00:29:26] I have not done React Native other than never getting it to run. But you seem like your pro like Flutter like giving it a try on other objects and spreading knowledge.

[00:29:39] Oh yeah. The thing I thought was really interesting was the I mean there was definitely it's kind of hard because I was thinking I was thinking because I had touched all these three different plat web iOS and Android.

[00:29:54] So I was kind of like going back and forth between them so I don't know if like someone the new one would be able to have that same experience.

[00:30:03] But at the same time the whole the whole model with like the React flowing kind of stuff the state management was really easy to pick up.

[00:30:16] Dart got out of my way a lot. I just it was just fine with whatever it was. There is still if then statements there's Rx that's there you just have to look up those things and learn them. There's testing the whole the whole the whole parts there. It's just a matter of taking some time out. But once you start doing it you start doing some interesting things. We at Level 11 we one of these is actually the project.

[00:30:50] We couldn't get this SVG. This is an SVG displaying.

[00:30:55] We couldn't get it to show in iOS and we knew there was, and I kept on saying like I don't know what's wrong. And they were like We don't have the right library. And I was like I think there's something wrong with the SVG. I don't think there's anything wrong with the library we're using. And I went back to my desk and took a Flutter. Just grab another Flutter example and put together a couple of libraries and send that same SVG into the app and then went back to them and was like look it's working in iOS it is working. We're going down the wrong path. We need to worry about the SVG itself not the not the library and stuff like that. I mean you can be that quick that can be really useful.

[00:31:39] I just wanted to share my experience with React Native.

[00:31:43] It seems that it's harder for people who haven't done have only done web development or do React Native than it was for me. Coming from a mobile platform was never done React before because you're still dealing with like two mobile platforms like the flow of the mobile platform and I would think the experience in Flutter would also be the similar where it would be more comfortable doing it, if you have previous mobile experience then learning just a different syntax of language.

[00:32:24] You showed a little bit about sort of the battery stuff. I'm just wondering, sort of across the board, Flutter versus just native code is it. Is it harder to take, generally harder, to take advantage of the capabilities of the phone like camera or messaging or stuff like that?

"I would say I would argue from the very beginning that any cross-platform solution is going to have some issues with this [taking advantage of device capabilities]. "

[00:32:44] I would say I would argue from the very beginning that any cross-platform solution is going to have some issues with this. There they have a lot of plug ins. They have all the plug ins for cameras and stuff like that that you would see. The thing that was really useful and which helped out the client was being able to go and give and call up native anytime you wanted, and you can even. I mean it's building it's building this iOS project over and over again with everything else on this Android project. I could even build this thing and then take the iOS part and just run it straight in XCode and debug it straight in there and so that that part I feel is like really the that's where you get if you get comfortable with that. And that was the part that I went right away for I was like I knew I know we need to do this. And anytime they had a problem they were like We want to incorporate this library and there's no Flutter version. We're like OK well we just split here, and we'll come back together once you know once they're done doing whatever it is. So, getting battery level or authenticating with a library that doesn't have a Flutter library we can call, and we can call their natives. And then once they come back and continue on there's no other questions, we're going to find some barbecue sauce and some barbecue.