Repository files navigation

11.08.2021 ~ 16.08.2021

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 usedview 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.

5 day weather forecast documentation

Weather conditions documentation

API Example

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= responseas?HTTPURLResponse,(200..<300)~= header.statusCodeelse{returncompletion(nil)}guardlet data= dataelse{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 resultas?Resource.ModelType}catch{returnnil}}func load(withCompletion completion:@escaping(Resource.ModelType?)->Void){load(resource.url, withCompletion: completion)}}

• 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

• Database:Realm
• Tool:Then

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.