Lecture Notes: Designing a Photo Application

Speaker Introduction

• Speaker: DJ Messock
• Profession: Android Developer since 2012
• Work Experience: Zburbank, Kaspersky (Software Expert, Software Architect)
• Key Responsibilities:
  • Software Expert: Command patterns, architectural design principles, mobile team
  • Software Architect: Testing infrastructure used by 1000+ developers
• Author of: Various articles and talks on architecture, analytics, Java
• Founder of: Kaspareso library for after-tests in Android

Application to Design: Photo App (Similar to Google Photos)

Requirements

• Audience: Worldwide, especially popular in India
• Main Features:
  • Albums with sharing capabilities
  • Privacy and security as top priorities
  • No photo editing
  • Offline mode capability
• Constraints: Need to handle 1 billion users

Functional Requirements

• Take photo
• Create and manage albums
• Share photos
• Upload and download photos

Non-Functional Requirements

• Network considerations (especially in India)
• Offline storage and access
• Privacy and Security
• Authentication (handled magically for design perspective)

High-Level Design

Modules

1. Take Photo Module: Handles capturing photos
2. Album Module: Inclusion of all photos and albums
3. Photo Watching Module: Viewing photos and albums
4. Sharing Module: Sharing capabilities, could be integrated with Photo Watching module later
5. Storage: For photos and data
6. Encrypting/Decrypting Module: Ensures user photos are secure
7. Offline Mode: Storage and access of photos offline
8. Navigation/Coordinator: Handles navigation between various screens
9. Upload/Download Photos Module: Manages network operations and resume configurations

Additional Components

• Backend: For storage and photo management
• API: Client + API interactions
• Dispatcher: For handling upload/download tasks with network constraints

Detailed Design: Albums and Photos

Album Structure

• Attributes: ID, name, description, list of photo IDs
• Photo Attributes: ID, description, raw bytes/reference to storage
• Consideration: Thumbnails for network efficiency

Storage Decision

• Photos: Stored as encrypted files rather than blobs in database to avoid database bloat and memory issues

Operational Flow

• Repository Pattern: Abstracts data source (online/offline handling) for photo modules
• Tasks vs. Jobs:
  • Tasks: Include downloading photos, triggered by user actions
  • Jobs: Dispatcher handles job execution, ensures network and storage policies' adherence

Sync and Policies

• Sync Operations: Context-aware handling based on network quality, region, and cost
• Policy Adaptation: Real-time experimentation and tweaking based on network/download conditions

Offline Scenarios and Edge Cases

• Local storage management
• Handling interrupted or poor network connections
• User interaction settings for download operations, traffic estimation and resume capabilities

Important Considerations

• User privacy and security should be revisited for detailed implementations
• Design Scalability: Adjusting according to large-scale user base, especially offline and network-specific operations
• Resilience: System should manage sync conflicts, data consistency, and fault tolerance effectively

Miscellaneous Feedback

• Avoid repeating requirements unnecessarily
• Emphasize decision-making criteria for storage and operational flows
• Adaptability to offline-first strategies more explicitly
• Clarity in explaining navigation and coordination components