[tizen_app_control] Update integration tests

[seungsoo47]

• Relax the 'Can find matching applications' assertion from isNotEmpty to greaterThanOrEqualTo(0): app_control_foreach_app_matched returns APP_CONTROL_ERROR_NONE with an empty list when no apps match, so an empty result is not an error.
• Add 'Can send and receive request with uri and mime': verifies that uri and mime fields are correctly transmitted and received (the existing test only covered the null case).
• Strengthen the String list extra data assertion in 'Omit invalid extra data' to check exact values instead of just isNotEmpty.

Validated on RPI4 and TV emulator (T-samsung-10.0-x86_64): 7 tests, all pass.

[gemini-code-assist]

Code Review

This pull request updates the integration tests for tizen_app_control by relaxing the matched app IDs assertion, adding a test for URI and MIME round-trips, and verifying exact string list extra data. Feedback highlights a tautological assertion on list length that should be replaced with a type check, and a potential race condition in the new test where the broadcast stream should be listened to before triggering the launch request.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Asserting matches.length is greaterThanOrEqualTo(0) is a tautology because a list's length is always non-negative. This assertion will always pass and does not verify anything useful.

If the goal is to verify that the method returns a valid list of strings (even if empty), you can explicitly assert its type using isA<List<String>>().

Suggested change

	expect(matches.length, greaterThanOrEqualTo(0));
	expect(matches, isA<List<String>>());

[gemini-code-assist]

There is a potential race condition here. Since AppControl.onAppControl is a broadcast stream, any events emitted after sendLaunchRequest() completes but before AppControl.onAppControl.first is subscribed to will be lost.

To prevent flakiness, you should start listening to the stream (by creating the Future) before calling sendLaunchRequest().

Suggested change

	await request.sendLaunchRequest();
	final ReceivedAppControl received = await AppControl.onAppControl.first;
	final Future<ReceivedAppControl> receivedFuture = AppControl.onAppControl.first;
	await request.sendLaunchRequest();
	final ReceivedAppControl received = await receivedFuture;