feat: add announcements feature

[tatsutakein]

Summary

• Add announcements menu item to My Page screen for easy access
• Create new feature_announcement module with list screen implementation
• Support different announcement types (info, warning, update) with visual indicators

Implementation Details

• Added navigation from My Page to announcements list
• Created reusable announcement card component with type-based styling
• Implemented mock data for UI demonstration
• Full localization support for English and Japanese

Test plan

• Navigate to My Page and verify announcements menu item appears
• Tap announcements to open the list screen
• Verify different announcement types display correctly
• Test pull-to-refresh functionality
• Verify localization works in both English and Japanese

Closes #279

🤖 Generated with Claude Code

[ishinova-actions]

Commands

Command	Description
/catalog	この Pull Request の Catalog を Firebase Hosting にデプロイ
/gen	コード生成コマンドを実行

[gemini-code-assist]

Hello @tatsutakein, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

Hello! Gemini here, providing a summary of this pull request. This PR introduces a new 'Announcements' feature to the application. It includes creating a dedicated feature module (feature_announcement), adding a new screen to list announcements, implementing a reusable component for displaying individual announcements with type indicators and a 'NEW' badge, and integrating this new screen into the navigation flow from the 'My Page' screen. The feature also includes initial localization support for English and Japanese.

Highlights

• New Feature Module: A new feature module, feature_announcement, has been added to encapsulate the announcements functionality.
• Announcements List Screen: A new screen (AnnouncementListScreen) is introduced to display a list of announcements. It currently uses mock data but includes placeholders for integrating with a data provider and pull-to-refresh.
• Reusable Announcement Card: A new AnnouncementCard widget is created to display individual announcements, supporting different types (info, warning, update) with visual styling and a 'NEW' badge.
• Navigation Integration: An 'Announcements' menu item has been added to the 'My Page' screen, providing navigation to the new list screen via GoRouter.
• Localization: Localization support for the new feature and the My Page menu item has been added for English and Japanese.

Changelog

Click here to see the changelog

• app/mobile/lib/router/app_router.dart
  • Imported the new feature_announcement module.
  • Added a new GoRoute /my/announcements named AppRoutes.announcements under the My Page route, pointing to AnnouncementListScreen.
• app/mobile/lib/router/app_routes.dart
  • Added a new static constant announcements for the route name.
• app/mobile/pubspec.yaml
  • Added feature_announcement as a dependency.
• feature/announcement/.flutter-plugins-dependencies
  • Added generated file listing plugin dependencies for the new module.
• feature/announcement/README.md
  • Added README file describing the new feature module, its purpose, dependencies, components, navigation, state management approach (Riverpod), localization, and development steps.
• feature/announcement/l10n.yaml
  • Added localization configuration file for the feature_announcement module.
• feature/announcement/lib/feature_announcement.dart
  • Added main export file for the module, exporting AnnouncementListScreen.
• feature/announcement/lib/src/gen/l10n/l10n.dart
  • Added generated localization code for the feature_announcement module.
• feature/announcement/lib/src/gen/l10n/l10n_en.dart
  • Added generated English localization strings for the module.
• feature/announcement/lib/src/gen/l10n/l10n_ja.dart
  • Added generated Japanese localization strings for the module.
• feature/announcement/lib/src/l10n/app_en.arb
  • Added English ARB file with strings for announcement titles, empty state, types, and new badge.
• feature/announcement/lib/src/l10n/app_ja.arb
  • Added Japanese ARB file with strings for announcement titles, empty state, types, and new badge.
• feature/announcement/lib/src/ui/component/announcement_card.dart
  • Added AnnouncementCard widget to display individual announcements.
  • Includes styling based on announcement type (info, warning, update).
  • Adds a 'NEW' badge for new announcements.
  • Includes a TODO for navigating to a detail screen on tap.
• feature/announcement/lib/src/ui/screen/announcement_list_screen.dart
  • Added AnnouncementListScreen widget.
  • Displays a list of AnnouncementCard widgets.
  • Uses mock data temporarily (with a TODO to replace).
  • Includes a RefreshIndicator with a placeholder refresh logic (with a TODO to implement).
• feature/announcement/pubspec.yaml
  • Added pubspec.yaml for the new feature_announcement module, defining its dependencies and dev dependencies.
• feature/my/lib/src/gen/l10n/l10n.dart
  • Added generated localization code for the new 'Announcements' menu item in the My Page feature.
• feature/my/lib/src/gen/l10n/l10n_en.dart
  • Added generated English localization string for the 'Announcements' menu item.
• feature/my/lib/src/gen/l10n/l10n_ja.dart
  • Added generated Japanese localization string for the 'Announcements' menu item.
• feature/my/lib/src/l10n/app_en.arb
  • Added English ARB string for the 'Announcements' menu item.
• feature/my/lib/src/l10n/app_ja.arb
  • Added Japanese ARB string for the 'Announcements' menu item.
• feature/my/lib/src/ui/screen/my/my_screen.dart
  • Added a new ListTile for 'Announcements' to the My Screen menu.
  • Configured the ListTile to navigate to the new announcements route.
• pubspec.yaml
  • Added the new feature/announcement module to the workspace definition.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

---

New feature takes flight,
Announcements now in sight,
Code review awaits.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively introduces the new announcements feature. The structure of the feature_announcement module is well-organized, including localization, routing, and basic UI components. The use of mock data for the initial implementation is clearly marked and understandable.

I've identified a few areas for improvement, primarily related to type safety, use of magic strings, and handling of generated files. Addressing these will enhance the robustness and maintainability of the new feature.

Overall, good work on setting up this new feature module!

Summary of Findings

• Version Control of Generated Files: The file feature/announcement/.flutter-plugins-dependencies contains user-specific paths and appears to be generated. It's recommended to add such files to .gitignore.
• Type Safety in UI Components: In AnnouncementCard, the use of Map<String, dynamic> for typeData and subsequent casting can be error-prone. Consider using a dedicated class or record for better type safety.
• Use of Magic Strings: String literals are used for announcement types in AnnouncementCard. Using enums or string constants would improve maintainability and reduce the risk of typos.
• Data Handling with Mock Data: In AnnouncementListScreen, force unwrapping (!) is used when accessing mock data from a map. This could lead to runtime errors. Also, the isNew field is stored as a string in mock data and converted to a boolean, which could be more robustly handled by storing it as a boolean directly or using a simple data model.
• README Content: The README for feature_announcement mentions features like 'Read/unread status' and 'Real-time updates' which are not yet implemented with the current mock data. This is acceptable for an initial feature overview but worth noting for future development alignment. (Low Severity - Not commented directly)
• TODO Comments: Several TODO comments are present (e.g., navigating to detail, implementing refresh logic). These are good placeholders for future work. (Low Severity - Not commented directly)

Merge Readiness

The pull request lays a solid foundation for the announcements feature. However, there are several medium-severity issues related to type safety, magic strings, and version control of generated files that should be addressed to improve code quality and maintainability. I recommend making these changes before merging. As an AI, I am not authorized to approve pull requests; please ensure further review and approval from team members.

[gemini-code-assist]

This file appears to be a generated file containing user-specific paths (e.g., /Users/tatsutakein/...). Such files are generally not recommended for version control as they can lead to merge conflicts and unnecessary diffs for different developers.

Could this file be added to the project's .gitignore file to prevent it from being tracked?

[gemini-code-assist]

The _getTypeData method returns a Map<String, dynamic> and relies on string keys ('icon', 'label', 'color', 'textColor') and type casting (e.g., typeData['color'] as Color). This approach can be prone to runtime errors if keys are misspelled or types are incorrect.

To improve type safety and maintainability, have you considered defining a small helper class or a record to represent TypeData? This would provide compile-time checks and better autocompletion.

For example, a record could look like:

({IconData icon, String label, Color color, Color textColor}) _getTypeData(BuildContext context) {
  // ...
  switch (type) {
    case 'info':
      return (
        icon: Icons.info_outline,
        label: l10n?.announcementTypeInfo ?? 'Information',
        color: theme.colorScheme.primaryContainer,
        textColor: theme.colorScheme.onPrimaryContainer,
      );
    // ... other cases
  }
}

Then, accessing properties would be type-safe, e.g., typeData.icon, typeData.label.

[gemini-code-assist]

The switch (type) statement uses string literals like 'info', 'warning', and 'update' for different announcement types. This can be error-prone (typos) and makes it harder to manage the available types.

Would it be beneficial to define these types as an enum or at least as static const String constants within the AnnouncementCard or a dedicated constants file? This would improve type safety and make the code more self-documenting.

For example, using an enum:

enum AnnouncementType {
  info,
  warning,
  update,
  unknown // for the default case
}

// In the widget, parse the string to the enum
// final AnnouncementType announcementType = AnnouncementType.values.firstWhere(
//   (e) => e.toString().split('.').last == type,
//   orElse: () => AnnouncementType.unknown,
// );

// switch (announcementType) { ... }

This would also make the default case in your _getTypeData more explicit if you map it to AnnouncementType.unknown.

[gemini-code-assist]

Accessing values from the announcement map (which is Map<String, String>) uses the force unwrap operator (!), for example, announcement['title']!. While this might be acceptable for tightly controlled mock data, it can lead to runtime exceptions if a key is missing or misspelled.

To make this more robust, even for mock data, have you considered:

1. Using announcement['key'] ?? 'default_value' if a fallback is acceptable?
2. Defining a simple data class/model for Announcement (even if it's just for the mock data initially) and then populating a List<Announcement>? This would provide type safety and better autocompletion.

For example, a simple class:

class _MockAnnouncement {
  final String title;
  final String description;
  final String type;
  final String date;
  final bool isNew;

  _MockAnnouncement({
    required this.title,
    required this.description,
    required this.type,
    required this.date,
    required this.isNew,
  });
}

// Then _getMockAnnouncements would return List<_MockAnnouncement>
// And you'd access properties like: announcement.title

This also helps with the isNew field, which is currently a string 'true'/'false' in the map but is used as a boolean.

[gemini-code-assist]

The _getMockAnnouncements method returns List<Map<String, String>>. However, the isNew field is stored as a string (e.g., 'true', 'false') within this map. In AnnouncementCard, this string is then converted to a boolean using announcement['isNew'] == 'true'.

This string representation for a boolean value can be a bit fragile. Would it be clearer to store isNew directly as a boolean in your mock data structure? If you adopt a simple model class for announcements as suggested in another comment, this would naturally be handled by defining isNew as a bool type in the class.

If sticking with Map<String, dynamic> for now, you could change the map to List<Map<String, dynamic>> and store isNew as a boolean:

List<Map<String, dynamic>> _getMockAnnouncements() {
  return [
    {
      'title': 'New Feature: Quest Sharing',
      'description': 'You can now share your quests with friends and family!',
      'type': 'update',
      'date': '2024-05-28',
      'isNew': true, // Store as boolean
    },
    // ...
  ];
}
// Then in AnnouncementCard:
// isNew: announcement['isNew'] as bool? ?? false,