Lieber Zuschauer, dieser Untertitel wurde automatisch generiert von YouTube und dementsprechend (sehr) fehlerhaft. Wenn du kannst, hilf uns bitte gute Untertitel zu erstellen: https://c3subtitles.de/talk/2610 Danke!
[Music]
hello um welcome to the first talk of uh
alpaka Village or yugant Village for
today uh I will give a short overview on
crossplatform development using flatter
some of you maybe already have seen one
or another talk about it uh at least if
you are from the ug hact bubble um
today's talk is going to be a bit more
advanced uh so it's definitely not to
begin this talk uh since it's meant
publicly for uh the entire Camp um yeah
thanks for all of you being here this
early in the morning um yeah who am I uh
I'm the one with a braid um I'm Dart and
flatter developer working in healthc
care uh mostly working on Matrix apart
from what I do uh at work I'm interested
in FreeBSD uh Linux uh risk
architectures and I started getting in
touch with flatter back in 2018 so it's
uh if you're familiar with that's pretty
much when flut was released
um in order to say it in good Danish FL
flut uh well what is flatter flatter is
a set of stuff you need or you can use
uh for crossplatform development um it
consists of the dart platform Dart is a
programming language we will get get in
touch with it later um the flat engine
which takes care of uh rendering and uh
doing all the stuff on your uh device
running an flatter application uh
Foundation libraries so everything
making flatter uh while you develop uh
all the libraries you use design
specific widgets in order to have some
predefined uh design stuff in order not
to start from scratch every single time
you develop an application and uh very
important uh a huge set of death Tools
in order to simplify the developers
life so what do I like about this Dart
and this flut thingy um
the most common pattern in crossplatform
development for ages was developing in
JavaScript and having a browser engine
rendering it everywhere of course always
running a browser in some cases is a bit
inefficient uh that's why flatter uses a
different approach we don't have browser
engine we don't have JavaScript uh we
have the diet language compiling to
native code of course if we use native
code we have way better performance than
if we uh interpret some uh stuff in a
web engine uh of course it's cross
platform development uh you have a
single code base unlike if you develop a
single iOS application a single Android
application a single desktop application
a single web application you have a
single code base and you write your
stuff once and you can use it everywhere
uh of course When developing some
projects that saves you lots of time uh
work power and money at least if you're
a company um what I also prefer
is uh flatter adopts to your platform uh
you design your application once you
implement everything and it looks pretty
much similar on any device as you define
it but it adapts it adapts to the usage
patterns you know from devices to the
users are familiar with from whatever
platform they run their application on
and that also simplifies both user
experience and developer experience
because as developer I do not need to
take care of these uh fine fine-tuning
tasks and yeah that's already the last
Point developing man experience flatter
is designed around developer experience
not about yeah how to interpret a
language as close as a CPU would do but
yeah how to make a language in a way
developers would like it and you feel
that while developing flatter has a
genius uh development experience because
it is uh developed around uh the
developers and not around the CPU runs
on and basically all that helps us
getting rid of some Legacy patterns in
crush platform development simplifying
our lives and our users
lives so quick history about Dart and
flatter uh Dart as already mentioned is
the programming language stand alone you
can do anything with it well not
anything but close to anything uh that
was initially released in 2011 and had
absolutely nothing to do with flatter uh
Dart aimed to replace
JavaScript with a TI save language you
know as as in yeah we interpret these
language in browsers as likely most of
you have never used Dart as an
interpreted language in your browser you
see this approach AB absolutely failed
um so it it was a nightmare from the
implementation uh no browser started
implementing it so it failed to replace
JavaScript and uh the developers of Dart
uh which is Google uh were looking for
another use case for Dart um that was in
back in 2015 where they thought hm
crossplatform development is a bit
crappy let's use that programming
language weed designed and make
something for cross platform development
with it um so back in 2015 development
around flatter started initially it was
just an Android engine uh for Designing
Android apps but
in 2018 already um when flatter was
initially released more and more
platforms were added um first the second
or second platform was uh iOS later on
the third platform to run on was web and
later on desktop support was added for
Windows Linux um Mac OS nowadays even
the universal windows platform for these
crappy Microsoft Store app so it's
pretty
portable only relevant platform it does
not run on is um FreeBSD for reasons we
will get in touch with this trouble
later um I don't know has anyone of you
ever used flatter
before yeah some people
okay let's still have a short heads up
um yeah just some basics of flatter so
what is flatter it's mostly a UI
framework it's it's meant to design
fancy UI and to connect your UI to
whatever Back ends you have um the
elements of your user interface are
called widgets in flatter so as you
would have XML tags in for example HTML
web development or in uh uh traditional
Java Android development where you have
XML files um uh you have XML TX units
and in flat you have
widgets widgets are nested into a tree
as you know it
from pretty any other UI design um you
have widgets containing many uh children
um CH uh widgets may have siblings so
you all your widgets you have in your
application they form a tree from the
most uh basic ones being the entire
applications to the uh tiniest ones
which might be a small text or
whatever and flatter has a fancy
combination so the framework itself
ships a fancy combination of super
lowlevel widgets up to super high level
widgets everything from a single
rendering objects having nothing but a
size property up to a fancy animated
account choose a button for your drawer
so you have everything in between that
and that's a lot um and that makes
development super easy because you can
use highle widgets wherever they suit
but you can form super easy to use uh
individual widgets uh whenever you need
customized
design now he talking a lot about
flatter um let's get to some sample and
this is the shortest sample or more or
less the shortest sample I could find uh
that's a flatter app
um it's three lines of D code you could
write it in one line um it's nothing
but one witchet a text everything we can
see on the screen is a witchet in
flatter or not everything but most uh
most of the things we can see on the
screen is widget so this text is a
widget and we run an app uh run app is
uh I think one of the most relevant uh
highle methods uh of flatter run app
tells the engine okay whatever is
contained into to this function this is
what we use as application usually you
play some material app or some high
level stuff containing lots of stuff but
you can also just place a text inside so
this is the most basic flutter app you
can get it will do nothing but have an
empty screen with
uh Jud which is a Kling on version of
Hello World um yeah likely an ugly app
but that's a basic flasher
app
so we were talking about widgets uh we
have different types of widgets there
the basic two types of widgets are
stateless and state full widgets
stateless widgets as the name indicates
are immutable uh they're created once
and they have no State they have no
access to their properties they they
simply they they are being created um
based on their surrounding based on
their parenting widgets and once they're
built they're used and as soon as
anything changes
they're disposed and
rebuilt
um yeah so they do not have any state on
their own but this the entire State
Management of uh stateless widget is
handled from the surrounding Widgets or
in particular the next parenting uh
State full widget State full widgets in
opposite are the opposite of uh stat
less wit is what that's what I mean with
the word opposite um so they are mutable
modifiable rendering objects um a
stateful widget can react on its can can
have listeners can react on uh user
input uh can change its state you can
have for example delays in there doing
something you can have animations going
on or everything which is changing the
properties of a widget on it own uh is
usually a state full widget uh so
they're capable of self modification to
say it in very simple
words so how to use uh stateful widgets
where to use stateless widgets uh what
What's that stuff how do I want to form
my code
um have as few State Management as
possible so whenever you can use
stateless widgets because uh the life
cycle of a stateless widgets is way
easier and way less heavy to compute for
the engine that's why always use State
list widgets apart from the the parts of
your code requiring State Management um
and if you do State Management use
methods like did update widgets uh in
order to check whether your environment
changed whether you need to react on a
change or whether you can just stick
with your current state of a widget
without trigging rebuild and
relayout
um yeah so uh common pattern in flatter
is having a controller
being uh given as property to uh widgets
in order to minimalize uh the
interaction of the widgets on their own
and use keys keys are property of
flatter keys are tiny classes uh you can
provide them to widgets and if a key is
equal to the previous key on a rebuild
of the screen uh we stick with our state
and we do not reinitialize which saves
us some performance um yeah now some
just basic patterns okay that was
details about how to optimize
performance but uh what do I need to do
some so to make some basic flatter
application I mean yeah fine you can
Nest some witchs but you usually want to
do some more interesting stuff um for
example routing uh most applications
websites whatever have many pages have
NE Pages reacting on S stuff and
navigation history handling can be a
difficult time askk uh flatter has some
pretty fancy mechanisms for that back in
the past years that usually was vrouter
uh but nowadays flut ships uh some a
core package called go router and go
router takes care of most of your
routing tasks navigation tasks uh and
also fancy stuff like nesting Pages if
you want to have a different layout for
desktop you can Nest pages into each
other which is quite comtable for
development um it hooks into the
material app. router cotino app. Router
or witchet app. router and his hand
navigation provider it's super
extensible you can Define Uh custom uh
page transitions um there uh you can
provide page builders in order to have
uh yet another possibility to change uh
transitions between uh pages and Ys it's
simply easy to use um here's a very
short sample how to use a go route how
to use go router if you use go router
you once declare a router with a set of
routes they can be nested for example
here we have uh our root route which is
slash as as you know from URL navigation
then we have a nested rout which is
details so in full it's SL details and
there yeah there we get to some details
page and that's everything uh of course
there are some other options uh you can
add in order to make it more fancy but
that's everything you need in order to
have uh good and usable navigation uh
during development um when using this
router you simply provide it to your uh
app provider which is material app
kutino app or witches app and then the
do router uh Constructor usually enables
you to uh take router config and use
your router and afterwards it's you
simply use uh context. go context. push
context. poop and you navigate through
your history with some Advanced uh
routing another very relevant thing
about software development is storage
you usually need to store some user data
if it's the HTTP access token your JWT
to access your server backends if it's
the user data you store you will store
data and first relevant Point Json is
not a storage Json is a data format for
data transfer it's not meant as a
storage it's the most in not the most
inefficient but a yet inefficient way to
store data that's why let's look at
mechanisms not to use Json in some files
or some whatever as a storage but um
some native or at least uh more
performant ways to store uh user
data there are a couple of start
solutions in flatter um four of them
presented here SQ Li I think anyone who
ever developed uh front-end software uh
at least in traditional desktop
development uh was touching SQ also if
you developed server stuff um SQ is
something you often touch site is simply
as SQL uh database you can store in your
application uh yeah
simply it's been there for ages it's
useful it won't disappear and that's
fine but there are you know more fancy
mechanisms to store your data in flatter
um for example Hive and esar are some
super fancy storage projects Hive is uh
dark native uh database
implementation uh storing all data as
binary objects we will look at Hive
later today so that's uh everything
about Hive as of now and eer is
something more or less similar it's also
an object store but it's a query based
Object Store so it's more less the
hybrid of Hive uh and SQ light if you
want to call it that way um it's written
in Rust uh that's maybe a curse
combination flatter and R but it's uh
getting more and more popular um because
especially on the io platform so on
mobile devices and desktop devices uh
you can archive better performance using
the rust implementation compared to the
do Native one um whereas the web
implementation of Isa is way less
efficient so it depends a bit on your
use case whether that's the more
performant one or less performant one
and the last but not least and I think
that's unfortunately the most common you
have some shared preferences and drop
some Jason in there Jason is not a
storage it's not a storage please don't
use it um some more words on hive um
Hive is super fancy um some things about
that one apply on Isa too um because
Hive is super dark native you have type
adapters um so you can store a runtime
object just put it into a hive Object
Store you can just grab objects from
your hive object store and they will
restore as native diet objects uh as
soon as you define a type adapter
they're listenable so you can just
listen on changes of a box and as soon
as there's a change you can um rebuild
your screen about it for example if you
have a list of stuff stored and once
there's the next item being inserted
because for example you receive it via
web uh stuff and store it um as soon as
in the Box Hive communicates to any
listener hey rebuild this is your new
item and that's super comfortable and
pretty efficient uh for
development hi renders if you want to
call it that way uh on different back
back ends uh there's the binary writer
uh used for um IO platforms again so
mobile and desktop uh where it simply uh
serializes any object you give it into
some Dart uh Native
uh types and write them in a binary
storage um the renderer for the web uh
is indexb so the stuff is serialized
into native uh JavaScript objects uh and
WR being written into an indexb and the
fancy stuff you can do all that in a web
worker because I don't know how familiar
you are with web development but if you
saw lots of data in your index Tob in a
main thread your application is going to
be very slow uh that's why uh Hive is
using web workers on demand in order to
uh speed up or not to speed up it
technically tastes short time longer but
it does not block your main threat and
fancy stuff um Hive has an encryption
API so you can provide ciphers there are
some ciphers PR defined uh Native Dart
ciphers for as there are also some um
uh uh Native uh platform native ciphers
you can use for example using the Java
crypto API and Android so they are quite
fancy methods to uh encrypt your
database which is pretty useful for data
address encryption especially I don't
know if your application has a
passphrase lock you can just use a
passphrase um for uh data addressed
encryption and stuff that's pretty
useful at least for privacy and uh
something yeah for Relevant
data uh yeah here I have a so straight
sample of um Hive this is how you write
a um type adapter um you simply have a
definition of a d class you have with
person with some properties name age and
a list of friends the person hopefully
has uh let's hope the uh list is not
empty and if you want to uh support this
type in Hive in order to just you know
put a an instant of person into your
Object Store
you add Hive type it and it will
generate uh
some part part of the code uh with some
type adapter you can uh provide to Hive
in order to serialize and de serialize
Hive types that's super useful uh makes
development sometimes very easy because
you don't need to hle with Jason's
serialization and der serialization it's
simply comfortable um yeah so far and
now we're talking about routing we're
talking about some storage and why Jason
is not a storage and let's get to how
flatter is ring because I'm Al I'm
always a fan of having performance code
and if we want to have performance
applications we always need to take care
of having performance frontend stuff
having performance
rendering okay uh I was already
mentioned some mentioning some parts of
flatter which is the flatter engine hat
language and some some stuff Let's uh
organize it in a diagram we have the
flatter engine the most basic stuff of
flatter if your application runs that's
the first thing we take care of we love
the engine and the engine takes care of
everything else the engine is uh written
again we look at uh the io platforms web
platform is a bit different uh we'll get
to the web platform later today um the
engine is written mostly in C++ um it's
using skia which is a uh UI friend
Library uh for
rendering of course the engine ships
Dart because well without Dart we cannot
have flutter uh and it takes care of
text communication which is relevant for
accessibility apis for screen readers
and so on uh yeah so these are the three
main parts of uh the engine and building
on the engine we have the dart framework
uh we have the foundation which is the
very most basic um flatter Library
flatter has few core libraries and
Foundations the the most basic one it
contains anything you need to initialize
flatter applications some constants and
some some stuff so these is the basic
one on that one we have animation
painting and gures of course
applications need to process input so
gures um we after we know how which
widgets we want to use we need to have
anything painting them and the dart
framework is communicating through the
engine how to paint stuff after
layouting um we have animations so
ticket providers with we uh stay in sync
with the GPU in order to uh have perform
animations um on that one we have
rendering which uh is uh taking it's the
process taking care of uh layouting
widgets positioning them and so on on
that building we have widgets and say
there there's everything we have core
widgets like I don't know simple box or
we have the Fancy Widgets like I don't
know the the kutino context menu with
animation overflow and
everything so um if we animate stuff or
render stuff how does it working working
flatter uh it's pretty easy um your
device has a GPU it has one at least it
has anything taken care of GPU tasks and
this GPU is or no the flatter engine is
communicating to the GPU uh checking its
performance so once the GPU is free to
uh build a frame uh the flatter engine
communicates to uh your application you
have a vsnc vsn is more or less every T
every TI that g this GPU can render you
get V hey we you can provide us with a
new frame um if we animate something for
example we can listen to any new tick of
the CPU uh GPU uh we can listen to this
vs uh for example if we have an
animation controller modifying a
progress bar every tick we receive we
can move it a bit further uh once we
know the new state for uh so now the
progress bar is no longer 100 pixels but
105 pixels uh we can build check okay
now it's a bit bigger so we need to move
this around and stuff we lay out things
after that one uh okay this is now
bigger so I need to move that one away
and stuff uh we painted for okay the
this progress bar has the color property
blue and there's a transparent thing
around uh so this is the next task the
engine takes care of and once we have
that we have a layer tree give it over
to the GPU and the GPU is taking care of
ring it uh so this is how an animation
uh TI of flut Works um and the life
cycle of widgets uh so whether they
react on such a tick uh how they build
how they lay out that different differs
between stateful and stateful stateless
widgets
we have status widgets they are once
being constructed built and once
anything around their environment
changes if the screen size changes if
the layout round changes there simply
being rebuild we don't take care of
anything we just rebuild them um and can
we reuse you know if we rebuild stuff we
we're speaking in flatter terms of a new
build context so once the layout or any
property if your environment changes you
have a new build context because the
context you build around is different
that's what you call build context in
flatter um if we have a state full
widgets it's a bit different
and once we have a new build context we
get a new state and we can use that this
state listen to stuff change things and
uh but we do not necessarily need to
rebuild we can a stateful witchet uh has
hookin in order to decide on its own
whether it's uh rebuilding or not that
this is mostly the did update confa did
update uh widget and stuff uh so all the
did update methods they uh handle
they're handling um context changes and
state full witchet can correspondingly
react on whether it's uh going to
reinitialize uh or whether it's going to
re-trigger a new build or whether it's
just uh sticking with its current state
uh whether it's updating some properties
whether it's just sticking with
everything thing um a state for widget
can very fine grantly react on that and
you can save lots of performance using
that so let's get deeper into that uh
State full widget thingy uh in
particular the state of a widget the
state full widget is not that
interesting it's once creating this
state that's what we saw on the last
slide we have this yeah it's just once
creating the state fine we have a state
but what's happening in this state
because this state must do state things
it's yeah it's it's it needs to to take
care of stuff um if we create a state we
once initialize it for example in our
initializer we set a variable uh color
to Red okay now we have this color set
to red but we did not paint anything yet
so we are in a dirty state where the
state of our widget differs from what is
shown on the UI since we just
initialized uh the widget nothing is
shown so it differs from the red color
which should be shown um if it's dirty
we can call the set State me
very very very relevant method infl uh
uh set state is Method uh available in
any state and it enables you to Simply
trigger a rebuild once the new next
frame is built so we have a dirty State
we trigger a uh build and then we have a
clean State because what should be
displayed and what is being displayed is
exactly the same we have the color red
and what we render is red
um then things can happen for example
the screen size can change we get a new
configuration or uh for example since
the parameter of the widget was
modified we have a time out calling a
set state for example uh changing some
properties then we are in a dirty State
again we trigger a rebuild and the
widget is in syn with uh Woods being
rendered again uh and last but not least
we have disposal once the widget is no
longer used for example because it's off
stage uh or in some cases you can
manually dispose them um it's simply
clean it's both clean disposed no more
listeners no more stuff we do not handle
anything performance fine because we do
not widget no longer exists yeah so
that's it uh about the life cycle of
widgets
um yeah how how now bit brief stuff
about um uh performance of how how to
use widgets efficiently
uh I already mentioned keys I want to
get bit deeper into them uh a key is an
object in
flatter which takes care of the
communication between the state for
widgets and their state if we provide a
a key to a widget uh the the
engine will not reender it unless
will not re uh initialize will not
create a new State uh of the widget
unless uh we provide a different key or
no more key so Keys take care in order
to preserve States uh around the life
cycle of a widget uh it prevents for
example rebuilding on stream Builders um
you often have the case that you build
for example a an inbox list the list of
your uh recent mails again some stream
Builders there may be some new messages
popping in and stuff and you might build
them against stream Builders and if you
use keys in that case for example uh
list you would always know I already
rendered this widget I can preserve the
state I do not need to compute
everything again uh it's super useful
for animations too because if we animate
stuff with different properties and hand
over key we know we already rendered
that and we do not need to start from
scratch
again in general uh caution with uh
stream Builders stream Builders are
fancy flatter has many Builders uh
listen build Builders so well you listen
build Builders stream Builders uh future
Builders everything Builders uh where we
wait for some asynchronous task or some
stream task and build our UI against
them um but use it with caution because
if we have a huge pile of stuff in
Builders it's being re re build again
and again once anything of the data in
the Stream or whatever we use changes
that's ineff so always when uh using
stream Builders or listen value
listenable Builders take care to only
modify the fewest
possible I'm talking too
much you for example you can use Keys
again they preserve the state
uh you can use animated lists where
instead of saying here these are your
200 items built against them can
communicate item five updated item five
was now moved to number three to
position number three uh and that's of
course again way more efficient than
having a blob of 200 items we build
again just saying hey move this one to
that one that's way easier for example
useful if you have a list where you can
drag items uh or if you have a list
where uh single items might update for
example the status list of your CI are
this job just finished it's completed
instead of building all the uh widgets
showing all the statuses again again and
again we can just communicate flat with
an animated list uh yeah this one was
changing please uh update that please
render that single one again uh that's
way more
efficient
um mod and applications have many
animations
um there is kind of a trend to have
animated
figures hopping around having uh I know
introduction videos and
whatsoever and they are efficient and
unefficient ways to do that the most
inefficient way is to play a video and
have a gif or a PNG please please don't
um there are more efficient ways uh for
animations there are vector animations
there rendering way more efficiently
than any apng any GI or any video would
render uh especially in flut since uh
flat does not use the uh Native uh GI
player but renders the gif as you know
frame per frame in the application which
is a bit inefficient so if you want to
have animations fancy ones you know high
level where you have some uh people
alpacas jumping around in your an
application rather use formats like
Lotty uh to render uh which is a pretty
popular animation format animation
standard um if it's not kind of things
hopping around complex Vector animations
but only widgets being animated for
example use the animations package uh uh
flat team has developed a fancy uh
package containing many pre-built
animations you may use um and again use
Keys performance-wise it's better um
yeah one more thing to focus on um we
can deploy any flatter app or not any
but pretty any uh flatter app as web
application but be C cautious uh by
default if you do not optimize on
performance you ship everything you have
in your application on initial load so
you have your 5 megabyte
application and you Lo everything and
then you start executing you can imagine
how much fun this is on an edge network
uh not at all so flatter has uh fancy
mechanisms to optimize that you can
simply use defered libraries whereas you
say uh we only need this splash screen
and maybe the main page on initial lot
and everything else all the other
libraries for example this framework we
need for communication with whatever we
defer that one we load it later on
demand that's way better also flatter
supports a browser optimized canvas kit
canvas kit is the rendering Library
flatter uses when uh being displayed as
web app there's still another one but
that's deprecated um and now nowadays
canvas kit has platform specific build
builds and platform specific as in
browser specific there's a combined
build of canvas kit which is a giant
blob and there are single builds for
optimized on Firefox on Chrome and for
some reason they are way smaller let's
wait for the train to pass by otherwise
no one can understand a single
word
okay train train is away again um
another thing relevant in when using
flatter for web use web workers that's
generally in web a good advice always
use the web workers uh I already
mentioned high for example supports uh
web workers but there are many other um
things you can also do task you can do
in web workers whether it may be
encryption uh heavy computation tasks
it's easy to place them in a web worker
and only take the result instead of uh
occupying your main threat with doing
stuff um yeah I think we don't need to
get deeper into animations we were
already talking a lot about animations
uh let's rather have uh some Web fun
because I think web is fun or web can be
fun because web is broken in my opinion
um flatter has super deep or Dart rather
Dart has super deep inter operation with
uh JavaScript as mentioned D was
initially aimed to as a or aimed to
replace JavaScript so there's still some
leftovers of JavaScript and you can have
fun with it fun in a very cursed
way so
uh any do code you write can interupt
with JavaScript code at
runtime uh so you can set a dart method
as listener to JavaScript method that's
very C so for example you can uh take
some Dome element of an HTML page and
make Dart listening on it and that's a
bit curs even more curs you can then
have a JavaScript Handler listening on
Dart again so you have an infinite
interoperation between Dot and
JavaScript and you can have lots of fun
with it because uh now safety is a good
approach but JavaScript does not like it
because everything you do with that
interop is just dynamic or not typed or
it's broken um also it's a bit fun
because uh that was not meant to support
Dynamic types in the dynamic way as we
have it with JavaScript so the syntax is
a bit uh broken again uh but still I
want to show it to you because in my
opinion it's just fun fun to uh look at
that that um again a bit of the history
again D aim to replace JavaScript that's
why we have lots of these JavaScript
stuff there um and for some reason all
this JavaScript interop stuff remain
part of the dart core language even 8
years later
and yeah 8 years ago some apis were
implemented and they're still semi
implemented as they were broken uh 8
years go
and you know in JavaScript you have
fancy types which is no types and uh if
you want you can have that with that as
well and I will show you how uh first
some use cases for example apart from
just having fun there are real world use
cases I also already uh had in
professional context uh using DJs into
off for example if you want to expose
API of some some framework some Library
wrote in D to an website using it uh if
you want to access native JavaScript
apis for example index DB uh web workor
API in Dart and FL flter app it's uh
again relevant to talk to JavaScript if
you're writing pure web apps in dot
that's absolutely possible you can write
pure rep apps in dot without a single
code of uh uh without a single thingy of
flatter um it's possible we we already
did that at work it's possible but I
can't recommend it and of course Flat's
web engine needs to talk a lot with the
website it's being displayed on because
otherwise with well with some Dart only
no browser knows how to use it um that's
why the flatter engine itself is
interrupting a lot with the JavaScript
listening on events uh listening on
input listening on screen changes
everything uh exposing storage apis and
all this stuff that's all so the flatter
engine itself is the main user of uh doj
as inter op and that's pity because it's
pain
um so Dart features two basic libraries
in order to have fun with uh JavaScript
uh JS and JS uh and util JS very
creative names by the way um and it
mostly exposes uh the list of uh the
list below uh jsif which makes any do
object a JavaScript object that's a bit
fun because of course well the run the
memory storage of objects differs in
JavaScript and dart but we have the jsif
uh method converting any do runtime
object into JavaScript object um you
know with the common syntax that you
have Aras fields and all the broken
stuff allow inter up I already mentioned
that one that's uh what we use in order
to convert
uh JavaScript and Dot functions into uh
D and JavaScript functions vice versa so
we can have uh we can handle callbacks
in JavaScript using allow interop in
Dart uh and we can simply handle a
method defined in JavaScript as a normal
Dart method that's pretty useful
especially when reacting uh on user
input and stuff um we have Constructor
calls and I will show you a code sample
because they're so ridiculous um you may
love about it and you can convert of
course uh all languages have
asynchronous features um JavaScript has
the promise API for as asynchronous
tasks in uh that they are called uh
Futures and you can convert them in
between two and you can access access
unsafe arrays in JavaScript from that
using some apis as well um here's a
small code
sample um that's a code
sample
uh creating a JavaScript promise in Dart
so the the most easiest task it's just
in kind of in JavaScript new
promise but expressed in Dart so what do
we do first we we we access some
property of a JavaScript uh uh object we
have the window property we know from uh
JavaScript and we can get a property
window. promise which is the Prototype
the JavaScript prototype of a promise
later on we call the Constructor so this
prototype is technically a Constructor
and we have the call Constructor High
LEL method so we call the
Constructor of our
prototype with a jifi interop of an
inline function resolving a completer to
the value provided uh
from from the resolving promise and yeah
that's just it's just curs
so if yeah I'm lacking words to describe
the hell of this syntax if you use it in
production
um it's more or less just meant as some
fun if you want to have pain with the
JavaScript code as uh
some giveaway here uh use the uh do JS
inter op code uh maybe that's not the
best way to convince you of using
flatter but that's it uh thanks for
[Applause]
listening do you have
questions I scared everyone I know I
think someone is coming with a
microphone over
there
what was your biggest uh project in
flutter well uh
I'm a so-called professional flutter
developer so I do flutter development
all my day um at work I mostly uh build
Matrix clients in flatter um if you look
at open source for example uh I'm
maintainer of the hive database
um I'm contributor of fluffy chat I was
implementing some random stuff but at
work mostly uh I Implement uh Matrix
clients so that's what I mostly do these
are pretty complex
applications um does flutter have any uh
media playback methods like if you want
to do streaming playback from the web uh
yeah you can we have you have everything
from playing a simple M file to web RTC
everything supported um in fact these
are uh plugins or packages uh you can
add to your the core I mean flatter as a
core does not support it but you have
dozens of uh packages providing these
functionalities
yes so who maintains and funds flutter
uh as mentioned in the beginning uh
flatter is a project uh developed by
Google evil
one is it working yes
uh how good is the touch support on
multiple platforms so multitouch or
maybe stylus on multiplatform it depends
on the device um on Android and iOS and
mechos everything is as much supported
as the operating system supports it um
on web it's a bit different uh it does
not recognize the difference between a
stylus and uh a touch input but it's a
PS
multitouch um and that's the same state
of Linux I'm unsure about Windows so
when handling mobile and meos S you can
use whatever input and it's super
reliable if you have web and Linux stus
will be recognized as touch and but
everything else works so uh touch always
works multi-touch no problem Gees just
whatever it's just the problem of out
Stillers
are there any more
questions well then thank you and uh
flut around enjoy the camp
[Music]