Contributing to your preferred open source project, starring Flutter — part 1

Fabio de Matos
Flutter Community
Published in
4 min readApr 11, 2018

--

In this installment: How to help the community without writing code.

I’ll show you how you can add a completely new feature to Flutter framework in 3 short steps:

  • Have an idea!
  • Learn Dart and also how Flutter works
  • Modify its internal source code, test it, follow all the review comments and Done!

See how easy?

And if you fine tune the second step you can apply it to so many things, that’s the power of oversimplification that often goes underrated. Look at my other very interesting bullet list, for how to be a millionaire:

  • Have a very good idea
  • ?
  • Get a million dollars

Unfortunately talk is cheap, so let’s stop with the click bait and get to the next part. I’ll guide you through those 3 steps above, from how I went from identifying a feature that I wish was present, to actually making it available and trying to bundle it into the Flutter framework that is used to build all apps.

Have an idea

This is the story of how I started learning Flutter and missed something. I want X when I do Y.

The way Flutter manages assets, either for images or json, is by adding entries to the pubspec.yaml file. They look like this:

flutter:assets:- assets/images/easter_bunny.png- assets/images/christmas_reindeer.png

The second step is to actually add them to your disk.

And finally, that’s how you use them in your source code:

new ImageAsset('assets/images/easter_bunny.png');

That made me cringe. Coming from an Android background and a long time user of different static languages. And the worst part is when you make a typo you’ll only find out when the app is running. It means when you have an image displayed in that rarely used screen that shows after a 10-step checkout flow and you do a refactor, you’d actually never notice unless you have unit tests. Unit tests are important, but they shouldn’t be the only way to detect these kinds of errors. There must be a better and safer way.

Let me show you how Android does it.

Step 1: add file to disk in the appropriate folder. Usually what you want will go in app/main/res/drawable/.

Step 2: Use it in source code in a statically typed and safe way

From xml it looks like this

<ImageButton. . .android:id=“@id/image_easter_bunny”>android:src=“@drawable/easter_bunny”>/>

That’s still a string, but don’t get me wrong, you can’t build your app if that name doesn’t match an existing file in the disk. It’s not a linter feature, it’s really part of the build tools.

Or if accessed with java or kotlin you can write it this way.

imageEasterBunny.setImage(R.drawable.easter_bunny);

And there’s nothing between step 1 and 2. Well, actually Android Studio will crunch a few files around, but as a developer it’s completely seamless.

If you’re developing for iOS step 1 consists of a) drag and dropping the file on XCode (the official IDE) and b) ticking one or two checkboxes.

Step 2 with the GUI consists of selecting from a dropdown list, and only if you rather do it dynamically in Swift you’ll get something unsafe.

UIImage(named: “easter_bunny.png”)

Exploring

I started to wonder, how could it work similarly in Flutter. Fortunately they are an open source project, which means I could peek into http://github.com/flutter/flutter and check if somebody already had that idea and was working on it. As it happens there was issue #4890 about people who wanted to avoid specifying assets one by one, and instead they think there should be a better way to include lots of assets. A real case had LOTS of assets, like, 3000 of them. Well if that’s not going to help me push my case, what would? That’s when I fleshed out some specs:

  • Easy way to add an entire folder
  • Tap into some internal structure and generate a dart source code file with accessors that would lead me to the right string

I actually wanted to have only the second part, but I noticed that they are pretty related. And I decided that I’d give it a try at writing the code myself.

The surprising part is that even before I started coding and was looking at related github issues I found lots of interesting information. And most projects can benefit from people opening issues or writing comments into existing ones, so I’d encourage people to do that part. It doesn’t require you to read code or deep dive into the moving parts, you learn about how things (are supposed to) work and it makes the world a slightly better place. Win-win.

Coding is still in progress, so hold on and check out what will happen in part 2.

Read the next part here: https://medium.com/@fmatosqg/contributing-to-flutter-part-2-46092dc4417e

--

--