DEV Community: Jordan Holland

Getting a substring in Dart

Jordan Holland — Wed, 11 Aug 2021 04:01:03 +0000

I was trying to figure out the most efficient way to trim or shorten a String in Dart(more speficially for a Flutter project) yesterday. There's actually a couple of different ways to do it.

The `substring` method

The first and most typical one is using the substring method. The use case is pretty simple, you call substring on your string and specify a start and end index:

final name = "developermemos";
final portion = name.substring(0, 9); // developer

While it's easy to understand it wasn't great for my use case because I just wanted to shorten an existing string, and if you specify an end index that your string doesn't contain(for example 20 for the above case hypothetically) you will get a RangeError.

The characters approach

What I wanted to do was get the first x characters for a string that could potentially have a length of anything above 0. I found out that the easiest approach for this case is to use .characters.take on the string, here's an example:

final name = "developermemos";
final portion = name.characters.take(9).toString(); // developer

The good thing about this approach is that you won't get a RangeError like you would with substring if you specify an index that is too high, it will just return the entire string instead:

final name = "developermemos";
final portion = name.characters.take(30).toString(); // developermemos

This was perfect for my particular use case. The only caveat is that it seems like while the above will work without any imports in Flutter, if you are using plain Dart you need to add and import the characters package.

Bonus: The takeLast method

There's also another method called takeLast that does pretty much the same thing as take but in reverse, it will take the last x characters from a string. If you use a count that is higher than the length of the string itself it will just return the entire string. Here's a quick example:

final name = "developermemos";
final portion = name.characters.takeLast(5).toString(); // memos

Capturing a Flutter widget as an image using RepaintBoundary

Jordan Holland — Wed, 04 Aug 2021 23:15:13 +0000

The other day I decided I wanted to add a feature in one of my projects to share a graph and I was looking for ways to convert the graph into an image. In the end the approach that I landed on was using the RepaintBoundary widget and I'm going to explain how to use it in this post.

The widget

First of all let's just start with a widget, a green Container with some text inside. Here's what the code for it looks like:

Container(
  decoration: BoxDecoration(
    color: Colors.green,
  ),
  height: 200,
  width: 400,
  child: Center(
    child: Text(
      "Hello world!",
      style: TextStyle(
        color: Colors.white,
        fontSize: 24,
      ),
    )
  )
)

And here's what the above widget looks like visually(this was generated using DartPad):

Wrap it with RepaintBoundary

To convert this widget to an image file(or capture/screenshot it) you need to wrap the widget in a RepaintBoundary widget:

RepaintBoundary(
  child: Container(
    decoration: BoxDecoration(
      color: Colors.green,
    ),
    height: 200,
    width: 400,
    child: Center(
      child: Text(
        "Hello world!",
        style: TextStyle(
          color: Colors.white,
          fontSize: 24,
        ),
      ),
    ),
  ),
)

Then you need to create a GlobalKey and pass that to the RepaintBoundary widget:


final key = GlobalKey();

...

RepaintBoundary(
  key: key,
  child: Container(
    decoration: BoxDecoration(
      color: Colors.green,
    ),
    height: 200,
    width: 400,
    child: Center(
      child: Text(
        "Hello world!",
        style: TextStyle(
          color: Colors.white,
          fontSize: 24,
        ),
      ),
    ),
  ),
)

Create the image

Now the last step is to use the key above kind of like a controller and create an image representation of the widget wrapped inside RepaintBoundary. I probably should also add that the widget you wrap doesn't have to be a Container widget. Okay, onto the code for getting the bytes for an image. You could trigger this code with a button or something along those lines:

final boundary = key.currentContext?.findRenderObject() as RenderRepaintBoundary?;
final image = await boundary?.toImage();
final byteData = await image?.toByteData(format: ImageByteFormat.png);
final imageBytes = byteData?.buffer.asUint8List();

Then the next step is to write those bytes to a file somewhere(you will need the path_provider package to use getApplicationDocumentsDirectory):

if (imageBytes != null) {
  final directory = await getApplicationDocumentsDirectory();
  final imagePath = await File('${directory.path}/container_image.png').create();
  await imagePath.writeAsBytes(imageBytes);
}

And here is the full code for this step:

final boundary = key.currentContext?.findRenderObject() as RenderRepaintBoundary?;
final image = await boundary?.toImage();
final byteData = await image?.toByteData(format: ImageByteFormat.png);
final imageBytes = byteData?.buffer.asUint8List();

if (imageBytes != null) {
  final directory = await getApplicationDocumentsDirectory();
  final imagePath = await File('${directory.path}/container_image.png').create();
  await imagePath.writeAsBytes(imageBytes);
}

Once you execute this code an image representation of the widget will be created in the applications document directory of your app. Here's the output I got after I executed the code on an iOS simulator:

By the way you can view the contents of a simulator's document directory using the following command on MacOS:

open `xcrun simctl get_app_container booted [Bundle ID] data`

Some caveats

I'll close this post with a couple of caveats with the approach above:

The resulting image might end up pixelated in some cases. You can rectify this by passing the pixelRatio parameter when using await boundary?.toImage(). You might want to combine this with MediaQuery.of(context).devicePixelRatio for the best effect. I learnt about this from the README of an excellent package called screenshot. (The reason I wrote my own implementation is because I already use a lot of packages in the project I was working on and didn't want to add any more...)
The generated image will be in PNG format. I'm not sure if you can generate a JPEG image or how you would do it. I might end up investigating this in the future.

Excluding Dart files from static analysis

Jordan Holland — Tue, 20 Jul 2021 02:32:02 +0000

I wrote a couple of posts about linting this year, but this one is about excluding files from static analysis. After adding static analysis to most of my Flutter projects I found that sometimes there were files that I didn't want to be warned about.

A good example of this is if you use something like mockito or json_serializable. When you implement these kinds of packages in your project you run build_runner and they generate code for you. Sometimes the analyzer will pick up issues with the generated code. You're not going to edit generated code to squash linting issues(or you shouldn't edit it anyway).

I got sick of the generated code files in my project showing up in the 'Problems' tab of VSCode so I finally decided to go digging for a solution this week and it was refreshingly straight forward. You just need to make some small changes to your analysis_options.yaml file. So for example if your file looks something like this:

include: package:flutter_lints/flutter.yaml

linter:
  rules:
    use_key_in_widget_constructors: false

You just need to add a key for analyzer and add your exclusions below it with exclude, like this:

include: package:flutter_lints/flutter.yaml

analyzer:
  exclude:
    - 'lib/ui/something/file1.dart'
    - 'lib/data/something/file2.dart'  

linter:
  rules:
    use_key_in_widget_constructors: false

You can also use '**' to target specific file patterns, so if you wanted to ignore all the .mocks.dart files in a specific test directory you could do something like this:

include: package:flutter_lints/flutter.yaml

analyzer:
  exclude:
    - 'lib/ui/something/file1.dart'
    - 'test/data/notifiers/**.mocks.dart'  

linter:
  rules:
    use_key_in_widget_constructors: false

You can also target all files with a specific pattern globally too. In my project I wanted to exclude all files with .mocks.dart and .g.dart so I ended up with these settings:

include: package:flutter_lints/flutter.yaml

analyzer:
  exclude:
    - '**.g.dart'  
    - '**.mocks.dart'

linter:
  rules:
    use_key_in_widget_constructors: false

The above examples worked for me in a Flutter project with sdk: ">=2.12.0 <3.0.0", and you can find more discussion about the topic here. It looks like the are some reports recently about issues with Dart 2.13.0 though 😅. And speaking of linting, if you want to hear my (very brief) thoughts about flutter_lints then check out my post from the other week.

Run Flutter tests with GitHub Actions

Jordan Holland — Sat, 10 Jul 2021 00:05:56 +0000

If you're like me you probably like setting your project up to automatically run your tests when you create a Pull Request on GitHub. I wrote another post about upgrading Flutter packages with GitHub Actions in May but I realised today that I never wrote a post about running tests, so here we go.

Run Flutter tests with GitHub Actions

There isn't an Action on the marketplace that does all of the steps for you. It's still pretty easy to set things up but, for installing Flutter I always use subosito/flutter-action@v1. Here are the rough steps that I want my action to perform:

Checkout the project
Caching(optional because it only saves around 30 seconds or so)
Install Flutter
Run pub get
Run the tests

The file for the action

So with the steps written above this is what we roughly end up with:

name: Run Tests(for PRs)

on:
  workflow_dispatch:
  # Runs when a PR is made against master branch 
  pull_request:
    branches: [ master ]

env:
  flutter_version: "2.2.3"

jobs:
  run_tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      # Cache Flutter environment
      - name: Cache Flutter dependencies
        uses: actions/cache@v2
        with:
          path: /opt/hostedtoolcache/flutter
          key: ${{ runner.OS }}-flutter-install-cache-${{ env.flutter_version }}  
      - uses: subosito/flutter-action@v1
        with:
          flutter-version: ${{ env.flutter_version }}
          channel: stable 
      # Run pub get 
      - name: Run pub get   
        run: flutter pub get
      # Runs tests
      - name: Run tests
        run: flutter test

Tinkering

The above action will run whenever you create a Pull Request against the master branch. You could change this to whatever your default branch is, you can even define multiple branches.
I also added workflow_dispatch so the action can be run manually - the reason I did this is because the cache doesn't seem to build properly unless you run the action on the base branch once(this seems to be by design according to GitHub).
You can also change the Flutter version around to your liking, the action above is pinned to 2.2.3 which is the latest stable version at this time. In some of my projects I started specifying 2.x for the version(but tossed out caching) so I don't have to update my actions every couple of weeks.

Potential Improvements

I think the only thing you could potentially add to the above action is something to build the project at the end like flutter build ios or flutter build apk. If your unit tests don't have great coverage you could potentially break your project and I'm pretty sure your tests would still run without any issues. Adding a build step to the end would make sure that your project still builds correctly, but keep in mind this would make the action take longer to finish.

Automate Flutter package upgrades with GitHub Actions(a Dependabot alternative)

Jordan Holland — Mon, 05 Jul 2021 03:16:06 +0000

Like with pretty much any other framework, keeping up with package upgrades in Flutter can get pretty tedious. I decided to see if I could make things a little less tedious over the weekend and I'd like to share a GitHub Action workflow that I came up with while experimenting.

What about Dependabot?

I'd actually be happy to use Dependabot but there isn't full support yet. Somebody is working on it at the moment though. I'm confident there will be full support one day, it's just a matter of time. For now though Dependabot isn't really a realistic option.

Using GitHub Actions

There was the option of creating an Action and putting it on the Actions Marketplace but I'm not entirely sure what that would involve yet and I'm not that committed to the idea yet either considering that there is work being done on the Dependabot front. So in the end I just decided to create a workflow with existing Marketplace Actions. Here's roughly the set of steps I wanted the workflow to use:

Check out the repo
Pull in cache data(so the next step runs a little faster)
Setup Flutter CLI so it can be used in the next steps
Run flutter pub upgrade --major-versions
Run flutter pub get
Run flutter test
(Optional) Capture the output of flutter pub outdated for later
If there are changes from (4) commit them to a new branch and open a PR

And obviously I'd want this workflow to run every so often so it would need to be scheduled with cron. In the end this is what I came up with:

name: Upgrade packages

on:
  workflow_dispatch:
  schedule:
    - cron: "0 0 * * *"

env:
  flutter_version: "2.2.2"

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  upgrade_packages:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2
      - name: Cache Flutter dependencies
        uses: actions/cache@v2
        with:
          path: /opt/hostedtoolcache/flutter
          key: ${{ runner.OS }}-flutter-install-cache-${{ env.flutter_version }}  
      # Installs Flutter    
      - uses: subosito/flutter-action@v1
        with:
          flutter-version: ${{ env.flutter_version }}
          channel: stable   
      # Upgrade packages(bump major versions)    
      - name: Run upgrade
        run: flutter pub upgrade --major-versions
      # Get/install packages  
      - name: Run get
        run: flutter pub get  
      # Run tests  
      - name: Run tests
        run: flutter test
      # Captures the output of `flutter pub outdated`  
      - name: Check remaining outdated packages
        id: check_outdated
        run: |
          content="$(flutter pub outdated)"
          content="${content//'%'/'%25'}"
          content="${content//$'\n'/'%0A'}"
          content="${content//$'\r'/'%0D'}"
          echo "::set-output name=outdated_info::$content"
      # Opens a pull request with changes    
      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v3
        with:
            token: ${{ secrets.PAT }}
            commit-message: Upgrade packages
            title: Upgrade packages
            body: | 
              Output for outdated check following upgrades:
              ${{ steps.check_outdated.outputs.outdated_info }}
            branch: feature/update-packages

For this to work you need to generate a Personal Access Token in your GitHub account's settings and then add that as a secret to your repository. You can learn more about this here. This is what the ${{ secrets.PAT }} value represents in the last step.

You might have also noticed that I have this set to run everyday at 12am UTC. I'm going to tweak this later on but like I said I'm just experimenting with things at the moment and want to see if I run into any issues down the road. If I find some improvements I can make I will update this post. If you wanted to run this on a weekly schedule instead, you could use something like "0 0 * * Sun" instead(12am UTC every Sunday).

Caveats

The above workflow has been working pretty good for me for the last few days on some simple, small projects. That being said it is far from perfect.

First of all the above workflow won't upgrade your Pods on the iOS side of things. If you switch from ubuntu-latest to macos-latest you could run pod install --repo-update in the ios directory of your project, I did try this out personally and it seemed to work okay - but keep in mind that workflows that use MacOS cost something like 10 times more than workflows that use Ubuntu. This would probably matter less if you were only running the workflow once a week or something like that.

Another thing you could tweak is the flutter pub upgrade --major-versions command. This command will potentially pull in breaking changes because it will upgrade over major versions. You can opt out of this behaviour by just running flutter pub upgrade instead.

One more shortcoming of the workflow above is that it only runs your tests. Your tests might not cover everything so adding a flutter build ios or flutter build apk might add an extra layer of security if the upgrades break your project. I think I'm going to look into all of these points as I keep tweaking the workflow.

Summing up

Like I said the workflow I introduced above definitely isn't perfect but I think that it's a good start and something that can be used to keep sane while we all wait for Dependabot support. If you're interested in more Flutter tips, I wrote another post about adding linting to a project a couple of days ago - you can find it here.

Trying out the flutter_lints package

Jordan Holland — Thu, 01 Jul 2021 03:48:02 +0000

I made another post last month about using linting in Flutter projects but the other day I found out about a (relatively) new package called flutter_lints so I thought I'd try it out and give my impressions.

The (somewhat) older options

If you read my other post or use linting in your Flutter projects you'll probably already know that there were two major options up until now for linting:

lints
pedantic (used internally at Google?)

I've used both and they are both pretty good, I use lints a lot more often though. I kind of get the feeling that lints is a little stricter but that just might be my imagination.

The new challenger(flutter_lints)

So I was browsing Twitter the other day and I saw a tweet in my timeline about flutter_lints. It looks like this package is actually endorsed and maintained by the Flutter Team. According to the pub.dev page it's built on top of the lints package I mentioned above:

This package is built on top of Dart's recommended.yaml set of lints from package:lints.

I also saw something else cool in the README:

Flutter apps, packages, and plugins created with flutter create starting with Flutter version 2.xx are already set up to use the lints defined in this package. Entities created before that version can use these lints by following these instructions:

It looks like this is going to come bundled automatically when you set up a new project from now on? I created a new Flutter project with 2.2.2 two days or so ago and couldn't confirm this but, so maybe it's something that hasn't landed on stable yet.

My impressions

So I decided to add flutter_lints to one of my older projects and take it for a test drive. If you need steps on how to do this you can check out my post from last month.

Unsurprisingly I found it to be really similar to lints, but I did notice I got a lot of 'Use widget key in constructors' warnings in my custom widgets. This warning is definitely fair, I just hadn't seen it before with lints or pedantic. Apart from that I mostly got the same warnings as with the other options, especially about adding const keywords 😅.

If this ends up automatically being added to all new projects it will be great, it'll take another step off my setup process. Plus, I never used to use any linting in my Flutter projects until a couple of months ago and I kind of regret not doing it sooner - it will definitely make things a lot cleaner and streamlined for newcomers.

Mixing packages that don't support null safety in Flutter

Jordan Holland — Wed, 30 Jun 2021 03:43:26 +0000

Null safety has been supported for a few months now in Dart and Flutter. I've migrated pretty much all of my projects to null safety without any issues but in some cases you might be waiting on a particular package that isn't supported yet. It's actually possible to use packages that don't support null safety in your project and still migrate to null safety. It's even possible to slowly migrate your project piece by piece to null safety too.

Using outdated packages(that don't support null safety)

I ended up in this precidament with one of my projects because I made the mistake of depending on charts_flutter. The package itself is great but Google is pretty terrible at keeping the GitHub mirror up to date with their internal repo. That's a story for another day though...Anyway there was only one package in my project holding me back from going to null safety. Building without null safety requires passing an extra command line flag, that's why I put things off for so long but in the end I gave in. So if you want to use outdated packages in your project(that has migrated to null safety) you need to add this to basically every command: --no-sound-null-safety. So if you were running flutter run you would do it like this:

flutter run --no-sound-null-safety

Same goes for your tests as well:

flutter test --no-sound-null-safety

Declaring the Dart version of your entry point

There's also another option of adding // @dart=2.9 to the top of the entry point(main.dart) of your app:

// @dart=2.9

main() {
  // Do something
}

I personally like this option better but doing this won't extend to your tests, so you either have to pin the dart version of all of your tests to 2.9 or use the --no-sound-null-safety flag. You can use the version pinning above to slowly migrate your project files too, which is pretty good if you would like to break your migration up into small commits(but still keep everything working between each commit).

In the end I just opted for using --no-sound-null-safety because I wanted to migrate all of my tests too. By the way, you still have to pass this flag even when you're doing stuff like building APK files:

fvm flutter build apk --split-per-abi --no-sound-null-safety

I'm gunna try fiddling with the entry point version pinning in the future to see if I can work around this somehow.

But this doesn't work with Visual Studio Code...

Yeah I noticed this myself too... To get all of this working with VSC(including your tests) you need to change some settings. Open your preferences and then select 'Workspace', then type 'args' into the search bar. After that select 'Dart & Flutter' from Extensions in the left pane. After this you should see settings for passing additional arguments to a bunch of different Flutter commands. You need to add --no-sound-null-safety to the ones that are relevant to you. You could opt to pass it to all flutter CLI commands too. I just added it for run and test in the end. Here's a screenshot of my setup for reference:

The pains of null safety migration

Null safety support was a pretty big change. I think it was worth it too, and I'm really glad that there is atleast an option to choose to build/run without complete null safety. I do kind of wish Google would keep their repos up to date though...Even if it is just a mirror of an internal project... But I guess that is just how open source is so I can't really complain too much.

DEV Community: Jordan Holland

Getting a substring in Dart

The substring method

The characters approach

Bonus: The takeLast method

Capturing a Flutter widget as an image using RepaintBoundary

The widget

Wrap it with RepaintBoundary

Create the image

Some caveats

Excluding Dart files from static analysis

Run Flutter tests with GitHub Actions

Run Flutter tests with GitHub Actions

The file for the action

Tinkering

Potential Improvements

Automate Flutter package upgrades with GitHub Actions(a Dependabot alternative)

What about Dependabot?

Using GitHub Actions

Caveats

Summing up

Trying out the flutter_lints package

The (somewhat) older options

The new challenger(flutter_lints)

My impressions

Mixing packages that don't support null safety in Flutter

Using outdated packages(that don't support null safety)

Declaring the Dart version of your entry point

But this doesn't work with Visual Studio Code...

The pains of null safety migration

The `substring` method