A base architecture written in swift and protocol oriented.

Currently not provide a stable version so please use branch "master" instead.

dependencies: [
    .package(url: "https://github.com/Mioke/SwiftyArchitecture.git", branch: "master"),
]

or if you are coding with a iOS application project, please add this repository as a git submodule:

git submodule add -b master https://github.com/Mioke/SwiftyArchitecture.git <path>
git submodule init
git submodule update

After that please click the project file in your Xcode and find "Package Dependency" tab, click button and then click Add Local..., finally please select the path of submodule and the program will automatically find the available package in the folder. Add the package's framework to your project's target and all done.

pod 'SwiftyArchitecture'
# or choose on your need
pod 'SwiftyArchitecture/AppDock'
pod 'SwiftyArchitecture/Componentize'
pod 'SwiftyArchitecture/Networking'
pod 'SwiftyArchitecture/RxExtension'
# Write tests
pod 'SwiftyArchitecture/Testable'

• Networking.
• Persistence Store, cache store and a memory store.
• AppDocker, an application context handler for helping developer to handle user authentication and local storage isolation.
• Data center, handle all API and storage of response data in realm database.
• Modulize or componentize your main project, provide data transmit and router between modules.
• Reactive extension for all functionalities above.

• Server

  Provide some basic functionalities of a server like url configuation, environments switch etc. In test Mode, offline the server.

  let server: Server = .init(live: cdn.config.liveURL,
                             customEnvironments: [
                              .custom("Dev"): cdn.config.devURL,
                              .custom("Staging"): cdn.config.stagingURL,
                            ])
  #if DEBUG
      server.switch(to: .custom("Dev"))
  #endif

You can comstomize the operation of dealing response data now, just subclass from Server and conform to protocol ServerDataProcessProtocol like:

func handle(data: Any) throws -> Void {
    
    if let dic = data as? [String: Any],
       let errorCode = dic["error_code"] as? Int,
       errorCode != 0 {
        throw NSError(domain: kYourErrorDomain, 
                      code: errorCode, 
                      userInfo: [NSLocalizedDescriptionKey: message])
    }
}

• API

  Now you can manager request with API<ApiInfoProtocol>, creating a class conformed to ApiInfoProtocol, only need to provide some infomation about the API and set where the callback is, you are already finished the configuration of an API.

    typealias RequestParam = [String, Any]
    
    var apiVersion: String {
        get { return "v2" }
    }
    var apiName: String {
        get { return "user/login" }
    }
    var server: Server {
        get { return mainServer }
    }

    typealias ResultType = _User

    static var responseSerializer: ResponseSerializer<ResultType> {
        return JSONResponseSerializer<ResultType>()
    }

The API provide some basic method like:

  public func sendRequest(with params: [String: Any]?) -> Void

Using chaining syntax to request data:

api.sendRequest(with: nil).response({ (api, user, error) in
  if let error = error {
    // deal error
  }
  if let user = user {
    // do response if have data
  }
})

• Rx supported

ApiManager provides an Observable for you, you can transfrom it or directly bind it to something:

api.rx.sendRequest(with: params)
    .flatMap {
        ...
        return yourResultObservable
    }
    .bind(to: label.rx.text)
    .dispose(by: bag)

See this documentation for detail, include App Context & User Context & Store.

SwiftyArchitecture provides a data center, which can automatically manage your models, data and requests. This function is based on Reactive Functional Programing, and using RxSwift. The networking kit is using API and database is Realm.

It provides an accessor called Accessor<Object>, and all data or models can be read throught this DAO.

Example:

Firstly, define your data model in model layer and your database model in Realm.

class User: RealmSwift.Object {
    @Persisted(primaryKey: true)
    var userId: String = ""
    @Persisted
    var name: String = ""
}

Then there may have a API which request data relevant to the User model:

final class UserAPI: ApiInfoProtocol {
    struct Param: Codable {
        let uids: [String]
    }
    typealias RequestParam = UserAPI.Param
    
    struct Reply: Codable {
        struct User: Codable {
            var userId: String
            var name: String
            var version: String?
        }
        var users: [Reply.User]
    }
    typealias ResultType = Reply
    
    static var apiVersion: String {
        get { return "v1" }
    }
    static var apiName: String {
        get { return "getUserInfo" }
    }
    static var server: Server {
        get { return getServer() }
    }
    static var httpMethod: Alamofire.HTTPMethod {
        get { return .get }
    }
    static var responseSerializer: ResponseSerializer<Reply> {
        return JSONCodableResponseSerializer<Reply>()
    }
}

To manage this User model, it must be conformed to the protocol DataCenterManaged, this protocol defines how data center should do with this model.

extension User: DataCenterManaged {
    // define API's type
    typealias APIInfo = UserAPI
    
    // defines how transform data from API to data base object.
    static func serialize(data: UserAPI.Reply) throws -> [RealmSwift.Object] {
        let result: [Object] = data.users.map { item in
            let user = User()
            user.name = item.name
            user.userId = item.userId
            return user
        }
        if data.isFinal {
            // do something else
        }
        return result
    }
}

Then you can read the data in database and use it by using Accessor<User>.

// read all users and display on table view.
Accessor<User>.context(.persist).all
    .map { $0.sorted(by: <) }
    .map { [AnimatableSectionModel(model: "", items: $0)] }
    .bind(to: tableView.rx.items(dataSource: datasource))
    .disposed(by: disposeBag)

And then you can update models throught requests, and when data changed, the Observable<User> will notify observers the new model is coming. And data center will save the newest data to database. For developers of in feature team, they should only need to forcus on models and actions.

print("Show loading")

let request: Request<User> = .init(params: .init(uids: ["10025"]))
DataCenter.update(with: request)
    .subscribe({ event in
        switch event {
        case .completed:
            print("Hide loading")
        case .error(let error as NSError):
            print("Hide loading with error: \(error.localizedDescription)")
        }
    })
    .disposed(by: self.disposeBag)

Support using cocoapods to modulize your project. You can separate some part of code which is indepence enough, and put the code into a pod repo. And finally the main project maybe have no code any more, when building your app, the cocoapods will install all the dependencies together and generate your app.

The good things of modulization or componentization are

• modules are closed between each other, and there's no way to visit the detail from another module;
• modules can be used in other project, if the module is well designed;
• instead of using git branch, now we can use version of the pod for development and generate app;
• using cocoapods package to generate binary library, fasten the app package process.

The bad things of it are (for now)

• low running performance for developing, because the more frameworks or libraries, the worse DYLD performance get;
• need a lot of utils to maintain pods and their git repos, like auto generate version, auto update Podfile etc.

So, this function should depend on the situation of your team and your project. ;)

For small-sized teams, I would like to recommend the monorepo format for your components. This means you can place all your components in one Git repository but in different folders and create a .podspec for each of them. Then, you can manage them using Git branches instead of publishing them one by one. At the same time, all the code is separated by Cocoapods, which cannot access each other between pods.

For large-sized teams, if you have a chain of tools and utilities to build pods and publish them, and have an integration tool to put them together into a main project, then you can use the multi-repo format to manage your pods.

• Module

  Modules should register into the ModuleManager when app started.

  if let url = Bundle.main.url(forResource: "ModulesRegistery", withExtension: ".plist") {
      try! ModuleManager.default.registerModules(withConfigFilePath: url)
  }

  The register .plist file contains an array of class names, which implement module's protocol, like:

  // in public protocol pod:
  public extension ModuleIdentifier {
      static let auth: ModuleIdentifier = "com.klein.module.auth"
  }
  
  public protocol AuthServiceProtocol {
      func authenticate(completion: @escaping (User) -> ()) throws
  }
  
  // in private pod:
  class AuthModule: ModuleProtocol, AuthServiceProtocol {
      static var moduleIdentifier: ModuleIdentifier {
          return .auth
      }
      required init() { }
      
      func moduleDidLoad(with manager: ModuleManager) {}
      
      func authenticate(completion: @escaping (User) -> ()) throws {
          // do your work
      }
  }
  
  // in .plist
  array:
    Auth.AuthModule,
    ...

  Call other module's method like

  guard let authModule = try? self.moduleManager?.bridge.resolve(.auth) as? AuthServiceProtocol 
  else {
      fatalError()
  }
  authModule.authenticate(completion: { user in
      print(user)
  })

• Navigation

  TBA

• Initiator

  When some modules should do some work at the start process, you will need Initiator and regitster you opartion in it.

  // defined in framework
  public protocol ModuleInitiatorProtocol {
      static var identifier: String { get }
      static var operation: Initiator.Operation { get }
      static var priority: Initiator.Priority { get }
      static var dependencies: [String] { get }
  }
  
  // implement in pod repo
  extension AuthModule: ModuleInitiatorProtocol {
      static var identifier: String { moduleIdentifier }
      static var priority: Initiator.Priority { .high }
      static var dependencies: [String] { [ModuleIdentifier.application] }
      static var operation: Initiator.Operation {
          return {
              // do something
          }
      }
  }  

• Custom extensions and categories.
• UI relevant class for easy accessing global UI settings.
• Logger API, default to write in system console, you can customize the action and record messages somewhere else.

Almost done >w<!

• Networking: cache, origin data transform to Model or View's data, priority of request.
• Mock of API's response.
• Download and upload functions in API manager.
• Persistance: transform data to model or View's data after query.(don't need it now, using Realm)
• Animations, Tools and Kits: TextKit like YYText, etc. (SwiftyArchitecture won't provide those utilities, because base shouldn't have to.)
• Refactoring, more functional and reative. Considering to use Rx or ReactiveSwift. Fully use genericity.
• Modulize of componentization usage. Router.
• Full Swift concurrency API support.

All the source code is published under the MIT license. See LICENSE file for details.