Reusable component with web service

Question

I am trying to create a reusable component / Cocoa Touch Framework in Swift that would display the current weather based on the user’s location.

Right now I cannot decide which approach should I take.

First approach: A custom UIView that displays the weather and forecast information. And inside this UIView is the logic of downloading the data from a weather API. What this does is that the component is readily usable since you only need to provide the API key and need not to write your code for downloading the data.

Second approach: A custom UIView that displays the weather and forecast information. This is only UI and no logic is written inside. No model, no data download. Basically the idea for this approach is so that you can reuse this view with another web service. So you download your data separately, say in your view controller. Then just pass in the values to the custom UIView.

What would be generally better if having a “reusable weather view” is what we are tryin to achieve? A reusable framework that can be in Cocoapods and be reused by other developers too.

Answer 1

Since your goal is to have a reusable component, I would advocate the use of second approach.

Additionally, going with the second approach - you should think about your view in isolation and the data it needs (and the structure in which you should provide that data to your component). It shouldn't be dependent on the structure in which the API provides the data but should make the most sense for your view.

This is mainly because fetching the data is business logic, and not UI Logic. Here's a nice SO question about where business logic in MVC pattern should go.

In general, you want to put only the logic which deals with the presentation along with your UI (logic to handle events, etc)

A few benefits of second approach over the first

1. Your data source might change, or you might have to use multiple data sources and aggregate their information.
2. Rest of your code might need access to the API too. Either your component would end up depending on code in rest of your application to make its API calls, or you would end up duplicating the logic which would come back to bite you when API changes in a non-backwards-compatible way.
3. Your code outside the component might need the data
4. You or a designer would be able to work on the UI alone using mock data, without having to worry about anything but UI.

The only upside I see to the first approach is that it's quick and doesn't require you to add another layer of abstraction (the interface between UI and data source), but this isn't the way to go since we want reusability.

---

^{Note: I've not particularly worked with cocoa touch framework but I've tried to answer in a framework-agnostic way altogether, based on my experience with working with other MVC UI frameworks}

Answer 2

Based on MVC design principles, which are generally encouraged in Cocoa Touch development, you should probably go with the second approach.

Basically, in MVC, the app (or some sub-component of the app) is broken into three parts: the View contains visual information, the Model contains information about data, and the Controller manages communication between the model and the view.

That fits into your situation like this: your custom UIView is the View, and only displays weather information. It knows nothing about downloading or processing this data. Your Controller, probably a UIViewController subclass, downloads the data and provides it to the View, possibly processing the data or removing unnecessary parts. It knows nothing about pixels, or colors, or any visual information.

This way, once your app is finished it will be modular. Say you want to update your colors to make them look nicer. Then change your UIView subclass and ignore the controller. Or if you want to change the API. Change the controller, don't worry about the view. If you took the first approach, both changes would lead you to the same file, which itself would probably be bigger and messier, taking you more time to update the code.

That's the real advantage of MVC: when you go back to it to change the code in the future, it's a lot easier and clearer.