DEV Community: Amerigo Mancino

How to create a debouncing timer in Swift

Amerigo Mancino — Thu, 05 May 2022 11:14:16 +0000

One common problem people tends to underestimate is when users decide to stress a heavy functionality within your app, for example by pressing a button numerous times in a small span, resulting in crashes and undefined behaviors.

One way to overcome this problem is to create a debouncing timer. We do that by defining a couple of variables inside the class where the functionality is used:

private var debouncingTimer: Timer? = nil
private let DEBOUNCE_TIME: TimeInterval = 0.5

The debounce time is the minimum interval for the heavy code to occur. Within that time span other user interactions will be ignored.

Then, from within the outlet of the button who triggers your heavy functionality we perform the following:

if debouncingTimer == nil || debouncingTimer?.isValid == false {
    self.debouncingTimer = Timer.scheduledTimer(
        withTimeInterval: DEBOUNCE_TIME,
        repeats: false) { [weak self] timer in
                timer.invalidate()
                self?.debouncingTimer = nil
            }

    // your heavy functionality
}

By doing this, we set a timer every time the heavy code is triggered and we protect it until the timer keeps running.

When the timer is invalidated, the functionality becomes available for the user again.

A real CarPlay Simulator: take off guide

Amerigo Mancino — Wed, 02 Feb 2022 11:40:06 +0000

Working with CarPlay might be though for various reasons and the recent upgrade to M1 chips only added more problems to the matter. Having to integrate third party libraries within your project that are not build for M1, having to run Xcode on Rosetta and having to support CarPlay is a difficult challenge for every developer nowadays.

Luckily Apple has recently released a standalone CarPlay simulator as a separate app that can natively run on your Mac. Let's see how to set it up and how it works.

Download and Install

At the time of writing, the only way to download the app is through the Apple Developer Portal. Download the Additional Tools for Xcode 13.2, then open the image file and go under the Hardware folder. Move the CarPlay simulator app to your Application directory.

Configuration

There is no official guide on how to configure your iPhone to be ready for the simulator. The only thing you have to make sure of is to turn off your hotspot on your device (if on). When this step is done, connect your device to your Mac and open the simulator. On your iPhone you should see a message from the simulator requiring permissions. Grant them and it will load the CarPlay interface. On the simulator menu, under Devices, you should see your device name with a green icon.

Notes

You can use this simulator for development purposes. When you run an app on debug mode and open the app on the simulator, all your print statements and breakpoints will be triggered.

How to create a custom Angular async validator

Amerigo Mancino — Thu, 04 Feb 2021 12:03:43 +0000

Angular provides a certain number of ways to validate your input data. With attributes like required or maxlength we can easily control what a user can and cannot insert in a form.

However, what if the validation has to happen on the backend? How do I implement a custom validator that is able to call a backend service and return the validation result?

In this article, I will guide you through the steps you need to perform in order to create your custom asynchronous validator.

The backend service

For the purpose of this example, let's imagine we have an endpoint which accepts, in the request body, a structure like the following one:

{
   "objectType": "SOME_OBJECT_TYPE",
   "value": "Some name"
}

Where value is the value to validate and objectType contains some information needed by the sever.

To this call, the server responds with another object containing the field valid (the validation result) and a message:

{
   "valid": false,
   "message": "Must not be blank"
}

The validator

To create a custom validator, we need to create a new directive by running:

ng generate directive nameIsValid

Let's define the directive decorator first:

@Directive({
  selector: '[nameIsValid][ngModel],[nameIsValid][FormControl]',
    providers: [
        {
            provide: NG_ASYNC_VALIDATORS,
            useExisting: NameIsValidDirective, 
            multi: true
        }
    ]
})

The code above registers the validator, so Angular is aware it exists and can use it during binding. This means that thereafter we can use it in an input field as in the following example:

<input
  type="text"
  id="name"
  name="name"
  nameIsValid
>

Moving back to the directive, we can now populate the validator class:

export class NameIsValidDirective implements AsyncValidator {

  private validationServiceUrl = "my backend url";

  constructor(
    private http: HttpClient
  ) { }

}

As you can see, the NameIsValidDirective class implements the AsyncValidator interface which requires us to define a validate function:

validate(control: AbstractControl): 
   Observable<ValidationErrors | null> {

    let fieldToValidate = {
        objectType: "NAME_VALUE",
        value: control.value
    };

    const request = this.validationServiceUrl

    const obs = this.http.post<any>(request, fieldToValidate)
        .pipe(
            map((validationResult) => {
                // null no error, object for error
                return validationResult.valid === true ? null : {
                  NameIsValidDirective : validationResult.message
                };
            })
        );
    return obs;
  }

control.value contains the value the user inserted in the input field. With this information, we build the object to send to the backend, make a call and get the response: if the validation went good, we must return null, otherwise we must return an object. In this example, I chose to return the validation error message.

Conclusions

Despite typically there is no need to create custom validators at all, there are specific cases or architectural needs where we require to perform a validation on the backend side. When this case occurs, you are now aware of how custom validators work and you successfully learned how to implement one.

Scrum for dummies

Amerigo Mancino — Sun, 06 Dec 2020 17:30:46 +0000

Agile methodology

Agile methodology refers to a set of software development methods that are opposed to the Waterfall Model and other traditional approaches. It proposes a less structured approach that focuses on the objective of delivering to the customer - frequently and in a short time - working and quality software.

Among the practices promoted by agile methods are the formation of small, self-organised development teams, adaptive planning and the direct and continuous involvement of the client in the development process.

The Agile Manifesto is based on four principals:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

Waterfall Model

The Waterfall Model is the most traditional model describing the software life-cycle. According to it, the software development process is structured into the following five clear phases:

Requirements analysis
Design
Development
Test
Maintenance

As we can see, the most important distinction among the two models is the fact that Agile provides a development for subsequent refinements which the Waterfall Model does not.

Scrum

Definitions

Scrum is an Agile Framework. You can think of it as one possible implementation of the Agile guidelines: if Agile provides the recipe, Scrum puts in the ingredients to realize it.

To create a product with Scrum, we receive specifics from stakeholders, i.e. from all those interested in creating the product itself.

In Scrum those specifics are called user stories or just stories and they are a brief description of a requested feature under the user's point of view. The way user stories are written is overall standard:

As a <type of user>
I want <some goal>
So that <some reasons>.

All the stories are grouped into the product backlog which is a required list of features related to the product.

In Scrum people necessary for the realization of a product are divided into:

Product Owner - represents the stackeholders and is the voice of the clients. He ensures that the product developed provides value to the business and writes the stories assigning them a priority. Then he adds them to the Backlog.
Scrum Master - removes obstacles that limit the team's ability to achieve the sprint goal. He is not the Team Leader
Development Team - they are responsible for product development; generally consisting of 3 to 9 people, it self-organises and self-manages.

A Sprint is the base development unit of Scrum development. With a fixed duration (from 1 to 4 weeks), during the Sprint the team works and develops all the user stories that pledged to deliver at the end of the Sprint. The delivered product at the end of each Sprint is called increment.

Workflow

The most common events that occur during a Scrum process are the followings:

Backlog refinement - The Product Owner meets the team to discuss the stories currently in Backlog. He shares the priority of each story and defines the concept of done, i.e. when a story can be considered as finished.
Sprint Planning - The team chooses the stories it undertakes to deliver at the end of the Sprint. This choice is made considering the priorities assigned by the Product Owner.
Sprint - As already discussed above, during a Sprint the team works to develop the user stories assigned to the Sprint. At the end of each Sprint, the value of the stories (generally measured in story points) contributes to give an estimation of the speed's team. A certain number of story points corresponds to a certain amount of hours that the team expects to need to finish the story.
Daily Scrum - The Scrum Master meets the team and each member answers to three simple questions:
- What have I done yesterday?
- What am I going to do today?
- What are the obstacles I encountered yesterday during my work?
Sprint Review - The team shows to the Product Owner and the Stakeholders what he did during the Sprint. Generally, this meeting includes a demo of the new functionalities implemented in the application.
Sprint Retrospective - The Scrum Master meets the team and tries to identify the things the team does well, what it should start doing to improve performance and what it should stop doing.

The following diagram describes in which order these events occur:

Implement Scrum

Jira is a professional and complete tool implementing Scrum. It's often used by large companies and offers a board where all the stories for a given Sprint are presented.

Stories on the board are sometimes called tickets. Jira includes a distinction among tickets to simplify the planning part. They are divided into:

Epics - Very big tickets that generally contain a general use case that is a collection of user stories (i.e. authentication).
User stories - Represents a user feature (i.e. forgot password).
Sub tasks - Development tasks to accomplish a user story (i.e. implement HTML/CSS of login screen).
Defects - A bug was found in a released story and needs to be fixed (i.e. login button doesn't work on Safari).

A less popular and less professional tool to implement Scrum is Trello. It is very simple to use and - despite having less features than Jira - it is recommended for projects that don't require a strong management infrastructure for building, fixing and releasing software. It is also definitely a good starting point for learning how Agile development works.

Trello provides a public board where you can learn more about Scrum and using the tool.

Why does Scrum fail?

What we learned so far is that Scrum is great and provides a useful support in planning, organization and development. Then why does it (sometimes) fail? or rather, to be more precise, why Scrum fails in large enterprises?

There are various reasons behind that:

The Product Owner is not involved in the process as much as he should and doesn't have a customer mindset.
Team members lack in experience (and consequently fail a Sprint).
The Scrum Master fails in removing the obstacles encountered by the team.
No clear roles distinction.
Bureaucracy prevents a successful Sprint (i.e. tickets are blocked because they are not approved).
Bad management and pyramidal scheme.
The team is not informed on the big picture and completes user stories blindly.
Lack of testing strategies.

We can reconnect most of these problems I mentioned (and those I didn't mention you can add to the list) to a main one: lack of communication. Meetings and discussions are important but they need to provide additional value to the entities joining in: the team must have a clear vision of what they are building, the Product Owner shouldn't start doing commands or speak one-to-one with developers, the Scrum Master must fulfill his role of "man in the middle".

Unfortunately large companies have always difficulties in integrating Agile in their structure and/or they do not have sufficient experience in understanding how to do it properly: they have different business units, more processes and, most important, a strong culture that defines how things are done, and this is something that makes an integration even more difficult.

Conclusions

Agile methodology and Scrum offer useful mindsets and tools to deal with development for subsequent refinements and in turn propose a successful working strategy. Unfortunately, large companies often fail in implementing it due to their culture and their complexity. However, by putting effort in integrating it, Agile proves to be a reliable method for software developing.

How to ActivatedRoute in Angular and how to mock it in Unit Tests

Amerigo Mancino — Wed, 02 Dec 2020 09:24:02 +0000

The topic of testing is always mistreated online. It's easy to check that on a hundred articles explaining how to develop a certain functionality, only one or two include a description of how to test it. Even in large projects and in big companies, it is not rare to just forget about testing because time is short or because workarounds are possible. This is a terrible behavior: the bigger the project, the easier it becomes to break something while implementing something else and - without unit tests - there is no way to know it for sure.

In this tutorial, I will explain you how to use ActivatedRoute to pass a parameter from a component to another and how to mock it in the corresponding Unit Test.

How to pass a parameter with ActivatedRoute

Let's say we have a Home component where we display a list of users. Our goal is to pass the user id via the web url, retrieve it and use it in a User component to collect - for example - all the user details:

To achieve that, first we need to define the route in app-routing.module.ts as the following:



{
  path: 'user/:id',
  component: UserComponent
},

To pass the id we have two possibilities:

The first one is by editing the HTML in the Home component:



<a [routerLink]="['user', id]">
   <!-- When clicked I redirect to the User component -->
</a>

The alternative is to navigate inside a typescript function; import the Router and declare it in the constructor:



constructor(
  private router: Router
) { }

Then use it in your function:



this.router.navigate(['/user', id]);

In the User component we can at last retrieve the id.
Let's import the ActivatedRoute and declare it in the constructor:



constructor(
  private activatedRoute: ActivatedRoute,
) { }

Afterwards in the ngOnInit() we can get the id:



const id = this.activatedRoute.snapshot.params.id;

Once we have it, we can use it the way we like. For example, we can pass it as a parameter to a service and retrieve the User details as stated above.

Unit test

It is pretty straightforward to mock the ActivatedRoute in the User component test file. All we have to do is to edit the providers list as follows:



beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [ UserComponent ],
      imports: [
        RouterTestingModule,
        HttpClientTestingModule
        // ... whatever other module you have
      ],
      providers:
      [
        {
          provide: ActivatedRoute,
          useValue: {
            snapshot: {params: {id: '24fkzrw3487943uf358lovd'}}
          }
        }
      ]
    })
    .compileComponents();
}));

That's it!

Run npm test in a terminal to execute all your unit tests and check the outcome!

How to dockerize an Angular app for different environments

Amerigo Mancino — Mon, 30 Nov 2020 16:16:15 +0000

Docker is an open-source tool designed to help programmers in development and deployment. It makes use of a structure called "container" which wraps the application and its dependencies together so that it can be executed on any machine. This is particularly important when have to deal with different servers - testing, integration, production - where the applications must run without any error or compatibility issue.

In this tutorial I will explain how to dockerize an Angular application for different target environments.

Set up custom environments in Angular

By default, Angular provides two different environment files, that can be found in the environments folder:

Let's add a couple more! Create two new files named environment.test.ts and environment.int.ts and replace in there your urls with the ones you want to use for the target environment. Here is my environment.int.ts:



export const environment = {
    production: false,
    name: 'int',
    functionUrls: {
        data1: 'my-data1-int-url',
        data2: 'my-data2-int-url'
    }
};

Then we need to tell Angular that we have new build configurations: edit the angular.json file and create new entries under architect → build → configuration. As you can see, the production and local (serve) entries are already present.

When inserting a custom environment we only need to notify the framework to replace the default environment.ts with the one we want at build-time, so in principle it is sufficient to add the following:



"int": {
  "fileReplacements": [
     {
      "replace": "src/environments/environment.ts",
      "with": "src/environments/environment.int.ts"
     }
  ],
},

We can customize the build options by adding extra settings. Refer to the official documentation for further details.

As a last step, let's edit the package.json and write some commands to build the app more easily:



"scripts": {
   "ng": "ng",
   "start": "ng serve",
   "build": "ng build",
   "build-test": "ng build --configuration=test",
   "build-int": "ng build --configuration=int",
   "build-prod": "ng build --prod",
   "test": "ng test",
   "lint": "ng lint",
   "e2e": "ng e2e"
},

Let's build our app!

Open a terminal and from the main project folder run npm build-int. This will build the application for the int environment. Your output is located into the dist folder in your project, ready to be deployed on a server.

If you want, you can test it using http-server. Install it with:



npm install http-server -g

Run it with:



http-server ./dist

It will start serving your project from the dist folder.

Integrate Docker

Now that we can build a project for different environments, it's time to integrate Docker and run the application in a container. First, create a docker folder inside the project, which will contain all the docker-related files. Then create a docker-compose file for each environment: docker-compose.int.yml for integration , docker-compose.test.yml for testing and so on. These files look like the following:



version: '3.3'

services:
  myapp:
    image: myapp
    build:
      context: ../
      dockerfile: docker/Dockerfile
      args:
        PROFILE: int
    ports:
      - "8080:80"

What's important to notice here is the line



PROFILE: int

were we define the environment we want to use: we'll inject this variable in the Dockerfile in a moment.

Let's create the Dockerfile:



FROM node:12.16.1-alpine As builder

### STAGE 1: Build ###
WORKDIR /usr/src/app
COPY package.json package-lock.json ./

RUN npm install

COPY . .

ARG PROFILE
ENV PROFILE $PROFILE

RUN echo "Environment: ${PROFILE}"
RUN npm run build-${PROFILE}

### STAGE 2: Run ###
FROM nginx:1.15.8-alpine

COPY --from=builder /usr/src/app/dist/myapp/ /usr/share/nginx/html
COPY --from=builder /usr/src/app/docker/nginx.conf /etc/nginx/conf.d/default.conf

EXPOSE 80

In stage one we build the application and restore the node_modules. As you can see, we use the PROFILE variable we defined above to retrieve the correct environment.

In stage two we run the application using nginx, which is an http and reverse proxy server. By default, nginx http server listens for incoming connection on port 80, which represents the standard web port. In the docker-compose we match that port with 8080.

In addition, note that here



COPY --from=builder /usr/src/app/docker/nginx.conf /etc/nginx/conf.d/default.conf

we replace the default nginx configuration with ours. To do so, we need to create one last file in our docker folder, called nginx.conf:



server {
  listen 80;
  location / {
    root /usr/share/nginx/html;
    index index.html index.htm;
    try_files $uri $uri/ /index.html =404;
  }
}

All games are done! Let's try to make this work.

If we want to build and run the configuration for integration, we only need to run the following commands in a terminal:



docker-compose -f docker/docker-compose-int.yml build
docker-compose -f docker/docker-compose-int.yml up

The up command will append the console at a message saying Attaching to..., then it goes to print logs.
Navigate to localhost:8080 to check the outcome.