DEV Community: Daniel Gomez

Building and Deploying Flutter Apps from CI with Fastlane: How to Reuse Code Efficiently

Daniel Gomez — Thu, 27 May 2021 00:11:19 +0000

We use fastlane for our flutter apps, for ios and android builds, it give us a common language to define the setup and reuse code for:

Generating a changelog based on our changelog style
Validate code style, formatting and lint
Unit testing
Verify that the project autogenerated code is been built fine.
Verify that the project builds fine for each platform.
Deploy to firebase app distribution for testing
Deploying to each app store

There are some tricks to be able to do it:

Create a parent fastfile where you have the reusable logic and one for each platform ios/fastfile and android/fastfile.
Have an easy way to run tasks from the root of the project, our idea was to create a lane sh_on_root to run all flutter commands from each platform fastfile.
Create a Gemfile for each platform and define .ruby-version file to have a defined environment to run, helping us to avoid problems on CI server requiring some specific ruby version to run fastlane in there.

Another thing we noticed is that using --no-pub --suppress-analytics params from flutter commands saved us some time on CI if you want to try that's a good start.

I will show an example of some usefull lanes and some workflows for them, you should think about your needs and call the lanes you need for each step but try to reuse for each platform some tasks having the parent fastfile file.

Show me the setup

Create the Gemfile for each platform
android/Gemfile
ios/Gemfile

Contents:

source "https://rubygems.org"

gem 'cocoapods'
gem "fastlane"

plugins_path = File.join(File.dirname(__FILE__), 'fastlane', 'Pluginfile')
eval_gemfile(plugins_path) if File.exist?(plugins_path)

Create the .ruby-version so the CI (in our case Bitrise) have a clue of which ruby version should be used
ios/.ruby-version
android/.ruby-version

Contents:

2.6.5

Create 3 fastlane files, 1 to be reused by each platform, and 1 for each platform (check that from each platform fastlane we import the parent one with import "../../scripts/Fastfile")

fastfile:

opt_out_usage

# Have an easy way to get the root of the project
def root_path
  Dir.pwd.sub(/.*\Kfastlane/, '').sub(/.*\Kandroid/, '').sub(/.*\Kios/, '').sub(/.*\K\/\//, '')
end

# Have an easy way to run flutter tasks on the root of the project
lane :sh_on_root do |options|
  command = options[:command]
  sh("cd #{root_path} && #{command}")
end

# Tasks to be reused on each platform flow
lane :fetch_dependencies do
  sh_on_root(command: "flutter pub get --suppress-analytics")
end

# Tasks to be reused on each platform flow
lane :build_autogenerated_code do
  sh_on_root(command: "flutter pub run intl_utils:generate && flutter pub run build_runner build --delete-conflicting-outputs")
end

# Tasks to be reused on each platform flow
lane :lint do
  sh_on_root(command: "flutter format --suppress-analytics --set-exit-if-changed -n lib/main.dart lib/src/ test/")
end

# Tasks to be reused on each platform flow
lane :test do |options|
  sh_on_root(command: "flutter test --no-pub --coverage --suppress-analytics")
end

ios/fastfile:

import "../../scripts/Fastfile"

default_platform(:ios)

platform :ios do
  # Updates XCode project settings to use a different code signing based on method
  private_lane :archive do |options|
    method = options[:method]

    profile_name = method == 'ad-hoc' ? "Distribution - Staging (adhoc)" : "Production"
    update_code_signing_settings(profile_name: profile_name)

    build_app(export_method: method)
  end

  private_lane :authenticate_apple_store do
    p8_path = path_for_secret("your .p8 file path")

    app_store_connect_api_key(
      key_id: "your key id",
      issuer_id: "your used id",
      key_filepath: p8_path,
      duration: 1200, # optional
      in_house: false,
    )
  end

  lane :build do |options|
    # Reuse parent fastfile tasks
    fetch_dependencies
    build_autogenerated_code


    sign_enabled = options[:sign_enabled] || false
    sign_param = sign_enabled ? '' : '--no-codesign'

    config_only = options[:config_only] || false
    config_param = config_only ? '--config-only' : ''

    sh_on_root(command: "flutter build ios --no-pub --suppress-analytics --release #{sign_param} #{config_param}")
  end

  lane :deploy_staging do
    build(sign_enabled: true)
    archive(method: "ad-hoc")

    upload_symbols_to_crashlytics(dsym_path: "your.app.dSYM.zip")

    firebase_app_distribution(
      app: "yours app id from firebase",
      ipa_path: "your.ipa",
      groups: "developers, staging",
      release_notes: changelog
    )
  end

  lane :deploy_staging_testflight do
    build(sign_enabled: true)
    archive(method: "app-store")

    authenticate_apple_store

    # Reuse parent fastfile tasks
    test

    upload_to_testflight(
      ipa: "your.ipa",
      reject_build_waiting_for_review: true,
      skip_waiting_for_build_processing: false,
      distribute_external: true,
      notify_external_testers: true,
      groups: "Your testers"
    )
  end

  lane :deploy_production do    
    # All certificates and .p8 file should be fine on runnning machine
    build(sign_enabled: true, config_only: true)
    archive(method: "app-store")
    authenticate_apple_store

    # Reuse parent fastfile tasks
    test

    deliver(
      ipa: "your.ipa",
      skip_metadata: true,
      skip_screenshots: true,
      submit_for_review: false,
      force: false,
      automatic_release: false,
      submission_information: {
        add_id_info_serves_ads: false,
        add_id_info_uses_idfa: false,
        export_compliance_uses_encryption: false,
      },
      precheck_include_in_app_purchases: false,
    )
  end
end

android/fastfile

import "../../scripts/Fastfile"

default_platform(:android)

platform :android do
  private_lane :build_apk do
    # Reuse parent fastfile tasks
    fetch_dependencies
    build_autogenerated_code

    sh_on_root(command: "flutter build apk --release")
  end

  lane :build do
    # Reuse parent fastfile tasks
    fetch_dependencies
    build_autogenerated_code

    sh_on_root(command: "flutter build appbundle --no-pub --release --suppress-analytics")
  end

  lane :deploy_staging do
    build_apk

    # Reuse parent fastfile tasks
    test

    firebase_app_distribution(
      app: "your app id",
      groups: "your testers",
      android_artifact_type: "APK",
      android_artifact_path: "#{root_path}/build/app/outputs/flutter-apk/app-release.apk",
      firebase_cli_path: "/usr/local/bin/firebase"
    )
  end

  lane :deploy_production do
    build

    # Reuse parent fastfile tasks
    test

    supply(
      track: 'beta',
      aab: "../build/app/outputs/bundle/release/app-release.aab",
      json_key: path_for_secret("your play store.json"),
      skip_upload_apk: true, # Upload the aab instead of apk
      skip_upload_metadata: true,
      skip_upload_changelogs: true,
      skip_upload_images: true,
      skip_upload_screenshots: true
    )
  end
end

How to install an app on Android Work Profile for Debug

Daniel Gomez — Thu, 11 Feb 2021 19:30:05 +0000

List all of your users (to find the number of the work profile (in the example the 11 is the work profile):

$ adb shell pm list users
Users:
    UserInfo{0:Propietario:13} running
    UserInfo{11:Perfil de trabajo:30} running

Copy the APK and then install it for that user with:

adb push app-debug.apk /data/local/tmp 
adb shell pm install -t --user 11 /data/local/tmp/app-debug.apk

Fastlane tips - How to setup IntelliJ for Fastlane and Fastfile

Daniel Gomez — Wed, 09 Dec 2020 13:28:12 +0000

If you use fastlane for your mobile environment and IntelliJ then you must be feeling the pain of opening your fastlane/Fastfile in IntelliJ and see all without syntax highlights or autocomplete?

That's because it does not have .rb and so IntelliJ can't understand the language of the file, but there's one simple setup that will fix it:

Open

Settings / File Types
Search for Ruby
Click + and write Fastfile.

Example:

Thanks to custom-file-types-in-intellij-idea

Test Code Sugaring - Using types and code extensions to improve code expressiveness

Daniel Gomez — Sat, 15 Aug 2020 22:07:58 +0000

All of this is applicable of any typed language, I used it in android with Kotlin in Android and now Im happy to use them in Flutter also (the at the bottom of the post to see an example of how you can do it on android and on dart).

Without types (be sad)

Lets assume that you are testing a presenter like this:

class LoginPresenter {
    final userRepository = UserRepository();

    void onLogin(String email, String password) async {
        final response = userRepository.login(email, password);

        if(response.httpCode == 200) {
            // Parse the response body and do something with it
        } else {
           // parse the response body to get the errors
        }
    }
}

That is using some abstractions like this ones:

class Response {
    String body;
    int httpCode;
}

class UserRepository {
    Future<Response> login(String email, String password) { 
      // Do the Http call here and return the http response
    }
}

How your tests may look

Using mockito to create the mocks:

void main() {
    test('on success', () {
       whenever(userRepository.login(any, any)).thenAnswer(() => Future.value(Response("your big json response", 200)));
       presenter.onLogin("email", "password");

       // expect each thing based on the json response values
    }) 
}

Problems with this

The problems with this kind of tests are:

You should be testing only 1 thing in a unit test, with this, you are testing the JSON parsed object, think the case that the service you are using changed the representation of the response to something else, you would have to go and change every BIG json string file and pray :P.
There are no so much separation of concerns since the presenter know what you are using Http to fetch the data, also know that 200 is a success, what if the service starts answering with 201?
You will end up with big Json strings representing each possible state that the presenter will handle and that your service may answer. You will suffer maintaining this JSONs over the time.
If you have to mock multiple repositories it is a little bit fill of boilerplate like returning a Future.value that is inside a function () => ... and the 200 again everywhere.
The presenters should parse the JSON file to get the errors and handle each case, and sometimes it requires you to use the http code together.

All of this is a lot of irresponsibility for a presenter doesn't it? when something does a lot of things then testing and maintaining those tests is ~~a hell~~ really hard.

Adding types for the rescue!

You can add some types to your system to represent the Success and the Failure of any task everywhere.

You can add some simple abstractions:

abstract class Result<T> {
}

class Success<T> extends Result<T> {
  final T body;

  Success(this.body);
}

class Failure<T> extends Result<T> {
  final String cause;

  Failure({this.cause});
}

And a repository that returns responses with Result class, like:

class Session {
   int userId;
}

class UserRepository {
    Future<Result<Session>> login(String email, String password) { 
      // Do the Http call here and get the user id...
    }
}

Now the presenters will look a cleaner:

class LoginPresenter {
    final userRepository = UserRepository();

    void onLogin(String email, String password) async {
        final result = userRepository.login(email, password);

        if (result is Success<Session>) {
           // use result.body.userId been sure that it is an int
        } else if (result is Failure<Session>) {
           // use result.message been sure that theres a string with the error
        }
    }
}

Goods of this

You remove a lot of knowledge from presenters, they will not know anything about Http, http codes or json parsing.
You defined types for responses an so presenters can be sure that the response is a Session that have an int attribute with the userId, so no double check or casting from string to the type you are supposed to get.

How tests benefits from this

Now that you know that your repositories responses your types, you can add extensions like this:

extension ResultMock<T> on PostExpectation<Future<Result<T>>> {
  // One for success
  void thenSucceed(T body) {
    var result = Result.success(body);
    thenAnswer((realInvocation) => Future.value(result));
  }

  // One for failures
  void thenFail([String message = 'mock-error']) {
    var result = Failure(message);
    thenAnswer((realInvocation) => Future.value(result));
  }
}

Then the tests may look like:

void main() {
    test('on success', () {
       whenever(userRepository.login(any, any)).thenSucceed(Session(1));
       presenter.onLogin("email", "password");

       // expect each thing based on the json response values
    }) 
}

What you get from this

Tests are testing only one thing and that's the behaviour of the presenter.
No need to maintain JSONS everywhere, you can add tests in the repository to test the parsing if that's what you want to, but they will be in only one place of your system.
You will mock easily everywhere since you don't need to think that you need to create a Future, a lambda that answers that future and the proper result type, just use the extension with the response type.
Some people prefer to use fake implementations of their abstractions to "mock responses", that is not the topic of this post to' I believe that with this you may not need to create fake implementations, mocking became so easy with this...
This can be used on any typed language, here are some examples of dart and kotlin extensions if you come from android and want to try it:

Types are a really powerful thing to separate concerns of your system.

MaterialComponents, CoordinatorLayout, AppBarLayout, Toolbar and automatic elevation Spike

Daniel Gomez — Tue, 09 Jun 2020 11:54:36 +0000

MaterialComponents, CoordinatorLayout, AppBarLayout, Toolbar and automatic elevation Spike

Here's an example of how to use themes to get automatic Toolbar elevation without extra code or custom listeners.

Use AppBarLayout
from MaterialComponents for it.

How to

Your app style should use a MaterialCompoment style, like src/main/res/values/styles.xml.
Setup you AppBarLayout:
- Use any MaterialCompoments style for this component like: Widget.MaterialComponents.AppBarLayout.Surface.
- Set app:liftOnScroll="true" to enable the automatic elevation based on scroll.
Setup your scrolling view:
- Set app:layout_behavior="@string/appbar_scrolling_view_behavior.

And that's all :)

DEV Community: Daniel Gomez

Building and Deploying Flutter Apps from CI with Fastlane: How to Reuse Code Efficiently

Show me the setup

How to install an app on Android Work Profile for Debug

Fastlane tips - How to setup IntelliJ for Fastlane and Fastfile

Test Code Sugaring - Using types and code extensions to improve code expressiveness

Without types (be sad)

How your tests may look

Problems with this

Adding types for the rescue!

Goods of this

How tests benefits from this

What you get from this

MaterialComponents, CoordinatorLayout, AppBarLayout, Toolbar and automatic elevation Spike

MaterialComponents, CoordinatorLayout, AppBarLayout, Toolbar and automatic elevation Spike

How to

Results