Showwcase

coverage
style: very good analysis

Generated by the Very Good CLI ?

Showwcase is a professional network built for developers to connect, build community, and find new opportunities.

Getting Started ?

This project contains 3 flavors:

  • development
  • staging
  • production

To run the desired flavor either use the launch configuration in VSCode/Android Studio or use the following commands:

# Development
$ flutter run --flavor development --target lib/main_development.dart

# Staging
$ flutter run --flavor staging --target lib/main_staging.dart

# Production
$ flutter run --flavor production --target lib/main_production.dart

*Showwcase works on iOS, Android, and Web.

Running Tests ?

To run all unit and widget tests use the following command:

$ flutter test --coverage --test-randomize-ordering-seed random

To view the generated coverage report you can use lcov.

# Generate Coverage Report
$ genhtml coverage/lcov.info -o coverage/

# Open Coverage Report
$ open coverage/index.html

Working with Translations ?

This project relies on flutter_localizations and follows the official internationalization guide for Flutter.

Adding Strings

  1. To add a new localizable string, open the app_en.arb file at lib/l10n/arb/app_en.arb.

{
    "@@locale": "en",
    "counterAppBarTitle": "Counter",
    "@counterAppBarTitle": {
        "description": "Text shown in the AppBar of the Counter Page"
    }
}
  1. Then add a new key/value and description

{
    "@@locale": "en",
    "counterAppBarTitle": "Counter",
    "@counterAppBarTitle": {
        "description": "Text shown in the AppBar of the Counter Page"
    },
    "helloWorld": "Hello World",
    "@helloWorld": {
        "description": "Hello World Text"
    }
}
  1. Use the new string

import 'package:showwcase/l10n/l10n.dart';

@override
Widget build(BuildContext context) {
  final l10n = context.l10n;
  return Text(l10n.helloWorld);
}

Adding Supported Locales

Update the CFBundleLocalizations array in the Info.plist at ios/Runner/Info.plist to include the new locale.

    ...

    <key>CFBundleLocalizations</key>
	<array>
		<string>en</string>
		<string>es</string>
	</array>

    ...

Adding Translations

  1. For each supported locale, add a new ARB file in lib/l10n/arb.

├── l10n
│   ├── arb
│   │   ├── app_en.arb
│   │   └── app_es.arb
  1. Add the translated strings to each .arb file:

app_en.arb

{
    "@@locale": "en",
    "counterAppBarTitle": "Counter",
    "@counterAppBarTitle": {
        "description": "Text shown in the AppBar of the Counter Page"
    }
}

app_es.arb

{
    "@@locale": "es",
    "counterAppBarTitle": "Contador",
    "@counterAppBarTitle": {
        "description": "Texto mostrado en la AppBar de la página del contador"
    }
}

Architecture ?

This project uses an adaptation of Clean Architecture designed especially for mobile application development with Fluttter.

Clean architecture is a set of principles whose main purpose is to hide implementation details from the application’s domain logic.

In this way we keep the logic isolated, achieving a much more maintainable and scalable logic over time.

The main characteristic of Clean Architecture compared to other architectures is the dependency rule.

In Clean Architecture, an application is divided into responsibilities and each of these responsibilities is represented as a layer.

Layers in the application

Domain layer domain

The domain is the heart of the application and has to be totally isolated from any dependencies outside of business logic or data. The domain layer represents the implementation of what we know as a business model, or business logic. Business logic is that logic that would exist even if we do not have an application to automate the processes of a company. It is made up of the following elements.

Entities domain / entities

The entities contain the business data. The entities of an application could be shared between different applications within a company. Each entity is implemented as a class whose attributes correspond to the characteristics of the entity in the business model. Entities must not implement methods or any type of logic that is not related to the business model. Implementation details such as logic for decoding data returned by an API should not go in the entities, since the domain layer must be independent of the type of implementation made in the application.

Repositories domain / repositories

The repositories in the domain layer (also known as adapters) are in charge of establishing the interface that must be implemented in the data layer to obtain information. Repositories are the connection point between the data layer and the domain layer. It is represented only as an abstract class where the methods that must be implemented in the data layer are specified.

Data layer

Models data / models

The models extend the classes defined in domain / entities and implement the necessary methods to decode the information sent by the database or API, in this particular case they are in charge of transforming the information sent in json format by the API in the object (entity) that corresponds to it. They can also contain methods to encode the information in the appropriate format in case it is necessary to send information to the API.

Data sources data / datasources

The datasources are the classes in charge of making http requests to the API or directly interacting with a database. They use the models to decode and encode the information.

Repositories data / repositories

The repositories in the data layer are responsible for implementing the repositories that were previously defined in the domain layer, they use the datasources to perform the necessary data manipulation. The reason that repositories do not make requests directly to the API is to guarantee decoupling that allows us to change one data source for another or use multiple data sources within a repository without changing the entire repository implementation. It also allows testing the implementation of repositories and datasources independently.

Presentation layer

The presentation layer contains everything related to the application UI and its structure can vary. This layer uses the repository definitions exposed by the domain layer to carry out its operations.

Advantages of using Clean Architecture

The main advantages of using Clean Arcchitecture are:

  • Independence from Frameworks. It is not coupled to libraries, which allows these libraries to be used as tools that are easily replaceable.

  • Testable. Layers and their components are easily testable without using the user interface, database, web server, etc.

  • Independent of user interface. The user interface is easily replaceable, it allows updates both in

GitHub

View Github