DEV Community: Gustavo Guedes

Dependency Diagram: Understanding and Visualizing Relationships

Gustavo Guedes — Fri, 04 Oct 2024 12:22:37 +0000

This approach is very useful for clarifying the dependencies of implementations we are working on or designing. It helps in understanding if each change is being made in the best possible way.

1. Arrow with Linear Body and Empty Head

"Inherits from" / "Is a"

Used to indicate that something inherits from or is something else. For example:

In this case, the MyViewController class is a UIViewController.

2. Arrow with Dotted Body and Empty Head

"Conforms to" / "Implements"

Used when something conforms to or implements a certain contract.

Here, the URLSessionHTTPClient implements the HTTPClient.

3. Arrow with Solid Body and Filled Head

"Depends on" / "Has a" / Strong Reference

Used when talking about direct dependencies between different concepts or things.



class RemoteFeedLoader {
  private let client: HTTPClient

  init(client: HTTPClient) {
    self.client = client
  }

In the example above, the RemoteFeedLoader class directly depends on (has a strong reference to) the HTTPClient. Whether it's an interface, a direct implementation, or if it needs something external to function, or even if this dependency is necessary to create the resource, we're talking about a strong dependency.

Therefore, this dependency can be represented as:

4. Arrow with Dotted Body and Filled Head

"Depends on" / Weak Reference

For this, the dependency exists but is not mandatory for creating the resource.

If we change the approach of RemoteFeedLoader to:



class RemoteFeedLoader {
  func load(with client: HTTPClient) {
    client.doSomething()
  }
}

Notice that the dependency exists, but it's not necessary to create a RemoteFeedLoader resource. However, when the resource is called, it will be necessary to continue the process.

With this approach, we gain more flexibility in creating our instances, but in return, whoever uses the RemoteFeedLoader will need to know about the HTTPClient, while in the first case, we don't have this issue.

So we can represent it as follows:

5. Colors for Each Context

This approach clearly shows when something being used comes from inside or outside the context. This makes it easy to understand if something is breaking the project's architectural pattern.

Conclusion

In conclusion, dependency diagrams are powerful tools for visualizing and understanding relationships between different components in software architecture. By using various arrow styles and colors, we can clearly represent inheritance, implementation, strong and weak dependencies, and contextual relationships. This visual approach not only helps in designing robust systems, but also in identifying potential architectural issues, making it an invaluable asset for developers and architects alike.

Thanks everyone! See y'all

ListView.builder vs ListView: Is There a Difference?

Gustavo Guedes — Fri, 27 Sep 2024 01:42:12 +0000

Recently, I came across a LinkedIn post where the author mentioned that during interviews with candidates who claimed to be Senior, questions at a Junior or even lower level were not being answered satisfactorily.

This inspired me to create a series of articles to explore and clarify these topics, aiming to consolidate my knowledge and help the community answer these questions more confidently.

In this article, we'll discuss the difference between ListView.builder and the default ListView constructor.

What are `ListView` and `ListView.builder`?

According to the Flutter documentation, ListView is "a scrollable list of widgets arranged linearly."

On the other hand, ListView.builder: "creates a scrollable, linear array of widgets that are generated on demand. This constructor is suitable for list views with a large (or infinite) number of children because the builder is only called for those children that are actually visible."

The key difference lies in how the widgets are created and managed.

A simple example of using a ListView is:

ListView(
  children: [
    ListTile(title: Text('Item 1')),
    ListTile(title: Text('Item 2')),
    ListTile(title: Text('Item 3')),
  ],
);

This is a simple way to enable scrolling on a list of items. A similar approach would be:

SingleChildScrollView(
  child: Column(
    children: [
      ListTile(title: Text('Item 1')),
      ListTile(title: Text('Item 2')),
      ListTile(title: Text('Item 3')),
    ],
  )
);

The behavior would be the same.

For simple lists where the number of items is small and all need to be loaded at once, the default ListView is a good option.

Now, imagine a scenario where the component displaying the items triggers an event for the Analytics service every time an item is created. If we use ListView.builder, some items that are never created won't trigger this event, potentially leading to incomplete data in the Analytics service.

But what about ListView.builder? What does "widgets created on demand" mean? Let's dive deeper into this concept.

On-Demand Rendering

On-demand rendering is a widely used concept, not only in Flutter but in many other technologies, such as:

List - SwiftUI
RecyclerView - Android (Java/Kotlin)
LazyColumn - Jetpack Compose (Android/Kotlin)
UITableView - UIKit (iOS - Swift)
FlatList - React Native
VirtualScroller - Vue.js
react-window or react-virtualized - React.js

Nearly every modern technology implements this concept. When dealing with lists containing hundreds or thousands of items, loading everything into memory at once can lead to performance issues, freezing, or even crashes.

The idea is simple: only load into memory what is currently being displayed, along with a few items before and after the visible area, if needed.

For example, imagine a list of 100 items, and the user is viewing items 10 through 15. The technology will load items around that range, such as from positions 5 to 20. This calculation depends on factors like item size, scroll position, and screen size.

A Closer Look at `ListView.builder`

One important aspect of ListView.builder is the itemCount property. Although optional, it helps optimize the rendering process. If you cannot define itemCount, the itemBuilder will handle notifying the parent ListView.builder when there are no more items to render.

The typing of this itemBuilder is: NullableIndexedWidgetBuilder, which in turn is:

NullableIndexedWidgetBuilder = Widget? Function(
  BuildContext context,
  int index
)

If at any point itemBuilder returns null, this will stop the creation of further items, even if itemCount is set.

Example:

ListView.builder(
  itemCount: 100,
  itemBuilder: (context, index) {
    print(index);
    return ListTile(
      title: Text("Item $index"),
    );
  },
),

Using an iPhone 15 Pro Max simulator, the console printed me from this list up to index 19, so out of 100 items only 20 of them are in memory. And if we make the following edit:

ListView.builder(
  itemCount: 100,
  itemBuilder: (context, index) {
    if (index == 50) {
      return null;
    }

    print(index);
    return ListTile(
      title: Text("Item $index"),
    );
  },
),

The display will display up to element 50, index 49.

Stay tuned!

Therefore, understanding how these properties work together is crucial to avoid inconsistencies in list rendering.

Conclusion

Using ListView.builder is generally recommended to reduce memory usage, especially on older devices. However, we’ve seen that there are scenarios where the traditional ListView may be a better fit.

There is still much more to explore, such as ListView.custom, ListView.separated, and integrations with SliverChildBuilder. But with the concepts discussed here, you should now be able to understand the main differences between these two widgets and when to use them.

ListView.build vs ListView tem diferença?

Gustavo Guedes — Fri, 27 Sep 2024 01:05:15 +0000

Recentemente esbarrei em um post no LinkedIn que dizia: "O mercado de Flutter brasileiro está morto." No post ele descrevia que em entrevistas com candidatos que se intitulavam Sênior, perguntas de nível Junior ou inferiores não eram respondidas de maneira satisfatória.

Então resolvi criar uma série de artigos/posts sobre as perguntas/assuntos abordados nesse post para consolidar meus conhecimentos e ajudar a comunidade a responder de maneira assertivas essas perguntas.

Nesse artigo falaremos sobre a diferença entre ListView.build e ListView(unnamed constructor).

O são `ListView` e `ListView.build`?

Conforme a documentação do Flutter, uma ListView é: "Uma lista rolável de widgets organizados linearmente."

Enquanto a ListView.build: "Cria uma matriz linear e rolável de widgets criados sob demanda.

Este construtor é apropriado para visualizações de lista com um número grande (ou infinito) de filhos porque o construtor é chamado apenas para os filhos que são realmente visíveis."

Fica claro que a diferença principal entre elas está na forma como os widgets da lista são renderizados e gerenciados.

Um exemplo simples da utilização de uma ListView é:

ListView(
  children: [
    ListTile(title: Text('Item 1')),
    ListTile(title: Text('Item 2')),
    ListTile(title: Text('Item 3')),
  ],
);

É uma maneira simples de habilitar o scroll em uma lista de itens. Uma abordagem semelhante seria:

SingleChildScrollView(
  child: Column(
    children: [
      ListTile(title: Text('Item 1')),
      ListTile(title: Text('Item 2')),
      ListTile(title: Text('Item 3')),
    ],
  )
);

O comportamento seria o mesmo.

Fica claro que esse tipo de abordagem são para listagens simples no qual a quantidade de itens não é massiva ou para elementos que necessitem ser instanciados quando forem para a tela.

Exemplo: Imagine que você possua uma listagem de itens que serão mostrados para o usuário e o componente que você criou para exibi-los, envia um evento para seu serviço de Analytics quando esse elemento é criado. Não exibido ou tocado, mas criado. Perceba que se a gente usar o ListView.build alguns desses elementos poderão não disparar esse evento, logo, as informações no serviço não irão refletir o comportamento esperado.

E quanto a ListView.build? O que seria "widgets criados sob demanda"? Vamos falar um pouco sobre isso.

Renderizações sob demanda

Esse conceito é algo amplamente utilizado não só no Flutter, mas em muitas outras stacks. Como:

Praticamente toda tecnológica moderna possui esse conceito, renderização sob demanda. Quando estamos inteirando uma listagem com centenas ou até infinitos itens, levando tudo isso para memória irá causa lentidão, freezing ou até crashs da nossa aplicação.

A ideia é bem simples: Só coloco em memória aquilo que está sendo exibindo, alguns itens anteriores, se for o caso, e alguns itens posteriores, se for o caso também.

Exemplo:

Imagine uma listagem de 100 itens. E o usuário está vendo o intervalo entre os itens 10 e 15. A nossa ferramenta irá colocar em memória os itens da posição 5 a 20. Esses números são um exemplo, o cálculo para isso leva em consideração algumas informações como: tamanho de cada item, posição do scroll, se está próximo do início ou final da listagem e até tamanho da tela.

Falando um pouco mais sobre o `ListView.build`

Lendo a documentação desse Widget, o segredo dele está no itemCount. É uma prop opcional, mas auxilia no cálculo que mencionei acima. Se em algum cenário você não tiver como configurar essa propriedade, o itemBuilder fará o papel de dizer para o componente pai, ListView.build, quando não há mais itens a serem renderizados.

A tipagem desse do itemBuilder é: NullableIndexedWidgetBuilder, que por sua vez é:

NullableIndexedWidgetBuilder = Widget? Function(
  BuildContext context,
  int index
)

Isso é importante entender porque se retornamos null em algum momento, mesmo com o itemCount configurado, irá interromper e exibição dos próximos itens.

Exemplo:

ListView.builder(
  itemCount: 100,
  itemBuilder: (context, index) {
    print(index);
    return ListTile(
      title: Text("Item $index"),
    );
  },
),

Utilizando um simulador do iPhone 15 Pro Max, dessa listagem o console me printou até o index 19, logo, de 100 itens somente 20 deles estão em memória. E se fizermos a seguinte edição:

ListView.builder(
  itemCount: 100,
  itemBuilder: (context, index) {
    if (index == 50) {
      return null;
    }

    print(index);
    return ListTile(
      title: Text("Item $index"),
    );
  },
),

A exibição irá exibir até o elemento 50, index 49.

Fique atento!

Conclusão

A utilização do ListView.builder é sempre recomendado para amenizar o consumo de memória, principalmente quando falamos de dispositivos mais antigos, mas também vimos que há cenários onde ListView se encaixa melhor.

Ainda tem muita coisa legal para falar sobre esse assunto, como: ListView.custom e ListView.separated além das integrações do ListView com elementos SliverChildBuilder. Mas acho que com os conceitos falados nesse artigo, você irá conseguir responder qual a diferença entre esses dois Widgets e quando os usar.

E isso! Vlw pessoal.

Improving Swift’s Equatable for Complex Class Comparisons

Gustavo Guedes — Fri, 20 Sep 2024 00:55:29 +0000

A little context

Recently, I needed to use the Equatable protocol in some entities within my application, and I encountered an interesting aspect of it: the requirement to manually compare the properties of a class. So I thought: there must be a better way.

What does Equatable offer us?

Without diving too deep into its implementation, Equatable forces us to create a method to compare objects.

Imagine the following class:

class PersonEntity {
    let name: String
    let age: Int

    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }
}

If we try to compare two instances of PersonEntity, we will get an error like this:

Binary operator '==' cannot be applied to two 'PersonEntity' operands

By implementing the Equatable protocol, we can finally compare instances using the == operator:

class PersonEntity: Equatable {
    static func == (lhs: PersonEntity, rhs: PersonEntity) -> Bool {
        return lhs.name == rhs.name && rhs.age == rhs.age
    }

Now the comparison is possible. But imagine a class with many properties, including other classes. Manually validating each property isn’t necessary in languages like Dart.

Inspiration

In Dart/Flutter, we have the Equatable package, which automates comparisons.

The code that handles this works as follows:

@override
bool operator ==(Object other) {
  return identical(this, other) ||
      other is Equatable &&
          runtimeType == other.runtimeType &&
          equals(props, other.props);
}

To summarize:

First, it checks if instances "A" and "B" are identical using the identical method (similar to AnyObject in Swift);
If they are not identical, it checks if the other instance (or rhs in Swift/Equatable) is of type Equatable;
Then, it compares the types of the instances using type(of:);
Finally, it compares the properties of both instances.

But what are these properties? They’re what we will create on our side to simplify comparisons.

Let’s get to work

We will create an array of properties, where we will store all the props used for comparison. This eliminates the need for manual comparisons.

protocol CustomEquatable: Equatable {
    var props: [Any?] { get }
}

I decided to extend Equatable to follow the language standard. Here's the implementation:

extension CustomEquatable {
    static func == (lhs: Self, rhs: Self) -> Bool {
        return lhs.isEqual(to: rhs)
    }

    func isEqual(to other: any CustomEquatable) -> Bool {
        return self.props.elementsEqual(other.props, by: { lhsElement, rhsElement in
                switch (lhsElement, rhsElement) {
                case let (lhsElement as any CustomEquatable, rhsElement as any CustomEquatable):
                        return lhsElement.isEqual(to: rhsElement)
                case let (lhsElement as AnyHashable, rhsElement as AnyHashable):
                        return lhsElement == rhsElement
                default:
                        return lhsElement == nil && rhsElement == nil
                }
        })
    }
}

In summary:

We implement the Equatable protocol;
We check each element in the props array;
If the element is of type CustomEquatable, we use recursion to validate complex objects;
For simple types, we compare using AnyHashable;
And, of course, we handle null values.

Pretty cool, right? But does it work? Let’s test it!

Unit tests

Here are the classes we will use for testing:

import Foundation

class PersonEntity: CustomEquatable {
    var props: [Any?] {
        return [name, age, preferences, nickname, luckNumbers]
    }

    let name: String
    let age: Int
    let preferences: PersonPreferencesEntity?
    let nickname: String?
    let luckNumbers: [Int]

    init(name: String, age: Int, preferences: PersonPreferencesEntity? = nil, nickname: String? = nil, luckNumbers: [Int]? = nil) {
        self.name = name
        self.age = age
        self.preferences = preferences
        self.nickname = nickname
        self.luckNumbers = luckNumbers ?? []
    }
}

class PersonPreferencesEntity: CustomEquatable {
    var props: [Any?] {
        return [darkmode]
    }

    let darkmode: Bool

    init(darkmode: Bool = false) {
        self.darkmode = darkmode
    }
}

The first validation is to check if the object we are comparing implements CustomEquatable. To do this, we instantiate PersonPreferencesEntity inside PersonEntity.

func testCompareCustomEquatableProps() {
    let equalPreferencesOne = PersonPreferencesEntity()
    let equalPreferencesTwo = PersonPreferencesEntity()

    let personOne = PersonEntity(name: "John Doe", age: 25, preferences: equalPreferencesOne)
    let personTwo = PersonEntity(name: "John Doe", age: 25, preferences: equalPreferencesTwo)

    XCTAssertTrue(personOne == personTwo)

    let diffPreferencesOne = PersonPreferencesEntity(darkmode: false)
    let diffPreferencesTwo = PersonPreferencesEntity(darkmode: true)

    let diffPersonOne = PersonEntity(name: "John Doe", age: 25, preferences: diffPreferencesOne)
    let diffPersonTwo = PersonEntity(name: "John Doe", age: 25, preferences: diffPreferencesTwo)

    XCTAssertFalse(diffPersonOne == diffPersonTwo)
}

With this test, we ensure that complex properties are compared correctly.

The second test validates values that do not implement CustomEquatable.

func testCompareCommonProps() {
    let personOne = PersonEntity(name: "John Doe", age: 25, luckNumbers: [1, 2, 3])
    let personTwo = PersonEntity(name: "John Doe", age: 25, luckNumbers: [1, 2, 3])

    XCTAssertTrue(personOne == personTwo)

    let diffPersonOne = PersonEntity(name: "John Doe", age: 25, luckNumbers: [1, 2, 3])
    let diffPersonTwo = PersonEntity(name: "John Doe", age: 25, luckNumbers: [4, 5, 6])

    XCTAssertFalse(diffPersonOne == diffPersonTwo)
}

Now, for nullable values:

func testCompareNullablesProps() {
    let diffPersonOne = PersonEntity(name: "John Doe", age: 25, nickname: "john")
    let diffPersonTwo = PersonEntity(name: "John Doe", age: 25)

    XCTAssertFalse(diffPersonOne == diffPersonTwo)
}

Finally, a test to ensure that we are not comparing the object to itself.

func testCompareInstances() {
    let diffPersonOne = PersonEntity(name: "John Doe", age: 25)
    let diffPersonTwo = PersonEntity(name: "John Doe", age: 25)

    XCTAssertFalse(diffPersonOne === diffPersonTwo)
}

With this last test, we validate that our protocol works as expected.

Conclusion

With this solution, we avoid having to manually create a chain of comparisons inside the == method. Since the original Equatable implementation required comparing each property manually, we maintain a time complexity of O(n).

Important: whenever you add a new property to your class, don’t forget to update the props array.

That’s it! I hope this was helpful. See you next time!

A Step Beyond Hello World: Building a Calculator App with ViewCode

Gustavo Guedes — Thu, 12 Sep 2024 01:42:05 +0000

Whenever I'm looking for content on how to build something, I often stumble upon videos and articles that stop at the classic "Hello World." Today, we’ll go a bit further.

As the title suggests, the goal is to add a bit more complexity when working with ViewCode.

In this article, I won’t cover the initial setup, as I’ve already discussed it in two previous articles: Getting Started with ViewCode in iOS: A Basic Guide and Setting Up ViewCode Projects for Versions Below iOS 13.

Let’s Get to Work

Creating the Main View

The idea is to replicate as much as possible from the native calculator app, especially regarding its functionalities.

To start, let's create a new file that will be responsible for managing the views of our application. Let’s name it CalculatorView.swift.

import UIKit

class CalculatorView: UIView {}

Now, in our controller, we’ll set our newly created UIView as the main view of our UIViewController.

private var calculatorView: CalculatorView? = nil

override func loadView() {
    view = CalculatorView()
    calculatorView = view as? CalculatorView
}

With this setup, we ensure that the views are handled within the view file, and the controller will only interact with them when necessary.

Creating the First Elements

Looking at the native calculator UI, we notice that the buttons are quite similar, differing only in some characteristics. Before thinking about how to customize them, let’s add the first button to the screen.

In our CalculatorView, we’ll add the following elements:

private lazy var buttonContainer: UIView = {
    let view = UIView()

    view.translatesAutoresizingMaskIntoConstraints = false

    return view
}()

private lazy var button: UIButton = {
    let button = UIButton()

    button.titleLabel?.adjustsFontSizeToFitWidth = true
    button.titleLabel?.font = UIFont.systemFont(ofSize: 40, weight: .medium)
    button.translatesAutoresizingMaskIntoConstraints = false

    return button
}()

init() {
    super.init(frame: .zero)

    backgroundColor = .black

    buttonContainer.backgroundColor = .darkGray
    button.setTitle("1", for: .normal)
    button.setTitleColor(.white, for: .normal)

    addSubview(buttonContainer)
    buttonContainer.addSubview(button)

    NSLayoutConstraint.activate([
        buttonContainer.centerYAnchor.constraint(equalTo: centerYAnchor),
        buttonContainer.centerXAnchor.constraint(equalTo: centerXAnchor),
        buttonContainer.heightAnchor.constraint(equalToConstant: 60),
        buttonContainer.widthAnchor.constraint(equalToConstant: 60),
        button.centerYAnchor.constraint(equalTo: buttonContainer.centerYAnchor),
        button.centerXAnchor.constraint(equalTo: buttonContainer.centerXAnchor),
    ])

    buttonContainer.layer.cornerRadius = 60 / 2
}

required init?(coder: NSCoder) {
    fatalError()
}

Here, we’re doing the following:

Creating a container for the button;
Creating the button itself;
In the view’s init, we apply the initial stylings, add the elements to the screen, and set up their constraints.

The result should look something like this:

Componentizing the Button

Now that we've taken the first step in building our components, let's create a separate button component, along with a small contract for our programmatic components.

The first step is creating a protocol to be followed by all our components. We can name it ViewCode.swift.

protocol ViewCode {
    func addSubviews()
    func setupConstrainsts()
    func setupStyles()
}

extension ViewCode {
    func setup() {
        addSubviews()
        setupConstrainsts()
        setupStyles()
    }
}

Each component will implement three methods:

addSubviews to add elements;
setupConstraints to configure the constraints;
setupStyles to style the elements.

With the setup method, we create a unified way to call this set of methods.

Now, we can create the button component in CalculatorButtonView.swift.

class CalculatorButtonView: UIView {
    private lazy var button: UIButton = {
        let button = UIButton()

        button.titleLabel?.adjustsFontSizeToFitWidth = true
        button.titleLabel?.font = UIFont.systemFont(ofSize: 40, weight: .medium)
        button.translatesAutoresizingMaskIntoConstraints = false

        return button
    }()

    init() {
        super.init(frame: .zero)

        setup()
    }

    required init?(coder: NSCoder) {
        fatalError()
    }

    func config(
        text: String,
        textColor: UIColor? = .white,
        buttonColor: UIColor? = .darkGray
    ) {
        backgroundColor = buttonColor
        button.setTitle(text, for: .normal)
        button.setTitleColor(textColor, for: .normal)
    }
}

//MARK: - ViewCode

extension CalculatorButtonView: ViewCode {
    func addSubviews() {
        addSubview(button)
    }

    func setupConstrainsts() {
        NSLayoutConstraint.activate([
            heightAnchor.constraint(equalToConstant: 60),
            widthAnchor.constraint(equalToConstant: 60),
            button.centerYAnchor.constraint(equalTo: centerYAnchor),
            button.widthAnchor.constraint(equalToConstant: 60),
            button.heightAnchor.constraint(equalToConstant: 60),
        ])
    }

    func setupStyles() {
        layer.cornerRadius = 60 / 2
        translatesAutoresizingMaskIntoConstraints = false
    }
}

The config method will allow future customizations of the buttons as needed.

In CalculatorView, we adjust the button positioning to ensure they are closer to their correct locations on the interface.

class CalculatorView: UIView {
    private lazy var one: CalculatorButtonView = {
        let one = CalculatorButtonView()

        one.config(text: "1")

        return one
    }()

    init() {
        super.init(frame: .zero)
    }

    required init?(coder: NSCoder) {
        fatalError()
    }

    private func oneConstraints() {
        NSLayoutConstraint.activate([
            one.leadingAnchor.constraint(equalTo: leadingAnchor, constant: 16),
            one.bottomAnchor.constraint(equalTo: bottomAnchor, constant: -24),
        ])
    }

}

extension CalculatorView: ViewCode {
    func addSubviews() {
        addSubview(one)
    }

    func setupConstrainsts() {
        oneConstraints()
    }

    func setupStyles() {
        backgroundColor = .black
    }
}

In the controller, we call the setup method from CalculatorView, as it now follows the established project pattern.

override func loadView() {
        // ...
    calculatorView?.setup()
}

With these changes we should have the following result.

Creating the Other Elements

Adding more simple elements to the screen, we might end up with something like this:

The button positioning followed this logic:

Button "one" is anchored to the bottom of the screen and 16px from the leadingAnchor;
Button "two" is 16px from the trailingAnchor of button "one" and centerYAnchor equal to one.centerYAnchor;
Button "four" is 16px from the leadingAnchor and the bottomAnchor 16px above one.topAnchor.

I chose not to use UIStackView in this context.

You may have noticed that the buttons still don’t resemble the native app. That’s because the fixed 60px size makes them look rigid and disproportionate. To fix this, we need to calculate the button sizes based on the screen width.

The logic applied in CalculatorButtonView is as follows: each element’s size will be the screen width minus the spacing, divided by 4. There are other approaches, but this will work for now.

static var elementWidth = (UIScreen.main.bounds.width - 5 * 16) / 4

I added this static variable to make it easier to access this information even outside the context of the element.

And if we replace the 60px we used in the file with CalculatorButtonView.elementWidth. We will have the following result:

Much better, right?

Final Buttons and Result Label

To complete the UI, we need to add a few more buttons and the field where the calculation result will be displayed.

In the CalculatorView file we create a new element:

private lazy var result: UILabel = {
    let label = UILabel()

    label.text = "0"
    label.font = UIFont.systemFont(ofSize: 80)
    label.textColor = .white
    label.translatesAutoresizingMaskIntoConstraints = false
    label.textAlignment = .right

    return label
}()

// ...

private func resultConstraints() {
    NSLayoutConstraint.activate([
        result.bottomAnchor.constraint(equalTo: divide.topAnchor, constant: -24),
        result.trailingAnchor.constraint(equalTo: divide.trailingAnchor, constant: -16),
        result.leadingAnchor.constraint(equalTo: leadingAnchor, constant: 16)
    ])
}

// ...

func addSubviews() {
    // ...
    addSubview(result)
}

func setupConstrainsts() {
    // ...
    resultConstraints(result)
}

If we run the application again, we will have something like this:

Lastly, let's move on to creating the final buttons. To achieve this, we’ll need to make some adjustments to our CalculatorButtonView so that the elements don’t have fixed sizes.

We start with our config method, allowing us to change the element's alignment and size dynamically.

func config(
    text: String,
    textColor: UIColor? = .white,
    buttonColor: UIColor? = .darkGray,
    alignLeft: Bool = false,
    width: CGFloat? = nil,
    height: CGFloat? = nil
) {
    backgroundColor = buttonColor
    button.setTitle(text, for: .normal)
    button.setTitleColor(textColor, for: .normal)

    if (!alignLeft) {
        NSLayoutConstraint.activate([
            button.centerXAnchor.constraint(equalTo: centerXAnchor),
        ])
    } else {
        NSLayoutConstraint.activate([
            button.titleLabel!.leadingAnchor.constraint(equalTo: button.leadingAnchor, constant: 24),
        ])
    }

    NSLayoutConstraint.activate([
        widthAnchor.constraint(equalToConstant: width ?? CalculatorButtonView.elementWidth),
        button.widthAnchor.constraint(equalToConstant: width ?? CalculatorButtonView.elementWidth),
        button.heightAnchor.constraint(equalToConstant: height ?? CalculatorButtonView.elementWidth),
    ])
}

With this modification we created the possibility of changing the element's alignment and size via the config method.

Important! We need to remove the constraints previously set in the setupConstraints method. If this isn't done, there will be conflicts due to multiple constraints being applied to the same element.

It will look like this:

func setupConstrainsts() {
    NSLayoutConstraint.activate([
        heightAnchor.constraint(equalToConstant: CalculatorButtonView.elementWidth),
        button.centerYAnchor.constraint(equalTo: centerYAnchor),
    ])
}

Now, we can create our final elements in the CalculatorView file.

private lazy var zero: CalculatorButtonView = {
    let zero = CalculatorButtonView()
    zero.config(text: "0", alignLeft: true, width: CalculatorButtonView.elementWidth * 2 + 16)
    return zero
}()

private lazy var comma: CalculatorButtonView = {
    let comma = CalculatorButtonView()
    comma.config(text: ",")
    return comma
}()

private lazy var equal: CalculatorButtonView = {
    let equal = CalculatorButtonView()
    equal.config(text: "=", buttonColor: .orange)
    return equal
}()

As you can see, the "zero" button will be the size of two buttons plus the 16px spacing between elements.

Next, we can configure the constraints for these elements.

private func zeroConstraints() {
    NSLayoutConstraint.activate([
        zero.leadingAnchor.constraint(equalTo: leadingAnchor, constant: 16),
        zero.bottomAnchor.constraint(equalTo: bottomAnchor, constant: -24),
    ])
}

private func commaConstraints() {
    NSLayoutConstraint.activate([
        comma.leadingAnchor.constraint(equalTo: zero.trailingAnchor, constant: 16),
        comma.bottomAnchor.constraint(equalTo: bottomAnchor, constant: -24),
    ])
}

private func equalConstraints() {
    NSLayoutConstraint.activate([
        equal.leadingAnchor.constraint(equalTo: comma.trailingAnchor, constant: 16),
        equal.bottomAnchor.constraint(equalTo: bottomAnchor, constant: -24),
    ])
}

Additionally, the constraint for the "one" button will need to change since it should be linked to the "zero" button rather than the screen itself.

private func oneConstraints() {
    NSLayoutConstraint.activate([
        one.leadingAnchor.constraint(equalTo: leadingAnchor, constant: 16),
        one.bottomAnchor.constraint(equalTo: zero.topAnchor, constant: -16),
    ])
}

Por ultimo colocamos os elementos na tela e disparamos as configs que fizemos:

addSubview(zero)
addSubview(comma)
addSubview(equal)

//...

zeroConstraints()
commaConstraints()
equalConstraints()

Finally, we place the elements on the screen and apply the configurations we made.

With this last modification, when we run the app, the result should look something like this:

Interactivity

Now that our UI is ready, we need to add some interaction between the buttons and the result field at the top. We can follow these steps:

In the CalculatorButtonView file, we create a delegate to capture which button was pressed. We also configure the UIButton to trigger this callback.

protocol CalculatorButtonViewDelegate: AnyObject {
    func didTapButton(_ sender: UIButton)
}

This allows us to capture which button was pressed. Still within this file we need to configure our UIButton with this callback:

private lazy var button: UIButton = {
        // ...
    button.addTarget(self, action: #selector(onTap), for: .touchUpInside)

    return button
}()

weak var delegate: CalculatorButtonViewDelegate?

@objc
private func onTap(sender: UIButton) {
    delegate?.didTapButton(sender)
}

These small changes make the component "clickable."

Next, in CalculatorView, we set up the delegate for the buttons. Here, I opted for the willSet approach to configure all buttons at once.

weak var buttonsDelegate: CalculatorButtonViewDelegate? {
    willSet {
        one.delegate = newValue
        two.delegate = newValue
        three.delegate = newValue
        plus.delegate = newValue
        four.delegate = newValue
        five.delegate = newValue
        six.delegate = newValue
        minus.delegate = newValue
        seven.delegate = newValue
        eight.delegate = newValue
        nine.delegate = newValue
        multiply.delegate = newValue
        clear.delegate = newValue
        positiveNegative.delegate = newValue
        percent.delegate = newValue
        divide.delegate = newValue
        zero.delegate = newValue
        comma.delegate = newValue
        equal.delegate = newValue
    }
}

Finally, in our controller, we implement the necessary logic to handle the interactions.

override func viewDidLoad() {
    super.viewDidLoad()
    // ...
    calculatorView?.buttonsDelegate = self
}

extension ViewController: CalculatorButtonViewDelegate {
    func didTapButton(_ sender: UIButton) {
        if let buttonValue = sender.currentTitle {
            print(buttonValue)
        }
    }
}

The result is:

Conclusion

With everything we've done so far, you now have the foundation to build the rest of the interactivity and logic for when each button is pressed. If you want to see the full project, check out the repository, where I’ve added some additional details not covered here, along with unit tests for the button logic.

Here’s how it turned out:

That’s it for today, folks. Thanks, and see you next time!

Let me know if you need any further adjustments!

Setting Up ViewCode Projects for Versions Below iOS 13

Gustavo Guedes — Wed, 04 Sep 2024 12:52:05 +0000

In iOS development, a significant change was introduced with iOS 13, bringing the SceneDelegate to facilitate multi-window support on iPads and other functionalities. However, when working with earlier versions of iOS, the SceneDelegate is not used, and the initial setup of the application must be done directly in the AppDelegate.

In this article, I'll guide you through the process of configuring your iOS application using the AppDelegate, ensuring compatibility with versions prior to iOS 13.

What is AppDelegate?

The AppDelegate is the entry point of the application. It is responsible for responding to events that affect the application's lifecycle, such as launching, transitioning to the background, and termination.

Setting Up the Initial Interface in AppDelegate

For iOS versions earlier than 13, where SceneDelegate is not available, the entire initial setup process should occur in the application(_:didFinishLaunchingWithOptions:) method of AppDelegate. Here, you must configure the main window of the application and set the initial UIViewController.

import UIKit

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

        // Initialize the main window
        window = UIWindow(frame: UIScreen.main.bounds)

        // Create the initial ViewController
        let initialViewController = YourInitialViewController()

        // Set the initial ViewController as the rootViewController
        window?.rootViewController = initialViewController

        // Make the window visible
        window?.makeKeyAndVisible()

        return true
    }
}

Understanding the Code

Window Initialization: window = UIWindow(frame: UIScreen.main.bounds) creates a new instance of UIWindow with the dimensions of the device's screen.
Initial ViewController: Next, we create an instance of the ViewController that we want to be displayed when the application starts. This is where you can configure your initial interface.
Root ViewController: We set the window's rootViewController to the initial ViewController.
Displaying the Window: window?.makeKeyAndVisible() makes the window visible and sets it as the main window of the application.

Why Not Use SceneDelegate?

For devices running iOS 13 or later, using the SceneDelegate is recommended. However, if you need to support earlier versions, it’s necessary to configure the initial interface in AppDelegate as shown above. This ensures your application works correctly across a broader range of devices.

Conclusion

When configuring your application to support iOS versions earlier than 14, understanding the role of AppDelegate is essential. The absence of SceneDelegate in these versions means that the initial setup of the application must occur in AppDelegate. With the instructions provided, you are ready to correctly configure your application and ensure compatibility with older versions of iOS.

Getting Started with ViewCode in iOS: A Basic Guide

Gustavo Guedes — Wed, 28 Aug 2024 01:02:06 +0000

Hey everyone! How’s it going? The idea of this article is to provide a basic guide on how to create a project using the ViewCode approach.

If you’re not familiar with what ViewCode is, I’ll explain a bit below.

What problem does it solve?

The storyboard pattern, used to create interfaces in Xcode, is very cool and intuitive. However, when working in a team, this approach can cause a lot of headaches.

Basically, screens created with storyboard have an xml file that stores everything we insert or edit. Since these changes are not made programmatically, they can lead to many conflicts when working in a team.

There are other ways to avoid this problem, and one of them is using ViewCode. This approach involves creating the screen elements programmatically, via code, without relying on Interface Builder and storyboards.

What about SwiftUI?

SwiftUI is one of the alternatives to solve this problem. It brings a declarative language for creating screens and components, with a very interesting Live Preview. If you’ve used Jetpack Compose or Flutter before, you’ll notice some similarities.

However, SwiftUI is only available starting from iOS 13. Depending on your app’s target audience, this could be a limitation, as devices like the iPhone 6, 6 Plus, and earlier models won’t have access. You can check the minimum and maximum supported versions for Apple devices here.

Let’s get to work

01. Creating the project

To start, let’s open Xcode and create a new project. In this example, I selected the iOS/App option.

Enter the project name and ensure the options are configured as follows:

Inferface: Storyboard
Language: Swift

Choose where to save the project and that’s it! Now we can start coding.

During the creation of this article, I used Xcode version 15.3 (15E204a), and the latest available iOS version is 17.4.

Our project will look like this once Xcode opens it:

If you unchecked the “Include Tests” option, the Tests and UITests folders will not be present. But don’t worry, we won’t be using them in this article, and they can be created later if needed.

With the project open, we see that it has two .storyboard files: LaunchScreen.storyboard and Main.storyboard. The LaunchScreen is the screen displayed while the operating system loads resources for our app to function correctly. The Main is the main screen of our app.

The file that interests us at this point is Main.storyboard.

02. Initial changes

Delete the Main.storyboard file.

Click on “Move to trash”.

Now, let’s access the Target Properties settings of our application.

With the settings open, delete the following lines:

“Main storyboard file base name”

"Application Scene Manisfest" > "Scene Configuration" > "Window Application Session Role" > "Item 0" > "Storyboard Name"

After making these changes, let’s access the SceneDelegate to configure the entry point of our application since we removed the storyboard references.

We’ll make a few small changes to this file.

Remove some comments and create our windowScene variable. It will be used to configure which controller/screen will be rendered.

func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
    guard let windowScene = (scene as? UIWindowScene) else { return }
}

Configure the controller that will be displayed when the app starts::

let safeWindow = UIWindow(windowScene: windowScene)
safeWindow.frame = UIScreen.main.bounds
safeWindow.rootViewController = ViewController()
safeWindow.makeKeyAndVisible()

window = safeWindow

At this stage, we create our window based on the scene provided by the guard let windowScene. Then, we configure the screen to occupy the entire available space and define the controller that will be used. Finally, we assign our safeWindow to the window variable.

This ViewController is the one created during the initial project setup

Running the application

Now, by selecting one of the emulators and running the application (either by clicking the play button at the top or using the CMD + R command), we should see the following behavior:

What’s happening is:

The LaunchScreen.storyboard file is displayed.
The view of our controller is rendered. And since it has nothing in it, the screen appears blank.

If we access our ViewController and set a background color for the view, we’ll already see the change when running the project again:

override func viewDidLoad() {
    super.viewDidLoad()

    view.backgroundColor = .red
}

Now we’re all set to start building our application programmatically.

Creating elements with ViewCode

Creating screen elements is done entirely programmatically. But how do we do that?

Example:

private lazy var label: UILabel = {
    let label = UILabel()

    label.text = "Hello World"
    label.translatesAutoresizingMaskIntoConstraints = false

    return label
}()

We can observe the following:

We use the private keyword to ensure that no one outside our class can access this information.
lazy is used so the variable only enters memory when it’s utilized.
The {}() approach is a function that self-executes and returns the variable’s type element.
translatesAutoresizingMaskIntoConstraints = false to prevent automatically generated constraint configurations from conflicting with the ones we manually configure.

It’s important to note that every element created programmatically needs the translatesAutoresizingMaskIntoConstraints = false configuration. Otherwise, conflicts may occur, and the elements might not behave as expected.

Now, we need to add this element to the screen.

override func viewDidLoad() {
    super.viewDidLoad()

    view.backgroundColor = .white

    view.addSubview(label)
}

We change the background of the view attached to our controller to white and add our label inside it.

To position our element:

NSLayoutConstraint.activate([
    label.centerXAnchor.constraint(equalTo: view.centerXAnchor),
    label.centerYAnchor.constraint(equalTo: view.centerYAnchor)
])

Then run the application, and voilà:

Conclusion

As mentioned at the beginning, this is a basic guide for creating projects using ViewCode. There are several improvements we can make, such as creating separate view files—after all, it’s not ideal to create these elements directly in our controller. But I wanted to keep this article concise and to the point. In the next one, we’ll explore element creation on the screen in more depth.

That’s it for today, folks. Thanks, and see you next time!

Let me know if you need any further adjustments!

The Importance of Error Handling in Mobile Applications

Gustavo Guedes — Wed, 21 Aug 2024 23:24:57 +0000

In mobile development, error handling is a crucial aspect that we cannot afford to overlook. After all, any unhandled error can result in a crash, directly impacting the user experience. Additionally, not knowing where and why an error occurs can be extremely frustrating for developers.

In this article, I will demonstrate how a simple pattern can help us handle potential errors effectively, "forcing" us to address them properly.

Errors Beyond Backend Calls

It’s widely known that almost any resource consumption operation can succeed or fail. Let’s take a look at a simple example:

DateTime parseDateFromString(String value) => DateTime.parse(value);

For those unfamiliar with Dart, the above method is used to convert a string into a date. It seems straightforward, but something you might not know is that the DateTime.parse method throws an exception if value is empty or in an incorrect format.

To solve this problem, we can modify the code as follows:

DateTime? parseDateFromString(String value) => DateTime.tryParse(value);

With this approach, the error still occurs, but it’s handled within the method’s try/catch, returning null if the parse fails.

This example shows that even when a method seems safe, errors can still occur. Of course, unit tests can help cover these use cases, but that’s not the focus of this article.

A language that aggressively handles errors is Go. In Go, operations return errors by default. It’s possible to write a method that doesn’t return an error, but the language’s philosophy is to make it clear that consuming a resource can fail.

Here’s an example:

func loadPage(title string) (*Page, error) {
    filename := title + ".txt"
    body, err := os.ReadFile(filename)
    if err != nil {
        return nil, err
    }
    return &Page{Title: title, Body: body}, nil
}

Notice that even on success, the nil error response is sent. Therefore, when consuming the loadPage method, we need to check if an error occurred.

Implementing This in Your Projects

A library that brings a similar approach to Dart as Go is fpdart. With it, we have access to several functional paradigm tools. One of the most useful is Either, which allows multiple return types for a single call, as in the example below:

Either<FailureObj, SuccessObj> someRequest();

It’s important to note that this behavior can be implemented without additional packages. There are articles like this one that teach how to do it. However, I use fpdart for the other tools it offers, such as Task and Option.

Using this pattern, we ensure that any call can return an error or success, making the handling for each case explicit in the code.

Another crucial approach is creating custom error contracts for the application:

class FailureException implements Exception {
  FailureException({this.message});

  final String? message;
}

With a custom error class created, we can use it throughout the application, and even extend it as needed:

Either<FailureException, SuccessObj> someRequest();

I prefer creating errors by functionality because it clarifies the context in which the error occurs.

class AuthException extends FailureException {
  AuthException({
    required super.message,
    required this.errorCode,
  });

  final String errorCode;
}

class ProfileException extends FailureException {}

Why not just use FailureException for everything? Because of the tools that monitor application crashes. Imagine if all errors had the same name: we would have to rely on the error message or stack trace to try to locate where the problem occurred.

Not every error will be typed, of course, but our AuthException will serve for known errors. This way, we significantly reduce the occurrence of generic errors in the application.

A simple tip that can help in this error analysis process is to send the custom error to the application’s logging tool:

try {
  // ...

  if (response.statusCode != 200) {
    final error = AuthException(
      message: response.body['error'],
      errorCode: response.statusCode,
    );

    logger?.error(error);

    return (...);
  }

  // ...
} catch (e) {
  final error = AuthException(
    message: e.toString(),
    errorCode: '500',
  );

  logger?.error(error);
}

With this approach, it becomes easy to search your logging tool for AuthException or ProfileException, for example, and find the cases that actually occurred in these functionalities.

Conclusion

This content may seem simple and superficial, but when problems arise — and they always do — you’ll be glad you prepared your application to handle them in the best way possible.

That’s all for today, folks! See you next time.

Barcode Reading Problem in Flutter

Gustavo Guedes — Fri, 16 Aug 2024 02:59:38 +0000

A Little Background

Recently, I encountered a "problem" reported in an application. The barcode reader wasn't working correctly—the value it captured was different from what was on the document. In this article, I'll share the journey I took to understand and resolve this issue.

Spoiler: The problem was related to a specific rule in barcode generation set by FEBRABAN, the Brazilian Federation of Banks, so the issue might be more relevant to the Brazilian context, but it might still offer some valuable insights. Let's dive in!

The Problem

As mentioned, the value captured by the camera was always different from what was on the document. Up until that point, the issue seemed to be with the application, because when we manually entered the number, our backend worked just fine.

With the document below, we can simulate the problem.

Reading Result:

Captured by the camera:

84620000001468501622024081048000000800872166

The difference lies in the check digits. Take a look:

846200000012468501622020408104800003008008721667

For a while, I thought the issue was with the reader itself, or perhaps the quality of the device's camera. Interestingly, the reader worked with other documents, but not with this specific type. After various attempts, I accepted that the problem might be in the application and started digging deeper.

Hypotheses and Investigations

The package we were using for barcode reading was qr_mobile_vision. I experimented with alternatives like simple_barcode_scanner and flutter_barcode_scanner, but all of them had limitations in customizing the camera display, and they all suffered from the same reading issue. Not seeing an obvious solution, I decided to delve into the qr_mobile_vision package.

I discovered that qr_mobile_vision uses Firebase's ML Kit to read codes. After exploring the documentation and running tests, I identified that the barcode type for this document is ITF. Without enabling this type, the reader would not capture anything.

So I dug deeper and ended up finding a sample project from Google using ML Kit, but the same reading issue occurred. That's when I started to question whether the problem was actually with the reader.

A Light at the End of the Tunnel

As my research progressed, I started to consider that the issue might not be within our app. I investigated how these documents are generated and found the document "Layout Padrão de Arrecadação/Recebimento com Utilização do Código de Barras" (Standard Layout for Collection/Receipt Using Barcodes).

I learned something important:

Number Position | Number of Characters | Meaning
01 – 01 | 1 | Product Identification
02 – 02 | 1 | Segment Identification
03 – 03 | 1 | Identification of the Real Value or Reference
04 – 04 | 1 | General Check Digit (module 10 or 11)
05 – 15 | 11 | Value
16 – 19 | 4 | Company/Agency Identification
20 – 44 | 25 | Free Field for Company/Agency Use

I noticed that none of these fields mention check digits. In the following pages of this document, there's an explanation of how to calculate them, and that's where I cracked the case: The highlighted values above weren't read because they weren't present in the barcode, not due to an issue with the package, device, or operating system.

Solution

After discussing the root cause with the leadership, we agreed that the backend would receive the information as read by the camera and handle the verification logic on their side.

Conclusion

It was quite an adventure to reach the solution to this problem, but I learned a lot along the way. I hadn't found many resources on this specific issue in the Brazilian banking system at the time of writing this article, but I hope it helps anyone facing a similar challenge.

That's it, folks. Thanks for reading!

Problema Leitura de Código Barras no Flutter

Gustavo Guedes — Fri, 16 Aug 2024 02:47:01 +0000

Um pouco de contexto

Recentemente, me deparei com um "problema" relatado em uma aplicação. O leitor de código de barras não estava funcionando corretamente: o valor lido era divergente do que constava no documento. Neste artigo, vou compartilhar um pouco dessa jornada para entender e resolver a questão.

Spoiler: O problema estava relacionado a uma regra específica na geração de códigos de barras da FEBRABAN (Federação Brasileira de Bancos). Portanto, o caso pode ser mais relevante para o contexto brasileiro, mas talvez possa oferecer insights valiosos para você. Vamos lá!

O problema

Como mencionado, o valor capturado pela câmera era sempre diferente do informado no documento. Até aquele momento, a culpa parecia ser da aplicação, já que ao digitar manualmente o número, nosso backend funcionava corretamente.

Veja um exemplo:

Documento

Resultado da leitura:

84620000001468501622024081048000000800872166

A diferença está nos dígitos verificadores. Veja só:

846200000012468501622020408104800003008008721667

Por um bom tempo, achei que o problema era do leitor ou até da qualidade da câmera do dispositivo. Curiosamente, o leitor funcionava com outros documentos, mas não com esse tipo específico. Após diversas tentativas, aceitei que o problema poderia estar na aplicação e comecei a investigar mais a fundo.

Hipóteses e investigações

O pacote utilizado para leitura era qr_mobile_vision. Experimentei alternativas como simple_barcode_scanner e flutter_barcode_scanner, mas todos apresentavam limitações na customização da exibição da câmera, além de sofrerem do mesmo problema de leitura. Sem encontrar uma solução óbvia, decidi me aprofundar no pacote qr_mobile_vision.

Descobri que o qr_mobile_vision utiliza o ML Kit do Firebase para realizar a leitura de códigos. Após explorar a documentação e realizar testes, identifiquei que o tipo de código de barras desse boleto é ITF. Sem habilitar esse tipo, o leitor não capturava nada.

Então fui mais fundo e acabei encontrando um projeto exemplo do Google usando o ML Kit, mas o mesmo problema de leitura ocorreu. Foi então que comecei a questionar se o problema realmente estava no leitor.

Uma luz no fim do túnel

Conforme as pesquisas avançavam, comecei a considerar que o problema poderia não estar na nossa aplicação. Investiguei como esses documentos são gerados e encontrei o documento “Layout Padrão de Arrecadação/Recebimento com Utilização do Código de Barras”.

E nele aprendemos algumas coisas bem legais:

Posição dos números | Quantidade de caracteres | Significado
01 – 01 | 1 | Identificação do Produto
02 – 02 | 1 | Identificação do Segmento
03 – 03 | 1 | Identificação do valor real ou referência
04 – 04 | 1 | Dígito verificador geral (módulo 10 ou 11)
05 – 15 | 11 | Valor
16 – 19 | 4 | Identificação da Empresa/Órgão
20 – 44 | 25 | Campo livre de utilização da Empresa/Órgão

Percebi que em nenhum desses campos é mencionado os dígitos verificadores. Nas páginas seguintes do documento, há uma explicação de como calculá-los, e foi aqui que descobri o ponto-chave: os dígitos destacados acima não foram lidos porque não estavam presentes no código de barras, e não devido a um problema no pacote, dispositivo ou sistema operacional.

Solução

Após alinhar com a liderança sobre a causa do problema, decidimos que o backend receberá a informação como foi lida pela câmera e realizará as lógicas de verificação necessárias.

Conclusão

Foi uma aventura e tanto até chegar à solução deste problema, mas aprendi bastante durante o processo. Não encontrei muitos recursos sobre esse problema específico do sistema bancário brasileiro, mas espero que este artigo possa ajudar quem estiver passando por algo semelhante.

É isso, pessoal. Tmj e vlw!

Efficient UI Validation: Exploring Widget Testing in Flutter (UI Tests)

Gustavo Guedes — Wed, 14 Aug 2024 02:24:11 +0000

A Bit of Context

Widget testing is a type of testing that is sometimes underestimated, but it holds significant value. In this article, we'll explore widget testing, provide tips to help you incorporate it into your daily workflow, and demonstrate its practical applications.

Before diving in, it's essential to note that the official Flutter documentation is an excellent starting point. It offers simple and practical examples that give you a solid understanding of how things work. Here, you'll find a summary of the key information along with insights from someone who has spent considerable time working with this type of testing.

What Problem Does It Solve?

To understand the role and types of widget tests, check out this video on the Flutter YouTube channel. It explains three types of UI tests:

Golden tests(Pixel perfect);
Finder tests(Behavior);
PaitPattern tests(Drawing instructions);

We will focus on the second type, Finder tests, which validate the behavior of your components. As the Flutter documentation states: "Many widgets not only display information but also respond to user interaction. This includes buttons that can be tapped, and TextFields for entering text."

Basic Concepts

Creating this type of test is very similar to unit testing. However, you'll need to add the Flutter widget testing SDK:

dev_dependencies:
  flutter_test:
    sdk: flutter

Once that’s done, you’ll have access to the methods necessary to build and run your tests.

A quick way to create a test file in VSCode is by right-clicking and selecting "Go to Test." This command checks if a test file already exists; if not, it suggests creating one. It’s a simple but useful command, especially since it creates all the necessary folder layers for that file. Pretty neat—give it a try!

Inside your test file, you should see something like this:

testWidgets('Test Description', (WidgetTester tester) async {})

testWidgets is the method used to execute widget tests, and tester is the tool that will be used to find, interact, and much more.

Now, you’ll need to place your widget for testing. The most common approach is as follows:

await tester.pumpWidget(const MyWidget());

This is also a good place to set up some basic configurations for your component, like theme settings or even dependency injection. A best practice is to wrap your component in a MaterialApp to ensure it has all the necessary theme and MediaQuery configurations.

await tester.pumpWidget(MaterialApp(home: const MyWidget()));

To locate elements on the screen, you can use the CommonFinders singleton. It offers various ways to find the element you’re looking for, and the notation is quite straightforward:

final buttonFinder = find.byType(ElevatedButton)
final textFinder = find.text('Hello world!')
final myWidgetByKeyFinder = find.byKey(Key('MyWidget-Key'))

It’s important to note that the variables created, such as buttonFinder and textFinder, don’t store the actual elements but rather a "way" to find them.

expect(buttonFinder, findsOneWidget);

In the test above, I'm looking for exactly one button; if none or more than one is found, the test will fail.

For interacting with elements, you’ll use the tester provided by the testWidgets method. You can perform actions such as tapping, entering text, or dragging. You can also select the element itself.

await tester.enterText(find.byType(TextField), 'hi');

await tester.pump()

To ensure that the widget tree is rebuilt after simulating a user interaction, call pump() or pumpAndSettle(). Here's a brief summary of how they work.

Let’s Practice!

Here’s our example component:

class PrimaryButton extends StatelessWidget {
  PrimaryButton({
    required String title,
    super.key,
    this.onTap,
    this.backgroundColor = Colors.blue,
    this.isLoading = false,
  }) : title = Text(
          title,
        );

  final Widget title;
  final VoidCallback? onTap;
  final Color backgroundColor;
  final bool isLoading;

  @override
  Widget build(BuildContext context) => ElevatedButton(
        style: ButtonStyle(
          backgroundColor: MaterialStateProperty.resolveWith<Color>(
            (Set<MaterialState> states) {
              if (isLoading) {
                return Colors.grey;
              }

              return backgroundColor;
            },
          ),
        ),
        onPressed: isLoading ? null : onTap,
        child: isLoading ? const CircularProgressIndicator() : title,
      );
}

The behaviors that immediately stand out as needing validation are:

Change of backgroundColor;
When isLoading is true:
- The onTap should not be callable;
- A CircularProgressIndicator should be displayed instead of our title;
- backgroundColor should be Colors.grey;

Validating the backgroundColor Change

Let’s get our component ready for testing:

testWidgets('Slould be able to render and interact with PrimaryButton',
    (tester) async {
  await tester.pumpWidget(MaterialApp(
    home: PrimaryButton(
      title: 'title',
      backgroundColor: Colors.red,
      onTap: () {},
    ),
  ));

  // ...
});

Now, let’s validate if the custom background color is correctly applied.

IMPORTANT

The button rendered on the screen isn’t the PrimaryButton but an ElevatedButton, so the validations and interactions should be performed on this component, not its parent. For example, the onTap method isn’t in the PrimaryButton; if you try to tap it, nothing will happen. But it will work with the ElevatedButton.

The same concept applies to keys; if you want to identify an element using a key, you need to know which widget to assign the key to. In our example, the key of the PrimaryButton is not the same as its child ElevatedButton. So, if you try to trigger onTap through the parent, it won’t work. To use these default Flutter component keys, you need to extend them:

class PrimaryButton extends ElevatedButton {}

This way, the issues mentioned above won’t occur. However, I chose to use the component as is because it’s more common than extending widgets.

To validate if the color we passed is indeed applied, we do:

final buttonFinder = find.byType(ElevatedButton);
final buttonWidget = tester.widget<ElevatedButton>(buttonFinder);

expect(
  buttonWidget.style?.backgroundColor?.resolve({}),
  Colors.red,
);
expect(find.text('title'), findsOneWidget);

With the advent of Material3 and the implementation of MaterialStateProperty, we use the resolve method to obtain the component’s property for a specific state. Since we didn’t pass any state, I used an empty Set.

Our first validation is now complete. Next, let’s interact with the onTap method.

Interacting with the onTap Method

One simple way to validate whether the method was called is by using a library like mockito or mocktail.

class OnTapMock extends Mock {
  void call();
}

void main() {
  late OnTapMock onTapMock;

  setUp(() {
    onTapMock = OnTapMock();
  });
}

We pass this mock as a callback for the onTap method and can validate:

verifyNever(() => onTapMock());

Now for the actual interaction:

await tester.tap(buttonFinder);

verify(() => onTapMock());

Simple, right?

Handling isLoading == true

Let’s start by creating a new test:

testWidgets('Slould be able to validate PrimaryButton behaivor with isLoading equals true',
    (tester) async {
  await tester.pumpWidget(MaterialApp(
    home: PrimaryButton(
      title: 'title',
      backgroundColor: Colors.red,
      onTap: () => onTapMock(),
      isLoading: true,
    ),
  ));
});

And the validations would look like this:

final buttonFinder = find.byType(ElevatedButton);
final buttonWidget = tester.widget<ElevatedButton>(buttonFinder);

expect(
  buttonWidget.style?.backgroundColor?.resolve({}),
  Colors.grey,
);
expect(find.text('title'), findsNothing);
expect(find.byType(CircularProgressIndicator), findsOneWidget);
verifyNever(() => onTapMock());

await tester.tap(buttonFinder);

verifyNever(() => onTapMock());

This way, we ensure that with the isLoading == true prop:

The background color is correctly set;
The title is not rendered;
The CircularProgressIndicator is displayed;
Tapping the button in this state does not trigger the callback;

Now we can confidently modify this component, knowing that its behavior remains consistent.

Conclusion

Widget testing in Flutter is a powerful and enjoyable process, allowing you to efficiently validate your components' behavior. Sometimes, these tests require you to rethink how your components are structured, but this is similar to what happens with unit tests, where improving the way we build our methods and manage dependencies results in more robust and testable code.

Implementing these tests brings greater confidence when making changes to the code, ensuring that the desired behavior remains intact. So, if you haven't yet integrated widget testing into your workflow, now is the perfect time to start.

That's all for today! See you next time!

Understanding and Avoiding Unexpected Component Rebuilds in Flutter

Gustavo Guedes — Fri, 09 Aug 2024 02:11:28 +0000

A little context

Recently, I encountered a problem that took me a few hours to understand what was happening. Let's dive straight into the example:

Imagine the following component:

class CustomButton extends StatefulWidget {
  const CustomButton({super.key});

  @override
  State<CustomButton> createState() => _CustomButtonState();
}

class _CustomButtonState extends State<CustomButton> {
  @override
  void initState() {
    print('INIT STATE CUSTOM BUTTON');
    super.initState();
  }

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: () {},
      child: const Text("Do something"),
    );
  }
}

Simple, right? But this initState gave me quite a headache.

Basically, every time the screen entered or exited the loading state, the initState was triggered. As we know, initState should only be executed once, when the component is first placed on the screen.

So I asked myself: what was destroying and rebuilding this component repeatedly? The answer is simple but interesting. Take a look:

When `loading` is more than `true` or `false`

Think of a complex component where there are multiple levels of loading: from the parent and from the component itself. A good example is a TODO list. It wouldn't be a great experience to disable the entire list just to update a single item on the backend.

We can take an approach like this:

Here we have the global loading of the list and the individual loading of each item. So where's the problem?

See what happens when we toggle the loading status:

flutter: PAGE initState
flutter: PAGE BUILD
flutter: List Item initState
flutter: List Item BUILD
flutter: PAGE BUILD
flutter: List Item initState
flutter: List Item BUILD

Notice that the initState of the List Item is called twice, while the screen's is called only once. In a list with simple items, this might not seem like a big issue, but when we talk about more complex lists or a screen that contains components imported from other features with their own initState routines, the problem can easily escalate. Can you see where this might lead?

Imagine, for instance, that every time our List Item sends a view event to an Analytics service, and this happens in the component's initState. The data about this widget's views would be considerably inflated because of this "problem."

Are there solutions?

Of course! But the solution depends on the scale of the problem.

In the case above, it would be easier to send the component's view information before the list is displayed, rather than within the component itself. This is one possibility. However, in larger applications, it's not sustainable to manage everything in one place.

The main point is to know exactly where to use your loading state and when to segment it.

I encountered this specific problem when using the shimmer library. The effect I used above was created with it. Every time a component's loading finished, the data in an input was cleared, precisely because the initState of the component was clearing the TextEditingController.

class CustomShimmer extends StatelessWidget {
  final Widget child;
  final bool loading;
  final Color baseColor;
  final Color highlightColor;

  const CustomShimmer({
    super.key,
    required this.child,
    this.loading = false,
    this.baseColor = Colors.black,
    this.highlightColor = Colors.white60,
  });

  @override
  Widget build(BuildContext context) {
    if (loading) {
      return Shimmer.fromColors(
        baseColor: baseColor,
        highlightColor: highlightColor,
        child: child,
      );
    }

    return child;
  }
}

As mentioned, every time the component changes state, our child is destroyed and recreated. It's important to clarify that this is not a problem with the library; if it were a CircularProgressIndicator, the same thing would happen.

Conclusion

The goal of this post was to highlight something simple but that can easily go unnoticed and end up generating an issue on your board in the future. Stay alert to these details! 😊

DEV Community: Gustavo Guedes

Dependency Diagram: Understanding and Visualizing Relationships

1. Arrow with Linear Body and Empty Head

2. Arrow with Dotted Body and Empty Head

3. Arrow with Solid Body and Filled Head

4. Arrow with Dotted Body and Filled Head

5. Colors for Each Context

Conclusion

ListView.builder vs ListView: Is There a Difference?

What are ListView and ListView.builder?

On-Demand Rendering

A Closer Look at ListView.builder

Conclusion

ListView.build vs ListView tem diferença?

O são ListView e ListView.build?

Renderizações sob demanda

Falando um pouco mais sobre o ListView.build

Conclusão

Improving Swift’s Equatable for Complex Class Comparisons

A little context

What does Equatable offer us?

Inspiration

Let’s get to work

Unit tests

Conclusion

A Step Beyond Hello World: Building a Calculator App with ViewCode

Let’s Get to Work

Creating the Main View

Creating the First Elements

Componentizing the Button

Creating the Other Elements

Final Buttons and Result Label

Interactivity

Conclusion

Setting Up ViewCode Projects for Versions Below iOS 13

What is AppDelegate?

Setting Up the Initial Interface in AppDelegate

Understanding the Code

Why Not Use SceneDelegate?

Conclusion

Getting Started with ViewCode in iOS: A Basic Guide

What problem does it solve?

What about SwiftUI?

Let’s get to work

01. Creating the project

02. Initial changes

Creating elements with ViewCode

Conclusion

The Importance of Error Handling in Mobile Applications

Errors Beyond Backend Calls

Implementing This in Your Projects

Conclusion

Barcode Reading Problem in Flutter

A Little Background

The Problem

Hypotheses and Investigations

A Light at the End of the Tunnel

Solution

Conclusion

Problema Leitura de Código Barras no Flutter

Um pouco de contexto

O problema

Hipóteses e investigações

Uma luz no fim do túnel

Solução

Conclusão

Efficient UI Validation: Exploring Widget Testing in Flutter (UI Tests)

A Bit of Context

What Problem Does It Solve?

Basic Concepts

Let’s Practice!

Conclusion

Understanding and Avoiding Unexpected Component Rebuilds in Flutter

A little context

When loading is more than true or false

Are there solutions?

Conclusion

What are `ListView` and `ListView.builder`?

A Closer Look at `ListView.builder`

O são `ListView` e `ListView.build`?

Falando um pouco mais sobre o `ListView.build`

When `loading` is more than `true` or `false`