All Versions
7
Latest Version
Avg Release Cycle
21 days
Latest Release
1404 days ago

Changelog History

  • v1.1.0 Changes

    December 17, 2017

    ๐Ÿš€ This release:

    • ๐Ÿšš cleans the code (remove unused imports, remove Foundation)
    • ๐Ÿ‘Œ improves the Demo Application code
  • v1.0.0 Changes

    November 21, 2017

    ๐Ÿš€ This release is the first that gets the whole expected features:

    • multi-warp weaving
    • pausable weftables
    • demo application
    • Carthage and CocoaPods availability
  • v0.9.1

    November 20, 2017
  • v0.9.0

    November 20, 2017
  • v0.3 Changes

    August 24, 2017

    When a warp (its presentables) is not currently displayed, every event emitted by its weftable is ignored, until the warp is displayed again

  • v0.2 Changes

    August 19, 2017

    The version:

    • simplifies the Warp concept
    • introduces the ability to have a Weftable at a Warp global level
    • modifies the weaving bootstrap process, as the Loom now takes a Stitch as a parameter (that must be a link to a whole Warp)
    • โž• adds documentation
  • v0.1 Changes

    August 15, 2017

    ๐Ÿš€ This release introduces the core principles of the weaving mechanism.

    Warp, Weft and Stitch

    Combinaisons of Warps and Wefts describe all the possible navigation patterns within your application.
    Each warp defines a clear navigation area (that makes your application divided in well defined parts) in which every Weft represent a specific presentation of a screen. This representation is called a Stitch. A Stitch can be presented in different ways such as "popup" or regular "show" screens.

    Weftable

    The basic principle of navigation is very simple: it consists of successive views transitions in response to application state changes. These changes are usually due to users interactions (such as button clicking or list picking), but they can also come from a low level layer of your application. We can imagine that a lose of network session could lead to a signin screen appearance.

    The most generic way of considering all this is to imagine that anything in the application can lead to a change of navigation state. We need a way to express these changes. As we saw, a combinaison of a Warp and a Weft represents a navigation action. As well as Warps can define your application areas, Wefts can define these navigation state changes inside these areas.

    Considering this, a Weftable is basically "something" in the application which is able to express a new Weft, and as a consequence a navigation state change, leading to a navigation action.

    A Weft can embed inner values (such as Ids, URLs, ...) that will be propagated to screens presented by the weaving process.

    Loom

    ๐Ÿ‘ท A loom is a just a tool for the developper. Once he has defined the suitable combinations of Warps and Wefts representing the navigation possibilities, the job of the loom is to weave these combinaisons into patterns according to navigation state changes induced by Weftables. It is up to the developper to:

    • define the Warps that represent in the best possible way its application sections (such as Dashboard, Onboarding, Settings, ...) in which significant navigation actions are needed
    • provide the Weftables that will trigger the Loom weaving process.

    Woolbag

    One of the goal of "Weavy" is to promote dependency injection, for valuable reasons:

    • avoid using singletons everywhere in your code to reach some low level services
    • separate the concerns. It is not the responsability of UIViewControllers, View Models, Presenters or whatever business logic layer to know what types of service to instantiate. They just have to use them, or at least one of their abstraction, and be flexible to an implementation change that can happen in the futur.
    • โœ… being able to chose the implementations of services that will be injected to all layers of your application in a early stage of its runtime flow can have a significant advantage in its testability. It is easy to mock services and to inject these fake ones at the application bootstrap.

    Let's get back to "Weavy". We saw that combinaisons of Warps and Wefts are weaved into Stitches that represent screens to be displayed. The big advantage of doing this programmatically is that we have the opportunity to inject whatever service we want into the UIViewControllers the Loom will instantiate. The only thing we need at this point is a a mechanism that will help the developper to provide these services.

    As well as real Wool is the raw stuff needed to weave some fabric when a warp and a weft are knitted, we need some kind of WoolBag in which developpers will store references to the services that will be needed by the UIViewControllers when they are weaved.

    WoolBags are basically containers that can be injected into whatever the Loom can produce (UIViewControllers, View Models, ...).

    Demo Application

    A demo application is provided to illustrate the core mechanisms of weaving. It consists of:

    • a main ApplicationWarp that represents the basic application navigation (a dashboard composed of two screens in a navigation stack)
    • an OnboardingWarp that represents an onboarding wizard that can be triggered within the first dashboard page (or automatically after 10s). The onboarding is composed of three screens in a navigation stack)
    • a SettingsWarp that represents the settings pages that can be triggered within the second dashboard page. The settings are composed of two screens in a navigation stack.

    ๐Ÿ’… As we can see, some screens (the login screen for instance) are defined once but used in multiple Warps in different presentation styles. We can clearly see the benefits of decoupling navigation from UIViewControllers.