Project 3: To Don't List

In this project, you will be programming a mobile app that puts your own creative twist on a generic “To Do List” app. You will learn more about GitHub, practice testing your code in Flutter, and extend an app’s functionality.

Learning Goals

Course Learning Goal	Learning Goal	Career Competency
LG2	Write clear unit tests for classes and widgets	Critical Thinking
LG3	Implement stateless and stateful widgets in Flutter	Technology
LG5	Document your application functionality with Markdown	Communication

Project Structure

Step 1 – Adding Your Jazz

After completing Project 2, you now have a to-do list app, with guarantees in your code that verify it is working correctly, hooray! But to-do list apps are a dime a dozen; it is time for you to augment and adapt this app to be unique. Be creative! Using what we’ve talked about so far in lecture with widgets in Flutter, either riff on what is there, or spin up something new! Is there a particular audience that needs a new twist on a list-based app?

https://docs.flutter.dev/development/ui/widgets-intro

Tip: Please stop by and talk to me if you are in need of some inspiration for creative app ideas.

There are a few requirements for this section:

The user must have multiple opportunities to interact with the app.
- There must be more than just the one Button requirement from the last lab.
Your app must still use the ListView and TextField input widgets as provided in the skeleton code you tested in Step 2.
- Remember, how you use them is up to you.
Your modifications should be significant as opposed to trivial.
- Changing the text content of some Text widgets is not enough. There should be substantive structural changes to the app behind the scenes.
You will need to create at least one new class and one new stateful or stateless widget.
For every new class and widget you create, you need to include a unit test that rigorously tests each of the methods and situations possible in your code.

Note: Remember to commit your code to your repository frequently as you are making these modifications, so you have bite-size checkpoints.

Step 2 – Repository Description and README.md

With your coding complete and tested, it is time to polish up your repository so others know what you have created. Every project you complete in this course will be part of your public GitHub portfolio, so it is helpful to follow the professional guidelines for open-source projects.

2.1 – Renaming Your Repository

First, click on the gear icon ⚙️ next to Settings in the Navigation Bar section on the main github.com page for your forked repository and edit the Repository name section. If your chosen name is multiple words, separate them with a -, as in “to-do-explosion”

2.2 – Adding a Description

Next, click on the gear icon ⚙️ in the About section on the main github.com page for your forked repository and edit the Description section. This should be two sentences at most, written in non-technical language, that clearly describes the intent of your application.

2.3 – Writing an Informative README

When a new GitHub repository is created, it usually comes with at least one file called README.md. README.md is written using Markdown, a simple language for formatting text that can be rendered as a web page. This README.md information will be displayed on the GitHub main page for your repository. Here is a resource specifically for Markdown syntax and GitHub.

https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

Now, with a text editor on your cloned repository, or by clicking on the edit icon ✏️ on the main github.com page for your forked repository, edit the README.md file in the root directory to provide details about your app’s functionality. Be sure to follow the guidelines of the GitHub documentation on what to include in your README.md file.

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes

The most important pieces to include right now are

Who is the audience for this app
What the app does
Why the app is useful
Multiple Screenshots of your app

Tip: For your app screenshots, I recommend saving these images in an /images directory in the root of your repository.

2.4 – Using a Code License

Our final professional open-source development skill is to add a license to your repository. A license specifies how you will allow others to legally use, modify, and share your code. Luckily, you do not need to write your own license, there are many licenses available, and choosealicense.com can help you decide what license is best for your repository.

Follow the instructions below to add a LICENSE file to your repository.

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository

Note: Remember to commit the LICENSE to your repository when you are finished.

Academic Integrity Rules

You must work individually on the first three labs in this course. You may discuss concepts and ideas with your classmates, but the code you turn in must be your own. Your pattern of commits to your GitHub repository are a record of your work; it will be obvious to me if you do not work on this lab individually. I strongly encourage you to schedule office hours meetings with me if you are struggling with elements of this assignment.

Grading Rubric

To Partially Complete this lab, you must

Continue to use ListView and TextFields
Ensure user has multiple input opportunities for interaction
Rename repository and edit description

To Complete this lab, you must do the above and

Make substantial structural modifications to the existing skeleton
Write new classes and stateful widgets
Write Unit Tests for new classes and widgets
Consistently make GitHub commits
Revise README.md file and add screenshots
Add valid LICENSE