Flutter template repository

Rafa Ortega
4 min readJul 25, 2021

Finally got around to write a post! I don’t get to code currently at my job and that’s part of the reason why I started a couple of side projects. I didn’t want to get rusty in my coding skills and every now and then I still enjoy closing Zoom and diving into an IDE where it’s just code and myself.

One of those projects was about creating a template repo to ease starting any app I might want to build using Flutter in the future. I found myself several times creating a project from scratch and going through the same steps over and over again. With the assumption that it’s not only me who has faced this situation, I hope this project can help both my future self and any other developer out there in the same need. The main goal was to create a CI infrastructure for testing, building the app, and distributing it.

It might not seem like a big deal, but you know… Engineers run away from repetitive tasks!

Template project

The template project is hosted in GitHub and can be checked out here. It contains a skeleton with a dummy feature implementation. I also took the chance and created the project replicating an architecture that I would use in a real-life example. That is: using the BloC pattern.

BloC is one of the most used architectural paradigms in Flutter development. It focuses on state management and a separation of the business logic from the UI. If you want to know more about this pattern I recommend you this guide. Don’t hesitate to ask any specifics about the architecture through a comment as well!

For you to have an overview of the project, here is the package structure:

As you can see in the above picture. This template project contains the different layers for a feature, these include view, data, and domain, each of them with the corresponding classes inside. You can also find tests for the BloC class and the widget. On top of that, you can find the corresponding GitHub actions that form the following pipelines setup:

Pull request workflow

Master workflow

Both pipelines are similar and quite self-explanatory. Nevertheless, here are some notes:

  • The “test” step includes also a static code analysis.
  • The last step is different between the two workflows. Inside the pull request one, the binaries are uploaded to Firebase App Distribution while in the master workflow, they are uploaded to the stores (Google Play at the moment, AppStore might come in the future).
  • The built artifacts on each of the pipelines are the proper ones for each scenario; that is, debug for the PR workflow and the release ones in the master branch.

Using the template project

For a small summary of the steps, please take a look at the Readme file in the repository, here they are as well:

  • Update the application ID to match your next amazing app.
  • Create your Firebase project and add the corresponding files (google-services.json and GoogleService-Info.plist) You can find detailed instructions here.
  • After that, if you want to leverage any firebase functionality. You still need to add firebase plugins to your app. The template doesn’t contain any in order to keep it lightweight.
  • In order for your pipeline to be able to upload the files to Firebase App Distribution, you will have to include some secrets into the repository. Those are FIREBASE_ANDROID_APP_ID and FIREBASE_TOKEN.
  • If you want also to enable the master pipeline to upload the Android app into Google Play, you will need SERVICE_ACCOUNT_JSON secret as well.

Disclaimer: the iOS app is currently not uploaded into Firebase because a real developer account is required to create the ipa file. You will need to finish some configuration once you set up your own.

After these small steps, you will be able to start building your app and rely on the CI infrastructure running the code analysis, tests, building your apps, and distributing them for you!

Next steps

There are of course more things that a template repository could do, but I think this is a good starting point. Among those extra things are:

  • Once an iOS developer account is ready, finish up the ipa generation and upload it to Firebase and AppStore.
  • Create test coverage reports.

That’s all for now, please drop me a message if you found this useful or if you think anything can be improved or extended to suit your needs better. Of course, pull requests are more than welcome!

Also, don’t hesitate to tell me if you end up using this template, any feedback is much appreciated.

Thanks for reading!

--

--

Rafa Ortega

Delivery Manager Native Apps @ Ciklum-Lottoland. Previously Android tech architect @ Sync;Android developer @ Trivago. Tech passionate, specially mobile stuff.