My experience on Null-Safety for Simple Animations and Supercharged

Felix Blaschke
2 min readNov 21, 2020

This week the Flutter/Dart team announced the beta for null-safety dart code: Now it’s the perfect time for packages to migrate.

So…my packages got migrated today! You can start testing your dependent packages or apps to prepare its migration.

  • Simple Animations will raise to version 3.0.0. With this step I will drop the migration package that helps the upgrade from 1.x.x to 2.x.x . Make sure to migrate to 2.x.x in order to opt-in into null-safety.
  • Supercharged will raise to version 2.0.0 without any unexpected breaking changes.

What is my experience with migration process?

I mainly followed the dart migration guide. Unfortunately the dart migrate command thrown some errors and couldn’t help. “It can’t be that hard”, I told to myself and just did it by hand. I used the Dart Analysis panel in Android Studio to navigate through the issues.

I stepped through the issues without fixing it, to get an overview on the different “null situations”. Then I made plan on how to handle different situations where I used nullability or could introduce nullability.

Introducing? Yes, since we have compiler level nullability awareness now, we can use null to indicate that things are somehow likely to blow up. Dart doesn’t force you to catch Runtime Exception/Errors like Java. But with nullability you can force developers to double check certain function call.

Another positive aspect is less code in functions. All these ArgumentError.checkNotNull(paramName, "paramName") went away. I also found a spot where "paramName" didn’t matched paramName anymore, because I refactored it at some point. This can never happen again. Also the unit tests got reduced. No more null-tests! 😊

So what’s the key takeaway?

Try to asap setup your Flutter environment (beta channel, set SDK constraints) until the point it highlights all your null issues. You don’t need to solve them immediately. Get an overview of the issues.

Don’t get afraid of the Analysis error count. You can solve nearly each issue one by one. Create a Git testing branch. Start to play around with the issues. Just think about how to solve this. Don’t fix it now. Move to the next issue. Sleep.

After some time you will feel confident on how to fix it. Then fix it.

Until next time
— Felix —