Move display name editing from Profile to Account Settings

[popand]

Summary

This PR improves the user experience by moving the display name editing functionality from the Profile tab to the Account Settings, positioning it logically above the skin type section for better information architecture.

🎯 User Experience Improvement

Before: Display name editing in Profile tab

• "Edit Display Name" action in Profile view alongside other account actions
• Separated from other account configuration options
• Profile view cluttered with editing functionality

After: Display name editing in Account Settings

• Display name section positioned above skin type in Account Settings
• Consolidated with other account-related configurations
• Cleaner Profile view focused on account overview
• Logical grouping of related settings

✨ Key Changes

AccountSettingsView.swift (+74 lines)

• New Display Name Section: Added above skin type section with clean design
• Inline Edit Button: Compact "Edit" button with icon for easy access
• Environment Integration: Uses @EnvironmentObject for AuthenticationManager
• System Prompt Handling: Automatically shows name edit for new users when settings open
• Consistent Styling: Matches existing account settings design patterns

MainContentView.swift (-32 lines)

• Removed ProfileActionRow: Eliminated "Edit Display Name" from profile actions
• Cleaned State Variables: Removed showingNamePrompt and newDisplayName state
• Simplified Profile View: Focus on account overview rather than editing
• Environment Passing: Added environmentObject(authManager) to AccountSettingsView

🏗️ Technical Implementation

Display Name Section Design

// Clean section with inline edit button
VStack(spacing: 16) {
    HStack {
        Image(systemName: "person.circle")
        Text("Display Name")
        Spacer()
        Button("Edit") { /* edit action */ }
    }
    HStack {
        Text(authManager.userDisplayName)
        Spacer()
    }
}

Maintained Functionality

• ✅ Name Validation: Same validation rules and error handling
• ✅ System Prompting: Automatic prompting for new users without names
• ✅ Component Reuse: Uses existing NameInputView component
• ✅ AuthManager Integration: Proper display name updates and persistence

Better Information Architecture

Account Settings:
├── Safety Warning (if applicable)
├── 📝 Display Name (NEW - moved from Profile)
├── 👤 Skin Type
├── 👶 Age Range  
├── 💊 Medical Information
└── 🌡️ Temperature Unit

📱 User Flow

1. Accessing Name Edit: Profile → Account Settings → Display Name → Edit
2. New Users: Automatic prompt when opening Account Settings (if name missing)
3. Existing Users: Manual edit via inline "Edit" button
4. Validation: Same robust validation as before

🧪 Testing

• Build succeeds without errors
• Display name section renders correctly above skin type
• Edit button opens name input sheet
• Name updates properly save and reflect in UI
• Profile view is cleaner without edit action
• Environment object properly passed to AccountSettingsView
• System prompting still works for new users
• Existing NameInputView component works as expected

📊 Benefits

User Experience

• Better Organization: All account settings in one logical location
• Reduced Cognitive Load: Cleaner Profile view focused on overview
• Intuitive Navigation: Name editing where users expect account settings

Code Quality

• Separation of Concerns: Profile for viewing, Settings for editing
• Reduced Complexity: Simplified Profile view with fewer state variables
• Consistent Patterns: Follows existing Account Settings design language

Maintainability

• Centralized Settings: All account configuration in AccountSettingsView
• Component Reuse: Leverages existing NameInputView component
• Clear Responsibilities: Each view has a focused purpose

🔄 Breaking Changes

None - this is a pure UX improvement that maintains all existing functionality while improving information architecture.

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com

[claude]

Claude finished @popand's task —— View job

---

Code Review Complete ✅

Reviewed this PR that moves display name editing from Profile to Account Settings. Here's my comprehensive feedback:

Todo List:

• Read and analyze AccountSettingsView.swift changes
• Read and analyze MainContentView.swift changes
• Review code quality and Swift best practices
• Check for potential bugs or issues
• Assess performance considerations
• Review security concerns
• Evaluate test coverage implications
• Provide comprehensive feedback

---

✅ Overall Assessment

This is a well-implemented UX improvement that successfully moves display name editing to a more logical location. The code follows good SwiftUI patterns and maintains existing functionality.

🔍 Code Quality & Best Practices

Strengths:

• Clean Architecture: Proper separation of concerns between Profile (viewing) and Settings (editing)
• Consistent Design Patterns: New display name section matches existing AccountSettingsView styling
• Environment Object Usage: Correctly uses @EnvironmentObject for AuthenticationManager
• Component Reuse: Smart reuse of existing NameInputView component
• State Management: Proper use of @State for local UI state (showingNameEdit, editingName)

Minor Improvements:

• Accessibility: Consider adding accessibility labels to the Edit button for VoiceOver users:

  .accessibilityLabel("Edit display name")
  .accessibilityHint("Double tap to change your display name")

🐛 Potential Issues

None Found - The implementation is solid:

• ✅ State Synchronization: editingName properly initialized from authManager.userDisplayName
• ✅ Sheet Handling: Correct sheet presentation and dismissal logic
• ✅ Validation: Uses existing validation from NameInputView
• ✅ System Prompting: Maintains automatic prompting for new users via onAppear

⚡ Performance Considerations

Excellent Performance Profile:

• Minimal Overhead: Only adds simple UI elements and state variables
• Efficient Updates: No unnecessary re-renders or expensive operations
• Memory Management: Proper use of value types and @State for UI state

🔒 Security Concerns

No Security Issues:

• ✅ Input Validation: Relies on existing NameInputView validation (trimming whitespace, empty checks)
• ✅ No Data Exposure: No sensitive data handling beyond display names
• ✅ Proper Data Flow: Secure data flow through AuthenticationManager

🧪 Test Coverage Implications

Testing Recommendations:

• Unit Tests: Test the new display name section rendering
• Integration Tests: Verify the edit flow (button tap → sheet → save → UI update)
• Edge Cases: Test behavior when authManager.userDisplayName is empty or very long
• System Prompting: Test automatic prompting for new users without names

Suggested Test Cases:

func testDisplayNameSectionRendersCorrectly()
func testEditButtonOpensNameInputSheet()
func testNameUpdateReflectsInUI()
func testSystemPromptingForNewUsers()

📝 Specific Code Feedback

AccountSettingsView.swift:20-69 - Display Name Section:

• Clean, well-structured implementation
• Good use of HStack/VStack layout
• Appropriate styling matching app design system

MainContentView.swift:289-291 - Environment Object Passing:

• Correct implementation passing authManager to AccountSettingsView
• Proper sheet presentation pattern

Removed Code in MainContentView.swift:

• Clean removal of name editing functionality from Profile
• Maintained all necessary environment object passing

🎯 Code Review Score: 9/10

Deductions:

• Minor accessibility improvements could be added (-1)

Highlights:

• Excellent separation of concerns
• Clean, maintainable code
• Proper SwiftUI patterns
• No security or performance issues
• Well-documented through PR description

💡 Recommendations

1. Add Accessibility: Include accessibility labels for the Edit button
2. Consider Animation: Could add subtle animation when name updates in the UI
3. Error Handling: Consider showing user feedback if name update fails (though AuthenticationManager likely handles this)

This PR is ready for merge - it's a solid improvement to the user experience with clean, well-structured code.

---