DEV Community: Martin Maier

Responsive Design with Protractor and Browserstack

Martin Maier — Sat, 26 Jan 2019 08:07:22 +0000

This article describes how we can use Protractor and Browserstack to create a good environment and development process to quickly get feedback about the responsive design of a web application during development.

Challenge

We want to develop a responsive web application. Therefore it should be able to be used in a user-friendly manner at various resolutions and in different environments.

So we want to make sure that the application is properly displayed and operable in different browsers under Windows, OSX, IOS and Android.

When viewing the app on the desktop, we distinguish between a maximized window and a reduced window, which may require a different layout. On mobile devices, we differentiate between portrait and landscape mode.

Approach

During development, we want to get feedback on the presentation of our web application in the different environments as quickly and efficiently as possible.

To do this we want to create an environment in which we can verify the current state of our locally hosted app at any time from the different browsers of different operating systems.

Environment

Own devices

We could now design our environment to be e.g. on a Mac and address the app hosted there from a virtualized or real Windows system. In addition, however, we still need mobile Android and IOS devices in our network to test our app from these as well.

However, this solution would require that we have to invest a lot of money in hardware. And this hardware would always have to carry with us and we may have to take big hurdles in order to operate all devices in our corporate network.

If we work with multiple developers in parallel or remotely, this solution is also unattractive.

Browserstack

Browserstack provides a virtual way of accessing web pages from various browsers, operating systems and devices. This can be used to manually or automatically test web applications.

Key feature for us is that we can also access our local environment from the Browserstack instances.

The license costs are not cheap depending on the needs, but they are still significantly lower than the hardware acquisition and configuration costs. It also allows us to develop efficiently and flexibly.

Development process

First we develop and optimize our web application with one of our favorite local browsers. We take into account the representation in maximum resolution and in small resolution. The latter may require adjustments via CSS MediaQueries etc.

Next we want to get feedback on how the application looks in a variety of environments. For example, if we’re initially developing against Windows Chrome, we’d like to know how the app is displayed maximized and small in OSX Safari, IE11, Android Chrome and iPhone Safari.

For this we put the app via a protractor test in the state, whose representation we want to verify. Subsequently, a screenshot is created within the test and stored locally.

These semi-automated tests are run on Browserstack by using a respective protractor configuration. The result is a screenshot per desktop browser of the maximized window and a smaller window of defined size. For mobile devices, screenshots are taken in portrait and landscape mode.

This gives us automated and immediate feedback on these very different environments.

Problems with the presentation can then be analyzed and fixed manually via Browserstack Live. Within the Browserstack instances we are supported by the individual dev tools of the browser, as usual.

When the app is properly displayed in all screenshots, we finally have to verify the remaining environments by hand.

We could also always make screenshots of all variants, but this would extend the capturing and viewing of screenshots accordingly.

If the app is neatly displayed in the most diverse environments, my experience is that there are rarely any problems with the rest of the environment.

Note on the duration of the screenshots:

Depending on the license, the different environments can be tested in parallel in different instances and the tests can also be executed in parallel within the individual environments. Accordingly, the duration of the screenshot depends very much on how many parallel test executions the license contains. In my experience, taking screenshots takes about a minute per browser.

Configuration

Browserstack

First we create an account on the Browserstack page with a license that allows you to run automated tests.

Logged in, we find in our username and the associated key in our settings.

We do not want to write this information as plain text in our configuration, so we put them in the environment variables of the OS as BS_USERNAME and BS_KEY.

For Browserstack to access our local instance we need the NPM package „browserstack-local“. We install this as described on the GitHub page.

Screenshoter

For capturing and saving screenshots i wrote a small helper class. You can copy it from my GitHub Gist.

Protractor configuration

Dependencies

In out protractor configuration we need browserstack-local and the Screenshoter.

const { Screenshoter } = require('./screenshoter');
const browserstack = require('browserstack-local');

Capabilities

What I have referred as the environment is called capability in the context of protractor and Browserstack. Each capability defines an environment and can be created with the support of the Browserstack website.

Some properties of the capabilities are the same across. We define them globally and then inject them into the individual capabilities.

const commonCapabilityProperties = {
  'browserstack.user': process.env.BS_USERNAME,
  'browserstack.key': process.env.BS_KEY,
  'browserstack.selenium_version': '3.13.0',
  'browserstack.local': 'true',
  'browserstack.video': 'true',
  'browserstack.debug': 'false',
  'browserstack.timezone': 'UTC',
};

BS_USERNAME and BS_KEY are our browser stacks username and key, which we have previously defined as the environment variable of the operating system. We pass them from the process at runtime.

Now we define our capabilities. This can look like this, for example:

multiCapabilities: [
    {
      logName: 'OSX_Safari_1920',
      ...commonCapabilityProperties,
      os: 'OS X',
      os_version: 'High Sierra',
      browserName: 'Safari',
      browser_version: '11.1',
      resolution: '1920x1080',
      'browserstack.safari.driver': '2.48'
    },
    {
      logName: 'Win10_FF_720',
      ...commonCapabilityProperties,
      os: 'Windows',
      os_version: '10',
      browserName: 'Firefox',
      browser_version: '64.0',
      resolution: '1920x1080',
      customWindowSize: {
        width: 600,
        height: 800
      },
      'browserstack.geckodriver': '0.22.0',
    },
    {
      logName: 'GalaxyS9_Chrome_landscape',
      ...commonCapabilityProperties,
      os_version: '8.0',
      device: 'Samsung Galaxy S9',
      browserName: 'Chrome',
      browser_version: '71.0',
      real_mobile: 'true',
      deviceOrientation: 'landscape',
      'browserstack.appium_version': '1.9.1'
    },
    {
      logName: 'IPhoneX_Safari_portrait',
      ...commonCapabilityProperties ,
      device: 'iPhone X',
      browserName: 'Safari',
      real_mobile: 'true',
      'browserstack.appium_version': '1.9.1'
    }
}

„CustomWindowSize“ is not a standard property. We use it if we do not want to run the tests in a maximized browser window, but in a window of a defined size. More about that right now.

Settings

We now have to make some smaller settings.

The SeleniumAdresse:

  seleniumAddress: 'http://hub-cloud.browserstack.com/wd/hub',

The maximum number of Browserstack instances used:

  maxSessions: 2,

Normally Browserstack instances can access the locally hosted instance via localhost. Unfortunately there are problems with this kind of redirection on the IOS devices. This has been resolved by redirecting to the local instance via „bs-local.com“.

Furthermore, there is a limitation in the possible ports that can be used. Information can be found on the Browserstack FAQs.

In our example, the app is hosted locally on port 5000.

  baseUrl: 'http://bs-local.com:5000/',

Access to the Screenshoter

In order to be able to access the screenshoter in the tests, we provide this as a protractor parameter via a function.

To do this, we create a global map and define the protractor parameters:

const screenshoters = {};
exports.config = {
  //...
  params: {
    getScreenshoter: () => screenshoters[this.config.params.logName],
    logName: ''
  },
  //...
}

Connection to Browserstack

When starting Protractor we connect to the browser stack and propagate our session. In case of an error, the start should be aborted.

 beforeLaunch() {
    return new Promise((resolve, reject) => {
      console.log('Connecting local');
      exports.bs_local = new browserstack.Local();
      exports.bs_local.start({ key: commonCapabilityProperties['browserstack.key'] }, 
        function(error) {
        if (error) return reject(error);
        console.log('Connected to browserstack');
        resolve();
      });
    });
  },

Before we finish Protractor, we close the connection properly.

  afterLaunch() {
    return new Promise(resolve => exports.bs_local.stop(resolve));
  }

Before the environment is getting started…

For each individual environment, a screenshoter should be instantiated and the window should be maximized or adjusted.

async onPrepare() {
   //...
   return browser.getProcessedConfig().then(config => {
      exports.config.params.logName = config.capabilities.logName;
      screenshoters[config.capabilities.logName] = new 
         Screenshoter(config.capabilities.logName);
      return resizeWindow(config);
    });
  },

const resizeWindow = async function(config) {
  const isDesktop = config.capabilities.os === 'Windows' || config.capabilities.os === 'OS X';
  const customWindowSize = config.capabilities.customWindowSize ? 
     config.capabilities.customWindowSize : null;
  if (isDesktop === true) {
    if (customWindowSize !== null) {
      await browser.driver
        .manage()
        .window()
        .setSize(customWindowSize.width, customWindowSize.height);
      console.log('Resized window to ' + customWindowSize.width + 'x' + 
         customWindowSize.height);
    } else {
      await browser.driver
        .manage()
        .window()
        .maximize();
      console.log('Maximized window');
    }
    browser.switchTo();
  }
};

After all tests of a single environment have been executed…

After all tests have been executed, the captured screenshots a saved locally.

 async onComplete() {
    return new Promise(resolve => {
      const screenshotDir = `${__dirname}/screenshots/`;
      exports.config.params.getScreenshoter().saveScreenshots(screenshotDir);
      resolve();
    });
  },

Specification of the semi-automated tests

We have to write a test spec that puts the app in the desired state and finally captures the screenshot.

A spec for making a screenshot might look like this.

describe('SomeResponsiveComponent', () => {
  const page = new Page();

  it('should display a responsive dialog', async () => {
    await page.open();
    await page.openResponsiveDialog();

    await browser.params.getScreenshoter().takeScreenshot('ResponsiveDialog');
  });
});

The screenshot is saved in the project´s subfolder „screenshots/ResponsiveDialog/.png“.

Conclusion

Browser stack can greatly facilitate and save costs during the development for multiple browsers and operating systems.

By creating screenshots, working hours can be saved and feedback can be generated immediatly without manually and monotonously changing the app again and again in various browsers to a defined state.

The post Responsive Design with Protractor and Browserstack appeared first on maimArt - Crafted Software.

Testgetriebene Entwicklung von Angular Apps (W-JAX 2018)

Martin Maier — Wed, 07 Nov 2018 20:31:04 +0000

Hier befinden sich die Slides meines Vortrags über die testgetriebene Entwicklung von Angular Apps vom 6.11.2018 der WJAX.

Das Projekt liegt auf GitHub. Die einzelnen Entwicklungsschritte sind dort innerhalb der Commits und dem zugehörigen GitHub-Project dokumentiert.

https://speakerdeck.com/maimart/testgetriebene-entwicklung-von-angular-apps-wjax-2018

The post Testgetriebene Entwicklung von Angular Apps (W-JAX 2018) appeared first on maimArt.

Tutorial: Developing an angular app driven by tests

Martin Maier — Mon, 30 Jul 2018 14:49:35 +0000

This article is a tutorial for developing Angular applications driven by tests (TDD).

Introduction

For a long time graphical user interfaces of complex systems were made of solid and heavy weighted technologies of higher developed, object oriented programming languages.

Mostly UIs have been fat clients, developed with WPF or Swing. Just rarely they were thin clients as web applications.

And even in this seldom cases, HTML and JavaScript got abstracted by big frameworks like ASP or JSF and rendered on server side.

But the language core of JavaScript evolved well with ECMAScript 2015 and so got interesting for more complex applications, too.

Based on the suggestions to ECMAScript2015, TypeScript raised and became an additional option to build web applications on a very high language level that even types statically.

This big language improvements and the strong support of giants like Facebook and Google made web technologies to get more and more interesting for developing more complex applications as single page applications (SPA).

Unfortunately the source code of web applications still has the bad record to be on a lower quality level when regarding readability, design and test coverage.

But the value of creating high quality code, for sustainable further development and maintenance, is independent of the technology and so are the methodologies that ensures that value.

Test driven development (TDD) is a methodology of the Extreme Programming (XP) to develop high quality and well tested code.

In TDD we first specify and validate the behavior in tests, before we start to implement it. When the tests succeeds, we refactor the code to improve the readability and structure of the code.

This leads to well testable and tested code and a process where developers early have to think about the structure, respectively the design of the code.

By specifying functionality in tests first, we effectively only develop functionality that is required and preserves against developing predictive and unnecessary complex code.

Projects created with the Angular CLI, out of the box contains all tools we need to develop driven by tests.

This tutorial bases on a simple scenario and describes how to develop Angular project driven by tests.

The scenario

We want to focus the methodology and so choose a very simple scenario.

The application is a very lightweight contact management tool and provides only two functionalities:

displaying contacts
adding new contacts

Setup the Angular project

We first create an Angualr project with the Angular CLI.
ng new ContactManager

We want to start from the scratch, so we:

delete the component app.component
cleanup dependents app.module und index.html
delete the end-to-end specifications in the directory e2e/src
and check our changes by building the project with ng build

The „Walking Skeleton“

Our system is very small, does not communicate with any backend and for the sake of convenience it is not deployed automatically.

So in our case the walking skeleton is a crosscut for developing our application driven by tests.

This should contain an e2e-test that interacts with the web application by page objects and a first small component which is developed driven by tests.

A suitable first small story to build the walking skeleton is to display the contacts.

Approach

We develop in short TDD iterations.

I am using some special text styles to get the tutorial more readable and clear:

First we talk about and specify what we want to achieve in the next tdd
iteration. In best case we don´t develop for our own, but have paired with
another developer.

Test fails! We specify an accordingly test, start it and watch it fail.

Test succeeds! After that we implement the functionality and start the test again until it succeeds.

We check our code style, make some refactorings and after that we start with the next small tdd iteration.

Specifying the story in a first e2e-test

We specify the context of the “contact management” in a new e2e-specification /e2e/src/c_ontact-management.e2e-spec.ts_.

We define, that the contact management initially lists the two contacts “Max” and “Moritz”.

Within the e2e-test we want to interact with the application on a very high level and delegate the access to the HTML-Elements to so called “page objects”.

In TDD manner, we write the e2e-test, as if there would already exist a class _ContactManagementPage _and so define it in the most meaningful way from the clients point of view.

We create an instance of the ContactManagementPage, navigate to its view and verify that the contacts “Max” and “Moritz” are listed.

describe('Contact Management', function () {

  it('should show a list of contacts, initially containing "Max" and "Moritz"', function () {
    const page: ContactManagementPage = new ContactManagementPage();
    page.navigateTo();
    expect(page.shownNamesOfContacts()).toContain('Max');
    expect(page.shownNamesOfContacts()).toContain('Moritz');
  });
});

When finished, we create the class ContactManagementPage /e2e/src/pageobjects/contact-management.po.ts, as assumed in the e2e-test.

Test fails! Now the test compiles, but fails as expected.

We start implementing the page object´s navigateTo-method, which navigates to the contact management view. In our case it is the root content “/”.

Next we need the names of all listed contacts. At this point, we define that the view contains HTML-elements of the class “contact”, which again contains elements of the class “name”.

We implement #shownNamesOfContacts by getting these elements and map their text values.

Protractor works asynchronous with its own Promise class. We have to make sure to import and use the right Promise-Class of the Protractor library.

import {browser, by, element, ElementArrayFinder, ElementFinder, promise} from 'protractor';
import Promise = promise.Promise;

export class ContactManagementPage {
  navigateTo() {
    browser.get('/');
  }

  shownNamesOfContacts(): Promise<string[]> {
    return this.contactNameItems().map(contactNameItem => contactNameItem.getText());
  }

  private contactNameItems(): ElementArrayFinder {
    return element.all(by.css('.contact .name'));
  }
}

Test fails! The test fails with the hint that no Angular application could be found. Currently no angular component gets bootstrapped.

To fix that issue we next create an Angular component “contact-list” with the Angular CLI.

ng generate component contact-list

It is automatically assigned to the global a_pp-module_ and declared within it. So far that´s ok for this tutorial, but we also have to integrate the component in our index.html and configure our module to bootstrap the component.

Test fails! The e2e-test still fails, but this time as intended by not fulfilling the expectations of the test.

Implementing the component

First the component should display a list of items per contact.

We create a test case in the contact-list.component.spec which was generated by the Angular CLI. While writing it, we again assume all dependencies already exist.

it('should display an element for each contact', function () {
  component.contacts = [new Contact('DummyContact'), new Contact('DummyContact2')];
  fixture.detectChanges();

  const contactElements: NodeList = fixture.nativeElement.querySelectorAll('.contact');

  expect(contactElements.length).toBe(2);
});

The code does not compile. We need a data structure „Contact“ and a property „contacts“ in the component´s controller contact-list.components.ts which provides the contacts_._

We create the class Klasse /model/contact.ts

export class Contact {
  constructor(public name: string) {
  }
}

and extend the controller by the property contacts: Contact[].

Test fails! This time we start the karma test server and runner with ng testand watch the written test failing, because we expect two contact elements that are currently no displayed.

We keep karma running and so get instant feedback about our changes and their impact on the behavior.

To display an item for each contact, we extend the view contact-list.component.html.

<div>
  <ul>
    <li *ngFor="let contact of contacts" class="contact"></li>
  </ul>
</div>

Test succeeds! The test succeeds!

So far, now we want to display the contact´s names.

it('a contact element should display the contact´s name', function () {
  const contact = new Contact('SomeName');
  component.contacts = [contact];

  fixture.detectChanges();

  const nameElement: HTMLElement = fixture.nativeElement.querySelector('.contact .name');
  expect(nameElement).not.toBeNull();
  expect(nameElement.textContent).toEqual(contact.name);
});

Test fails! As expected the test fails.

We make the list to display the name.

<div>
  <ul>
    <li *ngFor="let contact of contacts" class="contact">
      <span class="name">{{contact.name}}</span>
    </li>
  </ul>
</div>

Test succeeds! Our component now displays the contact´s names.

Are we finished? We have a look at the e2e-tests.

Test fails! They still fail. We expect “Max” and “Moritz” to be listed initially.

We want our component to initially contain the contacts “Max” and “Moritz”.

it('should initially display the contacts "Max" and "Moritz"', function () {
  const nameElements: NodeList = fixture.nativeElement.querySelectorAll('.contact .name');
  const names: string[]  = Array.from(nameElements, nameElement => nameElement.textContent);
  expect(names).toContain("Max");
  expect(names).toContain("Moritz");
});

Test fails! Now we also have a failing component test.

We initialize the controller´s contact-property with that contacts.

Test succeeds! All component tests succeeds!

Test succeeds! Now the e2e-test is also green and the implementation of the story is done!

Contact Management

√ should show a list of contacts, initially containing “Max” and “Moritz”

Further development

Now our skeleton walks and we can continue with further development.

Possible next steps could be:

Refactoring: Extraction and delegation of the contact-list-specific content to its own page object to keep the contact-page-object clean and to reuse it in other tests.
Story: Creation of new contacts
- Creating a new contact by entering its name in a textfield followed by pressing the enter-button
- when a new contact is created, the textfield should be cleared
Optimization: Managing the data in a Redux-store

Conclusion

Frameworks like Jasmine, Karma or Protractor support test driven development of web applications very well.

In case of Angular, projects created by the Angular CLI are already preconfigured with Jasmin, Karma and Protractor and out of the box can be developed driven by tests.

So TDD is also for web applications a very good methodology to create tested and well designed source code on a very high quality level.

In combination with other methodologies like pair programming and clean coding, nice synergy effect arise to develop and maintain complex applications in an effective and efficient way.

The post Tutorial: Developing an angular app driven by tests appeared first on maimArt.

Test strategies when developing redux stores in angular apps driven by tests (reworked and extended)

Martin Maier — Tue, 24 Jul 2018 10:04:59 +0000

I generally develop angular applications driven by tests.
That works well, but when using redux in my projects (currently ngrx, but also angular/redux), there are several different aspects to consider when testing and developing stores and feature/fractal-stores, driven by tests.

Intend

The issue is to find a good strategy to test and develop driven by tests.

There are e2e-tests, integration tests and unit tests, where last ones mostly tests static functions and static reactive variables in this context.

My main intend is to drive the development by tests from an integration level of stores and substores, down to the single components of the stores.

I want to be able to initially develop the store without integration in the rest of the angular application.

So scenarios where migrating from a non-redux data management or migrating from one redux framework to another can be done smoothly without a big bang.

Different perspectives and strategies

I tried different strategies of different perspectives.

When writing about store´s components i mean its reducers, effects, actions and action creators.

For me selectors are not parts of a store, but rather convenience functions that helps to access subsets of its state.

1. Treat the store and its components as a whole

When we treat the store´s components as just outsourced functions and variables of an holistic store, it is sufficient to test them integrated within encapsulating stores.

+ technical functionality of a store is specified in a whole

+ stores are explicitly tested as one integrated component, so their functionality is not just ensured in the e2e-tests

+ the direct effects and side effects of actions are specified at one single point.

- encapsulation into a store is only fictive. In practice there is no explicit class for each store, there is just one big store object.

- it is a very object orientated perspective in a more functional world

- can lead to very comprehensive integration test suites

- no “real” unit tests

2. Treat the store´s components strictly as separate components that are tested isolated

We treat the store´s components as separate and completely independent components and test them isolated.

+ small, lean test suites focusing on the respective functions and reactive variables

+ impact of actions is specified separately to the responsibility of the different components

+ real unit tests

- the interaction of the different components is just tested in the e2e-tests

- the specification of the actions´ impact is spread into multiple test suites

- the high cohesion of the store´s components is only seen in the file structure and their configuration within the ng modules

3. Treat the store´s components as separate components that are tested separate, but integrated.

We treat the store´s components as separate components, test them also separately, but integrated in stores.

+ small, lean tests focusing on the respective functions and reactive variables

+ impact of actions is specified separated to the responsibility of the different components

+ components of stores are tested integrated, so their functionality is not just ensured in the e2e-tests

+ the belonging to a specific store is also seen in the integration tests

- the specification of the actions´ impact is spread into multiple specs

- on first look on the spec name seems so be unit tests, but are integration tests

- no “real” unit tests

4. Treat the store and its components as a whole that is developed and tested depending on its actions

We treat the store and its components as a whole, develop and test them driven by its actions.

This perspective is similar to the first one, but orientates a bit more at the core concept and idea of Redux and also enables a better substructuring.

The thought is that in Redux and its stores is all about actions.

Actions are fired to change data and to trigger side effects which in turn trigger services. All the behavior is driven by actions.

So in this approach the tests are structured depending on the actions. Whereby the actions are tested integrated in the store.

In more complex stores, actions should be grouped to different kinds of actions and there should be one test suite for each group.

Tests of actions with simple behavior, such as only manipulating the state, can be specified directly on the top level of the test suite.

Tests of actions that leads to some more complex behavior should be substructured in nested test suites.

+ all impact of an action is specified and tested at one single point, not spread on the tests of the different technical components

+ technical functionality of a store is specified in a whole

+ stores are explicitly tested as one integrated component, so their functionality is not just ensured in the e2e-tests

- no "real" unit tests

Conclusion

First i started with a mix of the first and second approach, but soon the redundancy between the store´s integration test and the tests of its single components led me to hold on and to rethink about my perspective and this approach.

My second thought was to treat the components of the stores as just outsourced functions and reactive variables and to only test them encapsulated in the integration tests anymore.

Not to unit test the stores´ components still felt a bit uncommon, but the test driven development of the redux store now felt really good.

Furthermore because of structuring the tests in nested suits for every action, the output of the tests was also really nice. I saw at a glance what effects and side effects every action triggers.

But at least when i extended the store with multiple different kinds of side effects the integration test became much to big.

The second approach i just evaluated in theory, because for TDD i missed the integration test and also this would end up in a big bang, especially in the migration scenarios.

For some time the third approach felt as a good compromise and i think it is a good approach, but it still bothered me that the behavior of an action is spread on the different tests of the store´s components.

The test driven development and readability of the tests still did not feel fluent and continuous.

So finally i ended up with the last approach, where the development is driven by the actions and tests a structured depending on them. In Redux all is about the actions and in this approach the tests are too.

I would be very glad to read about your opinions and approaches to this issue.

The post Test strategies when developing redux stores in angular apps driven by tests appeared first on maimArt.

Replicate immutable data in typescript with the ReplicationBuilder

Martin Maier — Mon, 16 Jul 2018 14:33:00 +0000

The ReplicationBuilder is a typescript tool to clone immutable data objects in a typesafe, refactorable and well readable way.

In our single page applications we often use different implementations of redux to handle our application state.

The more complex the data structures become, the more complex becomes the code that handles the immutable states when using Object.assign() or something like that.

Therefore this often ends up in code that is really hard to read and maintain.

So my intention was to create a tool that can handle immutable data in a typesafe, refactorable and well readable way.

The powerful keyof-feature introduced in Typescript 2.1 to lookup for objects properties in a typesafe way helped me a lot to solve that.

The result i called ReplicationBuilder and is a typesafe, fluent API to build replications of an object.

Together with some other small helpers its published in the npm package "typescript-immutable-helper".

The source code is hosted on GitHub Repository

I would be glad for some feedback or if you want to constribute.

Syntax

simply replace property by with new value

return ReplicationBuilder.forObject(state).property('party')
   .replaceValueOf('name').with('MyParty')
   .build()

replace property depending on old value

return ReplicationBuilder.forObject(state).property('party')
   .replaceValueOf('partymemberArray').by((oldPartymemberArray) => [...oldPartymemberArray, 'new partymember'])
   .build()

clone property and apply some function on it

return ReplicationBuilder.forObject(state)
   .replaceValueOf('party').withCloneAndDo((clonedParty) => clonedParty.addPartyMember('new partymember'))
   .build()

Characteristics

typesafe properties

typesafe property values

chainable

return ReplicationBuilder.forObject(state)
    .property('party').replaceValueOf('name').with('MyParty').replaceValueOf('members').by((members) => [...members, newMember])
    .property('initiator').replaceValueOf('prename').with('Party').replaceValueOf('surname').with('guy')
    .build();

refactorable and easy to read

Usage

Load an object by calling ReplicationBuilder.forObject()
Navigate down the object tree through the typesafe function property()
Modify a property with either (see syntax paragraph above)
- replaceValueOf('prop').with(newValue:T)
- replaceValueOf('prop').by((T) => newValue:T)
- replaceValueOf('prop').withCloneAndDo((clonedProp) => clonedProp.doSomething()
- removeProperty('prop') to remove the property in the resulting object
Repeat step 3 and 4 until all modifications are done
Produce the replica with build()

Behaviour

deep copies the source object
freeze in --> freeze out. If the source object was frozen (for detecting manipulations while development), then the produced replica will also be deep frozen.
warning if source object is not deep frozen (produced replica will be deep frozen)

Demo

originally posted on http://maimart.de

Architecture of a JavaFX application

Martin Maier — Sat, 24 Mar 2018 19:04:13 +0000

Introduction

I am developing JavaFX applications for about 5 years now and used different architecture patterns for it.

First i started with MVC, then MVVM and lastly we used MVP passive view in my current project.

The way how to apply the MVC pattern is described well in the JavaFX documentation, MVVM is described well in the documentation of the mvvmFX framework, but for the MVP Passive View i spent a lot of time reading different articles about it, but i didn´t find the way that feels 100% right for me.

Futhermore i didn´t find a satisfying article about how to coordinate the different views built with the MVP pattern.

So i evaluated different ways of creating a complex JavaFX UI with views following the MVP Passive View pattern and how to coordinate them.

My focus was:

to avoid bidirectional dependencies between view and presenter
find the best way to manage the domain-specific properties for the views
parent components attach child components
workflow controllers access the components.
how and where to comunicate with the backend

So i came to following conclusion that feels good for me.

Structure of a ui component

Simple ui component with few view property bindings

Component Module

The whole component is bound in a context that manages the dependencies. I used guice so there is a private guice module that manages the internal dependencies.

More global modules that use this module have to ensure that all dependencies needed by the presenter are provided.

Presenter

The main purpose of the presenter is to provide domain-specific properties the view can bind on and to provide methods the view can straight delegate to.

It is responsible what information is shown, not how.

The presenter must not hold business logic, only logic about adapting between view and business logic.

The presenter does not know the view.

public class Presenter { private final StringProperty someString = new SimpleStringProperty(); void doSomething() { // not implemented yet } StringProperty someStringProperty() { return someString; } }

View

The view is responsible for how information is shown.

The view is am humble object. It does only three things:

provide a package-private factory method
bind the properties of the controls to the presenter´s properties and delegates the control´s actions to the presenter within the initialize method
provide its root node by a public methods

public class View { @FXML private StackPane root; @FXML private Label label; @FXML private Button button; private final Presenter presenter; private View(Presenter presenter) { this.presenter = presenter; } static View createInstance(Presenter presenter) { View view = new View(presenter); FXMLLoader.load("....", view); return view; } @FXML void initialize(){ label.textProperty().bind(presenter.someStringProperty()); button.setOnAction(event -\> presenter.doSomething()); } public Node getRootNode() { return root; } }

More complex ui component with several view property bindings

To keep the presenter clean, we outsource the view properties to a kind of view model.

The view model is only a helper class for the view and the presenter, so its access level only needs to be package-private.

Nested ui components

Nest a ui component as a child ui component (1:1 nesting)

If you want to nest a child view you need to install its module in the parent´s module.

So you can simply inject the exposed view of the child component into the factory method of the parent´s view.

If necessary it´s presenter can directly injected in the parent´s presenter.

Nest a component as a kind of control (1:n nesting)

Basicly i think a custom control should not be treated as a view and so not be implemented with the MVP pattern.

There would be a solution to handle that case this way:

the presenter of such a “control component” must be accessed through the view itself, not exposed by the module
the module´s provider of the view must be injected into the parent view
the parent view must care about instanciating child views/controls and to propagate it to its own presenter, that connects view logic

But as you see the MVP pattern is inappropriate for this typical use case of injecting custom control, so i won´t dive deeper into this case.

Coordination of the ui components

A user always has a reason for using an interface of a system. So applications base on use cases.

The realization of those uses cases are projected in some abstract objects that i call workflow controller.

There are different concepts and names for it, but in common they build the context of a use case or workflow and there purpose is to keep control of the workflow on a very abstract level.

In the ui layer their responsibility is to coordinate and orchestrate ui components, to build a context in which they interact with each other and how they interact with the backend.

Depending on the complexity of the ui and the use cases, in many cases they will not control the ui components directly but abstracted by some helping components of different responsibilities.

To keep the worklow controller decoupled from the presenter, the access to the presenters should be abstracted by a functional interface that is implemented by the presenter and used by the workflow controler.

The callback from the presenter to the workflow controller can be implemented either by injecting a callback function to the presenter, attaching listers to its properties or letting the presenter fire events that are catched by the workflow controller.

Another idea would be to handle the communication between the worklow controller and presenter through a task specific model that holds properties and callback functions.

But in my opinion an interface is more object orientated and it is much harder to keep a model clean and independent from the workflow and the presenter stuff than an interface.

So the presenter from above could look like:

public class Presenter implements WorkflowTask{ private final StringProperty someString = new SimpleStringProperty(); private Consumer\<String\> onDoSomething; @Override public void showSomeString(String string) { someString.set(string); } @Override public void setOnDoSomething(Consumer\<String\> onDoSomething) { this.onDoSomething = onDoSomething; } void doSomething() { onDoSomething.accept(someString.get()); } StringProperty someStringProperty() { return someString; } }

Interaction with the backend

The workflow controllers treat the interaction with the the backend.

For reasons of testability i prefer to use a service class that internally delegates to a fx service and returns a CompletableFuture to its clients.

If you are interessted in Angular and AWS read my article about how to push an angular spa to the cloud

The post Architecture of a JavaFX application appeared first on maimArt.