Term Project - Description

1. Overview
2. Collaboration
3. Option 1: Your own project idea
4. Option 2: Customer project - Breathe In, Stand Down
   1. Outline of weekly content
   2. Intellectual Property notice
   3. Option 2 requirements
5. General requirements for all projects
6. Competition & Reward

Overview

The bulk of your course grade is determined by this term project. You will implement a Flutter application from scratch that will be integrated with cloud-based authentication and database services.

You will deliver incremental functionality across multiple graded milestones, followed by a final deliverable.

The milestone assignments and due dates are collected in the Term Project module on Canvas.

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

Collaboration

I strongly encourage you to work with a partner. This is optional. Partners will earn the same grade on each milestone. Teams will not be expected to complete “larger” assignments than those working alone.

For each milestone, the GitHub commit contribution must indicate approximately 50/50 effort distribution. If a partner contributed nothing tangible, that partner will receive a score of 0. If a partner contributed substantially less, that partner will have the grade reduced by 50%.

Option 1: Your own project idea

Do you have an idea for a project? Something you’ve been dying to implement? We will discuss your idea. You must receive written approval from me on the set of requirements for your application. At a minimum, your project must include the following:

• User login, logout, and signup. The app must remember the signed-in user until they log out.
• Reading, writing, and updating data in a cloud database (we will cover one option for implementing a cloud database in class).
• Integration of at at least two of the following features:
  • content search or filter
  • location-aware features
  • use of phone gallery or camera
  • animation
  • other features to be negotiated with the professor

Option 2: Customer project - Breathe In, Stand Down

You will implement an application for Dr. Shaila Strayhorn-Carter of CHHS. She has designed an intervention for active-duty service members with alcoholism that will be delivered through a mobile application. Please watch the video below on Canvas for an overview of the project:

https://uncw.instructure.com/courses/90553/files/12754600?module_item_id=4022226

This is option is a great resume builder. You are capable of completing the app in its entirety. This is an excellent opportunity to build an app for someone for a good cause.

Outline of weekly content

Dr. Strayhorn-Carter furnished this table to give a better sense of the weekly content – Download the PDF

Intellectual Property notice

UNCW has policies that help determine what each member of the UNCW community can do with the intellectual property they create while attending the university. Those policies can be found here (IP Policy and Copyright Policy).

A project like this, involving students developing an app to distribute faculty-developed content, which is also funded by a grant, fits a category that determines the university owns the final developed app. This will allow the university to distribute the app to those populations that will benefit the most from it, and also give students a real-world, societally impactful app to showcase in their portfolio.

During the project or after, if you think of a separate use case for the functional aspects of the app that you develop, minus the faculty-developed content, feel free to incorporate those into a new app or other software. You can build other things with any code, widgets, or anything else they may build but you can’t use the content provided by Dr. Strayhorn-Carter.

Option 2 requirements

Your app must do the following:

• A Login Screen (email+password) and logout functionality. Signup is not required. The app must remember the signed-in user until they log out.
• A Splash Screen shown after login containing welcome text describing the purpose of the app.
• A Progress Screen, the “home screen” of the app:
  1. A list of the 10 Weeks of the program. Each week should indiciate if it is:
     • available but incomplete. Availability will be determined by calendar date in the final product, but can be determined by a flag in your implementation.
     • 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.
  2. Tapping a Week takes the user to the corresponding Weekly Content Screen.
• A Weekly Content Screen capable of displaying contents in “steps” and enforcing the user must complete each step before moving to the next.
  • The content ordering and content of each step must be pulled from a cloud database. The contents and ordering will be the same for all users.
  • The user must how many steps are in the week and how many they have completed, i.e., their progress.
  • The user may go back to the Progress Screen at any time. Upon re-opening the Weekly Content, the user’s progress on the week must be restored so they can resume where they left off.
  • The user may go view previous steps.
  • Content types are:
    • Videos
    • Audio recordings
    • A free response question displayed and response captured.
      • The UI must confirm that the user wishes to save their response.
      • Once a response is captured, the user may view the question and response but cannot update the response.
• A Survey Screen that displays automatically when the user accesses the app under certain conditions.
  • Four separate surveys are available:
    • At the start of Week 1
    • At the start of Week 5
    • At the start of Week 10
    • At the start of week 15
  • The Survey Screen must automatically pop-up when available and the user has not completed the survey.
  • The Survey Screen displays a URL link to the survey and a text field to enter a completion code. The URL and completion code will be different for each of the surveys.
  • The Survey Screen will validate the code and display an error if the incorrect code is entered.
  • The user can dismiss the screen, but the content of the Progress Screen is disabled until they complete the survey.
  • The user must have the ability to manually display the Survey Screen from the Progress Screen.

General requirements for all projects

• The app’s source code must adhere to the Dart style guide.
• The app’s source code must be free of dead code and commented out code.
• The app’s source code must be free of all Lint warnings and errors. Suppressing these warnings through Lint configuration must be approved on a case-by-case basis by the instructor.
• Your app must be robust/error-free. Quality is valued over style.
• You must work “vertically”. That is, focus on a feature and make it work well. The UI for that feature is finished, the data model is set, error conditions are handled gracefully, you give the user good feedback, etc. Correctly implementing 3 features will earn you more credit than implementing 7 features that are half-broken.

Competition & Reward

The authors of the best implementations for Option 1 and Option 2 at Milestone 4 will be invited to present at the Computing Showcase on May 1 and will be exempt from the Final Exam.

Runners-up will receive bonus points in their Final Exam.