https://github.com/ilyapuchka/schibsted

https://github.com/ilyapuchka/schibsted

Last synced: 13 days ago
JSON representation

• Host: GitHub
• URL: https://github.com/ilyapuchka/schibsted
• Owner: ilyapuchka
• Created: 2017-10-22T21:30:57.000Z (over 7 years ago)
• Default Branch: master
• Last Pushed: 2017-10-23T13:12:35.000Z (over 7 years ago)
• Last Synced: 2025-01-15T20:16:12.065Z (22 days ago)
• Language: Swift
• Size: 9.96 MB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
## Installation

After clonning repository run `carthage bootstrap --platform iOS` in its root directory to install dependencies. The only dependencies used are [R.swift](https://github.com/mac-cain13/R.swift) and [NextGrowingTextView](https://github.com/muukii/NextGrowingTextView). `R.swift` is used to generate various resource identifiers, i.e. for table view cell's reuse identifiers and xib files, to make working with them compile-time type-safe and free of stringly-typing. `NextGrowingTextView` is used for text input.

## Code structure

Code is broken into 3 high level layers:

- domain layer, contains domain models and services for data queries

- data access layer, contains concrete implementations of interfaces, used by services for data access i.e. via network or using in-memory cache

- application, contains all UI related components, broken by user stories

Code is written with dependency injection in mind to allow easy unit testing. Constructor injection is used for plain objects and property injection is mostly used for view controllers as the app is also using storyboards.

## Application layer components

Application layer is broken by user stories each of which contains of set of similar components:

- UI components: cells and lists view controller

- view models: cell view models map domain objects to their presentation models, lists view controller models store the state of the lists and map data (arrays of domain objects) to arrays of cells view models

- flow controller: manages navigation and data flow inside user story, making individual screens decoupled from each other

Usually I also use one more layer, but I decided to drop it out this time. This layer is:

- data providers: access services and constructs updated view models for lists

## Additional features

#### Segue manager

Simple helper is used to provide context-aware segue-execution, similar to [SegueManager](https://github.com/tomlokhorst/SegueManager). This allows to simplify passing data between screens when segues are used.

#### Keyboard observer

Keyboard observation is implemented with a simple protocol with default implementations which allows to add this behaviour with 3 lines of code on both screens.

#### Generic list view models

Generic protocols are used to facilitate list of messages which ensures more type-safe way of working with table view cells and their view models (also with a help of R.swift autogenerated code). But as I used generic parameter on a cell view model to specify type of message I could not use it to presend two different kinds of cells in one list. That could be probably solved with type erasure technique, which I didn't have time to implement, or with a different approach, like providing type of message sender as parameter of view model and use it to decide what content view to display in a cell, using one cell instead of two different cells for each type of sender.