Project 2: To Don't List

Overview

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
LG6	Expand your GitHub skills: forking a repo, licensing.	Professionalism
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

Step 1 – Setting Up Your Repository

Last time, we created a new repository on GitHub. In this lab we will “fork” an existing repository. This allows you to have a personal copy of the code in your own space for edits and changes yet remain connected to the original source code.

1.1 – Forking a Repo

Read the below description of how to fork a repository.

https://docs.github.com/en/get-started/quickstart/fork-a-repo

Now, fork the following repository from GitHub into your own account.

https://github.com/mgoadric/to-dont-list

1.2 – Cloning a Repo

Now, you can clone the repository locally with GitKraken as you did in the last lab. Find to-dont-list in your linked GitHub.com account, navigate to or create a good directory, and click the “Clone the repo!” button.

1.3 – Opening the IDE

Finally, you are ready to open the project in Visual Studio Code. Open Visual Studio, Code and using the File -> Open menu, navigate to the directory of your forked repository and open it.

Step 2 – Unit Testing

You will notice that the provided app is broken in several ways. As we write larger apps, it can become difficult to tease out the exact cause of errors. One way to help find bugs is to test the functionality of each of the classes and widgets we write. Designing good tests requires thinking critically about the behavior you want, and then specifying how you can empirically determine that the code gives you the expected behavior.

2.1 – Run Unit Tests

First, review the Flutter testing documentation discussed in lecture for classes and widgets.

Find the one class and one widget that currently have tests provided.

Run these tests. What errors are identified? For each error you see:

Edit the code to correct the error and pass the test.
Make a commit to your repository with a clear and succinct description of what you are correcting.

Warning: Do not commit all your error corrections for this step at once. You want each commit to be a small bite-sized chunk of coding, so that in case things go wrong later, you can easily identify the individual pieces you wrote.

Step 3 – Adding Your Jazz

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 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 4 – 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.

4.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”

4.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.

4.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.

4.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 two 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

Fork the repository
Correct errors identified by pre-existing unit test
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