Getting started

To begin this lab, create a new Android project in Android Studio, named according to the lab guidelines $-$ project name should be $$abc$123\_$lab$5,$ where abc$123$ is your UTSA ID$.$

Your project will start with the following:

MainActivity.java $-$ in the edu.utsa.cs$3443.$abc$123\_$lab$5$ package

activity$\_$main.xml $-$ in the res $>$ layout folder

RoleActivity.java $-$ in the edu.utsa.cs$3443.$abc$123\_$lab$5$ package

activity$\_$role.xml $-$ in the res $>$ layout folder

ActActivity.java $-$ in the edu.utsa.cs$3443.$abc$123\_$lab$5$ package

activity$\_$act.xml $-$ in the res $>$ layout folder

Model classes $($in the edu.utsa.cs$3443.$abc$123\_$lab$5.$model package$)$:

User.java

Role.java

Act.java

Scene.java

Your application will read in data and display it to the user.

In this lab, you will decide how to organize some functionality in the model classes.

There are many correct ways to write the code for the model classes, in terms of representing the relationships described in this section. It is recommended that you first draw a rough UML diagram to get an idea of how you want to create your classes before writing any code.

Our model must contain the classes listed above $-$ User, Role, Act, and Scene. Any additional classes are optional.

Users of the app will be cast members, who have roles in a show.

Each show has $2$ acts, and each act has a list of scenes. $($see the provided app views for examples of this data$)$

User

Each User has a username and a password. Since all users are also actors, they will also have a real name, as well as a list of roles that they play $($each user can have $0$ or more roles$).$

The file users.csv Download users.csvOpen this document with ReadSpeaker docReader contains information for Users of the app. Each line in the file contains a user's information, in the following order: username,password,real name,name of role $1,$ name of role $2,...$

The User class will contain a method called validate which should take in a user name and password. This method can be an object method or a class method, and must be called from the controller for the purpose of authenticating the user for log in$.$ You may decide what to return from this method.

If the user exists in the app $($if their user name is found in the given file$),$ then the password should be verified. If the given password is correct, then they should be permitted to move to the next view.

If the user does not exist in the app $($if their user name is not found in the given file$),$ or if the password provided is incorrect, they should not be permitted to move to the next view.

Scenes, Acts, and Roles

Each user has a list of Roles, which are parts that they play within a scene. Each Role has a name for the character.

Each Scene has an identification number $($the order in which it occurs in the act$),$ a title $($given in quotes in our data file$),$ and a list of roles which appear in that scene.

Each Act has a number $($in our case, $1$ or $2)$ and a list of Scenes in the act. Each Act has its own data file containing all of the scenes in that act. For our lab, see act$1.$txt Download act$1.$txtOpen this document with ReadSpeaker docReader and act$2.$txt Download act$2.$txt Open this document with ReadSpeaker docReader for data.

Decide on how you would like to represent the relationships needed between the classes described in this model. Again, there are many correct ways, and it is your choice.

Exception Handling

In this lab, pay special attention to the user experience. Here are a few things to check for to get started:

Is the user able to get beyond the login screen without a valid username and password?

Once they log out, is the user able to get beyond the login screen again $($without logging back in$)?$

If the user does not have any roles $($at all, or in the selected act$),$ does the app crash, or does it show the $"$no scenes" message?

If the user clicks the "back" button, does the app crash?