Flutter Bloc架构选型咨询：多屏数据共享场景下的方案建议

Hi there! Let's walk through your architecture options and pick the best fit for your app's needs—this is a super common scenario, so we can balance maintainability, performance, and ease of development.

Analysis of Your Candidate Solutions #

1. Split into 4 Independent Blocs #

This is a strong starting point that aligns with the single responsibility principle:

• Global Variables Bloc: Manages language, device type, and other app-wide state—keeps these concerns isolated from feature-specific logic.
• Shared JSON Data Bloc: Handles the 5 pages that rely on the same real-time JSON. This eliminates duplicate code for fetching (both scheduled and user-initiated), parsing, and updating data, ensuring all 5 pages stay in sync automatically.
• Favorites Page Bloc: Manages user favorites, which is a standalone user-specific feature.
• Separate JSON Data Page Bloc: Handles the unique JSON data for that one page, keeping its logic decoupled from other features.

Pros:

• No redundant code for the shared real-time data (critical since it updates every minute and supports manual refreshes).
• Clear separation of concerns makes the codebase easier to debug and maintain.
• Ensures data consistency across the 5 shared pages (e.g., a manual refresh on the search page will immediately reflect in the map page).

Minor Considerations:

• You’ll need to set up proper dependency injection (like using flutter_bloc's BlocProvider with singleton instances) to ensure all 5 shared pages access the same Shared JSON Data Bloc instance.
• For simpler global state (language/device type), you could use a Cubit instead of a full Bloc—it’s lighter since you don’t need complex event streams for these relatively static values.

2. Create a Bloc for Each Page #

This approach is not recommended for your use case:

• The 5 pages sharing JSON data would end up with duplicate logic for fetching, scheduling updates, and handling manual refreshes. This leads to inconsistent data (e.g., one page might have stale data while another is updated) and a maintenance nightmare if you need to change how the data is fetched or parsed.
• It also bloats your codebase with redundant Bloc classes, making it harder to track state changes across related pages.

3. Optimized Alternative to Option 1 #

While option 1 is solid, we can tweak it for better simplicity and performance:

• Replace Global Bloc with a Global Cubit: Language and device type have straightforward state transitions (no complex event chains), so a Cubit is more lightweight and easier to implement than a Bloc.
• Add a Repository Layer to the Shared JSON Bloc: Wrap the data fetching logic (API calls, caching, scheduling) in a dedicated Repository class. The Bloc then delegates data operations to this repository, separating business logic from data access. This makes testing easier—you can mock the repository to test the Bloc without hitting the real API.
• Page-Specific Cubits for UI Logic: For the 5 shared pages, if they need UI-specific state (e.g., search query input, map camera position), use small page-specific Cubits alongside the shared data Bloc. This keeps the shared Bloc focused on global data, while page Cubits handle local UI state.

Final Recommendation #

Go with Option 1, optimized with the tweaks above:

1. Global Cubit: Manages language, device type, and other app-wide preferences.
2. Shared JSON Data Bloc + Repository: Handles the real-time data fetching (scheduled and user-initiated), caching, and state management for the 5 related pages.
3. Favorites Cubit: Manages user favorite entries (standalone feature).
4. Separate JSON Data Cubit: Handles the unique JSON data for that one page.

Key Implementation Tips #

• Use flutter_bloc's MultiBlocProvider at the app root to provide the global cubit and shared data bloc as singletons.
• For page-specific cubits, provide them using BlocProvider within the page’s widget tree so they’re disposed when the page is closed (prevents memory leaks).
• Add local caching (e.g., Hive, SharedPreferences) to the shared JSON repository—this lets you show cached data immediately while fetching the latest update, improving user experience.
• Implement error states in the shared data bloc (e.g., network errors, parsing failures) so pages can display appropriate error UI instead of crashing.

内容的提问来源于stack exchange，提问作者edelweisspath