Assignment 2

Learning Objectives

• Compose navigation with outer (Drawer or Tabs) and inner Stack flows
• Navigate with dynamic routes using route parameters
• Create new items using a modal form with proper state management
• Update existing items with prepopulated edit forms
• Delete items using Alert confirmation prompts to protect destructive actions

• 💯 Worth: 6%
• 📅 Due: See due date on Moodle
• 🚫 Penalty: Late submissions lose 10% per day up to 3 days. Nothing is accepted after 3 days.

🔍 Context

In Assignment 1, you focused on Read with list/card views, filtering, and sorting.

For Assignment 2, you will continue with your app and add a clean navigation architecture plus the rest of CRUD. You’ll keep all Assignment 1 functionality working while adding Create functionality using a modal form, Update functionality with prepopulated edit forms, and Delete functionality with Alert confirmation. You’ll also implement Expo Router structure with outer navigation (Drawer or Tabs) and inner Stack navigation, plus dynamic routes for item-level screens.

🔖 Part 0: Tag & Branch

Since you’ll be making significant architectural changes (migrating from App.tsx to Expo Router), protect your Assignment 1 submission first:

1. Tag your Assignment 1 final state:

   git tag assignment-1-final
   git push origin assignment-1-final

   This creates a permanent bookmark you can return to if needed: git checkout assignment-1-final

2. Create a new branch for Assignment 2:

   git checkout -b assignment-2

   All your A2 work will happen on this branch. You can always go back to main if something breaks.

3. Push the new branch:

   git push -u origin assignment-2

Why Branch?

Branching protects your working A1 code while you restructure for A2. If migration goes wrong, you can always:

• Switch back to main: git checkout main
• Start over from the tag: git reset --hard assignment-1-final
• Cherry-pick specific commits if needed

📐 Part 1: Planning

Before coding, update your README.md on your new assignment-2 branch.

AI Usage Policy

You may use AI tools (Claude, ChatGPT, etc.) to help brainstorm routes, generate diagram markup, or suggest navigation patterns. However:

You must document all AI usage in your README under an “AI Usage” section:

• State what you prompted the AI to do
• Show what it generated vs what you actually used
• Explain why you made changes or accepted suggestions

Example disclosure:

“I asked ChatGPT to generate the route structure for my app. It suggested X, but I changed it to Y because…”

You must understand and validate everything AI suggests. Undisclosed AI usage or blindly accepting AI output violates academic integrity.

1. Route Plan

Plan your route structure including what static and dynamic id-based route(s) you will use. One way to think about routes is imagining what bunx expo-router-sitemap should return if you were to run it on your finished app. Refer back to the Expo Router Challenge we did for a refresher on this.

• Which screens are actual routes vs modals vs alerts?
• How do your dynamic routes map to item IDs?
• What’s your folder structure in app/?

For a todo app with tabs, the routes might look like:

# Main routes (Tabs)

/ → Root (redirects to /todos)
/(tabs)/todos → Todo list screen
/(tabs)/map → Map screen

# Item-level routes (Stack)

/todos/[id] → Todo detail (dynamic route)
/todos/[id]/edit → Edit screen (dynamic route)

# Other routes

/todos/create → Create modal (presented over current screen)

# Not actual routes:

- Delete: Triggered via Alert.alert() from detail screen
- Filters/Sort: UI state within /todos, not separate routes

Map Tab Placeholder

Create a route for the map tab that will be implemented in a future assignment.

2. State Diagram

You’ll have to show your navigation flow between screens just like in game programming. Only now instead of screens in your game, they’re screens in your app. Annotate your diagram with what CRUD operations happen on each screen.

Here’s an example for a simple todo app:

3. UI Sketches

For every screen in your app you’re planning, provide a hand-drawn or digital mockup. You may have a lot of these done already from last assignment, but here’s what I want to see overall for this assignment:

• All outer navigation screens (Drawer or Tabs)
  • You should have at least 2 tabs/drawer links, one for your list/card view, and one for the future map view.
• Item detail screens and what information is displayed (probably want to use Stack for this)
• Edit screen with form fields prepopulated
• Create modal with empty form ready for new entry
• Each sketch must show:
  • Navigation elements (ex. header, tabs, drawer, back button)
  • Key UI components (ex. buttons, inputs, lists, images)
  • Where alerts/modals appear (ex. delete confirmation)

4. Message Me

Once Finished

1. Verify that your README markdown on GitHub is being rendered as you expect.
2. Message me on Teams ASAP so I can verify and provide feedback.

You don’t have to wait for me to start implementing, but just be aware I may ask you to change things in the README which will affect your implementation. Detailed implementation specs coming soon!

🛠️ Part 2: Implementation

Setup

Assignment 1 used the barebone Expo template without Expo Router. While you could manually install Expo Router, it’s easier and safer to scaffold a fresh Expo app with Router pre-configured, then migrate your code.

1. Make sure you’re on your assignment-2 branch:

   git branch  # Should show * assignment-2

2. Create a backup directory and move your current files:

   mkdir ../a1-backup
   rm -rf node_modules  # Delete dependencies
   mv * ../a1-backup/   # Move everything to backup

3. Create a new Expo app with Router in the current directory:

   bunx create-expo-app@latest .

4. Remove the boilerplate code. Make sure to type n when prompted:

   bun run reset-project
   Do you want to move existing files to /app-example instead of deleting them? (Y/n): n

   This clears the example code but keeps the Router setup intact.

5. Verify the clean slate works:

   bun run start

   Press i for iOS or a for Android. You should see a minimal welcome screen.

6. Migrate your Assignment 1 code incrementally:

   • Create a src/ folder in your project root
   • Copy your data/ folder into src/data/
   • Copy your components/ folder into src/components/
   • Copy your types/ or interfaces into src/types/
   • Do NOT copy App.tsx directly, you’ll now need to refactor it into src/app/ routes

7. Refactor your UI into file-based routing:

   • Your single App.tsx will now become multiple route files in src/app/
   • Follow the structure you planned in Part 1
   • Start with the root layout (src/app/_layout.tsx)
   • Then add your tabs/drawer layout (src/app/(tabs)/_layout.tsx)
   • Add your main list screen (src/app/(tabs)/items.tsx or index.tsx)
   • Add your stack navigation for item details (src/app/items/[id].tsx)
   • Test frequently as you add each route

8. If you run into too much trouble and want to start back from step 1, remember you can git reset --hard assignment-1-final since we made the tag earlier.

9. Keep your .devlog.md in the project root and document any migration issues.

Test as You Go

After migrating each piece (data, components, first route), test on both iOS and Android before continuing. This makes debugging much easier than migrating everything at once.

You should have a structure similar to this by the end:

• Directorysrc/

  • Directoryapp/

    • _layout.tsx (root stack layout)
    • index.tsx (redirect to a tab)
    • Directory(tabs)/

      • _layout.tsx (tabs navigation layout)
      • map.tsx (placeholder for future assignment)
      • Directoryitems/

        • index.tsx (main list screen with filter/sort)
        • _layout.tsx (stack navigation layout)
        • create.tsx (modal for creating new item)
        • Directory[id]/

          • index.tsx (item detail screen)
          • edit.tsx (edit screen with prepopulated form)
  • Directorycomponents/ (your reusable components)

    • …
  • Directorydata/ (your seed data)

    • …
  • Directorytypes/ (your TypeScript interfaces)

    • …
• .devlog.md
• package.json
• README.md

Router Configuration

The new Expo template automatically configures Expo Router to look for routes in src/app/ when you have a src/ folder. No additional configuration needed!

Cross-Platform Testing Required

All required features must work on both iOS and Android. Features that only work on one platform receive partial credit at most.

CRUD Operations (6 points)

Implement full in-memory CRUD over your existing item model.

Create (2 points)

Requirements:

• User can create an item from a modal form
• Form captures meaningful fields for your data model
• New item appears immediately in list/card views
• New item participates in filter/sort logic

Criteria	Excellent (2)	Partial (1)	Incomplete (0)
Create	Modal create flow works end-to-end and integrates with existing views/logic	Create exists but has issues (validation/state update/view integration)	No usable create flow

Update (2 points)

Requirements:

• User can edit an existing item from a dedicated edit screen
• Existing values load correctly
• Save updates the target item only
• Updated item reflects in list/card views

Criteria	Excellent (2)	Partial (1)	Incomplete (0)
Update	Edit flow works correctly with stable state updates and persistence in UI	Edit flow exists but is incomplete or error-prone	No usable update flow

Delete + Alert Confirmation (2 points)

Requirements:

• User can trigger delete from details or list actions
• Alert confirmation appears before deletion
• Confirm deletes item; cancel leaves data unchanged
• UI updates immediately after delete

Criteria	Excellent (2)	Partial (1)	Incomplete (0)
Delete + Confirmation	Delete is implemented with proper Alert confirmation and correct UX branches	Delete works but confirmation behavior/state updates are flawed	No proper delete flow

Navigation Architecture (6 points)

Outer Navigation (2 points)

Requirements:

• Use Drawer or Tabs for top-level app sections
• Outer navigation is clean and functional
• At least two top-level sections are reachable

Criteria	Excellent (2)	Partial (1)	Incomplete (0)
Outer Nav	Drawer/Tabs implemented correctly with clear top-level screen access	Outer nav present but weakly configured or inconsistent	No valid outer navigation pattern

Inner Stack Navigation (2 points)

Requirements:

• Item-level flow uses stack navigation
• User can go List → Details → Edit (or equivalent)
• Back navigation behaves correctly

Criteria	Excellent (2)	Partial (1)	Incomplete (0)
Inner Stack	Stack flow is coherent and fully functional for item-level screens	Stack flow exists but route behavior/back flow has issues	No valid inner stack flow

Dynamic Routes (2 points)

Requirements:

• Use at least one dynamic route (e.g., /items/[id])
• Correct item data is shown from route params
• Invalid route handling is reasonable (no hard crashes)

Criteria	Excellent (2)	Partial (1)	Incomplete (0)
Dynamic Routes	Dynamic route(s) implemented correctly with id-based data lookup	Dynamic routing exists but mapping/param usage is inconsistent	No meaningful dynamic route

Code Quality (3 points)

Your code should be clean, readable, and follow best practices.

Requirements:

• All TypeScript types defined (no any types)
• Meaningful variable and function names (not x, temp, thing)
• Comments explaining complex logic
• No console errors or warnings (check terminal/console)
• No unused imports or variables
• Consistent code formatting (indentation, spacing)
• Components are modular and reusable
• Proper file naming conventions (PascalCase for components)

Caution

Run your app and check the terminal/console for any errors or warnings. Refer to https://docs.expo.dev/debugging/tools/ for debugging tips like how to view the console and component tree.

Criteria	Excellent (3)	Good (2)	Needs Improvement (1)	Incomplete (0)
Code Quality	All types defined (no any), meaningful names throughout, helpful comments, zero console errors/warnings, no unused code, consistent formatting, modular components	Minor issues: 1-2 warnings OR occasional unclear names OR some unused imports OR minor formatting inconsistencies	Multiple issues: some any types OR many unclear names OR 3-5 console warnings OR inconsistent formatting	Major issues: extensive any usage OR cryptic variable names OR console errors OR no code organization

📝 Dev Log (5%)

.devlog.md is your design diary. It’s where you document how you approached the assignment, what decisions you made, what challenges you encountered, and how you worked through them, including how you used any AI tools.

This is not a summary of your final product (that’s what your code and commit messages show). Instead, it’s a reflection of your process and thinking.

What to write:

• What approach you chose and why
• Any bugs or roadblocks you encountered and how you solved them
• How you tested and verified your implementation
• If you used AI tools (e.g. ChatGPT, Claude, Copilot), describe:
  • What you asked
  • What it returned
  • What you kept or changed
  • Include links to relevant chat logs when possible

What makes a good devlog:

• Specific technical insights (e.g. “I struggled with connecting the AI paddle’s movement to the ball’s position. I solved this by…”)
• Honest reflection on what you understood and what confused you
• Commentary on any AI output you received, what was useful, what wasn’t

What makes a weak devlog:

• Restating the assignment prompt
• Only describing what the final code does, without process
• Hiding or omitting AI tool usage
• Generic statements with no technical substance

Be concise. Bullet points are fine.

Caution

This must not be generated by AI since I’m looking for your personal reflection.

Criteria	Standard
Process Reflection	Clear explanation of approach, design decisions, and problem-solving steps
Technical Detail	Specifics about code structure, logic, or bugs encountered and fixed
AI Usage Disclosure	Clearly explains how AI was used, what was kept/changed, with reasoning
Insight & Critical Thinking	Thoughtful reflection on what was learned, understood, or found challenging
Clarity & Format	Concise, readable, well-structured with bullet points or short paragraphs

🤖 AI Involvement Category

At the top of your .devlog.md, you must declare your AI involvement category by selecting the option that best describes how you used AI during the assignment:

Category	Description
No Use	You did not use any AI tools at any point.
Tutor	You used AI to explain code, concepts, or errors. No code was generated by AI.
Assistant	You asked AI for code suggestions or snippets and integrated them with understanding.
Reviewer	You wrote the code yourself, then used AI to review, critique, or suggest improvements.

Danger

You must explain your AI usage in your .devlog.md. If you used AI but do not disclose it, that will be considered academic dishonesty.

💬 Self & Peer Assessment (5%)

Note

If you believe you’ve been unfairly assessed by a peer, come see me. I’ll review your case and make sure your grade reflects a fair and accurate evaluation.

You’ll use the Moodle Workshop feature to assess your own work and give feedback on 2 of your peers’ submissions. Assessment is a core developer skill. Reading others’ code, giving constructive feedback, and critically evaluating your own work are things you’ll do constantly in real software teams.

Self-Assessment

Before assessing your peers, you must grade your own submission using the same rubric. This helps you:

• Reflect on your work objectively
• Identify areas you could improve
• Practice evaluating code against clear criteria
• Develop self-awareness about your coding skills

Be honest in your self-assessment. The grade you give yourself is compared to the grade given by your peers and will negatively affect your final grade if there is a large discrepancy, and the thoughtfulness of your reflection will be considered.

Peer Assessment

After completing your self-assessment, you’ll assess 2 of your peers’ submissions. Your assessment grade depends on how thorough, specific, and helpful your feedback is.

1. Test thoroughly. Download each submission, run it on both iOS and Android emulators in the lab.
2. Grade using the rubric. Go through each criterion systematically, choosing the level that best matches what you observe.
3. Provide detailed feedback. Write specific, actionable comments explaining what works well and what needs improvement.
4. Be fair and constructive. Treat your peers like colleagues whose success matters to your team.

Deeper Dive: How Moodle Calculates Your Grade

You receive two grades in a Workshop, the submission grade and the assessment grade.

Submission Grade (90%)

The average of all peer assessments you received for your work.

Assessment Grade (10%)

How well you assessed others, based on how close your assessments are to the “consensus”. Moodle compares all assessments of the same submission and finds the one closest to the average (the “best” assessment). Your assessment grade depends on how similar your assessment is to this consensus:

• If you grade similarly to the majority of assessors → Higher assessment grade
• If you grade very differently from everyone else → Lower assessment grade
• The teacher’s assessment can have more weight to help establish the consensus

Example: Three peers assess the same app. Two give similar scores across all criteria, one gives very different scores. Moodle identifies the two similar assessments as closer to consensus and gives them higher assessment grades. The outlier gets a lower assessment grade.

💻 Code Walkthrough

For each assignment, I might randomly select a few students for a short (10-15 minute) one-on-one code walkthrough. You’ll be asked to explain your implementation, reflect on your design decisions, and answer a few questions. This helps ensure understanding, promotes academic integrity, and prepares you to communicate your work which is an essential skill for every developer. You can be selected for any assignment, so always be ready to walk me through your code.

🌿 Git

We will be using GitHub to submit in this course. You can use either the Git CLI or you can also use VSC’s built-in Git GUI client.

	Visual Studio Code (GUI)	Command Line (CLI)
1	Click the Source Control icon (third down on the left sidebar)	git status - View changed files
2	Click + to stage all changes, or + next to individual files	git add . or git add <filename> - Stage changes
3	Type a commit message in the text box, then click the ✔ to commit	git commit -m "Your message" - Commit staged changes
4	Click ... and choose Push to upload your commit to GitHub	git push - Push commits to GitHub

Commit frequently. It’s good practice, and it also creates a traceable history of your progress.

📥 Submission

Before submitting your assignment, ensure that your app includes all the necessary elements for your peers to properly evaluate your submission.

1. Go to Moodle and click the link for this assignment in the calendar.
2. Click the blue Add Submission button at the top of the workshop page.
   1. Title: A2 Submission.
   2. Submission content: Describe your app briefly and any information your reviewers should know.
   3. Zip your assignment folder (without the node_modules folder!) and attach it as a file. If you care about anonymity:
      • DO NOT include your name in any of the files or folders
      • DO NOT include the .git folder before zipping, otherwise it will contain your commit history which has your name and email in it
      • Optionally, you may include your .devlog.md file if you want to share your design diary with your reviewers
3. Click the Save changes button at the bottom.
4. You’ll be able to start assessing your peers the soon after the assignment is due, look out for an announcement on Teams for when this becomes available.