Unleash Your Inner App Developer Part 28: Managing User Settings

Examining with the User and UserEntity Classes

As with the other entities that we have retrieved using Core Data, I have created a User business controller object that can retrieve the UserEntity that contains the user settings from the database. 

Let's take a look at the User and UserEntity classes. 

1. Open the iAppsReview project in Xcode.

2. In the Project Navigator, click on the UserEntity.h file to select it and you will be able to see the properties shown in Figure 2.

Figure 2 - UserEntity properties

Notice that in addition to the email and password properties, there are also firstName, lastName, and userID properties. We won't be implementing these other properties right now, but I wanted you to see that they exist.

3. Now go back to the Project Navigator, select the User.h file and you will be able to see the getUser method declaration shown in Figure 3.

Figure 3 - The User.h file

Notice the getUser method only returns a single UserEntity object rather than an NSMutableArray. That's because there is only one user record for this app.

4. Now click on the User.m file in the Project Navigator. At the bottom of the code file you can see the getUser method implementation shown in Figure 4.

Figure 4 - The getUser method

As you can see, we are still using the getAllEntities method that we have used elsewhere in other business objects in this app. But the code then checks if any UserEntity objects are returned from this method (userList.count > 0), and if so, returns the first record in the array. Otherwise, the method returns nil (nothing). If you have ever wondered how to create a method that returns a single record from Core Data, this is it!

Implementing the User and UserEntity Classes in the Settings Scene

Now that we know more about the User and UserEntity classes, let's use them in the Settings scene.

1. In the Project Navigator, select the SettingsViewController.h file.

2. Add the import statement and propery declaration shown in Figure 5.

Figure 5 - Add the import statement and user property declaration

3. In the Project Navigator, select the SettingsViewController.m file, and add the import statements and instance variable declaration shown in Figure 6 (don't forget to add the curly braces surrounding the instance variable).

Figure 6 - Add the import statements and userEntity instance variable.

4. In the viewDidLoad method, add the code shown in Figure 7.

Figure 7 - Add this code to the viewDidLoad method.

This code creates an instance of the User class and stores it in the user property. Next, it calls the user object's getUser method and stores the resulting UserEntity object in the userEntity instance variable. Finally, it grabs the email and password values from the object properties and stores them in the email and password text fields.

Adding Edit Mode to the Settings Scene

As I mentioned in my previous post, as it stands right now it's too easy for the user to accidentally change their email address and password. It makes sense to add an Edit button that the user must click before they can change these settings. Let's do that now.

1. In the Project Navigator, select the MainStoryboard.storyboard file and then scroll to the Settings scene.

2. Drag a Bar Button Item from the Object Browser in the bottom-right corner of the Xcode window and drag it to the right side of the Settings scene's navigation bar until you see the rounded rectangle appear (Figure 8) and then let go of your mouse button. This adds the button to the navigation bar.

Figure 8 - Add a Bar Button Item to the right side of the navigation bar.

3. With the bar button item still selected, go to the Attributes Inspector (third button from the right in the Inspector toolbar) and set the Title to Edit. The button should now look like Figure 9.

Figure 9 - The Edit button

4. To prevent the user from changing the email address and password before they click the Edit button, select the text field in the Email address cell and deselect the User Interaction Enabled checkbox towards the bottom of the Attributes Inspector. Afterward, do the same to the text field in the Password cell.

5. Since we don't want the user to click the Log In button unless there are valid email address and password credentials, click on the Log In button in the design surface, and then go to the Attributes Inspector and uncheck the Enabled button. This turns the text of the button gray as shown in Figure 10.

Figure 10 - The Login button is disabled.

6. Now we need to create an action method that gets fired when the user taps the Edit button. To do this, click on the Edit button in the Settings scene to select it. Next, display the Assistant Editor by clicking the center button in the Editor button group at the top right of the Xcode window. This should display the SettingsViewController.h file. If it doesn't, select the file in the Assistant Editor's jump bar.

7. Next, go to the Connections Inspector (the button on the right in the Inspectors toolbar) and click the connection well to the right of the selector action. Drag your mouse down into the SettingsViewController.h file above the closing @end statement until you see the Insert Action popup as shown in Figure 11.

Figure 11 - Create an action method for the Edit button.

8. In the Create Connection popup, set the Name to editToggle and then click the Connect button. This adds a new editToggle: method to the header file as shown in Figure 12.

Figure 12 - The editToggle: method declaration

9. Before implementing the editToggle: method, go to the Project Navigator and click the SettingsViewController.m file. Near the top of the code file add the isEditMode instance variable shown in Figure 13.

Figure 13 - The isEditMode instance variable

10. Now add the code shown in Figure 14 to the editToggle: method.

Figure 14 - Add code to the editToggle: method

This code first checks if the scene is currently in edit mode. If it is, nothing happens because we don't have any code in the first part of the if statement yet. If the scene isn't in edit mode, here are the main steps performed by this code:

• Changes the text of the button from Edit to Done

• Hides the standard "back" button and displays a Cancel button in its place

• Disables the Login, Sign Up, and Feedback buttons

• Enables the text fields in the Email address and Password cells

• Sets focus to the Email address text field

• Sets the isEditMode flag to YES

Testing the Edit Button

Let's take a break from building the app and test what we have done so far.

1. Click Xcode's Run button, and when the app appears in the Simulator, click the Settings & Feedback option. You should see the scene shown in Figure 15.

Figure 15 - The Edit button at run time

Notice the Edit button on the right side of the Navigation bar and the iAppsReview "back" button on the left side. If you try to click in the Email address or Password text fields, there is no response, and the Log In button is disabled.

2. Click the Edit button and the scene should change as shown in Figure 16.

Figure 16 - The Settings scene in edit mode

The Edit button text changes to Done, the iAppsReview "back" button text changes to Cancel. In addition, the Email address text field has focus and can now be edited as evidenced by the appearance of the keyboard. Nice!

3. We haven't added the Done button logic yet, so to close the app in the Simulator, go back to Xcode and click the Stop button.

Adding Logic to the Done Button

Ultimately, the Edit button and Done button are one in the same. The text of the button is simply changed based on whether or not the scene is in edit mode. So, to add logic that fires when the user taps the Done button, we need to add code to the same editToggle: method you worked with earlier.

1. This time, add code to the first part of the if statement as shown in Figure 17 (note that you will temporarily get an error on the last line of code until you complete the next step).

Figure 17 - Add code to the if statement.

Here are the main steps performed by this code:

• Checks if the UserEntity object exists (it will if the user record has already been created. If not, a new UserEntity object is created. 

• The email and password text is taken from the text fields and stored in the properties of the UserEntity object.

• In the next three lines of code, temporary values are stored in the userID, firstName, and lastName properties of the entity. We will change this code at a later date to add this information, but for now, we'll just set default values (feel free to add your own name instead of mine!)

• Next, a saveEntities message is sent to the User business object. This saves the UserEntity to the database.

• The Login button is enabled

• A cancelEditMode message is sent to the view. You're getting a compiler error because we haven't created this method yet.

2. Now add the cancelEditMode method shown in Figure 18.

Figure 18 - The cancelEditMode method

I broke this code out into a separate method because it needs to be reused elsewhere as you will see in just a bit. Here are the main steps performed by this code:

• Changes the title of the Done button to Edit and enables the button

• Hides the Cancel button and displays the standard iAppsReview "back" button

• Enables the Sign Up and Feedback buttons

• Disables user interaction in the email and password text fields

• Sets isEditMode to NO

 

Testing the Done Button

Now let's see how the Done button functionality works at run time.

1. Click the Start button in Xcode and when the app appears in the Simulator, navigate to the Settings scene.

2. Click the Edit button to put the scene in edit mode.

3. Enter an Email address and press tab.

4. Enter a Password. As you enter the password, notice each character is automatically hidden after you type it.

5. Click the Done button and the scene's appearance should change as shown in Figure 19.

Figure 19 - Finished with edit mode

As you can see, the keyboard is hidden, the Done button changes back to an Edit button, and the Cancel button changes back to the iAppsReview button. At this point you can't click in the Email address or Password text fields, but you can click the Log in button (although it doesn't do anything right now).

6. To prove to yourself that the settings you specified were actually saved to the database, go back to Xcode and click the Stop button, and then click the Run button and navigate back to the Settings scene, where you can see your email address and password. When you're finished marveling at your handiwork, go back to Xcode and click the Stop button again!

Enabling and Disabling the Done Button

As it stands right now, as soon as you click the Edit button and the scene goes into edit mode, you can immediately click the Done button without having entered an email address or password. Obviously this isn't desirable, so let's fix this problem.

1. Scroll to the bottom of the SettingsViewController.m file and add the isLoginReady method shown in Figure 20.

Figure 20 - The isLoginReady method

This code returns YES if there is text in both the Email address and Password text fields. This isn't very robust checking. We would normally add code that checks for a valid email address and we would add rules for acceptable passwords. We'll do this in a future post, but for now, we'll just check for any character in both text fields.

2. Now we need to create an action method that can be called from both text fields when the user types a character. To do this, go to the Project Navigator, select the MainStoryboard.storyboard file and click on the Settings scene to select it. If the Assistant Editor isn't already displayed, click the center button in the Editor button group. If the SettingsViewController.h file isn't displayed in the Assistant Editor, go to the jump bar and select it.

3. Click on the Email address text field to select it, and then go to the Connections Inspector (the button on the far right in the Inspector toolbar). Click on the connection well to the right of the Editing Changed event and then drag down into the SettingsViewController.h file just above the closing @end declaration. When you see the Insert Action popup (Figure 21), release your mouse button. The Editing Changed event fires for a text field whenever the user adds or deletes a character.

Figure 21 - Create a new action method for the Email address text field.

4. In the Create Connection popup, set the Name of the action method to setDoneEnabledValue and then click the Connect button. This adds a method declaration to the header file.

5. Now let's connect the Password text field to the same action method. In the design surface, click the Password text field to select it. Go to the Connection Inspector, and click the connection well to the right of the Editing Changed event. Drag your mouse down to the setDoneEnabledValue action method and when you see the Connect Action popup appear, release your mouse button.

6. Now let's implement the new setDoneEnabledValue method. To do this, go to the Project Navigator and click on the SettingsViewController.m file to select it. Scroll to the bottom of the code file and add the code shown in Figure 22.

Figure 22 - Implement the setDoneEnabledValue method.

This code passes the isLoginReady message to the view controller and stores the returned Boolean value in the Done button's enabled property. If both the email and password text fields are filled in, then the button is enabled, otherwise it's disabled.

7. To complete our logic, we need the setDoneEnabledValue: method to fire when the user first enters edit mode (Done can be enabled/disabled based on whether an email address and password have already been entered). To do this, add a call to the setDoneEnabledValue: method to the editToggle: method as shown in Figure 23.

Figure 23 - Add a call to the setDoneEnabledValue: method.

 

Adding Logic for the Cancel Button
 

There is one more piece of logic we need to add to complete our Settings scene. We need to add the method that is executed when the user taps the Cancel button.