Forem: Levi Zitting

Flutter Multiple Stream Builder Package

Levi Zitting — Sat, 19 Dec 2020 06:18:27 +0000

When working with Flutter I find myself working with streams quite a bit. They're a great way to allow various parts of your app to be notified when data changes and keep things reactive.

Flutter even provides a built-in widget for working with streams called StreamBuilder. This widget allows you to pass in a stream along with a builder method that will get called every time the stream receives new data. Here's a quick example of how to use a StreamBuilder:

var stream = Stream<int>.periodic(Duration(seconds: 1));

Widget build(BuildContext context) {
  return StreamBuilder<int>(
    stream: stream,
    builder: (context, snapshot) {
      return Text('value: ${snapshot.data}');
    },
  );
}

For the most part, StreamBuilder works well. That is until you need values from multiple streams to build your UI. In that case, you have to resort to nesting StreamBuilders. Which, depending on how complicated your build method is can get a bit ugly.

var stream1 = Stream<int>.periodic(Duration(seconds: 1), (x) => x);
var stream2 = Stream<int>.periodic(Duration(seconds: 2), (x) => x);
var stream3 = Stream<int>.periodic(Duration(seconds: 3), (x) => x);

Widget build(BuildContext context) {
  return StreamBuilder<int>(
    stream: stream1,
    builder: (context, snapshot1) {
      return StreamBuilder<int>(
        stream: stream2,
        builder: (context, snapshot2) {
          return StreamBuilder<int>(
            stream: stream3,
            builder: (context, snapshot3) {
              return Text(
                'stream1: ${snapshot1.data} - stream2: ${snapshot2.data} - stream3: ${snapshot3.data}',
              );
            },
          );
        },
      );
    },
  );
}

So how can we clean this up? Let me introduce a package I published called multiple_stream_builder. This package provides new widgets that behave almost the same as a normal StreamBuilder, but it allows you to pass in multiple streams instead of just one.

Widget build(BuildContext context) {
  return StreamBuilder3<int, int, int>(
    streams: StreamTuple3(stream1, stream2, stream3),
    builder: (context, snapshots) {
      return Text(
        'stream1: ${snapshots.snapshot1.data} - stream2: ${snapshots.snapshot2.data} - stream3: ${snapshots.snapshot3.data}',
      );
    },
  );
}

As you can see this greatly shortens the amount of code we have to add as well as reduces the amount of nesting we need.
Due to some technical limitations with the Dart language you have to use a different StreamBuilder depending on the number of streams you want to pass in. For example, if you need data from 4 streams you'd use StreamBuilder4 while you'd use StreamBuilder2 for 2 streams.

If you want to get started using the package you can see the installation instructions on the package's pub.dev page. If you run into any issues with the package or would like to suggest a feature feel free to open an issue on the Github repo.

3 Features To Look For In a DNS Provider

Levi Zitting — Thu, 20 Aug 2020 16:05:57 +0000

There are countless DNS providers out there. Most of them make it easy enough to create and update the various records associated with your domains, but there are a handful of features that can make a DNS provider go from decent to amazing.

TTL Limit

Most DNS providers give you the option to adjust the TTL your domains DNS record. This value tells other DNS servers how long to cache the record for. When changing the value of a record it can be handy to set the TTL to be very low sometime before adjusting the record's value so you see the change much faster. There are some DNS providers that won't let you set this value to be very low. For instance, Network Solution's lower limit for TTL values is one hour, which has caused me plenty of issues in the past trying to point records towards new resources. As a rule of thumb, 5 minutes as a lower limit is a good balance between the speed of changes and cacheability.

Web forwarding.

There are plenty of scenarios where you may want to have traffic redirected from one domain or subdomain to another. (e.g blog.mydomain.com to myotherdomain.com/blog). One way to handle this is to point the domain at a web server or web application and handle the redirect there. However the easiest way, if your DNS provider has the feature, is to use web forwarding. Most DNS providers that support web forwarding make it fairly simple, just choose the domain or subdomain you want to redirect and then choose the URL you want traffic to be directed to. This lets you avoid having to set up any additional redirects to handle simple redirects.

ALIAS, ANAME, Virtual CNAME records

A tiny, annoying limitation in the DNS spec is that the root record for a domain can't be a CNAME. This can be incredibly frustrating when trying to point a record towards a resource such as an AWS Application Load Balancer. Resources like these don't always provide an actual IP for an A record to use, instead, they usually provide some other DNS name and expect you to create a CNAME record to direct traffic at the resource. Due to this DNS limitation, you would have to have traffic go through a subdomain (such as www) and have traffic to the root domain be redirected to the subdomain. (using something like web forwarding or a redirect server with a static IP)
However, some DNS providers offer workarounds to this DNS limitation through nonstandard record types. The most popular of these are ALIAS, ANAME, or Virtual CNAME records. These records are used exactly like traditional CNAME records. Behind the scenes, the DNS provider will resolve the record's value to the actual IPs and present them to the outside world as A records.

Hi, I'm Levi Zitting

Levi Zitting — Tue, 07 Feb 2017 20:02:04 +0000

I have been coding for 5+ years. I'm 19 years old and I live in southwest MO

You can find me on Twitter as @levi_zitting and on Github as @glitchedmob

I work with JavaScript, TypeScript, and PHP