 I'm Dilu and I'm planning to talk about why mobile developers should have a serious look at Flutter. Yeah, before start-up with things, anyone who has experience with Flutter? Okay. See, it's cool. It's great to see that all of you guys are new and because I can give you the actual thing behind that why, as mobile developers, why we should have at least look at Flutter. So this is basically about me. I'm currently studying at IIT and I'm part of GitHub Campus Expert Program also. I'm a training associate of engineer, so on 24-7, and we recently initiated Colombo Flutter Meetup at Sri Lanka. That's the first ever Meetup in Sri Lanka. So and this stuff, I'm kind of part of and I'm contributing to these organizations. So yeah, before moving to Flutter, you know, like nowadays we have this, we already had the mobile application development, right? So yeah, before I thought of like, before going jump into Flutter, if you can have a kind of a look at how mobile application development so far, then you can get the actual idea why I'm telling that you should have a serious look at Flutter. So yeah, when it comes to mobile application development, so we have these three platforms, right? So we have Android. They released the SDK back in 2009. So we have iOS. They released the FS SDK in back in 2008. And Windows. Do we have any Windows developers now? Okay, we have quite a very low number of developers for Windows. Okay, that's why I put the logo there. So I want to like, moving on, I'll only talk about these two because like, without comparing with Windows and stuff. So basically these are the major platforms that we are using today, right? The Android and the iOS. So like when it comes, even you are an Android or iOS developer, anyway you have to go through these layers because like that's the very high level layers that you have to go through in your application. So like, if you consider about the layers, like in the top part we have these widgets which renders your UI, whatever the thing that the users interact with. So that we, on your side we have the Cupercino widgets. In Android side we have material widgets with, they recently came up with these material principles and all the stuff that, to make sure that users are happy with the UI. So yeah, then the second layer we have the co-services and also in the Android side we have the application and the frameworks. So moving on, the third layer, that's kind of important because we have the co-OS in the iOS side. Comparing to iOS, the Android side we have the libraries and the runtime. And the bottom layer we have the kernel drivers in iOS as well as in Android side. We have Linux kernel and the device drivers. So this is a very, very high level thing. So like if you are just thinking about the native application development. Like in this part I'm talking about applications for single platform. Basically like, if you are developing application for iOS that means a single platform, right? So then again, if we consider a kind of high level architecture diagram. So here you have this application which was written in Java, Kotlin or Shift. Earlier days we used Objective C and in the other part we have the OEM widget box where you render the UI. So your application code directly communicates with the OEM widgets in order to render the UI. And also we have the Canvas and events in the same layer, in the same level. And whenever your application wants to use any of the location services or Bluetooth services or else assume that your project is using any other sensors, like any sensor, like you want to access any sensor, we call them through the services. So this is kind of a very high level thing about native application development or this application for single platforms. So whatever we do and whatever the platform we are talking about, everything has course and pros, right? So these are some of the pros that I noticed in single applications for single platform or the native applications. So like most of people telling that native applications are fast. So that's a key thing that hybrid applications are trying to achieve. So and it's also responsive. So also it has continuous support, yeah, because most of the native language native applications develop with big brands, right? Android said we have Google in the iOS side, we have the Apple. So and also the variety of features that we have, because we have already proven that Android applications or iOS applications, that's what today we are using, right? So it's already proven. And the community, that's the biggest part. So we have a lot of developers who has specialized in these areas, Android or either iOS. So moving on to the consite, the major thing that I see, as I assume you are a startup, you want to start a startup. You just want to make sure that you build mobile apps. So in your early stage or assume that you want to develop application for your freelance project or something like that. In that way that having two code bases, having two languages, it's the same case that every technology for multi-purpose, that's the selling point, right? That's how they promote it. So you have one code base for both applications. That's the anyway, I listed the same thing here. Also like maintaining two different projects and two different set of developers for both projects. It's again, it's a disadvantage. Assuming as a large scale company or a large product based company, so it's a disadvantage. So I don't know whether you guys have experienced that developing features in a synchronous way. It's somewhat hard when coming to native applications. So that part also I mentioned here. It's like if you are developing a feature in very synchronously, you have to put some effort there. So the next thing, like we had the applications for single platform. Then this one of the diagrams which shows the applications for multiple platforms. It has basically it's a kind of summary. So in this side we have basically two approaches, hybrid or the cross-platform approach. Maybe you guys are very familiar with these technologies. So one of these technologies. So if you are considering about hybrid approach, we have what do you call the application which was written in one of the markup languages like HTML, CSS to add styles, and we use JavaScript or a scripting language to add double logistics and stuff. So and also there are famous stuff like Kodowa, PhoneGap, and Ionic. Ionic is one of the very famous stuff for when it comes to hybrid approach. Then the other side is cross-platform approach. So in cross-platform approach we had maybe, have you ever noticed that we have two parts reactive and non-reactive? Okay. So moving on, these non-reactive stuff other than summary, I don't know whether anyone has used an accelerator? Anyone? Okay. So it's under the non-reactive part. So it's basically something similar to reactive, but it's more kind of, it's not developed in a very good way like reactive. So but the main reason reactive came up with they have then that reactive components. So in the other part, in the non-reactive side we have summary. Anyone have worked with summary? Okay. So summary is again, when you're developing large-scale, highly scalable mobile applications, we use summary which are written in C-sharp, and to the UI you can even use ASP.net as I guess. I would never work with summary, but I know the summary is there in the non-reactive side. So any react native developers? Okay. Cool. So react native is there, it's Google Flutter also there in the same area. So I'll talk about react native and Google how Flutter, how it differs in my next slides. So and we have the native JavaScript for write applications. So these are technologies that we are using to try to make sure that we can write applications for multi-platforms. So okay. So again, like before moving to in-detail stuff, this very high-level architecture about hybrid approach. Can you list what's the difference between the previous native architecture and this one? Anyone? Yeah, yeah. Bridge is there. Again, we have replaced the OEM widgets with something called WebView. So this is kind of a thing which runs on your browser. So it's basically we develop an application without thinking it as a web application. At the end of the day, it's a mobile application, but still we use a web view to render our things. So that way only we can communicate with the canvas or the events. And whenever the application, your hybrid approach application uses any of the sensors as in due to sensors or GPS or something. We have to go through this bridge because it can't directly communicate with the markup languages or the JavaScript languages. I'm not talking about the react native. This is something about the hybrid approach like Ionic or something like. We have this bridge in between these two steps. So moving to the pros and cons, in the pros side, we have a very good thing. We can do CI integrations, continuous integrations. So because we develop our application in the same way, we develop a web app. It's something similar to that. So even you can use your application as a web application. At the end of the day, if you have to change bit of UI and you have to make sure that some stuff are mapping your browser screen. So that way you can make sure that you can use the application as web application as well at the end of the day. So, and also we can use continuous integration. That's one of the key things, one of the key pros in hybrid approach. So moving on to the cons side, it's relatively slow because like OM widget, it renders the native components in cons side. But in this hybrid approach, what we have is a web view. So it has to make sure that the UI renders through a web view or inside the browser. So in that case, it causes some of the slowness in the application. Maybe you guys will experience lags, not for like smaller, small applications, but when it comes to large scale stuff, when we will experience those stuff. So it is one of the key points for use experience as I think. So moving on this cross-platform approach. This kind of a high level, very high level architecture for cross-platform approach. So we have the transfer native code in our left side, in my left side. So the framework libraries and SDK for non-reactive part, then this part is not basically a bridge, but we have something called JavaScript bridge. But in React Native, this is a very, React Native have very improvement way, improved way of communicating with the OEM widgets or the services. But still just to give you an idea about cross-platform approach, the entire technologies that we have in the cross-platform section. So it's something like this. So in cross-platform, did you notice that we have, again, we have the OEM widgets because the React kind of native, like when technologies like React Native, they can, now they can render native components as well. So then again that we, in this case, we have achieved that fast, the fast point, right? The native applications are fast, they are saying because they renders native components. So that thing we can achieve here as well, but not to that level. Like we experienced in native applications, but still we have the OEM widgets at the end of the reactive applications. So we also, in order to call with services, like we just have to go through it, RX bridge, the so-called JavaScript bridge, and the reactive part. So in that bridge, we have both non-reactive and reactive because in cross-platform approach, some of the stuff are non-reactive and some of the stuff are reactive. So this is the path for reactive stuff and that's the path for non-reactive stuff. So yeah, okay. I have the same thing, right? Not the same thing. It was a mistake. So I'll just keep it like that. So if I'm talking about the pros and cons in here, so I already mentioned that we have OEM widgets. So at the end of the day, we renders the same native components. So it's the look and feel somewhat similar to native components, the way it renders through the hardware. It's somewhat similar to native components. So even when you're accessing the services, it's way easier than the hybrid approach in these things. If you are considering about the cons in this approach still, that we can't achieve the frame rendering speeds, like assume like the native applications, we have 53 to 55 FPS. If you're trying to render something in that FPS count, we can render up to 55. But in this approach, I think in a cross-platform approach, we only can reach up to 51 or 50. So that was one of the major cons in hybrid approach. So if assume that you want to render kind of a very rich graphics application, so it's very hard to render stuff. We will realize the lags are there, the colors are coming, and it's still trying to render the colors. So those kind of stuff are there. So if I jump into Flutter, I'll talk about in a very brief way about the Flutter architecture, this is the exact very high-level architecture for Flutter. The Flutter has native ARM binary code. One you write with the dot language, so Flutter uses dot as the language, and they convert it to a native binary ARM code at the end of the day. And they have Flutter widgets. Flutter widget includes, maybe you guys have realized that in OEM widgets, we had Kupochino and Material both. So in same way, in Flutter, we have this Kupochino and Material widgets as an in-built thing in Flutter. So, and we have some thing called platform channels where they release all the plugins, libraries, to in order to achieve the services and all the stuff. So this doesn't work as a bridge because it doesn't convert anything. You can just import the plugin or the library, and you can directly call to the services. So yeah, Flutter runs on. So, as Google says, the Flutter runs on Jellybean and Android Jellybean up to, even it runs on ARM devices and up to 4.1. So, beginning from 4.1, the latest version to the latest version. So in iOS side, we have, we can Flutter supports iOS 8 or the newer versions. Also, the minimum hardware runs on iPhone 4s. So you can develop your application, you don't need to worry about the old phones or the old devices. So if we consider about the path, the Flutter came. So Google unveiled Flutter in 2015 during the Dart Summit, the Dart conference, or the Dart Dev Summit. So, and then they released their first alpha version in 2017, back in 2017. Then the 2018 was one of the most successful years for Google. The Flutter team announced the preview to the most stable version. We jumped into Flutter and tried some code and tried some application. So it was a very stable version where the developers started to, where the developers started to play with Flutter and what do you call, to make nice things in Flutter. So then they realized the current version is only have few fixes. So they released the version one back in 2018, December. So, and we are waiting for something called hummingbird. Without explaining about hummingbird, I'll keep that part for the last slides. So I'll jump into hummingbird in my last slides. So what is Flutter? So if I'm giving up just a short answer, it's the latest mobile SDK that was developed by Google Flutter team. And to develop high quality applications or high quality UIs, it can achieve very high quality stuff. Basically, I'll talk about the FPS rate that Flutter can achieve and all in later. So it supports both Android and iOS devices. And even in future, there's a project called Project Hummingbird, that's what I was showing in this diagram. So they are jumping to hummingbird in order to make sure that you only write once, you covered everything. So yeah, as I told, it's write once, run both. This is not a big thing, right? It's not magic. It's happening in every cross-platform or hybrid approach application. So it's one code base. So one code base to maintain. And also in Flutter, you have expressive, beautiful user interfaces. Some of the parts are very useful. I'll talk about those useful stuff. For now, it's very expressive and beautiful. So it has quick development. So the things come under quick development is like Flutter has something called hot reload and hot restart. Whenever you change application, assume you got into error and you fix that. I'll show you a kind of demo. So you fix that. You assume that you need to change the entire ABBA color in ABBA color, or a complete widget, or kind of thing, a complete part of your application. So it's just you change it. And one click on the hot reload button, it will appear. There's no delay between the rendering and the change. The moment you change the thing, you just press on the hot reload command R. It will build. It won't show you any progress lines or anything. It's that quick. So if you're looking to some kind of a demo project, once you've created the new Flutter project, Google giving this demo project which has the counter. You can press on a button and increase the number. So I have a pixel and the iPhone XR, which runs with iOS 12.1. This is the first time I'm running this application. So this project, so in the first time, it will take some time, as usual. But for further development, when you are working with the application, it won't take a lot of time. OK, so until it loads, you want to write one code base. And you need to deploy it through a mobile phone. And also then, as the extra. OK, that's why I told the hummingbird. There are a lot of surprises in hummingbird side. So just wait for hummingbird project slide. So now it's, I think, OK. This is the application which they give us as the demo application. So you can just press on a button and increase the number. That's the demo application. So you can see here the color is blue, right? The entire application or the app color is blue. So how do I show you the, OK. This way you can see how quick Flutter is. So assume you want to change this into red. Now it's made my change. Do you realize that? You may think the Android Studio also has the same button. But what it does is it renders the entire application again. So in Android, maybe you guys have experienced the same button is there, the kind of that button. So what Android does is they build the complete application again. But what Flutter does is it identifies the widget which changed, and it only renders that widget. So it maintains something called states. So it just refresh the state. That's it. Instead of building the entire application, it refreshes the state which helps to change the color from blue to red. So OK. I'll quickly go like since I have very limited time. So Flutter has something called, in Flutter, every UI a button, or whatever the thing we use, it's everything we call as a Flutter widget. So in Flutter, maybe a button or a menu, it's a widget. In a font color scheme or whatever, the padding stuff, aspect of layout, all those stuff are a widget. Even if you assume you want to capture a tap gesture, use a tap or something like, even it's a widget. So you can have a lot of widgets inside your widget folder. So you can reuse them. Assume you are creating a custom button, and you don't need to write it twice, so you just don't need to just import it everywhere. You just create a widget inside the widget folder. Just use it everywhere. So basically, what's a widget? If you're considering this part, the app buys a widget, and the hello world text, it's again another widget. So the scaffold, there's something called scaffold. When you're creating the scaffold, it's a widget. And the entire application is, again, a widget. So if you want to use this entire page, you just have to take the upper widget, and you can use it. So they maintain something, a widget tree. You can see, in this case, we have a card widget. And this is a widget tree, since I have only very short time, I'm moving on very fast. So you can just go through the Flutter widgets. You can just search for Flutter widgets. There are a lot of widgets. They have come up with everything, the shapes, and also everything is widgets. So they maintain the states, I told you guys, right? Instead of rebuilding the same application, the entire application, they only refresh the state, related to that part, or your change. So this is one of the key points that Flutter, it's capable of 60 FPS. And do you guys have here about racer phones, which you use to render games or graphics? It has 100 FPS capable screens. So even Flutter supports 120 FPS using the version one. So this high level architecture, this is there in documentation. We just have three main parts, the Dart framework, the Flutter engine, and the platform specific stuff. This is there in documentation, the entire diagram. So Flutter does not use OEM components. I was talking about this. So Flutter uses Dart, because if you are really comfortable with OOP related language, object oriented language, it's really the learning curve is very small. You can just learn Flutter within one week or two weeks, and just you can play. And you can develop beautiful apps. So it has fast allocation, and predictable high performance, the object orientation is there, and the developer productivity. So in Flutter, you can achieve the both native experience. In Android side, even you can write, if you want to see the native Android look and feel, instead of your custom feel, look and feel. So you can have that also in Flutter. It's built in. So it's free and open source. Even you can change the code and try out new things. So you can use these. These are the people who use Flutter. The Alibaba application, they entirely moved to Flutter because of the rendering time. Because of 120 FPS, Alibaba is using 120 FPS to render their mobile application. Google Ads now use Flutter. And these two, Hamilton. Maybe you guys have used Hamilton. So they are also using even the JD. So big brands are there, they are moving to Flutter. So one more thing, that's what I was talking about. So with the Hummingbird project, Flutter is capable of one code base, a Windows application for your desktop, a macOS application for your desktop, application for IoT devices, and also application for your mobile devices. So only one code base covering everywhere. So waiting for Hummingbird project, it's under development now. So next big thing in next December. So you can write one code base and have five or six apps for every platform. Isn't it cool? That's why I'm telling, start. Have a serious look at Flutter. Start learning Flutter, it's kind of an investment. You can just move to Flutter in next December. So this one of the applications which we do have, can you see the shape? How hard it is, how hard to achieve that shape in what you call in Android? You have to have import an asset. You have to design it using a designer, or you have to get help from a designer. So the thing is there, but still. So in Flutter, there's something called G Clipper. Just to import G Clipper, you can draw the shape. You give the points, 0, 0, that point and this. And you can just curve and adjust and all. It's simple. It's inbuilt. You don't have to import anything from outside. That's why it's fast. So I'll show you guys kind of a quick how fast, same application. I developed the same application using Android. And see the same shape and the same home screen. How fast Flutter is. See the shape is there. I'm importing the shape. I'm designing the shape. And I'm importing it to Flutter. The shape is already done. There you go. I was using the same laptop. I tried using the same internet connection, same. Everything same. Even the room temperature is same. Same place. It's done. 2,000 years later. So you can realize if you're working on a large scale project, how fast Flutter is. So yeah, that's the end of my last slide of my presentation. So yeah, the hummingbird. Just jump into Flutter and try out some stuff, because hummingbird is on the way. When you have a hummingbird, it's going to be a real cool thing. And it's from Google. Thank you very much.