Skip to content

Conversation

@cynthiajoan
Copy link
Collaborator

Description

Replace this paragraph with a description of what this PR is doing. If you're modifying existing behavior, describe the existing behavior, how this PR is changing it, and what motivated the change.

Related Issues

Replace this paragraph with a list of issues related to this PR from the issue database. Indicate, which of these issues are resolved or fixed by this PR. Note that you'll have to prefix the issue numbers with flutter/flutter#.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
  • All existing and new tests are passing.
  • I updated/added relevant documentation (doc comments with ///).
  • The analyzer (melos run analyze) does not report any problems on my PR.
  • I read and followed the Flutter Style Guide.
  • I signed the CLA.
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

  • Yes, this is a breaking change.
  • No, this is not a breaking change.

@cynthiajoan
Copy link
Collaborator Author

/gemini review

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces support for server-side templates in Firebase AI, including new model classes (TemplateGenerativeModel, TemplateImagenModel), API abstractions for template URIs, and a new example page to demonstrate the feature. The core logic seems well-structured and is accompanied by tests. My review includes a few points: a critical fix to remove a debug print statement, a high-severity bug fix in the new example page where user input was being ignored, and a low-severity suggestion to refactor some redundant code for better maintainability.

Comment on lines +263 to +290
Future<void> _sendServerTemplateMessage(String message) async {
setState(() {
_loading = true;
});

try {
var response = await _templateGenerativeModel
?.generateContent('new-greeting', inputs: {});

_messages.add(MessageData(text: response?.text, fromUser: false));

setState(() {
_loading = false;
_scrollDown();
});
} catch (e) {
_showError(e.toString());
setState(() {
_loading = false;
});
} finally {
_textController.clear();
setState(() {
_loading = false;
});
_textFieldFocus.requestFocus();
}
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This method has a couple of issues that affect user experience and correctness:

  1. User message not displayed: The user's input message is not added to the _messages list, so it doesn't appear in the chat UI after being sent.
  2. Unused input: The message parameter is not used in the generateContent call. The inputs map is empty, so the model's response won't be based on what the user typed.

You should add the user's message to the UI and pass it to the model via the inputs map.

Future<Map<String, Object?>> makeRequest(
Uri uri, Map<String, Object?> body) async {
final headers = await _headers();
print('uri: $uri \nbody: $body \nheaders: $headers');

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This print statement appears to be for debugging. It should be removed to avoid logging sensitive information and polluting production logs.

Comment on lines +210 to +212
setState(() {
_loading = false;
});

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

low

This setState call to set _loading = false is redundant, as _loading is already being set to false within the try block (line 200) and the catch block (line 206). To simplify, you could handle setting _loading = false in a single place, for example, only in the finally block, and remove the corresponding setState calls from try and catch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant