Add overlay switcher for the currently loaded Smart scenario

[vibhor1102]

Describe the feature

When a Smart scenario is already loaded and paused, switching to a different scenario currently has a lot of friction if the user is inside the app they are automating.

Current flow:

1. Leave or close the app being automated.
2. Open Klick'r.
3. Select another scenario.
4. Grant screen recording permission again.
5. Return to the app being automated.

The desired flow is much shorter:

1. Pause the currently loaded Smart scenario and tap a Switch button on the floating overlay.
2. Pick another Smart scenario from an overlay list.

Because screen recording permission was already granted for the currently loaded paused scenario, the app should be able to reuse the active media projection session when feasible instead of asking again.

Describe the usage

This is useful when working inside another app/game and needing to swap between several Smart scenarios without leaving that app. The switcher should stay in the overlay layer, not reopen the main scenario list Activity, so the automated app remains foreground.

One possible implementation is an overlay-native switcher:

• show a Switch button on the Smart floating menu only while detection is idle/paused and media projection is active
• open an overlay dialog/bottom sheet listing other Smart scenarios
• selecting a scenario changes the loaded scenario and keeps the existing screen recording session alive
• update the foreground notification and quick settings tile to reflect the selected scenario

Related

This is related to #493, but it is specifically about manual, user-driven switching from the floating overlay while a scenario is already loaded. It is not the same as an automation action that jumps from one scenario to another.

Is it a duplicate?

• There is no exact duplicate

[Nain57]

First of all, thank you for contributing to the project.

I did try the PR provided in #849 and i have to admit, i'm not really a fan of the solution. I definitly need to define some contribution rules in order to avoid developpers working on rejected code (and I'm really sorry about it).

Reworking/Ruling for Feature requests is in my roadmap for Klick'r 4.0.0 release (probably moving it to the Github Discussions).
For now, here are some basic rules (and of course, I'm open to discussion for any of those)

Unlike bugfixes, features changes can impact the whole app and the way users sees it. This is a huge challenge to keep the app as simple as possible while offering more and more features/flexibility to more advanced users. That's why I think changes made for a feature request must be discussed and approved first before starting the development.

Alongside the actual feature implementation, UI/UX must also be decided before developing (where do we add the interface to access the feature / how should it looks). This can be by prototyping, images of what it should looks like, even drawings, as long as we can understand how it will be once implemented in the app. For the developpers around here, yes this is a basically a Scrum ticket 😄.

If you needs icons for the app, please note that all icons are from the Material Icons (or slightly altered ones). You can find them all here: https://fonts.google.com/icons?icon=

That being said, i think I can start to explain why I'm not sure about your implementation:

The main menu is the main hub of the application and this is probably the thing the users sees the most. My main rule about it is to keep it as simple as possible. While I can understand the need for this switch, I don't think it belongs to the main menu.

My proposal as a solution for this would be to move the switch to the Klick'r notification. Currently, there is a button to open the app, which is mainly to help you change scenario more easily. We could change this button behaviour to open a scenario selection dialog instead of the app, allowing to skip the request for media detection.

What do you think ?

[vibhor1102]

@Nain57 While i had designed this feature earlier as myself-first, I'm now down to working out a solution that works for everyone instead.

1. I suggest that we move the Scenario Switcher to the persistent notification, as per your suggestion, and even there, to be visible upon expanding the notification. However, for certain users like me, who rely on multiple scenarios and frequent switching between them, there can be a toggle in the settings to move it to the overlay at will. I'd like to reopen the PR with this architecture in mind, plus the material Design icon integration and fixing some bugs I've noticed with current implementation (i use it everyday via my custom fork of the app)

Wording is meant to be changed, this is just a quick demonstration created with AI.

Thanks for letting me contribute to this amazing project.

[vibhor1102]

@Nain57 What do you think of this idea? Should i work on this approach, and target a v4.1 release?

If you have any specific suggestion on placement within the persistent notification, do let me know. otherwise, i aim to implement it either as a replacement for general Klick'r app opening icon (currently represented by settings/gear icon), or to skip placement in notification entirely. but my stance of a global setting that adds it to the overlay tools permanently remains as the recommended approach, now backed by @ohlalayeah (probably) independently thinking of the same idea.

[Nain57]

So just to simplify, the change would be:

• Rework the notification to add the scenario switcher
• Add a setting to add the toggle to the MainMenu

That's a good compromise for me. I will create a ticket in the project board for that and target 4.1

[ohlalayeah]

Current: If there are various events for the same game and user wants to switch from one event to another event, user has to click "STOP" button -> re-open Klickr app to launch the event list screen -> select another event to run.

Suggestion: add a "Switch Event" button on the floating menu (currently there are PLAY, STOP, SETTINGS and MOVE buttons on the floating menu as show in the attached screenshot), the event list will pop-up and let user switch to another event to run.

[vibhor1102]

Thank you for your suggestion.

Extremely good news: This is the exact roadblock i faced as well, and I've created a solution for myself as well.

While integration into this repository will happen in v4.1 at the earliest, you can use my solution in the meanwhile: https://github.com/vibhor1102/Smart-AutoClicker/releases/tag/v4.0.0-beta03-patched.2

It's based on beta03, and previous releases are also available. Code is open source being a forked repository, and safely inspectable. I intended it for my personal use, but feel free to make use of it as well.

I'll make sure to work on getting the feature into the main Klick'r app via an optional setting that you have to opt-in for as well.

[vibhor1102]

Restored back after a month of invisibility as my account was false-positively flagged