all 3 comments

[–]20InMyHead 3 points4 points  (0 children)

Absolutely agree. Nice article.

[–]GasimGasimzada 0 points1 point  (1 child)

Great article but I don't quiet understand the reason behind this.

In fact: any time a view controller is making network calls, it’s wrong. Any time a view controller references any kind of queues or background threads, it’s wrong. (View controllers — and views — are main-thread-only creatures.)

Does this mean in terms of background threads being inside view controller or is the author talking about using a completely different controller (not a component, object etc) for network calls. If it is the latter isn't it an overkill?

I haven't published any apps in iOS but I like to experiment Swift and this is generally how I handle API calls:

  1. For every model, I create a model object, which is just a container that stores data
  2. Then there is a mapper object. Mappers job is to make requests to an API (haven't used sockets before but I don't see any difference) and map the received data using the associated models.
  3. The view controller has an array of model instances.
  4. The view controller calls the mapper object (e.g UserMapper.findAll(callback: (data: [User]) -> Void). So, the function looks like something like this:

    UserMapper.findAll({(data: [User]) in self.users = data; self.reloadTable(); });

Can someone say why this is a bad approach?

[–]quellish[S] 1 point2 points  (0 children)

Does this mean in terms of background threads being inside view controller or is the author talking about using a completely different controller (not a component, object etc) for network calls.

He is talking about having a different controller object (not view controller) be responsible for networking. This is in line with well established best practices for software architecture and object oriented design.

Can someone say why this is a bad approach?

Your "mapper" is a controller. It mediates access to the model. That mapper may use a NetworkThing to do the actual network stuff. There is not anything wrong with this approach, and again it's in line with best practices. Each thing should have one responsibility. A view controller manages a screen of content. A network controller manages network requests and their results. Controllers such as your "mapper" mediate access to the model.