As we can see, the row has defined a block of what to do when the cell is selected, by calling the method onCellSelection. Two arguments are passed to this block — the cell and the row.

Inside the block, we reference the upper three rows by their tags (look how the constants struct comes handy this time). They’re optionals, so we need to unwrap them. Notice, that we are casting them as? RowOf<Type>. That’s because we don’t really care how they are implemented inside, we just need to know (and operate) on them by their type they’re holding.

Once we set the values, we need to call updateCell() on each row, to update their look. Another thing we do is to set the button cell disabled, while the name holds the value “Yoda”.

Notice, that we don’t specify it as a simple boolean, but instead we pass a block which evaluates if the row is disabled or not. The first parameter is an array that specifies which rows the value is dependent on (by tags). The second is a block which gets the form as a parameter, so that we can operate with it. evaluateDisabled() has to be called to update the button, but this is the only place where we have to do it, because after that it listens to the changes of the cells that the value depends on.

Selection rows

We often need to enable the user to select from multiple values that are offered to them. Three ways to do this, include offering them as input pickers, push row or to let them choose from a so-called selectable section. We’ll show their basic usage, but as with nearly everything in Eureka, you can customize them. There are much more of them, look for them in the Eureka Example app — link at the end.

Input Pickers

Input pickers allow the user to select an answer by presenting a picker that shows up in the keyboard area. The code is simple if you want to use the default cell offered by Eureka.

Push rows

Push rows are presenting the user a new ViewController to pick their choice from. Very suitable for long lists with more than textual information.

Selectable sections

Selectable sections are different, in a way that instead of presenting the choices to the user in a separate view or viewcontroller, selectable section presents itself inside the form.

Creating custom form elements

We will create a very simple custom element. It will have two functions — restrict the maximum length of the text and show a tiny progressbar on the bottom to indicate how much we used of that limit.

The code in the viewcontroller is simple enough, so I’ll just show you without any further explanation. We have defined our custom StringLengthRow class that we use here.

I’ll get into more detail with the code for the definition of these custom elements. We define two classes. For the row, we use StringLengthRow and for the cell StringLengthCell.

Let’s begin by StringLengthRow, as this is the simpler one, and the one we’ll be using in our viewcontroller code. Here, we just declare the properties we want to be settable. We also define in the initializer how we want to get the new cell. We chose to load it from nib.

The StringLengthCell is certainly more complex. We have two outlets — valueTextField and valueProgressView wired to the nib. Then we have the 2 basic methods each custom cell implements — setup() and update().

setup() is called once. It is a kind of an initialization function for the cell. Here we set not to highlight the cell when selected and set the delegate for the text field.

update() is called each time when the value is changed (or when updateCell() is called) on the row. It propagates the row’s properties to the cell UI.

Then we have a UITextFieldDelegate method keeping track of the length. We also have the textFieldDidChange(_:) method when the text is being changed. This writes the row’s value from text field and reflects length to the progress view.

Links