Apps Design

Blocks Design Pattern

For creating screens in Apps, you will be using the Blocks design pattern. Blocks is based off of the VIPER (View, Interactor, Presenter, Entity, Router) design pattern and has the following classes for you to override when creating screens for your apps: Block, Interactor, Presenter, ViewController. Blocks does not provide an Entity class; an Entity should be a data structure that you will be responsible for maintaining in your blocks. Blocks does have a Router class that can be overridden if custom navigation between Blocks are needed but this is a rare use case and using the default Router will be good enough for getting started.

Here's a brief description of each component in a Block:

Block

This is the builder object of the block, all dependencies for the Interactor and ViewController and any other components in your block should be resolved through this class. Typically these dependencies can be added through the constructor but sometimes data needs to be passed into the block after it's initialization creating a method within your Block to pass data to other components is required.

The Block class is also responsible fore initializing the block's Interactor and ViewController instances as well as implementing the methods view() and interactor(). These methods are used by Apps to render your screen and run your business logic for your app and you shouldn't need to call these methods yourself.

ViewController

The ViewController handles the view logic of your screen. This is where you will define TextViews, ButtonViews, ListViews, etc. and specify their formatting. The ViewController is also responsible for displaying state changes of your app for the user. Updating the ViewController due to state changes should happen through the use of a Presenter. When you create a Presenter for your block, it is the ViewController that should implement that interface.

Presenter

The Presenter is an interface you should extend for a block specific interface. The Presenter acts as the contract between your Interactor and ViewController classes and your Interactor will take the Presenter as a parameter in it's constructor that you can then call the Presenter's methods to update the ViewController. To handle UI events like a player clicking a button, pass a Listener or anonymous function to the Presenter that the ViewController can added to an interactive View like the ButtonView.

Interactor

The Interactor class is where you should write your business logic and handle updates to your app's state. You can pass data sources into your Interactor through it's constructor which your Block class will be responsible for satisfying. With the Presenter, you can wait for UI events from the player by setting Listeners or callbacks for interactive Views in the ViewController. When these events are triggered, you can then modify data and notify the ViewController of state updates through the Presenter again.

Next:

Now that you have a basic understanding of the major concepts of Apps, we can get started building our first app. You can use both Java and Kotlin to build apps but it is recommended to use Kotlin, even if you have an existing Java project you are looking to integrate Apps into, you can write your Apps code in Kotlin. We have tutorials for both Kotlin and Java so choose whichever one you'd prefer to develop in.