Day 18
Day 18 êŽë š
Project 1, part two
As Immanuel Kant said, âexperience without theory is blind, but theory without experience is mere intellectual play.â Yesterday we covered almost all the techniques required to build this app, so now itâs time to turn all that head knowledge into a real, practical app.
One of the things I love about SwiftUI is how easily this transition from theory to practice is â there are no surprises lurking around the corner and no epic extra new things to learn along the way.
Sure, Iâll sneak in a couple of tiny things just to keep you on your toes, but for the most part you already know everything you need to build this project, so now itâs just a matter of seeing how things fit together.
Today you have four topics to work through, in which youâll apply your knowledge of Form
, @State
, Picker
, and more.
Reading text from the user with TextField
Reading text from the user with TextField
Weâre building a check-splitting app, which means users need to be able to enter the cost of their check, how many people are sharing the cost, and how much tip they want to leave.
Hopefully already you can see that means we need to add three @State
properties, because there are three pieces of data weâre expecting users to enter into our app.
So, start by adding these three properties to our ContentView
struct:
@State private var checkAmount = 0.0
@State private var numberOfPeople = 2
@State private var tipPercentage = 20
As you can see, that gives us a default of 0.0 for the check amount, a default value of 2 for the number of people, and a default value of 20 for the tip percentage. Each of these properties have a sensible default: we donât know how much the check will come to, but assuming two people and a 20% tip both seem like good starting points for the app.
Of course, some people prefer to leave a different percentage of tip, so weâre going to let them select values from a predetermined array of tip sizes. We need to store the list of possible tip sizes somewhere, so please add this fourth property beneath the previous three:
let tipPercentages = [10, 15, 20, 25, 0]
Weâre going to build up the form step by step, starting with a text field where users can enter the value of their check. Weâll start with what you know already, but as youâll see that wonât quite work right.
Modify the body
property to this:
Form {
Section {
TextField("Amount", text: $checkAmount)
}
}
That isnât going to work, and thatâs okay. The problem is that SwiftUI likes TextField
to be used for entering text â strings, that is. We could allow that here, but it would mean users could enter any kind of text, and weâd need to carefully convert that string to a number we can work with.
Fortunately, we can do better: we can pass our Double
to TextField
and ask it to treat the input as a currency, like this:
TextField("Amount", value: $checkAmount, format: .currency(code: "USD"))
Thatâs an improvement, but we can do even better. You see, that tells SwiftUI we want the currency formatted as US dollars, or USD for short, but given that over 95% of the worldâs population donât use US dollars as their currency we should probably not force âUSDâ on them.
A better solution is to ask iOS if it can give us the currency code for the current user, if there is one. This might be USD, but it might also be CAD (Canadian dollars), AUD (Australian dollars), JPY (Japanese Yen) and more â or it might not currently have a value, if the user hasnât set one.
So, a better format to use is this:
.currency(code: Locale.current.currencyCode ?? "USD"))
Locale
is a massive struct built into iOS that is responsible for storing all the userâs region settings â what calendar they use, how they separate thousands digits in numbers, whether they use the metric system, and more. In our case, weâre asking whether the user has a preferred currency code, and if they donât weâll fall back to âUSDâ so at least we have something.
So far our code creates a scrolling entry form of one section, which in turn contains one row: our text field. When you create text fields in forms, the first parameter is a string that gets used as the placeholder â gray text shown in side the text field, giving users an idea of what should be in there. The second parameter is the two-way binding to our checkAmount
property, which means as the user types that property will be updated. The third parameter here is the one that controls the way the text is formatted, making it a currency.
One of the great things about the @State
property wrapper is that it automatically watches for changes, and when something happens it will automatically re-invoke the body
property. Thatâs a fancy way of saying it will reload your UI to reflect the changed state, and itâs a fundamental feature of the way SwiftUI works.
To demonstrate this, we could add a second section with a text view showing the value of checkAmount
, like this:
Form {
Section {
TextField("Amount", value: $checkAmount, format: .currency(code: Locale.current.currencyCode ?? "USD"))
}
Section {
Text(checkAmount, format: .currency(code: Locale.current.currencyCode ?? "USD"))
}
}
That does almost exactly the same thing as our TextField
: it asks SwiftUI to format the number as a currency, using either the system default or USD if nothing else is available. Later on in this project weâll be using a different format style to show percentages â these text formatters are really helpful!
Weâll be making that show something else later on, but for now please run the app in the simulator so you can try it yourself.
Tap on the check amount text field, then enter an example amount such as 50. What youâll see is that as you type the text view in the second section automatically and immediately reflects your actions.
This synchronization happens because:
- Our text field has a two-way binding to the
checkAmount
property. - The
checkAmount
property is marked with@State
, which automatically watches for changes in the value. - When an
@State
property changes SwiftUI will re-invoke thebody
property (i.e., reload our UI) - Therefore the text view will get the updated value of
checkAmount
.
The final project wonât show checkAmount
in that text view, but itâs good enough for now. Before we move on, though, I want to address one important problem: when you tap to enter text into our text field, users see a regular alphabetical keyboard. Sure, they can tap a button on the keyboard to get to the numbers screen, but itâs annoying and and not really necessary.
Fortunately, text fields have a modifier that lets us force a different kind of keyboard: keyboardType()
. We can give this a parameter specifying the kind of keyboard we want, and in this instance either .numberPad
or .decimalPad
are good choices. Both of those keyboards will show the digits 0 through 9 for users to tap on, but .decimalPad
also shows a decimal point so users can enter check amount like $32.50 rather than just whole numbers.
So, modify your text field to this:
TextField("Amount", value: $checkAmount, format: .currency(code: Locale.current.currencyCode ?? "USD"))
.keyboardType(.decimalPad)
Youâll notice I added a line break before .keyboardType
and also indented it one level deeper than TextField
â that isnât required, but it can help you keep track of which modifiers apply to which views.
Go ahead and run the app now and you should find you can now only type numbers into the text field.
Tip: The .numberPad
and .decimalPad
keyboard types tell SwiftUI to show the digits 0 through 9 and optionally also the decimal point, but that doesnât stop users from entering other values. For example, if they have a hardware keyboard they can type what they like, and if they copy some text from elsewhere theyâll be able to paste that into the text field no matter what is inside that text. Thatâs OK, though â the text field will automatically filter out bad values when they hit Return.
Creating pickers in a form
Creating pickers in a form
SwiftUIâs pickers serve multiple purposes, and exactly how they look depends on which device youâre using and the context where the picker is used.
In our project we have a form asking users to enter how much their check came to, and we want to add a picker to that so they can select how many people will share the check.
Pickers, like text fields, need a two-way binding to a property so they can track their value. We already made an @State
property for this purpose, called numberOfPeople
, so our next job is to loop over all the numbers from 2 through to 99 and show them inside a picker.
Modify the first section in your form to include a picker, like this:
Section {
TextField("Amount", value: $checkAmount, format: .currency(code: Locale.current.currencyCode ?? "USD"))
.keyboardType(.decimalPad)
Picker("Number of people", selection: $numberOfPeople) {
ForEach(2 ..< 100) {
Text("\($0) people")
}
}
}
Now run the program in the simulator and try it out â what do you notice?
Hopefully you spot several things:
- Thereâs a new row that says âNumber of peopleâ on the left and â4 peopleâ on the right.
- Thereâs a gray disclosure indicator on the right edge, which is the iOS way of signaling that tapping the row shows another screen.
- Tapping the row doesnât show another screen.
- The row says â4 peopleâ, but we gave our
numberOfPeople
property a default value of 2.
So, itâs a bit of âtwo steps forward, two steps backâ â we have a nice result, but it doesnât work and doesnât show the right information!
Weâll fix both of those, starting with the easy one: why does it say 4 people when we gave numberOfPeople
the default value of 2? Well, when creating the picker we used a ForEach
view like this:
ForEach(2 ..< 100) {
That counts from 2 up to 100, creating rows. What that means is that our 0th row â the first that is created â contains â2 Peopleâ, so when we gave numberOfPeople
the value of 2 we were actually setting it to the third row, which is â4 Peopleâ.
So, although itâs a bit brain-bending, the fact that our UI shows â4 peopleâ rather than â2 peopleâ isnât a bug. But there is still a large bug in our code: why does tapping on the row do nothing?
If you create a picker by itself, outside a form, iOS will show a spinning wheel of options. Here, though, weâve told SwiftUI that this is a form for user input, and so it has automatically changed the way our picker looks so that it doesnât take up so much space.
What SwiftUI wants to do â which is also why itâs added the gray disclosure indicator on the right edge of the row â is show a new view with the options from our picker. To do that, we need to add a navigation view, which does two things: gives us some space across the top to place a title, and also lets iOS slide in new views as needed.
So, directly before the form add NavigationView {
, and after the formâs closing brace add another closing brace. If you got it right, your code should look like this:
var body: some View {
NavigationView {
Form {
// everything inside your form
}
}
}
If you run the program again youâll see a large gray space at the top, which is where iOS is giving us room to place a title. Weâll do that in a moment, but first try tapping on the Number Of People row and you should see a new screen slide in with all the other possible options to choose from.
You should see that â4 Peopleâ has a checkmark next to it because itâs the selected value, but you can also tap a different number instead â the screen will automatically slide away again, taking the user back to the previous screen with their new selection.
What youâre seeing here is the importance of whatâs called declarative user interface design. This means we say what we want rather than say how it should be done. We said we wanted a picker with some values inside, but it was down to SwiftUI to decide whether a wheel picker or the sliding view approach is better. Itâs choosing the sliding view approach because the picker is inside a form, but on other platforms and environments it could choose something else.
Before weâre done with this step, letâs add a title to that new navigation bar. Give the form this modifier:
.navigationTitle("WeSplit")
Tip: Itâs tempting to think that modifier should be attached to the end of the NavigationView
, but it needs to be attached to the end of the Form
instead. The reason is that navigation views are capable of showing many views as your program runs, so by attaching the title to the thing inside the navigation view weâre allowing iOS to change titles freely.
Adding a segmented control for tip percentages
Adding a segmented control for tip percentages
Now weâre going to add a second picker view to our app, but this time we want something slightly different: we want a segmented control. This is a specialized kind of picker that shows a handful of options in a horizontal list, and it works great when you have only a small selection to choose from.
Our form already has two sections: one for the amount and number of people, and one where weâll show the final result â itâs just showing checkAmount
for now, but weâre going to fix it soon.
In the middle of those two sections Iâd like you to add a third to show tip percentages:
Section {
Picker("Tip percentage", selection: $tipPercentage) {
ForEach(tipPercentages, id: \.self) {
Text($0, format: .percent)
}
}
}
That loops over all the options in our tipPercentages
array, converting each one into a text view with the .percent
format. Just like the previous picker, SwiftUI will convert that to a single row in our list, and slide a new screen of options in when itâs tapped.
Here, though, I want to show you how to use a segmented control instead, because it looks much better. So, please add this modifier to the tip picker:
.pickerStyle(.segmented)
That should go at the end of the pickerâs closing brace, like this:
Section {
Picker("Tip percentage", selection: $tipPercentage) {
ForEach(tipPercentages, id: \.self) {
Text($0, format: .percent)
}
}
.pickerStyle(.segmented)
}
If you run the program now youâll see things are starting to come together: users can now enter the amount on their check, select the number of people, and select how much tip they want to leave â not bad!
But things arenât quite what you think. One problem app developers face is that we take for granted that our app does what we intended it to do â we designed it to solve a particular problem, so we automatically know what everything means.
Try to look at our user interface with fresh eyes, if you can:
- âAmountâ makes sense â itâs a box users can type a number into.
- âNumber of peopleâ is also pretty self-explanatory.
- The label at the bottom is where weâll show the total, so right now we can ignore that.
- That middle section, though â what are those percentages for?
Yes, we know they are to select how much tip to leave, but that isnât obvious on the screen. We can â and should do better.
One option is to add another text view directly before the segmented control, which we could do like this:
Section {
Text("How much tip do you want to leave?")
Picker("Tip percentage", selection: $tipPercentage) {
ForEach(tipPercentages, id: \.self) {
Text($0, format: .percent)
}
}
.pickerStyle(.segmented)
}
That works OK, but it doesnât look great â it looks like itâs an item all by itself, rather than a label for the segmented control.
A much better idea is to modify the section itself: SwiftUI lets us add views to the header and footer of a section, which in this instance we can use to add a small explanatory prompt. In fact, we can use the same text view we just created, just moved to be the section header rather than a loose label inside it.
Hereâs how that looks in code:
Section {
Picker("Tip percentage", selection: $tipPercentage) {
ForEach(tipPercentages, id: \.self) {
Text($0, format: .percent)
}
}
.pickerStyle(.segmented)
} header: {
Text("How much tip do you want to leave?")
}
That uses multiple trailing closures to specify both the section body (the first closure) and the second header (the second closure).
Itâs a small change to the code, but I think the end result looks a lot better â the text now looks like a prompt for the segmented control directly below it.
Calculating the total per person
Calculating the total per person
So far the final section in our form has shown a simple text view with whatever check amount the user entered, but now itâs time for the important part of this project: we want that text view to show how much each person needs to contribute to the payment.
There are a few ways we could solve this, but the easiest one also happens to be the cleanest one, by which I mean it gives us code that is clear and easy to understand: weâre going to add a computed property that calculates the total.
This needs to do a small amount of mathematics: the total amount payable per person is equal to the value of the order, plus the tip percentage, divided by the number of people.
But before we can get to that point, we first need to pull out the values for how many people there are, what the tip percentage is, and the value of the order. That might sound easy, but as youâve already seen, numberOfPeople
is off by 2 â when it stores the value 3 it means 5 people.
So, weâre going to create a new computed property called totalPerPerson
that will be a Double
, and it will start off by getting the input data ready: what is the correct number of people, and how much tip do they want to leave?
First, add the computed property itself, just before the body
property:
var totalPerPerson: Double {
// calculate the total per person here
return 0
}
That sends back 0 so your code doesnât break, but weâre going to replace the // calculate the total per person here
comment with our calculations.
Next, we can figure out how many people there are by reading numberOfPeople
and adding 2 to it. Remember, this thing has the range 2 to 100, but it counts from 0, which is why we need to add the 2.
So, start by replacing // calculate the total per person here
with this:
let peopleCount = Double(numberOfPeople + 2)
Youâll notice that converts the resulting value to a Double
because it needs to be used alongside the checkAmount
.
For the same reason, we also need to convert our tip percentage into a Double
:
let tipSelection = Double(tipPercentage)
Now that we have our input values, itâs time do our mathematics. This takes another three steps:
- We can calculate the tip value by dividing
checkAmount
by 100 and multiplying bytipSelection
. - We can calculate the grand total of the check by adding the tip value to
checkAmount
. - We can figure out the amount per person by dividing the grand total by
peopleCount
.
Once thatâs done, we can return the amount per person and weâre done.
Replace return 0
in the property with this:
let tipValue = checkAmount / 100 * tipSelection
let grandTotal = checkAmount + tipValue
let amountPerPerson = grandTotal / peopleCount
return amountPerPerson
If youâve followed everything correctly your code should look like this:
var totalPerPerson: Double {
let peopleCount = Double(numberOfPeople + 2)
let tipSelection = Double(tipPercentage)
let tipValue = checkAmount / 100 * tipSelection
let grandTotal = checkAmount + tipValue
let amountPerPerson = grandTotal / peopleCount
return amountPerPerson
}
Now that totalPerPerson
gives us the correct value, we can change the final section in our table so it shows the correct text.
Replace this:
Section {
Text(checkAmount, format: .currency(code: Locale.current.currencyCode ?? "USD"))
}
With this:
Section {
Text(totalPerPerson, format: .currency(code: Locale.current.currencyCode ?? "USD"))
}
Try running the app now, and see what you think. You should find that because all the values that make up our total are marked with @State
, changing any of them will cause the total to be recalculated automatically.
Hopefully youâre now seeing for yourself what it means that SwiftUIâs views are a function of their state â when the state changes, the views automatically update to match.
Hiding the keyboard
Hiding the keyboard
Weâre now almost at the end of our project, but you might have spotted an annoyance: once the keyboard appears for the check amount entry, it never goes away!
This is a problem with the decimal and number keypads, because the regular alphabetic keyboard has a return key on there to dismiss the keyboard. However, with a little extra work we can fix this:
- We need to give SwiftUI some way of determining whether the check amount box should currently have focus â should be receiving text input from the user.
- We need to add some kind of button to remove that focus when the user wants, which will in turn cause the keyboard to go away.
To solve the first one you need to meet your second property wrapper: @FocusState
. This is exactly like a regular @State
property, except itâs specifically designed to handle input focus in our UI.
Add this new property to ContentView
:
@FocusState private var amountIsFocused: Bool
Now we can attach that to our text field, so that when the text field is focused amountIsFocused
is true, otherwise itâs false. Add this modifier to your TextField
:
.focused($amountIsFocused)
Thatâs the first part of our problem solved: although we canât see anything different on the screen, SwiftUI is at least silently aware of whether the text field should have focus or not.
The second part of our solution is to add a toolbar to the keyboard when it appears, so we can place a Done button in there. To make this work really well you need to meet several new SwiftUI views, so I think the best thing to do is show you the code then explain what it does.
Add this new modifier to your form, below the existing navigationTitle()
modifier:
.toolbar {
ToolbarItemGroup(placement: .keyboard) {
Button("Done") {
amountIsFocused = false
}
}
}
Yes, thatâs quite a lot of code, so letâs break it down:
- The
toolbar()
modifier lets us specify toolbar items for a view. These toolbar items might appear in various places on the screen â in the navigation bar at the top, in a special toolbar area at the bottom, and so on. ToolbarItemGroup
lets us place one or more buttons in a specific location, and this is where we get to specify we want a keyboard toolbar â a toolbar that is attached to the keyboard, so it will automatically appear and disappear with the keyboard.- The
Button
view weâre using here displays some tappable text, which in our case is âDoneâ. We also need to provide it with some code to run when the button is pressed, which in our case setsamountIsFocused
to false so that the keyboard is dismissed.
Youâll meet these more in the future, but for now I recommend you run the program and try it out â itâs a big improvement!
Before weâre done, thereâs one last small change I want to make: Iâd like you to modify the ToolbarItemGroup
to this:
ToolbarItemGroup(placement: .keyboard) {
Spacer()
Button("Done") {
amountIsFocused = false
}
}
That adds one small but important new view before the button, called Spacer
. This is a flexible space by default â wherever you place a spacer it will automatically push other views to one side. That might mean pushing them up, down, left, or right depending on where itâs used, but by placing it first in our toolbar it will cause our button to be pushed to the right.
If you run the app again youâll see the difference â itâs really minor, but having the Done button on the right of the keyboard is also the same thing other iOS apps do, and itâs good to make our own code adopt those conventions.
Anyway, that was the last step in this project â pat yourself on the back, because weâre finished!