Open Imveryweird opened 4 years ago
mmazzarolo
commented
4 years ago Hey @Imveryweird , thanks for the feedback. The reason why the app doesn't work in the background is because... it's complicated :) If you know how to do it, we're open to pull requests and support 👍 I have a couple of ideas on how it could be achieved, but they would require a huge rewrite of the app.
G-i-o
commented
3 years ago HI @mmazzarolo,
First thank YOU very so much for this app and for providing it on F-Droid.
Then, I second @Imveryweird proposition very much. ATM I can only use this app at home or when I'm near a power socket because it drains so much battery.
I did not realize it was so much more difficult to make it run in the background since most apps can do this (i.e. all music players etc.) but if that is problematic maybe you could make it to allow export of audio files? So, one could chose all the preferred settings (time + session) and export the audio file to be played with a normal player.
On a side note, I don't know if I should create another ISSUE for this but since I downloaded this from F-Droid, I'd like to make a donation to support the development and as a thank YOU. The easier, most private and safest way for both donors and you, would be to have a cryptocurrency address (or better, few, like Ethereum, Cardano, Tron, Litecoin, a stablecoin etc.) where to send the funds. Maybe you could add one either on the F-Droid page or in an ABOUT page (currenlty missing) on the app itself.
Thank YOU again.
mmazzarolo
commented
3 years ago First thank YOU very so much for this app and for providing it on F-Droid.
Thank you! Is the F-Droid version up-to-date? I wasn't the person who originally posted it on F-Droid and I don't know how to update it there :/
I did not realize it was so much more difficult to make it run in the background since most apps can do this (i.e. all music players etc.)
Yeah, there are a couple of reasons for it being "difficult":
I'm still looking into it from time to time and I have a couple of ideas on how to tackle this work. I just need to find some time to actually give it a try.
but if that is problematic maybe you could make it to allow export of audio files? So, one could chose all the preferred settings (time + session) and export the audio file to be played with a normal player.
That's a smart idea, but I think that would be even more difficult to implement natively. But maybe it could be done on the server-side... 🤔 Let me think about it.
On a side note, I don't know if I should create another ISSUE for this but since I downloaded this from F-Droid, I'd like to make a donation to support the development and as a thank YOU. The easier, most private and safest way for both donors and you, would be to have a cryptocurrency address (or better, few, like Ethereum, Cardano, Tron, Litecoin, a stablecoin etc.) where to send the funds. Maybe you could add one either on the F-Droid page or in an ABOUT page (currenlty missing) on the app itself.
Thank you 😊 But currently I'm not accepting any donation.
mmazzarolo
commented
3 years ago but if that is problematic maybe you could make it to allow export of audio files? So, one could chose all the preferred settings (time + session) and export the audio file to be played with a normal player.
Now that I think about it, do you have any idea of how the other breathing apps run in the background? Do they just run the exercise like if it was an audio track?
mmazzarolo
commented
3 years ago (On a side note, I created https://github.com/mmazzarolo/breathly-app/issues/60 to track the F-Droid support)
G-i-o
commented
3 years ago Thank You Matteo for the prompt and comprehensive reply.
Pity you don't accept donations as it could help to pay for expenses etc. . However, I respect that.
The F-Droid version is outdated, unfortunately (v1.4). So I hope it can be updated at some point but mostly, I hope you'll manage to sort out how to circumnavigate the always-on screen issue. Meanwhile, I'll just carry an extra battery with me. :-)
This is the first and only breathing helper I've ever used but if I can be of any help, I can look at some other and then maybe I'd be able to give you a response on how they run in the background.
I also live with a professional security IT engineer that have in the pass worked and researched Android apps. So, if you like, I could ask him if I can can share his contact with you. Maybe he could give you some friendly but professional advice.
Ta.
On 27/09/2020 16:34, Matteo Mazzarolo - notifications@github.com wrote:
First thank YOU very so much for this app and for providing it on F-Droid.Thank you! Is the F-Droid version up-to-date? I wasn't the person who originally posted it on F-Droid and I don't know how to update it there :/
I did not realize it was so much more difficult to make it run in the background since most apps can do this (i.e. all music players etc.)Yeah, there are a couple of reasons for it being "difficult":
- The app architecture wasn't built with the "guided meditations" in mind. They were added only later on after they have been requested. This means that adding support for the exercises to un in the background requires a non-trivial rewrite of parts of the app.
- The app "framework" (react-native) used by Breathly doesn't offer any tool to run the app in the background out of the box. So it won't be as easy as it would be for other app features.
- (Because of 2) It would probably require some native work on both Android and iOS, and I'm not that good at iOS development 😬
I'm still looking into it from time to time and I have a couple of ideas on how to tackle this work. I just need to find some time to actually give it a try.
but if that is problematic maybe you could make it to allow export of audio files? So, one could chose all the preferred settings (time + session) and export the audio file to be played with a normal player.That's a smart idea, but I think that would be even more difficult to implement natively. But maybe it could be done on the server-side... 🤔 Let me think about it.
On a side note, I don't know if I should create another ISSUE for this but since I downloaded this from F-Droid, I'd like to make a donation to support the development and as a thank YOU. The easier, most private and safest way for both donors and you, would be to have a cryptocurrency address (or better, few, like Ethereum, Cardano, Tron, Litecoin, a stablecoin etc.) where to send the funds. Maybe you could add one either on the F-Droid page or in an ABOUT page (currenlty missing) on the app itself.Thank you 😊 But currently I'm not accepting any donation.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mmazzarolo/breathly-app/issues/54#issuecomment-699650155, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIWPXXJRDXDLO2UDI5BNHIDSH5LQHANCNFSM4PXHCSGQ.
G-i-o
commented
3 years ago Great. Looking forward to see new updates on F-Droid.
Since you don't accept donations, I'll donate to them.
Thank YOU so much. On 27/09/2020 16:53, Matteo Mazzarolo - notifications@github.com wrote:
(On a side note, I created #60 https://github.com/mmazzarolo/breathly-app/issues/60 to track the F-Droid support)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mmazzarolo/breathly-app/issues/54#issuecomment-699652434, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIWPXXK5EU23C3QLB6ASWLLSH5NW7ANCNFSM4PXHCSGQ.
mmazzarolo
commented
3 years ago Just wanted to suggest few apps that run in the background with screen on or off. As they are opensource, you might be able to take some of their code and integrate it into Breathly just with some adjustment rather than having to make "several changes"?
Lineage own Music Player OpenTracks OsmAnd~ AudioAnchor
Thanks @G-i-o for the examples -- unfortunately, they won't help too much for this case.
To add some more context, there are three main problems "blockers" for this feature to be implemented:
n track for every possible combination (or generate them on the spot on the app, which is surely even more complex to do). G-i-o
commented
3 years ago @mmazzarolo I see. However, your description seems to apply solely to the audio players. Maybe OpenTrack works more similarly to Breath as the announcements have an adjustable time between them and they always say something different (Voice synthesized, though).
Also, something it's better than nothing. If the variety of adjustable session settings makes it more complicated, I guess better having at least a couple of sessions with fixed values that can work in the background than nothing.
I also guess from your comment that exporting the session would meet the same difficulties.
What about darkening the screen to simulate turning-off. The app would be running on the foreground as now but the screen would be off and then brought back/re-adjusted to the initial luminosity setup. Would that be easier?
Finally, I do personally appreciate your work and your time constraints. I hope more volunteering devs will like to join and help with the development.
🙏🏼
mmazzarolo
commented
3 years ago Maybe OpenTrack works more similarly to Breath as the announcements have an adjustable time between them and they always say something different (Voice synthesized, though).
I think OpenTrack is Android-only though, right? 🤔
Also, something it's better than nothing. If the variety of adjustable session settings makes it more complicated, I guess better having at least a couple of sessions with fixed values that can work in the background than nothing.
I (kinda) disagree. Half-baked solutions sometimes work but also expand the scope of the app making it even harder to maintain. And the more features you add, the higher the expectations people will have: just as an example, adding the guided meditation LOWERED the score of the app on the play store because people expected the voice to also run in the background. If I need to spend some time on a feature, personally, I prefer to make it work consistently across both iOS and Android. Of course if someone else would like to join and develop a half-baked solution, that would be a different story :)
I also guess from your comment that exporting the session would meet the same difficulties.
Yep :/
What about darkening the screen to simulate turning-off. The app would be running on the foreground as now but the screen would be off and then brought back/re-adjusted to the initial luminosity setup. Would that be easier?
Yeah, this + the OLED rework could be a nice tradeoff. Not 100% sure what can be done on the iOS part for that though, I'll investigate 👍 thanks
G-i-o
commented
3 years ago Yeah, was not even aware (Or maybe forgotten) this was also on Google store + Apple store.
I agree on the expectations and if ratings are important to you, that's a different story. My comment was from the user's perspective....and not your typical Google/Apple user either, who maybe less appreciative.
All, in all whatever works and takes less effort.....time constraints in mind, as mentioned. :pray:
mmazzarolo
commented
3 years ago I agree on the expectations and if ratings are important to you, that's a different story. My comment was from the user's perspective....and not your typical Google/Apple user either, who maybe less appreciative.
To clarify: it's not much about what the rating of the app is, it's more about the reasons behind the ratings. I don't care that much if ratings drop, and I even agree with those users. Adding half-baked features creates unrealistic expectations: we're not supporting running the app in the background, we're only supporting running a handful of combinations... which would probably meet < 5% of the use cases. How should we pick these use cases? What pattern + voice + length should we run in the background? I don't see how this would scale 🙁
(Just my 2 cents — I genuinely appreciate discussing this topic, thanks for contributing 👍 )
G-i-o
commented
3 years ago I guess you always have to start somewhere. I'm not expert of both those app stores and the technicalities of developing what discussed here. However, you should be able to clarify in the description that certain features are at very early stage of development and improvements may come at a slower pace according to your time constrains. In my experience, customers/users always appreciate clarity. After all, no app/piece of software is fully developed with all functions and in perfect state on the first versions. As long as the description clearly says what the app does, it should not be a big problem and people should not be disappointed. A user should not mark you down for something you have not committed to.
As for picking the starting point with the use cases, I might be wrong here, but the difficulty is at the beginning when you have to set the framework to support it. Once it's done for one, adding more cases should not be so time consuming and difficult. Also, you can start adding the first one or two sessions, in the order they are right now. If creating more does not involve programming knowledge, I'd be happy to help.
Finally, I also appreciate your being open to discuss :pray: ....and if darkening the screen or other proposed alternatives work better for you, I'm all for them.
mmazzarolo
commented
3 years ago My understanding of this:
I guess better having at least a couple of sessions with fixed values that can work in the background than nothing.
Was to manually create the tracks for a few sessions. Meaning that we won't setup a "framework" as you mentioned below 👇
As for picking the starting point with the use cases, I might be wrong here, but the difficulty is at the beginning when you have to set the framework to support it. Once it's done for one, adding more cases should not be so time consuming and difficult.
So adding more cases would mean doing the entire same manual process again. That's why I don't think it would be scalable. Maybe I misunderstood your suggestion?
G-i-o
commented
3 years ago For my limited knowledge in the specific subject, when you do make a couple of sessions with fixed values and then want to add more, you don't need to start from scratch. The path is already set. You'll need to tweak here and there.
Even if you do it manually, at least if you use Linux, one can find tons of CLI commands and other tools that can help. For instance, I think there's a way to re-direct the audio, piping it into a ogg/opus file. I would have to re-research on it but basically, if so, you'd only need to play one session on Android (or simulated environment) to create the pre-recorded session. An initial learning curve but once learn and done, takes only few minutes. In fact, I might even look into it myself, whether it can be done via ADB or KDE Connect, for instance.
Just doing some brainstorming to find a viable solution. 😛️
🙏️
On Sat, 2021-05-15 at 05:14 -0700, Matteo Mazzarolo wrote:
My understanding of this:
I guess better having at least a couple of sessions with fixed values that can work in the background than nothing. Was to manually create the tracks for a few sessions. Meaning that we won't setup a "framework" as you mentioned below 👇 As for picking the starting point with the use cases, I might be wrong here, but the difficulty is at the beginning when you have to set the framework to support it. Once it's done for one, adding more cases should not be so time consuming and difficult. So adding more cases would mean doing the entire same manual process again. That's why I don't think it would be scalable. Maybe I misunderstood your suggestion? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
mmazzarolo
commented
3 years ago For my limited knowledge in the specific subject, when you do make a couple of sessions with fixed values and then want to add more, you don't need to start from scratch. The path is already set.
The process can definitely be automated, but we would still hit the scaling problem, right? We have an enormous amount of combinations to support, and also: where should these be stored? As I mentioned in an old comment, I think storing them on the client is not a valid option because it would increase the app size a lot. And even storing them on the server would not be possible given the number of permutations. Storing them on the server would also introduce a UX/design question (when/how should they be downloaded?) but it's definitely something we can find a solution for.
In all honesty, the more I think about it, the more I feel like the right path here is to either generate them on the fly on the client or on the server. What do you think?
G-i-o
commented
3 years ago My suggestion is that they could be stored on Github and the app could be able to download them on request and start them using an external audio player.
The combination: at the moment, talking about fixed values, not custom ones, you have 5 sessions. Those could be recorded with a starting point of 5 min individual total length.....so only 5 to start with and then increase the total lenght on request or as time constraints allow.
If automatic download from the app is too demanding, then a message pointing at the location where they can be downloaded from, maybe with a clickable link so that the browser does the job.
On a side note, the audio does not need to be high quality but just decent, so I don't think they would be huge. The 5min ones should be able to fit in 2-3MB, maybe less?
On Sat, 2021-05-15 at 06:10 -0700, Matteo Mazzarolo wrote:
For my limited knowledge in the specific subject, when you do make a couple of sessions with fixed values and then want to add more, you don't need to start from scratch. The path is already set. The process can definitely be automated, but we would still hit the scaling problem, right? We have an enormous amount of combinations to support, and also: where should these be stored? As I mentioned in an old comment, I think storing them on the client is not a valid option because it would increase the app size a lot. And even storing them on the server would not be possible given the number of permutations. Storing them on the server would also introduce a UX/design question (when/how should they be downloaded?) but it's definitely something we can find a solution for. In all honesty, the more I think about it, the more I feel like the right path here is to either generate them on the fly on the client or on the server. What do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
G-i-o
commented
3 years ago So, I've done some research and some thinking and I have few points to add:
• Manually building pre-made tracks can be done but it'd be awkward indeed. This should be kept only as very last resort after all other alternatives have been tried first. • There's an opensource audio file manipulator tool called SOX (see here:http://sox.sourceforge.net/sox.html) that, among many things, allows the merging of different audio files into one single track and automatic creation of silence audio files of different lengths (Here it shows how to create silence files: http://activearchives.org/wiki/Padding_an_audio_file_with_silence_using_sox).
So, in reference to the last point, SOX could be used by BREATHLY to create fixed-value as well as customized sessions and have them saved into a single audio track. If I'm correct, according to what you previously mentioned, this should bring BREATHLY at pair with any normal audio player and thus make running it in the background / with screen off a simple task ?
mmazzarolo
commented
3 years ago Thanks for the research 🙏
I also spent some time thinking through this and I'm now 100% sure that the only way this should land (unless someone else actively develops an alternative solution) is if we can make it run on the client only AND support all configurations AND both Android/iOS. So either build tracks on the fly on the client or find a way to orchestrate the different tracks in the background while the screen is off.
So, in reference to the last point, SOX could be used by BREATHLY to create fixed-value as well as customized sessions and have them saved into a single audio track.
🤔 I'm not sure I'm following how? Does SOX run on iOS and Android (and has a React-Native bridge)?
If I'm correct, according to what you previously mentioned, this should bring BREATHLY at pair with any normal audio player and thus make running it in the background / with screen off a simple task ?
It would definitely not be a simple task, but at least it would be doable 👍 We're still talking of multiple hours of work (between implementation for supporting both platforms + testing).
G-i-o
commented
3 years ago thinking I'm not sure I'm following how? Does SOX run on iOS and Android (and has a React-Native bridge)? You are right, sorry. SOX only runs on Linux for now. However, I think the libraries it uses run on Android too. Even so, I'm not familiar at all with IOS system nor with React-Native.
I agree on everything else you said. So, I guess the most feasible and quickest way to circumvent this issue would be optionally having the client turn the luminosity down to zero and then up to the previous level once the session has ended. Also (I think this might have been suggested already), a full dark mode should also come to help in terms of battery drainage.
The last thing I want to do is stare at my phone for an extended period of time while trying to relax. If I want to go to sleep doing the 4-7-8 breathing technique (btw you also need a custom sleep timer), or if I'm in public trying to calm down, the last thing I wanna have to do is keep my phone screen on while its on my nightstand or in my pocket possibly burning the screen.