TL;DR: I built a tool that lets you inspect app-state in real-time and allows you to do even more in the future. Visit www.detective.dev for instructions on how to use it.

On debugging

Debugging can be fun at times, but most of the time, it just sucks. The feature is done, the workday is over but and you are ready to do anything but sit in front of the computer for the rest of the day. But just as you close your IDE you notice something, something that is bound to keep you awake at night: a bug.

You were ready to move on onto your next coding adventure (others call them “feature”) but you can’t.

I hope I’m not the only one feeling like this from time to time.

I did a Twitter poll and it turns out, debugging is a rather big part of developing an app, and scenarios like this aren’t the exception.

Debugging mostly consists of guessing where the problem might be and then setting up assumptions and checking those.

It’s like looking through a magnifying glass

Sometimes you just don’t see the wood for the trees. When debugging, you only see a very small portion of your application. It may be the variables you printed out for debugging purposes or the current frame where the debugger hit a breakpoint. So you keep looking for the issue with a very small slice of the whole world and this works surprisingly well. People find bugs and subsequently fix them — but now imagine what happens when you have the power to see more? To levitate above the forest instead of standing in the middle of it.

Detective to the rescue

Detective allows you to inspect all the interesting application states at once. For information on how to install, head over to www.detective.dev.

How to use it

First, you have to select a class you are interested in. This typically is some sort of class holding some mutable (changeable) state.

Next, select the specific instance to use. Most often, the class you are interested in only exists once, if that’s the case just select it. Sometimes you may not find an instance at all, there are a couple of reasons for that but one to watch out for is that Providers are lazy by default, meaning the instance will not be created until its first use.

And you are ready to go! Start by looking at the state of this specific instance of your class. Notice how changes, that you do by using the app, happen in real-time — no need for any reloading.

Seeing the big picture is great — but can we do even more?

Good question! And the answer is a definite yes. State inspection is just the very beginning of all the possibilities with an app that is able to access meta information in combination with runtime information of a process. Here are my top three features on the roadmap:

Debug function invocation

Sometimes, while debugging, you just want to invoke a function, emit an event or change the state in a specific way. Usually, this happens through some sort of UI, but there can potentially be a couple of problems with that.

The UI is not built yet

Starting with logic first and then building the UI is generally a widespread approach. But testing said logic becomes hard without an interface, so usually, some kind of placeholder is implemented — this again takes time and can be avoided.

UI cumbersome to use

Some features just require lots of setup to move into the desired state. This could be tapping through long forms, changing system settings, or any other setup.

Faster due to the use of presets & shortcuts

A lot of programmers prefer command lines and other text-based inputs due to having mastered the keyboard quite well. So why go the slow route of using a point and click UI?

Visualizing class-dependency graphs

Everybody knows the term ‘spaghetti’ code. What that means is code that is very interconnected. Everything is referencing a lot of classes, maintaining such code becomes increasingly difficult as it is very hard to reason about a specific section without having the whole picture in one's mind.

Therefore is important to separate code into chunks that are very isolated, and thus making it easy to read and modify. A reference is when one class [‘Foo’ uses another class ‘Bar’], meaning [‘Foo’ depends on ‘Bar’] or [‘Foo’ references ‘Bar’]. If you look at all classes in your project and you notice a lot of cycles ([‘Foo’ uses ‘Bar’] and [‘Bar’ uses ‘Foo’]), it probably is a good indicator to refactor.

Getting a sense of the project structure can be hard at times because you can only look at one class at once. Visualizing this into a graph structure lets you reason more efficiently about the architecture you chose.

State time travel

This one is potentially the coolest.

When debugging applications, a very interesting fact to learn about is state changes, and what causes them. Right now, when the state is changed, there is no going back. This means if you want to find out what leads to said state change, you are forced to redo the actions that led to right before the interesting state change.

Make this process of redoing time-consuming, and requiring multiple tries and you successfully spent more time than you wanted on solving the issue instead of creating something new.

Detective has the potential to record interesting states as you interact with the app and replay it to you without having to do anything in the app anymore.

Think of this as time-travel in Redux web but for Flutter. I think it is pretty self-evident how this can potentially save a lot of time.

Embedding it into IntelliJ and VSCode

This one is pretty self-explanatory. Using the power of Flutter web, Detective can be built right into IntelliJ and VSCode, using a plugin, resulting in fewer windows on your desktop and even more productivity.

Closing remarks

If this sounds as execting to you as it does to me, be sure to give it a try at www.detective.dev. It only takes 3 commands to install.

If you want to stay up to date with the newest development information be sure to join the newsletter at the bottom of the site.

Last but not least, let me know what you think!

Detective, how to dramatically speed up debugging. was originally published in Flutter Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a widget builder for Flutter. At first, it might look like just another layout builder, but this is going to be so much more.

Check out the landing page I made for this: https://norbert515.github.io/widget_maker/website/

Core features

These are the features I feel are the core of the whole project.

Keep in mind, most of these features are not implemented yet.

Code — Visual seamless transition

There is not going to be any copy paste. You can work with the drag and drop interface while simultaneously modifying the code.

Stateful editing

Interacting with widgets while also editing its source code.

Editing complex properties easily

Editing BoxDecorations, CustomPaints, and CustomMultiChildLayouts with ease.

The core philosophy of this project

Improve rather than replace

Unlike some HTML editors — which try to hide the actual HTML and CSS code as good as possible (I get why - CSS is horrible), this editor embraces the power of the underlying code.

Instead of hiding the code under some GUI it generates clear, readable and correct code which happens to be visualized and editable through a GUI.

No platform restricting

The widget maker will run on all desktop platforms. In addition to that, it will be able to run on the web thanks to project Hummingbird.

Besides being able to run the editor on mobile, I’ll be looking into actually compiling apps on the phone, I’ve done some research and I’m pretty sure it is possible.

Does not require any fancy setup

When opening a dart file containing a widget, widget maker will analyze and automatically pick up on that and suggest showing the visual editor.

Made for everyone

Doesn’t matter if you are new to Flutter or have been coding since the alpha. Widget maker will bring value to everyone.

Fast feedback-loop

A fast feedback loop is, in my opinion, the biggest productivity boosts you can get. And Flutter does a hell of a good job with its hot-reloads. But there are scenarios which can be improved.

I want to talk about one example: Developing a responsive layout.

What you would do is write the code and check how it looks on a small device, then you’d get your tablet and take a look at how it looks there.

You might also be fortunate enough to have an emulator/ embedder which supports resizes. This is already a huge improvement compared to having multiple physical devices/ emulators open at the same time. But you’d still have to change code — resize the window to a bunch of different sizes and repeat.

The workflow with Widget-Maker might look like the following:

Have differently sized flutter apps open in one GUI which update in real time as you slide a slider which, for example, controls the flex value of one of the Expanded’s.

A few teasers for future possibilities

I don’t want to talk about every single idea I have right now, simply because I first want to make it solid before expanding (and I have way too many ideas), but here are some ideas I thought about, which might make it into the application someday:

Animations through keyframes

Possible workflow:

Select a property and set a keyframe, press a button or trigger any other action, select the same property and add another keyframe.

The animation code is generated and used on the fly.

Writing tests on the fly (without actually writing tests)

Widget tests: automatically generated golden files (images of the widget to compare to) and basics assertions (the color you set is actually used etc.)

Integration tests: Click through your App and assert things (like Robolectric for Android) and then generate widget tests (which can be run headless) and actual on-device tests.

Share and download widgets

Similar to pub (the Dart package manager) but focused on widgets.

Key differences being:

1. No need to add anything to pubspec.yaml
2. Browse widgets with preview and source code
3. Drag&Drop in widgets from the web
4. Share and browse widgets

Downloading the program

Head over to https://github.com/Norbert515/flutter_ide/releases/tag/v0.1-alpha

Just unzip the folder and run “run.bat”.

If it’s not working try installing the C++ runtime files (https://aka.ms/vs/15/release/vc_redist.x64.exe)

What can you do to make this happen?

I believe this could be a huge thing — but I need feedback.

Before diving in heads deep into this project (what some argue I already have) I need to find out whether people are actually interested in this.

For that purpose, I made the current demo available to download and play around with. But please keep in my, it’s just a demo. There are a few bugs in it and it’s nowhere near finished.

If you do like this project or have feedback please let me know on Twitter, through an e-mail or other communication channels. The more feedback I get the better I can make an informed decision about the future of this project.

PS. Thanks to Simon Lightfoot for the last minute panic help :)

Introducing: Flutter Widget-Maker, a Flutter App-Builder written in Flutter was originally published in Flutter Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you ever thought about how cool it would be if you could just make this quick change in your app without opening your laptop? Or you simply thought about the idea of writing Flutter apps on your phone.

I did some experimenting and I might have something for you!

If you want to try it out, head over to this Github repository which has a detailed setup guide.

This article will take a look at the hows and whys.

How does it work?

It’s probably simpler than you thought.

The compilation is still being done by a PC.

What is happening is that there is a server (written in Dart) running on the computer. It manages the files, handles building and reloading.

The app you are developing needs to include the IDE itself. This works by wrapping the topmost widget in an IdeApp.

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return new MaterialApp(
      title: 'Flutter Demo',
      theme: new ThemeData(
        primarySwatch: Colors.red,
     ),
      home: IdeApp(child: new MyHomePage()),
    );
  }
}

The IdeApp manages listing editable files, writing those back to the computer and invoking hot reloads.

Fun fact: because the IDE itself is inside the project, you can modify the phone-IDE through itself.

When pressing the hot-reload button in the app, a request is sent to the server to reload the app. It then performs a Flutter hot-reload and pushes the changes to the device (if it is Android, this goes through ADB).

In the gif there is no cable, how’s that possible?

The answer is simple: ADB over WiFi.

So I’ll have to be in the same private network? What if I want to develop on the go?

You still need to be in a private network with the build server but here is where VPNs (Virtual private networks) come to the rescue.

Using a VPN you can be in a private network anywhere on the earth over the internet.

With a configured build server and a VPN, you can develop apps anywhere.

Be it on the train, while walking through the city or secretly in a lecture. All you need is an internet connection.

Improvements

Well, there are obviously a lot of possible improvements to this. Bear in mind, this was only an experiment I have written in about one day.

A good text editor

Having a good text editor that supports features every IDE needs would, in my opinion, makes this a somewhat viable way to develop in some cases.

Compiling on the device instead of relying on a build server

I think it might be possible, but I haven't looked into that too much.

Not having to include the ide code in the actual app

This should be possible. There are a few ways to achieve this. For example, the server could copy the project on start and inject the necessary classes on start.

Is this actually useful?

Probably not. At least not yet.

Could this be useful?

In my opinion, yes.

Imagine being in a meeting with a client and he wants to see how the app looks like with a tiny change. Let’s be honest, is there any cooler way than taking out the phone and editing that small change right on the spot?

Also, writing code inside a running app and then hot reloading it, is quite satisfying.

Conclusion

I’ve been involved in building a desktop embedder and I’m currently exploring ideas in that area.

I’m actually working on something even crazier right now :)

Be sure to follow me on Twitter, to stay up to date.

Coding Flutter Apps on your Phone with Flutter, an Experiment was originally published in Flutter Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

At its core, Flutter is a standalone, binary executable; making it a game-changer not only on mobile, but on desktop as well.

Writing once and deploying natively on Android, iOS, Windows, Mac and Linux and additionally sharing all the business logic to the web (using AngularDart) is a big deal.

Let’s explore this idea!

Native Desktop client to accelerate mobile development

But before taking a look at actual native desktop apps, let’s see what running Flutter on desktop can do for people developing for mobile.

Startup time

The first thing that happens before anything productive can be done is starting the android emulator and running Gradle.

In the following Gif I recorded myself cold booting the emulator and running the default Flutter app. I took me a whopping 2 minutes and 40 seconds. Just image how much productive things could have happened during that time.

What if I told you, you could be up and running in less than 10 seconds?

Running the app natively skips the whole overhead of running Android on your system and going through Gradle.

Just check this out:

Notice how you don’t have to leave IntelliJ. We’ve written the tooling needed to run Flutter as a native application. Works in all Flutter IDEs.

Resizable during runtime

As with any app, you’ll want to test your layout for different sizes. What do you do?

You ask all your friends with different phones and/or create a bunch of emulators to make sure your layout looks as intended on each and every device.

This feels pretty cumbersome to me. Can we do it better?

Yes, we can!

Work with assets on your PC

When developing and testing apps which need to interact with assets on the phone, it can be quite annoying to first move all the testing files to the emulator or device.

Wouldn’t it be nicer to just pick the file you want with your native file picker?

If you are screaming YES, then I got the right thing for you!

The best part about this: the desktop implementation uses the same method channel as the mobile implementation, therefore no code needs to be changed at all.

Hot reloads and debugging

This is all nice and fun. But hot-reloading and debugging capabilities are a must for every productive engineer.

So we made that work for desktop too!

RAM

Last but not least: RAM. This is a pretty big deal for people working on notebooks and/or somewhat less beefy machines.

The Android emulator eats up roughly 1GB of RAM. Now, imagine running two of those (testing a chat application or similar), IntelliJ, and the ever-RAM-hungry Chrome.

That’s pretty heavy.

Because the embedder is running natively, there is no need for Android. Which makes it much smaller.

Native Desktop Apps

Simply running a Flutter app on desktop isn’t enough for a fully fledged, production-ready desktop app. Doing so feels (and it essentially is) like running a mobile app on desktop.

What’s missing? A lot!

Hovering, Cursor Changes, Scroll Wheel Interaction, etc.

So we built that too!

We managed to implement those features without changing any platform code — so, it’s a standalone package that can be included within any ordinary Flutter app. However, when used together with our desktop embedder, magic happens!

This is the exact same code running on the Android emulator.

Notice how it behaves like a normal app on the emulator, but changes the cursor and adds the hover effect on desktop.

A little showcase of the simplicity of these desktop widgets

Hovering:

Cursor:

Writing a truly cross-platform app — including desktop

Widgets

Most of the widgets you create are universally usable. Think button, loading indicators, etc.

Those which need a different look depending on the platform can be encapsulated pretty easily by checking the TargetPlatform property.

Widgets like the CursorWidget can also be included in the Android version without a problem. They are simply ignored there.

Pages

Pages differ quite a bit depending on the platform and the screen size. However they mostly only differ in layout and not in actual functionality.

Using a PageLayoutWidget makes creating accurate layouts for each platform super easy.

Bonus: You also have nice tablet support by default :)

Plugins

No changes to your Flutter code have to be done when using a plugin which also supports the desktop embedder.

When will the code be released?

It’s here! Check it out at:

https://github.com/devangels/desktop_simulator

• GitHub - devangels/flutter_simulator: flutter_simulator Dart Extension written in C++
• GitHub - devangels/flutter_desktop_widgets: Desktop Widgets (hover and such) [for Flutter Desktop apps]
• JavaScript is not available.
• Simon Lightfoot 🥇💙 (@devangelslondon) | Twitter
• Norbert Kozsir (@norbertkozsir) | Twitter

Flutter on desktop, a real competitor to Electron was originally published in Flutter Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

First off.

It has been a long time since I last posted here on medium. Interestingly my follower count kept growing — so thanks for that! :)

When I started posting on Medium back in February. I didn’t really know what I was doing (I still don’t).

My first post “Flutter: How I built a simple app in under an hour from scratch. And how you can do it too.” got featured on AndroidProDev and got pretty big.

I wrote it because I saw a YouTube video about Flutter and tried it out. I was so amazed, that I thought “Why not write a post about that?”. So I did.

But the app I was working on didn’t have that much potential and eventually, I lost motivation.

People always say “The idea is worth nothing, it’s all about execution”, while I certainly don’t disagree. I think there is more to it. If the idea you have isn’t exciting (for yourself) then you [probably] won’t be able to execute it well.

Enough rambling

As you might have guessed from the title, I’ve been working on a music player.

Why a music player?

The Design

I love well-designed stuff.

Sometimes I just go to sites like dribbble.com or uplabs.com and admire the beauty people create.

I wanted to challenge myself and music players seemed like a great opportunity to do so.

The market

If you search for “music player” on the app store, you will be flooded with apps. Seriously you wouldn’t be able to count them.

So why on earth should there exist another one?

A lot of them have a huge amount of downloads. I’m pretty sure I won’t reach those counts, but it’s nice to know that the market exists :D

Most of them are “good”. But I haven’t seen too many amazing ones yet.

Don’t get me wrong. They all do their job. And I’m also pretty sure there are a few outstanding ones, but most do their job and that’s it.

In my eyes apps are more than just a tool to accomplish a task. Music is art. So are apps.

What I’ve done until now

Design

The design took me a long time and still is one of those parts where I’m not exactly sure what I am doing. But every iteration it looks a little bit nicer, so that’s good!

Keep in mind, nothing is final yet.

Here are some cool snippets of the app:

What already works

• List all songs/ all albums/ all artist/ all genres / all folder
• Homepage displays recently played albums
• Editing metadata + cover art fetcher
• Artist Page downloads artist images
• Searching for individual songs
• Background service/ Notification with controls/ Lock screen image

Whats still left to do

• Designing and implementing the Home-Page
• Rewriting the Queue Logic to run in the background service
• A lot of small UI tweaks
• Fixing bugs
• A lot of cool features

The future of this series

As a disclaimer, this app is not going to be open source (at least for now). I will, however, post snippets which might be useful for other people and explain them.

Also, I will release packages which have their origin in this project. For example, https://github.com/Norbert515/pimp_my_button was made for this app.

I hope you can understand!

If you want to get the latest new about the development, be sure to follow me on Twitter! https://twitter.com/norbertkozsir?lang=en

Villains allow you to add page transition like the one above with just a few lines of code.

The package is available here. You can find how to use villains in the projects README. This post is more focused on explaining heroes and villains and the thought process behind all of it.

One of the most awesome parts of flutter is having such a nice and clean API for everything. I just love the way you can use Heroes. Two simple lines of code, and it just works. You just drop in Heroes at two places, assign according tags and the rest is taken care of.

Before you understand the villain, you must first understand the hero.

We’ll take a quick look at how the heroes are implemented.

Overview

There are three major steps involved in the hero animation.

1. Finding and matching the heroes

The first step is to determine which heroes exist and which have the same tag.

2. Determining the hero positions

Then, the position of both heroes are captured and the flight is ready to happen.

3. Initiating the flight

The flight always happens on the new screen, but not with the actual widget. The widget on the opening page is replaced with an empty placeholder widget (SizedBox) during the flight. Instead the Overlay is used (the Overlay can display widgets on top of everything).

The whole hero animation happens on the page being opened. The widgets don’t share any state between pages and are completely separate.

The NavigationObserver

It is possible to observe the events of routes being pushed and popped with a NavigationObserver .

The hero uses this class to start the flight. Besides being able to add NavigationObservers yourself, the MaterialApp adds the HeroController by default. Take a look.

The Hero Widget

The hero widget doesn’t actually do much. It holds the child and the tag. In addition to that, the createRectTween argument determines what route the Hero takes while flying to its destination. The default implementation is the MaterialRectArcTween. As the name suggests it moves the hero along an arc to its final position.

The state of the hero also is responsible for capturing sizes and replacing itself with the placeholder.

_allHeroesFor

Elements (concrete widgets) are placed in a tree. Using a visitor, you can walk down the tree and gather information.

An inline function called visitor is declared inside the method. The context.visitChildElements(visitor) method and element.visitChildren(vistor)call the function until all elements below the context are visited. On each visit it checks whether that child is a Hero and if it is, it saves it into a map.

The start of the flight

This gets called in response to the route push/pop event. On line 14 and 15 you can see the _allHeroesFor call which finds all heroes on both pages. Starting on line 21 a _HeroFlightManifest is constructed and the flight is initiated. From here on there is a bunch of code setting up the animation and handling edge cases. I encourage you to take a look at the whole class, it’s pretty interesting and there’s a lot to learn from it. Also you can take a look at this.

How do villains work

Villains are simpler creatures than Heroes.

They use the same mechanic of finding all villains for a given context and they also use a NavigationObserver to automatically react on page transitions. But instead of animating from one screen to another they only animate on their respective screen.

SequenceAnimation and custom TickerProvider

When dealing with animations, you usually use the SingleTickerProviderStateMixin or the TickerProviderStateMixin. In this case the animation doesn’t start in a StatefulWidget and we therefore need another way to access a TickerProvider.

Defining a custom ticker is pretty easy. All there is to it is implementing the TickerProvider interface and returning a new Ticker.

First all villains which should not be playing (those who set animateExit/animateEntrance to false) are filtered out. Then an AnimationController with the custom TickerProvider is created. Using the SequenceAnimation library each Villain is assigned an animation running from 0.0–1.0 in their respective time slot (the from and to duration). At the end, animations are all started. When all of them finish, the controller is disposed.

The Villain build()

This might look scary, but bear with me. Let’s just look at line 3 and 4. The widget.villainAnimation.animatedWidgetBuilder is a custom typedef:

typedef Widget AnimatedWidgetBuilder(Animation animation, Widget child);

Its job is to return a widget which animates according to the animation (most of the times the returned widget is an AnimatedWidget).

It gets handed the child of the villain and this animation:

widget.villainAnimation.animatable.chain(CurveTween(curve: widget.villainAnimation.curve)).animate(_animation)

The chain method first evaluates the CurveTween. It then uses that value to evaluate the animatable on which it is called. This simply adds the desired curve to the animation.

That was a rough overview on how the villains work, be sure to also look at the source code and feel free to ask questions.

Mutable static variables are bad, let me explain..

I was sitting at my desk in the late evening, writing tests. After a few hours every single test was passing and it seemed there were no bugs. Right before heading to bed I ran all the tests together to make sure it’s alright. Then this happend:

I was pretty confused. Every test succeed before. Sure enough, when I ran those two tests by themselves, they worked as expected. But when running all tests together the last two failed. WTF.

The first reaction was obviously: “My code must be working, it has to do something with the way tests are executed! Maybe tests are playing in parallel and thus interfering with each other? Maybe it is because I used the same keys?”.

Brian Egan point out to me that deleting one particular test fixed the bug and moving it to the top made all other tests fail too. If that doesn’t scream “SHARED DATA” then I don’t know what does.

When I found out what the problem was I just couldn’t stop laughing. It was exactly the reason why using static variables are considered bad in certain situations.

Basically, the predefined animations were all static. I was too lazy to write a method for each animation taking all the parameters that a VillainAnimation needs. So I made the VillainAnimation mutable (bad idea). This way I didn’t have to explicitly write all the necessary parameters into the method. This looked like this when using it:

Villain(
  villainAnimation: VillainAnimation.fromBottom(0.4)
    ..to = Duration(milliseconds: 150),
  child: Text("HI"),
)

The test which broke everything was supposed to test villain transitions starting after the page transition finished. It set the starting point of the animation to 1 second. Because it was setting it on a static reference, the test after that used that as the default. The tests failed because an animation can’t run from 1 second to 750 milliseconds.

The fix was pretty easy (making everything immutable and passing the arguments in the method) but I still found this little bug quite entertaining.

Wrapping up

Thanks to the Villains the balance between good and evil is now restored.

Opinions and discussions about the #fluttervillains are welcome. If you create cool animations with the villains, I’d love to see it.

My Twitter: @norbertkozsir

Flutter Heroes and Villains — bringing balance to the Flutterverse. was originally published in Flutter Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever wondered how Flutter takes those widgets and actually converts them to pixels on the screen? No?

You should!

Understanding how an underlying technology works makes the difference between a good developer and a great one.

You can create custom layouts and special effects more easily when you know what works and what doesn’t; and knowing this will save you a few long nights at the keyboard.

The goal of this post is to introduce you to the world beyond the surface of flutter. We will take a look at different aspects of flutter and understand how it actually works.

Let’s get started

You probably already know how to use the StatelessWidget & StatefulWidget. But those widgets only compose the other widgets. Laying out the widgets and rendering them happens elsewhere.

I highly recommend opening your favorite IDE and following along, seeing the structures in the actual code often creates those “aha” moments. In Intellij you can double tap shift and enter a class name to find it.

The Opacity

To get familiar with the basic concepts of how flutter works we will take a look at the Opacity widget and examine that. Because it’s a pretty basic widget, it makes a good example to follow along.

It only accepts one child. Therefore you can wrap any widget in an Opacity and change the way it’s displayed. Besides the child, there is only one parameter called opacity which is a value between 0.0 and 1.0. It controls the opacity (duh).

The Widget

The Opacity is a SingleChildRenderObjectWidget.

The hierarchy of extension class extensions goes like this:

Opacity → SingleChildRenderObjectWidget → RenderObjectWidget → Widget

In contrast, the StatelessWidget and StatefulWidget goes as follows:

StatelessWidget/StatefulWidget → Widget

The difference lies in the fact that the Stateless/StatefulWidget only compose widgets while the Opacity widget actually changes how the widget is drawn.

But if you look at any of those classes you won’t find any code related to actually painting the opacity.

That’s because a widget only holds the configuration information. In this case, the opacity widget is only holding the opacity value.

This is the reason why you can create new widget every time the build function is called. Because the widgets are not expensive to construct. They are merely containers for information.

The Rendering

But where does the rendering happen?

It’s inside the RenderObjects

As you might have guessed from the name, the RenderObject is responsible for a few things, including rendering.

The Opacity widget creates and updates a RenderObject with these methods.

@override
RenderOpacity createRenderObject(BuildContext context) => new RenderOpacity(opacity: opacity);

@override
void updateRenderObject(BuildContext context, RenderOpacity renderObject) {
  renderObject.opacity = opacity;
}

source

RenderOpacity

The Opacity widget sizes itself to be exactly the same size as its child. It basically mimics every aspect of the child but the painting. Before painting its child it is adding an opacity to it.

In this case, the RenderOpacity needs to implement all the methods (for example performing layout/ hit testing/ computing sizes) and ask its child to do the actual work.

The RenderOpacity extends the RenderProxyBox (which mixes in a few other classes). Those are exactly implementing those methods and deferring the actual calculation to the only child.

double get opacity => _opacity;
double _opacity;
set opacity(double value) {
  _opacity = value;
  markNeedsPaint();
}

I removed a lot of assertions/ optimizations in this code. Take a look at the original for the full method. source

Fields usually expose a getter to the private variable. And a setter, which in addition to setting the field, also calls markNeedsPaint() or markNeedsLayout(). As the name suggests, it tells the system “Hey I have changed, please repaint/relayout me”.

Inside the RenderOpacity we find this method:

@override
void paint(PaintingContext context, Offset offset) {
    context.pushOpacity(offset, _alpha, super.paint);
}

Again, removed optimization and assertions. source

The PaintingContext is basically a fancy canvas. And on this fancy canvas there is a method called pushOpacity. BINGO.

This one line is the actual opacity implementation.

To recap

• The Opacity is not a StatelessWidget or a StatefulWidget but instead a SingleChildRenderObjectWidget.
• The Widget only holds information which the renderer can use.
• In this case the Opacity is holding a double representing the opacity.
• The RenderOpacity, which extends the RenderProxyBox does the actual layouting/ rendering etc.
• Because the opacity behaves pretty much exactly as its child it delegates every method call to the child.
• It overrides the paint method and calls pushOpacity which adds the desired opacity to the widget.

That’s it? Kind of.

Remember, the widget is only a configuration and the RenderObject only manages layout/rendering etc.

In Flutter you recreate widgets basically all the time. When your build() methods gets called you create a bunch of widgets. This build method is called every time something changes. When an animation happens for example, the build method gets called very often. This means you can’t rebuild the whole sub tree every time. Instead you want to update it.

You can’t get the size or location on the screen of a widget, because a widget is like a blueprint, it’s not actually on the screen. It’s only a description of what variables the underlying render object should use.

Introducing the Element

The element is a concrete widget in the big tree.

Basically what happens is:

The first time when a widget is created, it is inflated to an Element. The element then gets inserted it into the tree. If the widget later changes, it is compared to the old widget and the element updates accordingly. The important thing is, the element doesn’t get rebuilt, it only gets updated.

Elements are a central part of the core framework and there is obviously more to them, but for now this is enough information.

Where is the element created in the opacity example?

Just a little paragraph for those who are curios.

The SingleChildRenderObjectWidget creates it.

@override
SingleChildRenderObjectElement createElement() => new SingleChildRenderObjectElement(this);

source

And the SingleChildRenderObjectElement is just an Element which has single child.

The element creates the RenderObject, but in our case the Opacity widget creates its own RenderObject?

This is just for a smooth API. Because more often then not, the widget needs a RenderObject but no custom Element. The RenderObject is actually created by the Element, let’s take a look:

SingleChildRenderObjectElement(SingleChildRenderObjectWidget widget) : super(widget);

source

The SingleChildRenderObjectElement gets a reference to the RenderObjectWidget (which has the methods to create a RenderObject).

The mount method is the place where the element gets inserted into the element tree, and here the magic happens (RenderObjectElement class):

@override
void mount(Element parent, dynamic newSlot) {
  super.mount(parent, newSlot);
  _renderObject = widget.createRenderObject(this);
  attachRenderObject(newSlot);
  _dirty = false;
}

(Right after super.mount(parent,newSlot); source

Only once (when it get’s mounted) it asks the widget “Please give me the renderobject you’d like to use so I can save it”.

The End

And that’s it. This is how the opacity widget works internally.

My goal with this post was to introduce you to the world beyond widgets. There are still a lot of topics to cover, but I hope I could give you a nice introduction to the inner workings.

Big thanks to Simon Lightfoot for helping me out researching this!

Edit: If you want to learn more, check out the talk I did on this subject on Youtube!
https://www.youtube.com/watch?v=PnWxW21vDak

Flutter, what are Widgets, RenderObjects and Elements? was originally published in Flutter Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

TLDR: I made a package which takes care of all of this, if you are interested on how it’s done keep reading.

How to do it.

Usually your entry point to the app looks like this:

If you want to change the theme of your app at compile time you can modify ThemeData. There is an attribute called Brightness which changes a bunch of colors from light to dark if set to Brightness.dark .

We want it to dynamically change that variable during runtime. We therefore introduce state to the top level widget.

Now, we have to access this state. Either by passing down a callback, writing a custom InheritedWidget or using the BuildContext to walk up the tree.

Passing down a callback is the most straight forward thing to do. But it also is the most annoying one. If the tree gets deep a lot of classes just pass the callback to its children. The logic is pretty simple though all that happens is:

• Top widget implements a method which changes the brightness and calls setState()
• Any child who has a reference to that method can invoke it.

An InheritedWidget would solve this problem by giving all the children access to the callback. You would still have to manage a callback, but this time there is no need to pass it all the way down.

The last viable option is searching the tree for the state. This one is pretty straight forward. We need a context to start the search, all we do is walk up the tree a search for a State which is of our type.

context.ancestorStateOfType(const TypeMatcher<YourState>());

Holding a static reference or global variable is a big no go, I won’t cover why in this post though.

Now we are be able to access and modify the Brightness on the go. The last thing is to persist the Brightness across app restarts.

Using shared preferences we can fetch the brightness before we run the app. When the brightness changes we will also have to save it there.

Because the shared preferences are asynchronous we need to await the result. The call is very fast and therefore this is not a big deal.

And we’re done! Now we can change the Theme of the app anywhere in our code.

The package

Because we as developers shouldn’t waste time re-implementing features, I made this a package!

Basically it’s exactly doing all the things I talked about above but encapsulated in one handy class.

Here is how it works:

You wrap your MaterialApp in the DynamicTheme widget. There you can specify a default brightness.

Because the brightness value is changing the colors when constructing the ThemeData you’re able to either just pass the brightness on to the ThemeData constructor and let it take care of it, or you can customize it by passing your own colors depending on the Brightness.

Last but not least, the ThemedWidgetBuilder. This is the place you usually just return the MaterialApp and pass it the theme.

And that’s it.

Now you can modify your Theme from anywhere in your code with:

DynamicTheme.of(context).setBrightness(Brightness.dark);

It will take care of saving it to the shared preferences and updating the app.

Bonus

Because I had way to much fun coding this, here is a dialog you can use for the theme switching:

How to dynamically change the theme in Flutter was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Taking the bookshelf app from demo to a real app.

The Idea

“Collecting books as you read them, virtually”

It isn’t rare that people don’t own the physical book but instead read them on an e-reader, listen to them as an audio books or simply lend them a from friend. The books have been read but the shelf stays empty. There is no sense of accomplishment and more importantly no collection of books to show your grandchildren.

There are two aspects to the app: collecting books and discovering new books.

The app consist of different collections.

First there is your own collection (all the books you have read).

Then there are collections about certain topics, for example a “Fantasy” or a “Biography” collection, these contain books which the author of the collection found to be similar to each other. You will later be able to browse collections people made and add them to your list.

The future of this series

The future posts will be more directed towards updates and exciting features I made. I won’t go into detail on every change but I will always include code and a walk through about topics I think many people could benefit from.

As always, the code can be found here.

Creating the stamps

The stamp is basically just an image in a stack with the locked icon. But there are still some interesting things going on.

The elevation

This one’s pretty simple but effective. Wrap your widget in a transparent material which has the attribute elevation . That’s it, this way you can add elevation to any widget.

child: new Material(
  elevation: 8.0,
  color: Colors.transparent,
  child: new Center(
    child: _clippedNetwork(context, width, height, holeRadius),
  ),
),

The stamp shape

There are two ways one could accomplish this. Either by using an image or crating it programmatically. The image solution has two downsides.

• Scaling can result in a resolution drop
• It is fix, meaning you can’t change the looks of it at runtime

On the other hand there are Clippers, these clip the area a widget can draw on.

I used the ClipPath with a CustomClipper . This way you can define a mesh to cut out of the canvas of a widget.

return new ClipPath(
  clipper: new StampClipper(holeRadius: holeRadius),
  child: myWidget
);

Drawing the path

The CustomClipper has the getClip method which you need to override and return the Path that you want to cut out.

I won’t go into detail how this algorithm works. But basically it calculates a new radius which is as close as possible to the original one and “looks good”. Meaning edges are handled well. It then goes through all the sides and cuts out the circles.

Here are some variations using different circle radii:

You might notice the shadow is a bit off. That’s because the shadow is not affected by the ClipPath . This could probably be fixed pretty easily (masking the shadow too). But in my case (the left example) this works out just fine.

The fade in animation

The page containing the animation (home_page.dart) has an animation which runs once the page is opened.

AnimationController cardsFirstOpenController;

@override
void initState() {
  super.initState();
  cardsFirstOpenController = new AnimationController(vsync: this, duration: const Duration(milliseconds: 1300));
  cardsFirstOpenController.forward(from: 0.2);
}

This AnimationController runs a 1.3 seconds long animation starting from the value 0.2 to 1.0. As this is in the initState() method this will run when the page is opened.

Next I made a method which wraps the widgets in an animated widget for convenience.

Normally you’d have to listen to the animation and on each tick update the widget based on that value with a setState() call. But theSlideTranstion and the FadeTransition are both AnimatedWidgets. These handle all the setState() calls, all they require is an animation.

The CurvedAnimation

If you’d pass the animation we created before, all widgets would move identically. We need a curve to change that behavior.

The animation runs from the value 0.2 to 1.0 in 1300ms. But we can modify the actual value the widget receives at a given time with a curve.

This little class transforms the time value based on an index. This index is the position of that widget in the list. If you look at the formula you will see that widgets with a low index will move slower than widgets with a larger index.

All the movements start at the same time and end at the same time, but move at different speeds.

I also wrapped that animations in a curved animation using a Curve.ease to make them smoother.

Here everything comes together and the list is done.

Be sure to check out the whole home_page.dart if you want to learn more.

If you want to learn more about animations take a look at the official documentation: https://flutter.io/tutorials/animation/

The next medium post

If you look at the source code every time the home page is opened the database is queried for essentially the same information. This is not a big problem because such a small database query is very fast but once the database becomes very big this might change. Also there is a prettier solution.

Next post will be about architecture, we’ll be looking at different possibilities and implement a suitable one.

Call to action

If you are a designer or somebody who has an idea how to make this app look better don’t hesitate to contact me. All suggestions are welcome.

Also if you have an idea about the name or an idea in general feel free to leave a comment.

As always, if you enjoyed this post, please leave a few claps.

You can also follow me on Twitter.

Flutter Book App part 4: From demo to real app. was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this post I’m am going to discuss a good way to store/ cache/ and load data. Most of today’s apps rely on a server to display information. In combination with a cache, a database and error handling, this can become pretty messy. Luckily there is a design pattern which makes accessing data very convenient and easy.

Without a pattern:

Each screen needs data, and therefore requests the network to load it. Let’s say you also want to have a cache, now every screen first needs to check the cache and then the network. Everything added to the data layer is reflected inside UI code.

The code is tightly coupled and not well organized, the question arises why the screen manages the data.

Introducing the repository:

A repository is a datasource. To be more specific, to the rest of the app, it’s the only datasource. Screens requesting data don’t necessarily need to know where it is coming from. This allows all data related operations to be in one place. Refactoring and modifying becomes easy and accessing the data even easier.

Strucuture

• The data folder contains all data related classes
• I split pages (which are actual screens) and widgets (reusable screen elements) into their respective folders.

As always, the code can be found at: https://github.com/Norbert515/BookSearch/tree/v3

The repository

Same as the BookDatabase, the repository is a singleton.

These calls do not need any additional logic and are therefore simply delegated to the database.

This method returns all the books based on a search query. The result is composed of the books coming from the internet and the ones coming from the database (books which hold additional information such as the star and notes).

In v2 a database request was issued for every book. This is very inefficient for huge databases. This however involves only one SQL query:

• First all books coming from the network are stored in a map (using the ID as its key)
• Then all keys a queried together returning a list of books
• These books hold more information, therefore we can simply replace the according network-book with the database-book

The list gets convert to “(“id1”, “id2”, …, “idn”)” and inserted into the SQLite query.

Error handling

You might have noticed the ParsedResponse class which is the return type of the method wrapped in a future.

This neat little generic class holds the already parsed response and the status code. This enables us to return a ready to use dart object alongside additional information such as the servers status code.

Now the search_book looks much cleaner. The data-flow is as follows:

• Request the data
• When it arrives check the status code and decide whether to show the result or an error message.

As an alternative to this, it is also possible to use a FutureBuilder which I will go into in one of my next posts.

Making as many widgets as dumb as possible

In v2 the BookCard managed it’s own clicks, meaning when pressed, it went right to the database and updated the appropriate entry. But there’s a better way.

Now, the BookCard exposes two on click listeners, one for the clickable star and one for the rest of the card surface. The card doesn’t know anything about a database or what so ever. It is now reusable in any part of the app.

Furthermore the logic is now at a more appropriate place, a simple card shouldn’t know about a database, its only purpose is to display data and notice clicks.

The Collection Screen

We have a centralized data access and made the BookCard reusable, let’s build a page which displays all starred books.

The repository exposes a method called getFavoriteBooks(), this method gets delegated to the database which then performs a rawQuery:

var result = await db.rawQuery('SELECT * FROM $tableName WHERE ${Book.db_star} = "1"');

I kept the loading indicator because at some point in time the books will also come from a remote database.

And that’s it, the collections page is done.

The build method is pretty much the same as the search screen one. The class can be found here.

Wrapping up

We learned:

• how data abstraction can make the overall code more readable, and easier to manage.
• how making widgets “dumb”, makes them easier to reuse and easier to debug.

If you liked the post be sure to hold that clap button down for a few second.

Also if you want the latest development updates you can follow me on Twitter.

Edit: Part 4 is now up!

Flutter Book App part 4: From demo to real app.

Flutter Bookshelf App Part 3: Managing data the right way. was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.