*music*
Herald: I would like to welcome our first speaker for the day and he's amazing. His
talk which he's been working on all night. A warm welcome!
*applause*
Speaker: Yeah good morning. My name is 'the one with the braid' and today I will
give an introduction into Flutter. What is Flutter? Flutter is a software development
kit for creating cross-platform applications from one single codebase.
Here you can see the great logo of Flutter. Brief history of Flutter: Flutter
was announced by Google in 2015 as a new framework for creating Android
applications. It was initially launched in 2018 and since that it has become one of
the most popular cross-platform software development kits. Getting started with
Flutter, well, we will have a look at the installation of Flutter, at one of the
special features of Flutter called widgets. There we'll have a look on two
different types of widgets called stateful and stateless widgets. And at the end we
will have a look at something really strange in Flutter: Unlike in actually
every other software you use for mobile development you write the design in your
code but not in any XML files but directly into your Flutter code. Installation is
quite easy on Linux and Mac OS. You can just clone the git repository from Github,
update your PATH and enjoy your new Flutter installation. On Windows you need
to download pre-built binaries as Windows is unable to execute shell scripts. That's
it about the installation. Now we will go a bit deeper into the technology Flutter
is using. Flutter is written as an extension for the language Dart, that's
what you can see over there, it's a framework for the language Dart. And you
can actually say the language Dart was developed for Flutter and Flutter was
developed for Dart. Actually no one is using Dart without Flutter yet, so it was
made just for Flutter. The language Dart is written in C++ and C and the so-called
Flutter engine is written and C++ and C too. Why? It's simply because this allows
low-level rendering, that means Flutter does not need any libraries of the
operating system it's executed on. So if you run an Flutter application on Android
you won't need any libraries of Android. If you run it on iOS you won't need any
libraries of iOS and if you run it as a webpage you won't need any JavaScript
dependencies. What does the engine provide us? The engine provides actually the basic
rendering of the layout, core functions like I/O access, graphic encoding and
decoding, animations, accessibility options and network of course. It's using
the Skia library of Google, it's quite well known in Android and even for desktop
development. That's what the engine does and on top of the engine you will have
which is visible, and which is visible is called widgets. An application is built
out of many widgets. You can just imagine widgets like HTML tags, you just put them
into each other, they have several childs and so on and you get a tree of widgets as
you get a DOM tree in JavaScript and HTML. That's how you can imagine of. Whoops, I
hate these buttons. Let's have a closer look at these widgets. As already
mentioned at the beginning we have two different kinds of widgets. We have these
stateless widgets, they provide no feedback. For example a simple text or an
image or buttons, a ListView, a table, they could be displayed as stateless
widgets. A stateful widget is able to provide feedback means you can tell a
stateful widget "if you press this button please do this". That's something
you only can do with stateful widgets but not with a stateless widget. But why do
you separate between these stateful and stateless widgets? Couldn't you just make
one type of widget ? It's due to better performance because stateless widget is
being rebuilt as soon as its content changes. For example we create a text
containing the variable "hello_world" with the text "Hello world" and now if we
change the variable "hello_world" the whole widget, this text will be
rerendered on the screen. Every stateless widget will be just re-redenred without
being able to be informed about a change of anything. And that's a difference to a
stateful widget. A stateful widget is able to say "Okay, I now want to change because
a timer was running down, because an event occurred because of I don't know what".
And a stateful widget is not being rebuilt by its upper widget, by its super widget
and so on. Means a stateful widget will not be changed if the state of the upper
widget changes. That's the difference between this stateful and stateless stuff.
I do not want to get deeper into the technology. Let's just have a look at some
shortened source code. If you write an application for example a mobile
application in Flutter it will actually be just this. Okay you will have to implement
this homepage but that's actually all you need. You have the main method in which
you call runApp() and there you provide an application, in this case a Material app.
Material means it uses the Material design. Material design is a design
standard by Google, you know it from Android but I could tell Cupertino app as
well then it would show an iOS like user interface or I could just create my own
style if I want but no one would like it. And there we provide just the homepage and
now we'll have a look at the home page. Here you can see a basic class in Dart.
Dart is the language for Flutter. You can see it is a stateless widget, means if the
app opens it will be built, if the app closes, it will be moved to trash. If - I
don't know what - if the system decides: okay better we say if I don't know what,
we reduce network traffic, so the stateless widget cannot react, it will
just get the information from the application and the operating system.
Yeah. We here... the most important in any widget in Flutter is the build method the
build-method contains everything which is displayed on the screen. In our case we
will display a ListTile, means one element of an ListView containing some
text and a button which will share any text if you press it. But that's not the
interesting part. Important is this build method which tells okay this widget, my
widget TestScoreDetail should look like this on the screen. Here again, this is
everything which is finally displayed on the screen, everything which is within
this build method. That was a stateless widget, a stateful widget is a bit more
complicated. You can see over there, there's not written just
JoinTestScoreTile, but JoinTestScoreTileState, means this is the
class containing the state and the state offers different - you could sort, you
could call them stages. First of all, the init state, in our case we do not modify
anything, it does not need to be initialized, that's why we just call the
super init state method but what you could do an init state for example who would be
loading something from network, if my widget should display - I don't know -
data from Wikidata and you would place the code for loading this data in the init
state method. This is being executed before the widget is built the first time.
Here you can see the build-method again and here I highlighted why we need a
stateful widget in this case. You can see here, it's an if-statement, a short and
inline if-statement. When you build the widget, it checks whether the variable
testLoaded is true, testLoaded is initially false so the first time the
widget will be opened, it will skip down there and it will show an progress
indicator, means a spinning circle in the center. And as soon as this should ever
change, it will as soon as this variable will get true, it will show this part and
that's why we need a stateful widget, because the widget has to react on
variables within the class. Over there, just at the beginning of the
implementation of this class, you can see some variables initialized at the
beginning. These are variables which are available within the class. It's just like
you can see the use, it's the only use in this case over there. And again, as it's a
widget, everything which is provided by the build, by the whole build method is
what the widgets, what the widget looks like. So in the first case it will be this
and afterwards it will be this. And now one more property of a stateful widget: Here
we return an expansion tile, you can imagine like a part of a list which is
expandable with an arrow button and if you press it will show some more detailed
information and there we set a listener on the change of its expansion and as soon as
it will be expanded, the first time, we will just execute this function loadScore
and maybe the loadScore function would be the function changing this boolean to true
and as soon as it will be changed to true we have our widget providing the
information within there. That's the main difference to a stateful to a stateless
widget. Now just a little compared to other cross-platform frameworks you maybe
know. I will compare it with JavaScript frameworks like React and Electron. Okay,
if you have a JavaScript mobile application, you usually load in webview,
consuming about 200 megabytes RAM. This is ugly for a mobile device, because no
mobile device wants to provide 200 megabyte RAM for five applications,
because not every mobile device has that much RAM. That's how JavaScript works
because you need a web viewer and webview needs all this stuff, webview needs a
JavaScript engine, style engine and so on. That's different in Flutter, because
Flutter code is being compiled to native code. Means if I compile this application
for Android, the code will be compiled to Kotlin code which is then executed. Means
no need for JavaScript, no need for virtual machines or anything like that. That's
why the consumption of memory is much lower. The next point is its native look
and feel. If you, for example, if you write an app in JavaScript you have the
problem that its JavaScript and not the native design of the platform. If I write
an Android app in Flutter, I can just tell the app: Ok, you should, you shall now
look like an Android app, provide material design, provide buttons which look like
Android buttons, provide a navigation drawer like an Android application and so
on. That's actually almost impossible with JavaScript but in flutter it's actually
the standard. Then this, there I will come to one of the problems of Flutter: It's
the same layout on all platforms. Means if I tell my application: Okay, you shall
look like an Android application, it will even look like an Android application if I
compile it for a Linux desktop or for iOS. Means you as developer have to decide
which layout will be used and this layout will be used or this design will be used
on every platform you deploy the app to. Of course, you can use some styling stuff
within the app to make it more like a native designed platform application for
your platform and no loss of performance is what I just explained at the beginning
as native app. I hope I could, I was able to introduce some bit of the idea of
Flutter, I would just now start like to start an Q&A about Flutter, about what it
is able, what you can do with Flutter and what you cannot do with Flutter. Thank you
for your attention.
*applause*
I don't know, shall I moderate? I would just ... oh, ok well then you can just
ask. Q: You said that is compiled to native
code and then afterwards we need a different tool change for each OS.
Do we have some experience, what is the effort, what do we have to do to, let's say
run it in *incomprehensible*
A: Well, you actually, the question was whether,
what you have to do for running or for providing one app at four different
platforms. Well, everything you have to do is running Flutter build and name of the
platform. So if you decide to deploy it to iOS, Android, Linux and Mac OS you can
just execute "flutter build apk" for Android, afterwards "flutter build ios"
for iOS, "flutter build linux" for Linux and "flutter build macos" for Mac OS. So
you actually do not have to go deeper into the single platforms. Flutter provides
everything you need there. Did I answer your question?
Q: *(incomprehensible)* A: Yeah, it will install it automatically,
if you download it, if you download Flutter and you execute it the first time,
it will ask you to install this and this and this, the Android tool chain, the iOS
Xcode tool chain and whatever you need to. Q: I have a question. At the main function
you just have to define your style and the home page right. So what is hindering me
to say: Release a version for Android to the Android style then just change the
style for something that looks more iOS and then release a different version for
iOS? A: Yes, sure you can do it and Flutter
even offers a parameter of material app, you can provide their theme data class and
within this theme data class you could tell the application: OK, on iOS I should
behave and look like this and on Android I should behave and look like
this. So even offers native functionalities for this.
Q: Thank you for this nice talk. Who has developed Flutter and how it is protected
by being bought by Oracle. A: I don't think Oracle will buy Flutter,
because it's developed by Google and I'm quite sure Google won't sell it. And as
its open-source, it will remain open source. I'm not sure about license, it was
I guess it was Apache or MIT license. So it won't become closed-source software
tomorrow. Q: Hi and thanks again for the talk. What
I would actually know, is the performance of all native components, I mean like all
native code the same on all platforms? A: Yes-No because some functions are not
available on every platform. For example, if I run the application on the web, you
won't be able to save local files or open local files, because that's not what a
website should do or just can do. But yeah, on the mobile platforms actually
everything is the same, on the desktop platforms everything is the same and in
the web, it's a bit different. Q: Hi thanks for the talk. What about
capabilities like Bluetooth Low Energy. Is there any restrictions or something like
that to get deep into the platform? A: Well, Flutter provides access to
Bluetooth. The only restrictions you may have is from your platform, but even if
you want to use a feature which is not implemented in Flutter, you can access
native code. So from flutter you can just call Swift code on iOS and Kotlin code for
Android and so on, if anything is not implemented in Flutter.
Q: Hey I was a little bit late, in the talk you maybe already talked about this,
but what kind of projects did you make with Flutter and did you think that
Flutter was a good fit for these projects or not?
A: Well what I do with flutter is actually everything running on mobile devices,
because I'm not such a huge fan of the native programming languages of iOS and
Android. I don't like Java and I don't like Swift, that's why I got used to
Flutter. And yeah, I think it's actually very good for this, because you only write
code once and then you can deploy to all the mobile platforms. Applications I
developed were mostly JugendHackt projects, projects of youth hackathons, of
the open knowledge foundations. Other questions?
Q: Hello. All the widgets are emulated and not native widgets of the operating
system, of iOS or Android? A: It's not emulated nor if you use the
native design, it's the native design. Flutter provides its totally own graphics
library, so even if you use Cupertino design on iOS, it's not the Cupertino
design from iOS but the Cupertino designed from Flutter. So independent of the
platform, it offers its own graphics library.
Q: So you lose the integration with accessibility features from the operating
system? A: No that's what I told on this slide:
The engine, the low-level engine provides a accessibility component, for example,
and, yeah, pipes them to the native platform.
Q: So what's the main advantage compared to other frameworks like Qt?
A: Better performance, I would just say and many more platforms, because most of
the frameworks are just - they are usually just available for mobile platforms.
Electron focus on, for example, for desktop platforms and flutter provides
them all and just from one single codebase and its native code you execute.
Q: Have you ever worked with background services, native background services on a
platform? Like Android service? A: Yeah, Flutter provides background
services and if you use them, it will just subscribe the native background services
of the platform you're using.
Q: What's the current state of IDE
integration because with other frameworks I had problems that the IDEs I use are
mostly the ones from JetBrains and those didn't work with all frameworks I tried.
A: Flutter offers official support to Android Studio and Visual Studio Code, but
for many other IDEs there are third-party plug-ins with language support for Dart
and Flutter. Q: Are there any restrictions on how far
you can make your app ready for, for example provisioning profiles on iOS to
get ready to in the store or is it just raw building for that platform and
everything else if you want to get it in the store or you have to go native?
A: No, I never had a problem with that. I published three apps for iOS. iOS has most
restrictions and I never had any problem, because the design of flutter follows all
the guidelines and they pay attention on following the guidelines of the maintainer
of the stores of all the platforms they support.
Q: The person there asked about IDE. I understood IE and that's a good point -
web platform: How the Microsoft browsers are supported as they are used heavily in
big environments. A: Sorry what was, what should I say?
Q: My question is how Flutter supports the Microsoft browsers, even if we don't want
use them all but we need do somehow. A: According to the README of Flutter Web
repository, there's no support for browsers by Microsoft and I even tried
once, you will see an empty screen in Internet Explorer and on Microsoft Edge
you will get many crashes. But this will change in January as Microsoft will start
rolling out the chromium based Microsoft edge to all Windows 10 devices and even
older Windows devices. So that's something, I say I don't care about .
*Music*
Subtitles created by c3subtitles.de in the year 2021. Join, and help us!