Fix app initialization: localization wiring, DB init, package name, and widget test#4
Conversation
…nd widget test - Fix package name from template_flutter to carbon_tracker - Wire AppLocalizations delegates and supportedLocales into MaterialApp - Initialize database at app startup before runApp - Fix broken widget test to match actual app UI - Delete empty database_test.dart stub that broke test suite - Fix List<dynamic> to List<String> in User model for type safety
github-actions
Bot
added
configuration
WalkthroughThis PR fixes three initialization issues: migrates the package namespace to ChangesApp Initialization and Package Migration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
size/M
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@lib/database/models/user.dart`:
- Around line 7-8: User.fromMap currently assigns jsonDecode(...) results
(List<dynamic>) directly to the typed fields preferredTransports and
frequentTransports which can cause runtime type errors; update User.fromMap to
convert/cast those decoded values to List<String> (e.g. use
List<String>.from(decoded) or decoded.map((e) => e.toString()).toList()) and
handle null or non-list values by providing an empty list default, ensuring
preferredTransports and frequentTransports are always List<String>.
In `@lib/main.dart`:
- Line 8: Replace the startup call to DatabaseHelper().initDB() with a call to
the singleton-initializing accessor DatabaseHelper().getDB() so the
DatabaseHelper._database field is populated and reused; ensure you locate the
startup invocation that currently calls initDB() and change it to getDB()
(keeping DatabaseHelper, initDB, getDB and _database as the reference points).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 7d55f43f-f2c8-4b10-b9c0-1fae541a703a
⛔ Files ignored due to path filters (4)
ios/Flutter/Debug.xcconfigis excluded by!**/ios/**ios/Flutter/Release.xcconfigis excluded by!**/ios/**ios/Podfileis excluded by!**/ios/**pubspec.lockis excluded by!**/*.lock
📒 Files selected for processing (7)
lib/database/database_helper.dartlib/database/models/trips.dartlib/database/models/user.dartlib/main.dartpubspec.yamltest/database_test.darttest/widget_test.dart
| final List<String> preferredTransports; | ||
| final List<String> frequentTransports; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify List<String>-typed fields are currently assigned from raw jsonDecode outputs.
rg -n -C2 "final List<String> preferredTransports|final List<String> frequentTransports|preferredTransports:\s*jsonDecode|frequentTransports:\s*jsonDecode" lib/database/models/user.dartRepository: AOSSIE-Org/CarbonTracker
Length of output: 593
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect User model around fromMap / constructor to see expected types and any additional conversions.
sed -n '1,120p' lib/database/models/user.dart
# Find other occurrences of fromMap or preferred_transports usage to understand how these fields are stored/decoded.
rg -n "preferred_transports|frequent_transports|fromMap\\(" -S lib | head -n 50Repository: AOSSIE-Org/CarbonTracker
Length of output: 2906
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect User model around fromMap / constructor to see expected types and any additional conversions.
sed -n '1,120p' lib/database/models/user.dart
# Find other occurrences of fromMap or preferred_transports usage to understand how these fields are stored/decoded.
rg -n "preferred_transports|frequent_transports|fromMap\\(" -S lib | head -n 50Repository: AOSSIE-Org/CarbonTracker
Length of output: 2906
Cast decoded transport arrays to List<String> in User.fromMap.
User.fromMap assigns raw jsonDecode(...) (for JSON arrays this is typically List<dynamic>) into fields typed as List<String>, which can fail with a runtime type error when constructing User.
Proposed fix
factory User.fromMap(Map<String, dynamic> map) {
return User(
id: map['id'],
- preferredTransports: jsonDecode(map['preferred_transports']),
- frequentTransports: jsonDecode(map['frequent_transports']),
+ preferredTransports:
+ List<String>.from(jsonDecode(map['preferred_transports']) as List),
+ frequentTransports:
+ List<String>.from(jsonDecode(map['frequent_transports']) as List),
trackingMode: map['tracking_mode'],
weight: (map['weight'] as num).toDouble(),
sustainabilityThoughts: map['sustainability_thoughts'],
lastResetMonth: map['last_reset_month'],
lastResetYear: map['last_reset_year'],
);
}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@lib/database/models/user.dart` around lines 7 - 8, User.fromMap currently
assigns jsonDecode(...) results (List<dynamic>) directly to the typed fields
preferredTransports and frequentTransports which can cause runtime type errors;
update User.fromMap to convert/cast those decoded values to List<String> (e.g.
use List<String>.from(decoded) or decoded.map((e) => e.toString()).toList()) and
handle null or non-list values by providing an empty list default, ensuring
preferredTransports and frequentTransports are always List<String>.
|
|
||
| void main() async { | ||
| WidgetsFlutterBinding.ensureInitialized(); | ||
| await DatabaseHelper().initDB(); |
There was a problem hiding this comment.
Use getDB() at startup to initialize the singleton DB handle.
Line 8 currently calls initDB(), but that path does not assign DatabaseHelper._database. The first later getDB() call will initialize again instead of using a prewarmed singleton path.
Proposed fix
void main() async {
WidgetsFlutterBinding.ensureInitialized();
- await DatabaseHelper().initDB();
+ await DatabaseHelper().getDB();
runApp(const MyApp());
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| await DatabaseHelper().initDB(); | |
| void main() async { | |
| WidgetsFlutterBinding.ensureInitialized(); | |
| await DatabaseHelper().getDB(); | |
| runApp(const MyApp()); | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@lib/main.dart` at line 8, Replace the startup call to
DatabaseHelper().initDB() with a call to the singleton-initializing accessor
DatabaseHelper().getDB() so the DatabaseHelper._database field is populated and
reused; ensure you locate the startup invocation that currently calls initDB()
and change it to getDB() (keeping DatabaseHelper, initDB, getDB and _database as
the reference points).
|
Please resolve the merge conflicts before review. Your PR will only be reviewed by a maintainer after all conflicts have been resolved. 📺 Watch this video to understand why conflicts occur and how to resolve them: |
1 participant
Closes #3
Changes
Bug fixes
pubspec.yamlname fromtemplate_fluttertocarbon_trackerto match the projectpackage:template_flutter/...imports topackage:carbon_tracker/...List<dynamic>toList<String>forpreferredTransportsandfrequentTransportsdatabase_test.dartthat caused test suite compilation failureFeatures
localizationsDelegatesandsupportedLocalestoMaterialAppso translation infrastructure actually worksDatabaseHelper().initDB()inmain()beforerunApp()to ensure the database is readyTesting
flutter analyze: No issues foundflutter test: All tests pass (1/1)Summary by CodeRabbit
New Features
Bug Fixes
Chores