Term Project - Milestone 2
Objectives
- To implement 2-3 screens of your application, including a list display.
- To use classes to represent the data in your system.
Collaboration
Work with your project partner(s), if any, on this assignment. The GitHub history must show approximately equal amounts of code contribution from both partners.
Due
Tuesday, April 2 @ 11:59pm via GitHub.
Instructions
Review the overall Term Project Description first.
- Your application’s Home Screen is what the user sees when they load the app.
- Your application’s Primary Display is the starting point for interacting with the main process. In the default project, the Primary Display shows a list of sites on the UNCW campus.
- Your Home Screen and Primary Display may be the same screen. However, you may elect to separate them for navigation reasons. The choice is yours.
Instructions for the Default Project
The term site refers to UNCW buildings, landmarks, or any other point of interest. Which ones you pick are up to you. You will need a picture of each site, which you can take yourself or collect from elsewhere.
- Create a class that represents site information. This class must contain, at a minimum:
- the name of the site.
- a description that says what you want your user to know about the site.
- an image reference that you can use to construct Image widgets for displaying a picture of the site. So you probably want to use a string that specifies where the image is, like
"assets/images/fisher.png"
. - Define a class constructor that initializes the class variables.
- You do not need any other methods than the constructor.
- Create a Dart list of at least six (6) of these site objects that contains your information. You will use this list on your Primary Display. Refer to the Bob Ross example project from the the ListView and the GridView lab and the PageView lab.
- Implement the Primary Display that shows a list of at least six (6) UNCW sites
- The sites must be displayed in a list widget, i.e., a ListView, GridView, or PageView.
- You must use the Dart list from the previous step as your source of data. You may not hardcode values into the list widget.
- You can customize these widgets as you see fit. Or your can make your own list-ish widget so long as it is capable of displaying an arbitrary number of items.
- Each site must have the picture and title displayed. You will need a widget for this, such as a Card or custom stateless widget you create. You may use
Image.network()
orImage.asset()
. - Tapping on a site’s list entry takes you to the Detail Display.
- The sites must be displayed in a list widget, i.e., a ListView, GridView, or PageView.
- Implement the Detail Display that shows all of the content pertaining to a site.
- The user sees the name, image, and description of the site they selected from the Primary Display list. Hint: You should pass the site to your Detail Display screen as a parameter.
- Provide different text styling to distinguish the site name from the site description.
- Display the site’s image at the top of the screen. The image must occupy at least 75% of the screen’s width. You do not have to calculate this precisely in code, just make sure it appears to be true in your testing.
- “Going back” from the Detail Display using either AppBar navigation or system navigation must return the user to the Primary Display.
Instructions for Custom Projects
- Custom projects all have some sort of data that is displayed to the user: a card from a card deck, a professor to be rated, a class or student, etc. Implement at least one Dart class that represents the data with an appropriate constructor and class variables. Specify the class variables and a constructor to initialize those variables.
- Create a Dart list of at least six (6) of these site objects that contains your information. You will use this list on your Primary Display. Refer to the Bob Ross example project from the the ListView and the GridView lab and the PageView lab.
- Create a Primary Display appropriate to your app that displays your data list. The data must be displayed in a list widget, i.e., a ListView, GridView, or PageView.
- You must use the Dart list from the previous step as your source of data. You may not hardcode values into the list widget.
- You can customize these widgets as you see fit. Or your can make your own list-ish widget so long as it is capable of displaying an arbitrary number of items.
- Each list element must display some information from its data object. You will need a widget for this, such as a Card or custom stateless widget you create.
- Tapping on a list element entry takes you to the Secondary Display.
- Implement the Secondary Display that shows all the relevant information from the list element that is necessary for the “next step” in your user’s process. This will obviously vary per project, as each custom project’s workflow is different.
- This Secondary Display should be styled appropriately. It does not necessarily have to be interactive, but can be if appropriate to your app.
- “Going back” from the Secondary Display using either AppBar navigation or system navigation must return the user to the Primary Display.
- You may propose alternative requirements, but they must be approved before you submit your work. The above are minimum requirements for reference, but do not force them if they don’t make sense for your app. Please get in touch with me via Slack, email, or in class to discuss changes to these requirements.
Other General Requirements
- Your app will be tested on a phone. Make sure that you are testing in either the emulator or a real phone.
- Your app must have an App Bar:
- Each Screen must have an appropriate title.
- The App Bar must have backward navigation.
- Adhere to the 8 Golden Rules of Interaction Design
- The project must be free of warnings and errors. These are reported in the “Problems” tab. You may not ignore warnings without instructor permission.
- Your app must not have runtime errors, including crashes and RenderFlex overflow errors.
- Code must be formatted according to Dart conventions. VS Code’s formatting tool will do this for you.
- For those working in pairs: the GitHub history must show approximately equal amounts of code contribution from both partners.
Submission
Commit and push your project to GitHub.