Latest 0.6.2
Homepage https://github.com/WINKgroup/WinkKit
License MIT
Platforms ios 10.0
Dependencies Alamofire, AlamofireImage, Argo, Runes, Curry, DateTools
Frameworks UIKit, Foundation
Authors

An iOS framework that contains a set of classes that solve some common problem written in Swift, used for Wink’s application. Follow this guide to know how to structure a Wink iOS project.

Getting Started

Prerequisites

You need Xcode 9, Swift 4 and CocoaPods installed.

Installing

Just paste the CocoaPods dependency in your podfile

# Podfile
use_frameworks!

target 'YOUR_TARGET_NAME' do
    pod 'WinkKit'
end

Understanding Structure

Before talking about classes of framework we’ll take a look on architecture structure.

It is a kind of VIPER pattern; look at this iOS Architectures overview to understand differences between MVC, MVP, MVVM, VIPER.

A Wink iOS project should be structured in the following way, expecially if the project will grow a lot:

Arch diagram

This kind of architecture is try to follow the Responsability Distribution concept: each layer exists without other ones and every component has different responsability; this improves the maintanance and the testability. The whole Xcode proj structure that maps this architecture is something like this:

Presentation

It’s the layer that contains all iOS Framework dedicated classes, like UIKit framework. We could say that this layer cannot exists without an iPhone/iPad because UIKit can run only there.

  • AppDelegate: It’s the well known AppDelegate class, nothing special;
  • Use Cases: A group that contains all use cases. It’s important to understand that a Use Case is what user do in one or more app screen, for example the Login.
    • Login: En example of a Use Case. It will contain all related ViewControllers, Presenter (if a use case contains more than one), DataSources etc.
      • LoginPresenter: A simple presenter; LoginPresenter keep the state of LoginViewController; a presenter is the class that contains logic, the ViewController does not contain logic. Presenter doesn’t contains UIKit classes!, this is needed to keep presenters easy testable.
      • LoginViewController: In classic MVC pattern, (Massive View Controller in iOS world 😫) all logic was here, mixed with the view handling; in this framework a ViewController owns a presenter and delegates it for the logic. The view controller doesn’t have a method func performLogin(email: String, password: String) for example; instead, the presenter does. The view controller will only receive user input and tell the presenter that something happened. The presenter will do work and tell the view controller that the view should change.
  • Core: A group that contains base classes re-usable all around project. It’s a good practice to define this classes to avoid code duplication that could increase the maintanance difficulty.
  • Models: Contains all model classes that are used only in the presentation layer.
  • Resources: All resources go here, included .xcassets, custom fonts…

Data

It’s the layer that handles all data stuff, such as http calls, cache uploading/downloading to/from a backend. No UIKit classes in this layer!

  • Cache: A group that contains classes like SessionManager and all other stuff that saves data locally.
  • Networking: The group that contains the Http Client, which must be implemented with Alamofire. WinkKit provides Alamofire and Alamofire Image in the framework itself, so you don’t need to add anything in the Podfile.
    • ResponseSerialization: Contains the DataResponse extension of Alamofire: it provides a common response for http calls that return an object instead of a json; json parsing is done in this extension (see source file for detail). Notice that this extension uses Argo for json parsing.
    • Resource: and enum that maps the response of https calls.
    • Error: the class/struct that maps http errors (both client and server)
    • Routers: Routers are responsible to know api’s endpoints and to create a urlRequest that are used by Services to perform http calls.
    • Services: Services perform http calls, using the request created by routers.
    • Models: Simple classes/structs that maps the server json response.

Domain

It’s layer in which there is business logic; it’s a kind of bridge that connect Presentation and Data layers without without couple them. No UIKit classes in this layer!

Here you’ll put interactors that contain all business logic; presenters use this interactor to communicate with data layer.

Authors

Rico CrescenzioLinkedin

License

This project is licensed under the MIT License – see the LICENSE.md file for details

Latest podspec

{
    "name": "WinkKit",
    "version": "0.6.2",
    "summary": "Base UIKit classes with more features and MVP/Viper implementation.",
    "description": "This framework have a set of UIKit subclasses to improve their implementation; nit has been written to create a guideline for Wink's projects and to have some commonnbehaviours: for example `UIView` is sublcassed to provide more control in InterfaceBuilder.nMorover, it follows a kind of MVP/Viper architecture implementation.",
    "homepage": "https://github.com/WINKgroup/WinkKit",
    "license": {
        "type": "MIT",
        "file": "WinkKit/LICENSE"
    },
    "authors": {
        "Rico Crescenzio": "[email protected]"
    },
    "platforms": {
        "ios": "10.0"
    },
    "source": {
        "git": "https://github.com/WINKgroup/WinkKit.git",
        "tag": "0.6.2"
    },
    "source_files": "WinkKit/**/*.swift",
    "frameworks": [
        "UIKit",
        "Foundation"
    ],
    "dependencies": {
        "Alamofire": [
            "~> 4.5"
        ],
        "AlamofireImage": [
            "~> 3.2"
        ],
        "Argo": [],
        "Runes": [],
        "Curry": [],
        "DateTools": []
    },
    "pushed_with_swift_version": "echo "4.0" > .swift-version"
}

Pin It on Pinterest

Share This