Skip to content

Latest commit

History

38 Commits

Folders and files

NameName
Last commit message
Last commit date

Repository files navigation

☔️ Weather App

11.08.2021 ~ 16.08.2021

Design Pattern

design-pattern

Interactor — contains business logic related to the data (Entities) or networking, like creating new instances of entities or fetching them from the server. For those purposes you’ll use some Services and Managers which are not considered as a part of VIPER module but rather an external dependency.

Presenter — contains the UI related (but UIKit independent) business logic, invokes methods on the Interactor.

Entities — your plain data objects, not the data access layer, because that is a responsibility of the Interactor.

Router — responsible for the segues between the VIPER modules.

In this project, I used view models to tranform lots of data from the model and inject information to the view directly.

The VIPER architecture is based on the single responsibility principle (S.O.L.I.D.) which leads us to the theory of a clean architecture.

Using this architecture one can easily test at the boundaries between each layers. One feature, one module. For each module VIPER has five (sometimes six) different classes with distinct roles. VIPER makes the code easier to isolate dependencies and to test the interactions at the boundaries between layers.

Structure

2

10

3

4

5

6

7

8

API

5 day weather forecast documentation

Weather conditions documentation

API Example

Consideration

For the SOLID Principle(Dependency Inversion Principle), Should I write the code like below?

protocolNetworkRequest:AnyObject{associatedtypeModelTypefunc decode(_ data:Data)->ModelType?func load(withCompletion completion:@escaping(ModelType?)->Void)}extensionNetworkRequest{fileprivatefunc load(_ url:URL, withCompletion completion:@escaping(ModelType?)->Void){letsession=URLSession(configuration:.default, delegate:nil, delegateQueue:.main)lettask= session.dataTask(with: url, completionHandler:{[weak self](data:Data?, response:URLResponse?, error:Error?)->Voidinguard error ==nilelse{returncompletion(nil)}guardlet header = response as?HTTPURLResponse,(200..<300)~= header.statusCode else{returncompletion(nil)}guardlet data = data else{returncompletion(nil)}completion(self?.decode(data))})
task.resume()}}protocolAPIResource{associatedtypeModelType:Decodablevarlatitude:String{get}varlongitude:String{get}}extensionAPIResource{varurl:URL{letbaseURL="https://api.openweathermap.org/data/2.5/forecast"letAPI_KEY=""varurlComponent=URLComponents(string: baseURL)
urlComponent?.queryItems =[URLQueryItem(name:"APPID", value:"\(API_KEY)"),URLQueryItem(name:"lat", value:"\(latitude)"),URLQueryItem(name:"lon", value:"\(longitude)"),URLQueryItem(name:"units", value:"metric")]return(urlComponent?.url)!
}}structWeatherResource:APIResource{typealiasModelType=WeatherResponseletlongitude:Stringletlatitude:String}classAPIRequest<Resource:APIResource>{letresource:Resourceinit(resource:Resource){self.resource = resource
}}extensionAPIRequest:NetworkRequest{func decode(_ data:Data)->(Resource.ModelType)?{do{letresult=tryJSONDecoder().decode(WeatherResponse.self, from: data)return result as?Resource.ModelType}catch{returnnil}}func load(withCompletion completion:@escaping(Resource.ModelType?)->Void){load(resource.url, withCompletion: completion)}}

Git Commit Message Guide

  • feat: A new feature
  • fix: A bug fix
  • docs: Changes to documentation
  • style: Formatting, missing semi colons, etc; no code change
  • refactor: Refactoring production code
  • test: Adding tests, refactoring test; no production code change
  • chore: Updating build tasks, package manager configs, etc; no production code change

Third-Party Libraries

After Code Review

  1. Indiscriminate use of Singleton is not good.
  2. If I use local data, it is better to use it actively than to try to reduce its use.
  3. I should also consider the possibility that data may be different in the process of saving it to local data. Therefore, if there is information to be brought from local data, it is better to bring all the information that way.
  4. It is more effective to use observer than to use viewWillAppear.
  5. If I think I don't need to use lazy var, I don't need to use it.
  6. I need to think more about the effective method to implement something.

About

☔️ Minimalist weather app with VIPER design pattern + Unit Test + Realm / 👨‍💻French company coding assignment

Topics

Resources

Stars

11 stars

Watchers

1 watching

Forks

Used by

Contributors

Languages