search

sweakpl / qralarm-android

QRAlarm is an Android alarm clock application that lets the user turn off alarms by scanning the QR Code.
GNU General Public License v3.0
112 stars 10 forks source link

Support for Multiple, distinct Alarms - Scheduling #24

Open tearfulnumpty opened 1 year ago

tearfulnumpty commented 1 year ago

QR Alarm should allow for support of multiple distinct alarms. For example, if I wanted an alarm to be scheduled daily at 8 AM, and nightly at 10 PM, I shouldn't have to reset and change my alarms twice, daily.

It would be nice to merely have these set as a given schedule, and even nicer if it had advanced scheduling techniques allowing for it to repeat on specific weekdays, etc.

sweakpl commented 1 year ago

Hey, this issue has been already touched upon in https://github.com/sweakpl/qralarm-android/issues/5 and https://github.com/sweakpl/qralarm-android/issues/2 threads. This feature is not planned to be added now but may be considered in the future.

tearfulnumpty commented 1 year ago

Those issues only mention scheduled and persistent alarms, but not multiple simultaneous alarms. I believe the functionality of my first paragraph is distinct from scheduling, though my second paragraph included scheduling since it's a related topic.

Even looking past the possibility of scheduling as an explicit option with prompts to the user warning them of the perceived risks, simply having a second alarm which can be set at the same time as the first (aka, "set" concurrently - as in, I can set an alarm for 10 AM and an alarm for 11 AM, and set both of these alarms in one sitting at 9 AM) in a manual fashion would be beneficial. As for the first paragraph's example use case, I would currently have to scroll through a not so great sliding system twice a day to set my alarms. With the proposed feature here, even if I still had to manually enable my alarms daily (without the scheduling or persistent addition, ie. distinct from #5 and #2), I could still have a distinct alarm for the AM and for the PM which would highly mitigate the above problem.

This would also help mitigate problems from others who want a scheduled system. Say someone wants a single alarm M-F and then a different alarm on weekends. With this proposal, you could have a distinct time alarm and separate them by days of the week. For example, Alarm 1 could work for the weekdays M-F. Then, Alarm 2 could work for Saturday, and Alarm 3 could work for Sunday. It's not scheduled in advance, it still needs to be manually enabled within 24 hours of the target alarm time (as is the case now, I would presume), but it solves the problem that most people have, where a manual and tedious process of scrolling through the alarm target time setting on a more frequent basis. Instead, users merely adjust for which preset configuration they want to use, and enable that one.

If multiple alarms are manually configurable and also able to be enabled concurrently, I would also only need to do this manual interaction once a day for my original stated use case in the original post. I think this is distinct from #2 and #5, and I would kindly ask you to reconsider. I hope this makes what I'm asking for clear, and how it seems distinct from the potential scheduling problems. Thanks.

sweakpl commented 1 year ago

I think I understand your case. This is a compromise between alarm scheduling and safety. I like that idea and can see it working although I can not guarantee if and when such feature would be added to the application as it seems to me that it requires some major restructuring in the code. Thank you for contributing either way!