Milestone 5

Learning Objectives

• Integrate physical IoT devices from 6P3 Connected Objects course to replace simulators
• Unify tab-based architecture into a cohesive multi-device system with consistent authentication
• Implement offline resilience with graceful degradation and automatic reconnection
• Handle network errors, device disconnections, and edge cases without crashing
• Document complete setup instructions for reproducing the IoT Hub configuration
• Demonstrate live system functionality including real-time telemetry, commands, and error recovery

🔍 Context

Milestone 5 is the culmination of your App Dev III project. In Milestone 4, you built the foundation with device simulators, Azure infrastructure, and individual Expo app tabs/screens.

This milestone will test the integration of all your subsystems with a unified Expo app experience. Your app should handle real-world scenarios gracefully like network outages, device disconnections, unexpected errors, etc.

✅ Requirements

Separate Requirements

These are the requirements for App Dev. Michael and I might have different ways we grade you. Below is what will determine your App Dev grade, Connect Objects will be different. Please refer to Michael’s requirements for your Connected Objects criteria.

1. Physical Device Integration

Plan B

If physical devices are non-functional during the demo, you may use simulators as a backup with a -50% penalty.

• Replace all device simulators with your actual reterminal subsystems from 6P3
• All telemetry data must come from physical sensors (temperature, motion, etc.)
• All commands must control physical actuators (motors, LEDs, etc.)
• Devices communicate through Azure IoT Hub using the same connection architecture from M4

The signalRService singleton in M4 only supports one telemetry callback, which won’t work when you need different handlers for each of your three tabs. Create separate instances instead of using the singleton:

app/(tabs)/device1.tsx (or device2.tsx or device3.tsx)

import { SignalRService } from '../../services/signalr';

// Create a tab-specific instance
const signalRService = new SignalRService();

// Use it normally
await signalRService.start((reading) => {
  // Tab-specific telemetry handler
});

Remove the exported singleton at the bottom of signalr.ts.

2. App Unification

Tip

You can use Expo Go on the emulator or a physical phone. But if you want to take it one step further, you can create a development build and actually install the app for real on your phone!

• All three app tabs must work together without conflicts or crashes on a single device (no switching between teammates phones/emulators to demo different parts of the app)
• TypeScript type definitions properly integrated (union types, no conflicts)
• Consistent authentication/authorization across all tabs (see M4 for baseline)
• Shared state management coordinated across team members
• User logs in once and can access all three app tabs
• All tabs use the same WebSocket connection for real-time updates
• No tab-specific authentication barriers or isolated systems
• Consistent UI patterns and error handling across tabs

3. Offline Resilience & Error Handling

Your app must gracefully handle network disruptions and device failures. This will be tested during the demo by enabling airplane mode.

• App does not crash when network connection is lost
• Displays last known telemetry values when offline
• Shows clear visual indication when disconnected (e.g., “⚠️ Offline” banner)
• Handles WebSocket disconnection without crashing
• Provides informative error messages (not generic “Error occurred”)
• Visual indicator appears when connection is lost
• Automatically attempts to reconnect when network returns
• Updates UI immediately when reconnection succeeds
• Disables command controls when offline (with explanation)
• Logs connection state changes to console for debugging

Testing Scenarios

Refer to Assignment 3’s Error Handling section for comprehensive testing patterns:

1. Enable airplane mode while app is running → Verify graceful degradation
2. Disable airplane mode after being offline → Verify automatic reconnection
3. Disconnect a physical device → Verify app doesn’t crash
4. Send command while offline → Verify appropriate error message

4. Git Integration

• All work must be merged to the main branch and easily accessible
• Git history shows good coordination (meaningful commit messages, proper branching)
• .gitignore properly configured (i.e. no node_modules/ committed)

5. Documentation

Your repository must include complete setup instructions in the README:

• How to obtain Azure connection strings (IoT Hub, Web PubSub, Function App)
• Environment variable names and where to set them
• Dependencies installation steps
• How to run the app
• How to deploy the Azure Function App
• Known issues or limitations
• Relevant 6P3 documentation for physical device setup

The goal is that another team or instructor should be able to clone your repo and configure their own IoT Hub to test your app with your suite of devices.

🎬 Demo Format

Note

Your scheduled demo slot is also your final deadline for this milestone.

During your in-person demo, your team will demonstrate the complete system functionality. All team members must be present. You will be asked to go through each of the requirements stated above and will be graded on the spot. Failure to meet any of the criteria will result in deductions, and you will not have any opportunities after the demo to fix them.

📊 Grading Rubric

Team Grade (17 points)

The entire team receives the same grade based on the complete system integration:

1. Physical Device Integration (5 points)

Points	Criteria
5	All three physical devices fully integrated. Real-time telemetry displays correctly. Commands execute successfully with immediate feedback. All devices handle edge cases.
4	All three devices working with minor issues in telemetry timing or command execution for 1-2 devices. Most edge cases handled.
3	All three devices partially integrated. Some significant issues with telemetry reliability or command execution. Some edge cases cause problems.
2	Only 2 devices working, or all 3 devices have major functionality issues. Major connectivity or data display problems.
1	Only 1 device working, or multiple devices barely functional.
0	Using simulators instead of physical devices, or all devices completely non-functional.

2. App Unification & UI Quality (4 points)

Points	Criteria
4	All three tabs work together seamlessly on a single device (no device switching during demo). Unified authentication (2+ user roles with appropriate authorization). Professional UI across all tabs. Real-time updates instant and reliable. Excellent unified user experience. No conflicts between tabs.
3	All tabs functional on one device with minor integration issues. Authentication works but may have minor inconsistencies across tabs. Good UI. Real-time updates work but may have minor delays. Mostly consistent experience across tabs.
2	Tabs mostly independent with limited integration. Requires switching devices for some features OR authentication present but not fully unified across tabs. Basic UI with usability issues. Real-time updates inconsistent. Some conflicts when switching tabs.
1	Poor integration between tabs. Must switch devices to demo different parts. Authentication missing or only 1 user type. Significant usability problems. Real-time updates unreliable.
0	Tabs don’t work together. No authentication/authorization system. Crashes when switching tabs or non-functional UI.

3. Offline Resilience & Error Handling (5 points)

Points	Criteria
5	Excellent offline handling. App remains stable during airplane mode test. Clear visual indicators. Automatic reconnection works. Informative error messages. Device disconnections handled gracefully.
4	Good offline handling. App mostly stable during disconnection. Visual indicators present. Reconnection works with minor issues. Error messages adequate.
3	Basic offline handling. App doesn’t crash but behavior inconsistent. Visual indicators missing or unclear. Reconnection manual or unreliable.
2	Minimal offline handling. App unstable during disconnection. No visual indicators. Poor error handling.
1	Very poor offline handling. App barely functional during network issues.
0	App crashes during offline test or no error handling implemented.

4. Code Quality, Git, & Documentation (3 points)

Points	Criteria
3	Clean, well-organized code. TypeScript types properly defined and integrated (union types). Meaningful commit messages showing good coordination. Complete README documentation. No console errors.
2	Generally clean code with minor issues. Most types defined. Git history adequate. Documentation mostly complete. Minor console warnings.
1	Acceptable code with multiple issues. Some type conflicts. Poor Git coordination. Incomplete documentation. Console errors present.
0	Poor code quality. Major type conflicts. No Git coordination. Missing documentation. Major console errors.

Peer & Self Assessment (3 points)

After the demo, each team member completes a Moodle Workshop assessment rating their teammates and themselves on:

Criteria	Scale
Did this teammate contribute their fair share?	1-5
Did they communicate effectively with the team?	1-5
Was their code clean and well-documented?	1-5
Did they meet deadlines and commitments?	1-5

Be Honest and Constructive

Peer assessment is anonymous. Focus on specific behaviors and contributions, not personalities.

Example good feedback: “Leia consistently communicated progress in our Discord channel and helped troubleshoot my Azure Function App connection issue.”

Example poor feedback: “Luke was lazy.” (not specific or constructive)

Within 24 hours of your demo, complete the Milestone 5 Peer & Self-Assessment on Moodle Workshop. When you rate yourself, reflect honestly on your contribution percentage, your communication effectiveness, what you could improve, what you learned from teammates, etc.

Completing Assessment is Mandatory

Failing to complete the peer/self-assessment within 24 hours of your demo results in a zero for the whole of Milestone 5.

Final Grade Calculation

Your peer assessment score affects your grade in two ways:

1. As a multiplier on the team grade (accounts for individual contribution)
2. As direct points (rewards positive peer feedback)

Final Grade = (Team Grade × Peer Factor) + Peer Points

Where:
- Peer Factor = Average Peer Score / 20
- Peer Points = (Average Peer Score / 20) × 3

Assume the team earned 15/17 on the team components:

Student	Peer Score	Calculation	Final Grade
Leia (strong contributor)	18/20	(15 × 0.90) + 2.70	16.2/20
Luke (average contributor)	15/20	(15 × 0.75) + 2.25	13.5/20
Han (weak contributor)	8/20	(15 × 0.40) + 1.20	7.2/20

📝 Summary

Component	Points	Notes
Physical Device Integration	5	All three reterminal devices working
App Unification & UI Quality	4	All tabs unified, 2+ user roles with authorization, professional interface
Offline Resilience & Error Handling	5	Airplane mode test required during demo
Code Quality, Git, & Documentation	3	Clean code, types, Git coordination, README
Team Subtotal	17	Shared grade for entire team
Peer & Self Assessment	3*	Multiplier + direct points (see formula above)
TOTAL	20	Team Grade × Peer Factor + Peer Points

Good luck with your final integration!