Skip to content

Stop button#30

Merged
Android-PowerUser merged 18 commits intoBackupfrom
stop-button
Jun 5, 2025
Merged

Stop button#30
Android-PowerUser merged 18 commits intoBackupfrom
stop-button

Conversation

@Android-PowerUser
Copy link
Owner

No description provided.

Android-PowerUser and others added 18 commits June 5, 2025 14:15
…rom Gemini 2.0 Flash Lite to Gemini 2.5 Flash Preview.

This involved updating the initial value of `currentModelName` in both `GenerativeViewModelFactory` and the `GenerativeAiViewModelFactory` companion object.

The order of model options in the selection UI remains unchanged.
The guide string for the "Chromium-based Browser" default entry
contained a sequence `\"-\"` which caused a Kotlin compiler error
(unresolved reference, receiver type mismatch for minus operator)
during release builds.

This commit changes the problematic sequence
`tap the \"-\" (multiple times)`
to
`tap the 'minus' symbol (multiple times)`
to avoid the parsing issue and allow the build to complete successfully.
The meaning of the guide text remains the same for you.
This commit introduces a "Stop" button that appears in the PhotoReasoningScreen banner when I am busy processing your request or when the application is executing commands I generated.

Key changes:
- Modified PhotoReasoningScreen.kt to conditionally display a "Stop" button. When the "Stop" button is visible, the regular input elements (text field, "Add Image" button, "New" button, "Send" button) are hidden.
- Implemented logic in PhotoReasoningViewModel.kt for the "Stop" button. Clicking "Stop" cancels my ongoing reasoning tasks (coroutines) and interrupts in-progress command execution loops. It updates the UI state to reflect that the operation was stopped.
- Added a new PhotoReasoningUiState.Stopped state to differentiate user-initiated stops from other states like Loading, Success, or Error.
- Added ViewModel unit tests to verify the cancellation logic, state changes, and chat message updates upon stopping.
- Added screen UI tests to verify the conditional visibility of the "Stop" button and the regular input banner, as well as the invocation of the stop action.

The "Stop" button allows you to interrupt lengthy operations or command sequences, providing better control over the application's behavior.
This commit addresses compilation errors that arose from the implementation of the stop button functionality.

- Corrected unresolved `isActive` references by explicitly using `coroutineContext.isActive` within coroutines and suspend functions. This ensures checks are made against the correct coroutine context.
- Reviewed `return` statements within `sendMessageWithRetry` and related functions to ensure they correctly exit from the intended scope.

These changes resolve the build failures and ensure the stop functionality operates as intended with proper coroutine cancellation checks.
…iewModel

This commit addresses compilation errors by refining how coroutine cancellation is checked.

- Updated `isActive` checks to explicitly use the `isActive` property of the `Job` instances (`currentReasoningJob?.isActive == true` and `commandProcessingJob?.isActive == true`). This avoids reliance on implicit `coroutineContext` which may have caused resolution issues.

These changes aim to resolve build failures.
…branch

Addresses a compilation error where a 'return' statement inside a
`response.text?.let { ... }` block in the `sendMessageWithRetry`
function was attempting a non-local return.

Changed the problematic 'return' to 'return@let' to ensure it
only returns from the lambda block, resolving the "'return' is not
allowed here" error.

This fix is based on the code structure observed on the stop-button
branch.
Fix incorrect return statements in PhotoReasoningViewModel

I'll refactor the `sendMessageWithRetry` function to avoid using `return`
statements that attempt to return from the outer function from within
`let` and `withContext` blocks.

I'll introduce a boolean flag `shouldProceed` to control the execution flow
and ensure that cancellation requests are handled correctly without
triggering compilation errors.
This commit addresses compilation errors related to 'return'
statements being used in disallowed contexts.

Changes include:
- Ensured `return@launch` is used in the `reason()` method's
  `launch` block, specifically within the nested `content` builder,
  to correctly exit the coroutine lambda at lines corresponding
  to the original error locations (approx. 136, 138, 141).
- Verified that the `sendMessageWithRetry` method uses a
  boolean flag (`shouldProceed`) to manage control flow and
  avoid incorrect `return@let` and `return@withContext` statements
  that were previously causing compilation issues.
…el`.

I replaced `return@launch` statements within the `content` block's lambda
with a boolean flag to control processing flow. This resolves a
compilation error where returns were used in an invalid scope.

The `reason` function in `PhotoReasoningViewModel.kt` was modified to:
- Initialize a `shouldContinueProcessing` flag to `true`.
- Inside the `content` builder, if `currentReasoningJob` is inactive,
  this flag is set to `false` instead of an invalid `return@launch`.
- Loops and conditional blocks within `content` now check this flag
  and `break` or skip processing if it's false.
- After the `content` block, if `shouldContinueProcessing` is `false`,
  the coroutine now correctly returns using `return@launch`.

Note: I observed further build issues related to SDK location,
but I believe these are unrelated to these specific code changes.
@Android-PowerUser Android-PowerUser merged commit fe51ad8 into Backup Jun 5, 2025
1 check passed
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