Just as the #1 feedback, being able to use this widget on iOS is a game-changer. The browser shortcut doesn’t work this way. With the browser shortcut, when the screen goes to sleep (like it’s supposed to) the music turns off. With the browser shortcut I can’t listen to a playlist on my phone and do something else with my hands, since I have to keep on coming back to touch the screen to keep it awake.
With the expo wrapper it functions more like a music app.
Obviously it would be nice to have some tweaks (like show what artist), but since the point is to listen when the screen is black not being able to see it is not an issue.
If the iOS PWA doesn’t allow for screen-off listening, it is rather useless!
Android PWA has always had this. IME, it is functionally indistinguishable from an app, although a recent update by Google seems to have removed most audio control buttons from the widget
Added a github spike to track this effort.
Repeating some of the thoughts I shared on the github ticket below:
How would we manage the repo on github?
How does this temporary solution gel with the long-term goal of building a mobile app
Should we also be testing (at-least locally) with the development branch of stream repo considering the Wordpress transition should be launching within the next 2-3 weeks – change the WebView source prop to source={{ uri: 'https://stream.resonate.ninja/discover' }}. As far as I know, the only difference for the streaming player from a visual perspective should be signup/login flow and account settings
Establish a process of QA testing the the mobile app when the streaming player is going to be updated
@piper, I just wanted to take a second on this thread to seriously thank you for stepping up and using your skills to just do this.
I have pushed and pushed and pushed for this exact approach to a temporary Resonate app for years now, and I’ve felt it’s been a struggle to get anyone to take me seriously on it, so this is an enormous breath of fresh air for me personally.
In my view, with just this simple first step, we are one step closer to making this platform as accessible as it needs to be in order for it to be taken seriously by those looking for a music streaming alternative. It’s not gonna be perfect right out of the gate, but again, one step closer… Accessibility.
has been merged, and I’ve pushed the new release associated with it 1.0.4 to both Apple and Android store.
Apple is still reviewing our release so that should be pushed to TestFlight and I’m hoping that should be available for everyone on iOS later today.
With respect to Android, Google Play Console verified my ID and have let me submit the Android 1.0.4 build for their review. Once approved, we should be able to get a public link out to everyone for external testing:
New pull request up to address this issue reported by @boopboop (Minimal Mobile Stream App - #21 by boopboop) where iOS Now Playing and Control Center widgets show current page title instead of page user is currently browsed to. This wouldn’t show them album art metadata, but at least the Artist Name and Track Title would be properly functioning for iOS at least. (Android has album art and artist and title fully functional.)
It seems this is industry standard as well, most commercial industry web players have this enabled (I think because users like having a tab in their browser and being able to glance and see what song it changed to without having to switch to the actual tab).
I’d love to jump in and give the Android build a test run if that’s OK. Seems my Google account needs to be given access first. Really excited about this!
It appears that I can see the public link because I’m logged in, but others may not be able to because Google is still reviewing and we’re waiting for them to approve our request for open testing. I thought since they were showing me a public link that we were ready to go, but clearly not quite yet. In the meantime, if you’re on Android and would like to test, private message me your email and I will get you added to the Internal Testing list.
Just to give everyone visual, our internal testing looks like this:
And our open testing track looks like this:
It looks like it can take an average of a week to get approval for the Google Play Store. So we should be very close.
Hi all! Rich Jensen sent me a link to this forum so I could check out the iOS beta.
I wasn’t able to get past the launch screen because I’ll never toggle App Tracking on. Is there anyway around this in future builds? The stats for people keeping the toggle off are something like 96% last I looked.
I personally wouldn’t turn on App Tracking for a single or any app, even though only turning on the option for each app to individually ask permission, it just feels bad from a UX standpoint. I don’t like the idea of anyone having an “icky” feeling!
I think “to ensure you get the best esperience” might be misleading because “best” is a vague term and what’s better for someone might be worse for some other (and usually what startups think is “best” is absolute shit). I think you could skip that and only say something like “Resonate only uses cookies to garanty core functionalities, such as keeping you logged in for a while, or remembering your theme settings. No other type of activity is tracked” and here I 100% agree with @boopboop we could add a link to the codebase or something and add “if you want to make sure of it you can check our code here” or “if you don’t want to take our word for it you can check our code here” something like that.
I’d be happy to try to test it on my Apple devices. I’ve got business grade internet here so shouldn’t have any issues with connection etc. Just let me know what the turn around time is and I am happy to submit bug reports to whomever etc.
Yes, we’d be happy to have you test! Here’s the TestFlight link. Feel free to post any bugs you find in this thread. Currently, it will only allow you to test if you enable Tracking for the app in Settings > Privacy > Tracking.
