The Domain layer (An iOS architecture part IV)

The aim of this post is just to explain how to organise the domain layer in an architecture. A possible definition of domain layer is where the application business logic is implemented, or the told in the contrary way what is nor view neither data acquisition.

The domain layer is the fuzzy invisible border between View and Data layer. But as app grows in complexity (and in lines of code) is the cornerstone of your development, so this is why is important to have this layer under control.

Components

Sequencer

The sequencer is the component that will handle the start up sequence, this is something thats starts very simple at the beginning of the implementation, but as time (and requirements) goes on could turn into a really nightmare 🎃. You can find the implementation details in the following post.

Managers

Managers is the wrapper class for accessing to a unique device services like bluetooth, maps, gyroscope… Or in case that you wanted  to centralize a behaviour in a single class, for instance, a Session Manager for controlling wether a user was logged properly or not. This class is a singleton implementation.

Up to here this is good about this component. But watch out, to start abusing them! Is quite common that will start appear singletons as mushrooms. I recommend to read the following post.

Use Cases

Use cases functions are the entry point for any functionality requested by views.  The reason for living of this component lies in:

  • Unload task from views. Helps to reduce Massive View Controllers problem.
  • Reusability. Is likely that you use the same functionality from different views.
  • TDD. You can apply unit test to this function class.

Coordinators

Coordinators controls the flow of screens presented, is the coordinator who decides which is the next screen to present, not the view any longer…

This will help to reduce the amount of code to put in the view, and also its reusability, the same view can be placed in a totally different screen flow.

Use cases and coordinators working together but not mixed

Presenters interacts with use cases when some functionality has to be performed (e.g request data from a service, try to connect to a bluetooth device, get a map pinpoints,…). But in case that presenter considers that is no more longer usable (e.g. user select dismiss button to remove the view, or selected an item for pushing another view with the item details) it has to interact with the coordinator and will be the coordinator who will decide  which is the next view to present.

Conclusion

In this post we have reviewed which is the role of Domain layer and its components.

What’s next

In the next post will be presented the Data Layer and how to retrieve data independently where is phicially stored (ddbb, service, keychain, user defaults… ).

     

Swifting a Mock Server (with Vapor)

The aim of this post is put up the level of previous post (Testing at the edge of your App with a Mock Server), just by using Vapor (a swift backend framework) and deploying server with Heroku (a cloud platform that lets companies build, deliver, monitor and scale apps).

Setup the environment

Vapor

For installing vapor backend framework just:

For creating a new vapor project, afterwards create a new git repository with the stuff generated and finally open the project:

Up to this point you will have XCode with new project:

stp

Run the project, open your favourite browser and type the url http://localhost:8080

browser

Mock server is working on local ?. Ready for getting to next level? ?

Heroku

If you do not have an account just sign up here. Later on, download Heroku command line tools, for validating installation just type (restart computer if necessary).

….finally after several minutes the mock server is deployed on a remote site, just type https://mock-vapor.herokuapp.com/ in your browser.

browser2

Implementing a dummy service

Our mock server will return .json, first thing to do is setting  content-type.  Just update View.swift extension:

Validate with any rest analyzer:

post

Adding basic fixer answer. This is what our mock servier will answer:

latest_FORCE_BUSINESS_ERROR is just a json template file.

The client App

The client app will be exactly the same presented in previous post, but obviously replacing urls.n In this case we will use three schemas:

  • Local mock server. For debugging with local mock server.
  • Remote mock server. For working with common development mock server.
  • Fixer real server. For working with final service.

Select Local mock server schema and launch the test:

tr

Deploy the mock server

At the moment there is nothing by typing https://mock-vapor.herokuapp.com/latest in the remote server:before

For deploying just push changes:push

This process can take several minutes… ?

push2

But finally we have the remote with latest, at this moment, just type: https://mock-vapor.herokuapp.com/latest. The remote server is ready!

after

Switch mock remote server

Switch oclient Mock Server Schema to lauch the tests on the client, but this time bouncing to a remote mock server.

rs

Conclusion

With this post you have seen how to deploy a remote mock server. You can use this server as a test platform or you could develop your app backend. If you were interested in investigating more you can fetch source code from here.

Useful links

     

Testing at the edge of your App with a Mock Server

The aim of this post is to just present how to build a simple mock server for validating the service calls on your iOS app with unit tests. The components that contains the service calls are at the edge our app and usually are not validated mostly because it is assumed that api is working fine, but this is not always true…

 

The mock server will respond with a controlled response and will also help you to simulate several error status responses or even delays on answers. Android and Windows phone platforms can also take profit on it.  The server will be implemented in node.js, but do not get scared, there is no need a lot of knowledge on this technology.

The server is mocking fixer public API service, and in concrete the following rest API http://api.fixer.io/latest?base=USD

What’s node.js?

Node.js is an open-source, cross-platform Javascript runtime environment for developing a diverse variety of tools and applications. For installing on your mac just type the following commands in your terminal:

Express  is a web application framework for Node, this will facilitate our task for developing our http server. For writing code, there are many text editors (sublime2atom,…) , but I recommend Visual Studio Code (VSC) because it allows you to debug the code.

The mock server

With VSC just open localMockServer folder, go to debug and press the play button.

vsc

Open your internet browser and type http://localhost:3080/latest in the url, if mock server was started well you should have to see something like this:

resp

Developing iOS service component

Once we have an answer from the server let start to develop the iOS service component. For doing that we will create a simple single view app, please do not forget include support for unit testing.

sva

For network service support I will use Alamofire pod, this is what it was AFNetworking in Objective-C.

For switching between real Fixer server and our mock server I will create a new schema and inside it I will define an environment variable for controlling which baseURL hast to be returned.

sch

baseURL attribute will be calculated in the following way:

Remember, from now on we will work with mock server so switch to FixerClient-MockServer schema.

sch2

The service implementation is the following:

The second function parameter is optional and only will be used for notifying server which test scenario we want to run. At the moment there are two error test cases, one for reproduce a server error and another for reproducing a business error (json with unexpected structure basically).

Unit testing our iOS app service component

The unit test implementation for forcing business error is the following:

After the rest of unit tests implementation just launch the test:

te

 

Conclusion

With the mock server all your business layer can be validated using unit testing and will isolate your development from backend. For doing this sample project I have used cocoapods 1.1.1 and XCode 8.1. You can download the code here.

Links

     

Validating View Controllers with Quick and Nimble

On arriving  UI automated testing in XCode 7 developers had a great tool for automatically validate our apps.  But as our test suite starts growing we start facing some inconveniences.

By using accessibility interface you cannot validate view controller attributes, for instance validate if you got the right number of cells in a collection. Another problem that I faced was at time of refactoring test cycles took to long.

I strongly believe in testing, but dealing with such inconveniences  pushed me to search for another iOS test frameworks. After watching some videos and hearing about them in some conferences I decided to investigate about validating view Controllers with Quick and Nimble.

The aim of this post is just show how to setup Quick and Nimble test frameworks and play a little bit with them.

Quick and Nimble

Quick is a BDD testing frakework that is almost the same as XCTest, but with the additional focus on describing your intent and why you are testing parts of your code.

Nimble allows you to express expectations using a natural, easily understood language.

Environment

I have found some difficulties downloading sample projects with the framework integrated. So at the time of writing this posts the XCode that I am using is 7.3.1 and the Podfile content is the following:

View controller undertest

The view controller under test shows a collection of Gremlins with a search bar that will allow to filter them by name.

Simulator Screen Shot 31 Jul 2016 00.33.15

 

Test are implemented as a regular UN test, so adding a new test is just adding a new UN test file:

projfiles

untest

As was mentioned before test are implemented as BDD test structure changes a little bit but do not get scared. Lets start  testing the view controller title:

First thing to do is import Quick and Nimble and extend our test class from QuickSpec. beforeEach is the chunk of code that will be execute before each test. Tests itself are implemented by specifying with it.

Another important issue is the call controller.beginAppearanceTransition before each test, this execute viewcontroller lifecycle calls before executing test.

Now lets launch test:

redtogreen

But remember we have to move from red to green. Now, just set the expected title string name and re-run the tests.

The first impression that you experiment with this framework is how easy and fast is execute a battery of test. An how easy is get into view controller internal attributes and methods for validating what is going on.

Let’s test that collection view can show all the expected gremlins

The view controller by default will show a hardcoded set of gremlins for better understanding, but that is not the real case scenario. For validating that the first that we do is just validate that the number of items that can see the collection view are 13, and afterwards we inject an array of 3 items for validating that the new number of items that can see the collection view now is different:

Lets look for more gremlins

But the view controller also allows us search gremlins by name, now lets validate that this functionallity is really working:

An important issue that I want to mention at that point is that or view controller hides the search bar when there are no items. This is very easy to do with this framework, just check .hidden attribute from search bar and that’s all!.

You can download the sample project used in this post here.

Conclusions

With Quick and Nimble you can run a test suit very quickly and this is great for refactoring. On the other hand is direct to have access to view controller internal stuff, this will save you lines of code and execution time on UI testing. So Quick and Nimble is a great alternative to unload test stuff from UI testsuite.

gizmo

Useful links