Term Project - Milestone 2

  1. Project Milestones
  2. Objectives
  3. Collaboration
  4. Due
  5. General instructions
    1. Instructions for Dr. Strayhorn-Carter’s Mindfulness Project
    2. Instructions for Custom Projects
  6. Grading
  7. Submission

Project Milestones

Due Title
  Term Project Description
March 16 Milestone 1: Prototypes, User Flow Diagram, and Starter Code
March 23 Milestone 2: Primary and Secondary Display (this page)
April 6 Milestone 3: Authentication and Cloud Data
April 27 Milestone 4: Minimum Viable Product
May 7 Final deliverables

Objectives

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

Sunday, March 23 @ 11:59pm via GitHub.

General instructions

  1. Updated your README.md file to include a statement of “This app was developed primarily for … “ either Android or iOS so I know what to test on. I will evaluate your app based on whether you primarily use Android or iPhone.
    • An Android “Medium Phone” emulated device. This device’s dimensions (1080x2400) is close to that of the loaned Moto G*Power phones (1080x2300).
    • An “iPhone 16” simulator.
  2. Use relative positioning and the axis alignment attributes of Columns, Rows, and Stacks to greatest extend possible to create a “responsive” look and feel across phone sizes.
  3. Do not use large values for SizedBoxes or the margin or padding attributes of widgets to achieve alignments. Use them to create small spaces. Ask me if you’d like feedback on the best way to position something.
  4. Your app must have an App Bar unless otherwise approved by me:
    • Each Screen must have an appropriate title.
    • The App Bar must have backward navigation.
  5. The project must be free of warnings and errors. These are reported in the “Problems” tab. You may not ignore warnings without instructor permission.
  6. Your app must not have runtime errors, including crashes and RenderFlex overflow errors.
  7. Code must be formatted according to Dart conventions. VS Code’s formatting tool will do this for you.
  8. For those working in pairs: the GitHub history must show approximately equal amounts of code contribution from both partners.

Instructions for Dr. Strayhorn-Carter’s Mindfulness Project

  1. Implement the Splash Screen containing the following. Repurpose your Welcome Screen from Milestone 1 as the Splash screen.
    • Create header text with the title of the app “Breathe In, Stand Down”. Style with some emphasis.
    • Add Welcome Text describing the purpose of the app. For now, create your own summary. Dr. Strayhorn-Carter will provide text at a later date.
    • Position and style all text with typographically-pleasing margins, alignment, font size, and coloration.
    • Text must be free of spelling and grammar errors.
    • Provide a means to dismiss or navigate from the Splash Screen to the Progress Screen.
  2. Partially implement the Progress Screen with that displays the following by leveraging instances of the Week class (described below):
    • A ListView of that uses a builder to display a List<Week> representing the 10 Weeks of the program. You have freedom in styling the list.
    • You will manually hardcode the data for now.
    • Each element of the list must display the label: “Week 1”, “Week 2”, etc.
    • Each element of the list must display a visual indicator (icon or image) of the Week’s status.
    • Each element must be tappable. On tap, take the user to a Week Screen. For now, the Weekly Progress should display only the label of the week you tapped on, e.g., “Week 1”, “Week 2”, etc.
    • The user must be able to “Go back” from the the Week Screen to the Progress Screen using either AppBar navigation or system navigation.
  3. Create a Week class that represents a Week of treatment. This class must contain:
    • the label, e.g., “Week 1”, “Week 2”, etc.
    • the order, e.g., 1, 2, 3, etc.
    • the status. For now, simply hardcode or randomly-generate the status of each Week. Ultimately, status will be determined by calendar date in the final product. The possible statuses are:
      • partially completed (in progress)
      • available but not started
      • available but locked because previous weeks are incomplete
      • unavailable. Again, availability will be determined by calendar date in the final product, but can be determined by a flag in your implementation.
    • Define a class constructor that initializes the class variables.
    • You do not need any other methods than the constructor.

Instructions for Custom Projects

  1. Define a class: 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.
  2. Create a Dart list of at least six (6) of these objects that contains your information.
  3. 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. Contact Dr. Layman to negotiate if you believe your Primary Display should be something else.
    • 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.
  4. 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. Contact Dr. Layman to negotiate if you believe your secondary display should be something else.
    • This Secondary Display should be styled appropriately. It does not necessarily have to be interactive, but can be if appropriate to your app.
    • The user must be able to “Go back” to the Primary Display from the Secondary Display using either AppBar navigation or system navigation.
  5. 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.

Grading

Your grade is based on completing the line items from the General Instructions and the project-specific instructions above. Refer to the Rubric on Canvas assignment page.

Submission

Commit and push your project to GitHub.