Maintaining State in Your Apps あなたのアプリの状態を保守する

Overview 概要

Effectively managing state, the bits of data that keep track of how the app is being used at the moment, is an important part of a developing your app. Because enumerations define a finite number of states, and can bundle associated values with each individual state, you can use them to model the state of your app and its internal processes. 効果的に状態、どのようにその時アプリが使われるかの情報を得る少量のデータ、を管理することは、あなたのアプリの開発の重要な部分です。列挙がある有限の数の状態を定義する、そして個々の状態それぞれに関連値を束ねることから、あなたはそれらを使ってあなたのアプリの状態とそれの内部処理をモデル化できます。

Use an Enumeration to Capture State 列挙を使って状態をキャプチャしてください

Consider an app that requires a user to log into an account. When the app is first opened, the user is unknown, so the state of the app could be called unregistered. After the user has registered or logged into an account, the state is logged in. After some time of inactivity, the user’s session may expire, leaving the app in a session expired state. ユーザがアカウントにログインするように要求するアプリを考えください。アプリが最初に開かれた時、ユーザは誰か分かりません、それでアプリの状態は無登録と呼ぶことができるでしょう。ユーザがアカウントに登録またはログインした後は、状態はログイン済みです。しばらく活動がない後に、ユーザのセッションは期限切れになるかもしれません、アプリを期限切れセッションの状態のままにします。

You can use an enumeration to specify the exact states needed for your app. This approach defines an App class with a nested State enumeration that includes only the specific states you need: あなたは列挙を使って、あなたのアプリに必要とされる正確な状態を指定できます。この取り組みは、Appクラスを、あなたが必要とする特定の状態のみを含むState列挙とともに定義します：

class App {
    enum State {
        case unregistered
        case loggedIn(User)
        case sessionExpired(User)
    }
  
    var state: State = .unregistered
  
    // ...
}

In this model, each state is represented by a case with a matching name. The loggedIn and sessionExpired cases include the user as an associated value, while the unregistered case doesn't include an associated value. When you update your app's state, there's a single variable, state, to modify, no matter what the transition. このモデルにおいて、各状態は合致する名前を持つケース節によって表されます。loggedInとsessionExpiredケース節はユーザを関連値として含みます、一方でunregisteredケース節は関連値を含みません。あなたのアプリの持つ状態をあなたが更新する場合、修正するただ１つの変数、stateがあるだけです、推移が何であろうと。

Don't Spread State Across Multiple Variables 状態を複数の変数に渡って広げないでください

It's also possible to model an app’s state by using individual variables in combination to hold the state and the required data, which is not recommended. アプリの持つ状態を、状態と必要データを保持するよう組み合わせた独立した幾つかの変数を使ってモデル化することもまた可能です、それは推奨されません。

In this model, the app defines two variables: an optional user that stores user information, and a Boolean value named sessionExpired. The user variable is nil when the user not logged in and has a value once the user logs in. The sessionExpired variable begins as false and is set to true if the session expires. The three states are captured by different combinations of the two variables. このモデルでは、アプリは２つの変数を定義します：ユーザ情報を格納するオプショナルのuser、そしてsessionExpiredと名前をつけられるブール値。user変数は、ユーザがログインしていない場合nilです、そして一旦ユーザがログインするならばある値を持ちます。sessionExpired変数は、falseで始まります、そしてセッションが期限切れになるならばtrueに設定されます。３つの状態は、２つの変数の異なる組み合わせによって捕えられます。

Using this approach is prone to mistakes for a few reasons, in ways that can lead to bugs and make it harder to reason about your code: この取り組みを使うことは、2、3の理由から間違いを起こす傾向があります、バグに至りうるそしてあなたのコードについて論じることをより困難にするやり方で：

• For every change in state, you need to provides updates for both user and sessionExpired in tandem. 状態におけるすべての変化に対して、あなたはuserとsessionExpiredの両方に対して相前後して更新を提供する必要があります。

• If a future change to the app requires an additional state, you need to update an additional variable at every existing change in state. アプリに対する将来の変更が追加の状態を要求するならば、あなたは、状態において起こっているすべての変化で、追加の変数を更新する必要があります。

• The two variables have an unused combination—it’s possible to set the user to nil and sessionExpired to true, even though that doesn’t have a corresponding state. ２つの変数は使われない組み合わせを持ちます — userをnilにそしてsessionExpiredをtrueに設定することは可能です、たとえそれが対応する状態を持たないとしてもです。