Forem: Jonathan Böcker

Drawing arrows in Flutter, or anything else, based on widget positions

Jonathan Böcker — Fri, 07 Aug 2020 07:19:32 +0000

I recently made a Flutter package called widget_arrows which caught some attention on the FlutterDev subreddit.
I thought I'd take a minute to explain how it works, since the technique can be applied to other things, such as a tutorial hole overlay.

Schwusch / widget_arrows

Draw arrows between widgets in Flutter

widget_arrows

Draw arrows between widgets

View on GitHub

Using it is fairly straight forward, wrap the Widgets you want to draw arrows between with an ArrowElement and wrap both with an ArrowContainer higher up in the Widget hierarchy .

In this case I wrap the whole MaterialApp in an ArrowContainer in order to display the arrows while dragging an element:

The core Widget is the ArrowContainer, which is the one drawing the arrows on a canvas layered on top of the child, using a Stack.
Here's an example:



ArrowContainer(
  child: Column(
    children: [
      ArrowElement(
        id: 'top',
        targetId: 'bottom',
        child: Text('Text1'),
      ),
      ArrowElement(
        show: showArrows,
        id: 'bottom',
        child: Text('Text2'),
      ),
    ],
  ),
)

During initState(), the _ArrowElementState looks up the widget hierarchy and finds the closest _ArrowContainerState and registers itself by calling addArrow(this) on the container. The _ArrowContainerState will then trigger a repaint on the CustomPainter that draws on top of ArrowContainers child, which in this case is a Column.

How does the _ArrowElementState find the _ArrowContainerState? By calling this method on the BuildContext:



context.findAncestorStateOfType<_ArrowContainerState>();

Since ArrowContainer is a StatefulWidget, it has its associated _ArrowContainerState. It's a relatively expensive lookup, but the good news is that it is only needed once per ArrowElement.

The _ArrowContainerState has ChangeNotifier mixed in, in its class declaration. That means that it can be passed in as an argument to the CustomPainter constructor, and it will repaint every time _ArrowContainerState calls notifyListeners().

_ArrowContainerState.notifyListeners() is called every time an arrow element is added or removed, which means it is always kept in sync with all ArrowElements currently mounted in its child Widget subtree.

The _ArrowContainerState build method look like this:



@override
Widget build(BuildContext context) => Stack(
      children: [
        widget.child,
        IgnorePointer(
          child: CustomPaint(
            foregroundPainter: _ArrowPainter(
              _elements,
              Directionality.of(context),
              this,
            ),
            child: Container(),
          ),
        ),
      ],
    );

The CustomPaint is wrapped with an IgnorePointer, to let through touch events to widget.child, which is the users real UI. The _ArrowPainter is a custom class extending CustomPainter to draw the Arrows. It takes the _ArrowElementStates as a first argument, the TextDirection as the second argument (we will cover why later), and a Listenable as the third argument. The _ArrowContainerState is a Listenable, due to having ChangeNotifier mixed in.

What happens in _ArrowPainter.paint() is the real magic. It loops through all _ArrowElementStates, and calls this method:



final renderBox = arrowElementState
                    .context
                    .findRenderObject() as RenderBox;

The RenderBox is the key to finding the position of the start and end of the arrows we're about to draw.
By calling this method:



final Offset upperLeftCorner = renderBox.localToGlobal(Offset.zero);

We get an Offset of where it is relative to the top-left corner of the screen. The RenderBox also has RenderBox.size which gives us its dimensions, which is used to describe the rectangle in which the child is drawn.

This is where TextDirection comes in. The ArrowElement has a sourceAnchor and a targetAnchor argument which takes an AlignmentGeometry. This allows us to specify where in the child Widget we like the arrow to start or end from, and is Alignment.centerLeft by default. You can pass an AlignmentDirectional to make it adapt to whether the text is right-to-left or left-to-right. To adapt to the text direction, this method is called on the AlignmentGeometry object:



final Offset startPosition = sourceAnchor
  .resolve(textDirection)
  .withinRect(/*child widget rectangle*/);

From there, all that's left is to draw a Path or whatever you like on the canvas at that position.

Happy Fluttering!

Does null safety (really) bring any value to businesses?

Jonathan Böcker — Tue, 17 Sep 2019 10:09:52 +0000

Here goes another article about null

<TL;DR>

It seems to me that including nullability in type systems is an obvious technical step forward in operational security and cost effectiveness. The market is either lagging behind or I am overestimating its value. Perhaps I am part of a daring but naive minority that gives too much credit to safer type systems.

</TL;DR>

Null safety has become quite fashionable in mainstream platforms. Languages such as Swift and Kotlin is endorsed by Apple and Google for use in their platforms. Rust is all the hype in systems programming and WebAssembly. C# received non-nullable types in its 8th edition and TypeScript is gaining traction as a replacement for JavaScript. The Dart team is working hard to make a similar journey in what they call Non-Null By Default(NNBD).

At the same time, I have encountered development teams where this topic is not spoken of, almost as if this null problem that so many language creators is working on is a non-issue. Many developers go about in their Java/C++/JavaScript code base, adding value to their company as intended, not adopting this null-safe fad. Null safe languages is rarely in the top 10 when measuring most used/most popular languages such as TIOBE index and Github Octoverse, with the exception of C# (not measuring the usage of C#8 and onward) and TypeScript (measured in open source projects).

"We manage to build software very well without null safety, thank you very much." - Mr Straw Man, for the sake of this argument

There is a million reasons not to solve this theoretical issue, and I sympathize with a lot of them. Introducing new technical decisions is always a risk, and there has to be equal or larger benefit balancing out the risk-reward scale. It might be a good idea to compare this paradigm leap to paradigm shifts of similar magnitude. The object-oriented paradigm brought a nominal type system which has been widely adopted and brings many benefits when statically typed:

// Java
class Cat {
    void meow() {}
}

class Dog {
    void bark() {}
}

Dog doggie = new Dog();

doggie.meow(); // Compiler error

This example might be obvious and intuitive as to why it will not, and should not, work. It is hard to quantify how much value the nominal type system has brought to businesses, but the popularity is statistically clear. The object-oriented languages has won the market with a landslide.

It is harder to reason about, and explain why this should be able to compile:

// Java
Dog doggie = null;

doggie.bark(); // Compiles but explodes at runtime

There is seemingly no good reason for this to be allowed, but it just is the way most popular languages work. It can seem a bit disorderly for a newcomer that a type system made to protect the programmer from common mistakes allows for this "shadow" type system. An extra dimension, where you as a programmer has to act as a compiler and find these programmatic landmines. Landmines that plague applications in production everyday, since humans are not as competent as compilers at finding type system errors.

"But null is a value and not a type, and should be evaluated at runtime", someone might add. True in a sense, but most type systems does not allow an instance of Cat to be assigned to a Dog-typed variable. I would argue the instantiated Cat is a value, at least when assigned to a Cat-typed variable.

Tony Hoare says it is a bad idea, and it is his invention

Most people have heard or read Tony Hoare declaring null references as his "billion dollar mistake", and it deserves to be repeated. There is a reason why so many languages deals with this. A weak but colorful analogy would be firearms, which in most cases has what is called a safety catch to somewhat reduce the risk of an accidental discharge. It is questionable whether a safety catch is a good idea when the user needs to fire the weapon as fast as possible in a threatening situation. Still most, if not all, military and police weapons implement some kind of safety catch. This could seem unproductive if the human factor were not accounted for, but it is indubitably a good idea when considering the users, probably stressed and maybe even sleep deprived.

When push comes to shove we need to compensate the human factor through the safety of their tools. A classic risk vs consequence analysis has to be made before deciding on the tool to be used by the many.
This leaves me wondering about the rationale behind the choice of a programming language without a null safety catch. Is the probability of a programmer forgetting a manual null check dismissably low, or is the eventual consequences considered tolerable?

Not all accidents can be prevented

Stray bullets still fire despite weapon safeties and applications crash or break even when implemented with type-safe languages. Why do language creators still bother creating these complex compiler heuristics, offering us these implied senses of security?
One could argue it gives the programmer a peace of mind while focusing on the main task at hand. Why doing cognitive work that can be offloaded to a compiler, says the pragmatist. The compiler can never catch all bugs, so it is better to check it properly yourself, the cynic would argue.

Return of investment (ROI) is a central concept to businesses, and technical decisions is no exempt to this reasoning. If the price of the safety catch quadruples the price of the gun, an argument can be made to just train the soldier to be more careful. If the price of development would rise in disproportion to the gains of security by choosing a type-safe language, it would be no wonder why Java and C++ is still popular. It is however not as easy to measure alternative development costs as it is to measure the costs of different weapon configurations.