Yup! Just logged out, quit/killed the app, opened it again and I was still logged out as expected. Seems fixed!
3 Likes
Here’s what I get - using the browser currently set as my default (Iceraven, a Firefox fork), as well as the /e/ OS’s default browser (Chromium based).
Iceraven :
/e/ OS’s default web browser :
And just to be sure, I rechecked using the Resonate app, and yeah, I still do not get the same behavior with that (nothing shows up in the notification area).
@CPacaud that’s unfortunate. According to React Native WebView documentation, it should automatically use your phone’s default browser. I will do some digging and see if we can “force” it to use one we know supports MediaSession, since it appears to be getting confused with your unique setup. Every time I read through their docs I get more ideas for things to implement, so fingers crossed we can get this functionality going for you!
2 Likes
I’m way out of my league here, but could it be related to /e/ OS’s use of microG, replacing Google’s proprietary libraries (yeah, I don’t know 100% what that means, I’ll let you read up…)?
1 Like
It doesn’t look like React Native WebView lets you set or request a particular browser from the user’s OS. The fact that /e/ OS’s default web browser clearly supports MediaSession but not with the app makes me suspect /e/ is having trouble realizing it’s technically a browser and treating it as such. I believe on Android you can bookmark a webpage and it’s not really differentiatable from an app, so until there’s an update from /e/ that happens to correct this or we finish our native app development, this may unfortunately be the only decent option for /e/ users. I’ve changed a few parameters in this next update (1.1.1), so I’m gonna hope that one of them will happen to make /e/ happy and realize how it should treat this app, but it’s a bit of a shot in the dark.
1 Like
There will be a big end of the week update coming down the pipe in the next version 1.1.1, which should be available to everyone on Android/Apple stores sometime tomorrow.
1.1.1 Release Notes
- Origin Allowlist: Open all URLs to non-Resonate based sites in user’s browser. This list
- Automatically refresh WebView on crash or iOS terminates the session after it was inactive for some minutes
- Status Bar no longer occasionally changes its color to the same color as the background
- Link to Resonate’s GitHub on the Cookie Policy page now opens in a modal browser in-app for a more cozy user experience
- Loading indicator while WebView is loading, and we no longer flash the Cookie Policy for a second if user has already chosen to accept or deny permissions, gives the perception that the app is loading faster because users don’t sit around waiting with a blank white screen
A lot of changes under the hood were put into place for this version, so I really appreciate everyone’s diligence in testing so we can make sure I didn’t break anything or cause any regressions with this update! Cheers, and happy Friday everyone! 
2 Likes
@CPacaud, version 1.1.1 (11) has arrived on the stores now. Along with the other improvements mentioned above, I did manage to enable something that your /e/ browser may need to be enabled to use MediaSession. When you get a chance, please let me know if the most recent version gets your music playback controls showing up in your system notification area.
That’s a great idea! Maybe they might be able to tell us how to sort it out.
I’ll write up a post summing up the issue over there later today and share the link here. Maybe if more technical questions come up you could chime in at that point ?
1 Like
Here we go!
1 Like
As of this afternoon, version 1.1.3 has been released in Android and iOS stores. This includes some really great load time optimization, removing the Cookie Prompt that would flutter for users even if they’d already accepted/denied permissions (since the Cookie Prompt was slowing down load times for all users and really was only seen once [on the first use] by the 4% of iOS 14+ users that don’t have Tracking disallowed).
Also have managed to reduce the package size to around 5MB (super small for a modern app, and great because it helps folks who have slower connections), and things are feeling a bit snappier and slightly less laggy. There were a lot of improvements under the hood to drastically reduce the total amount of code necessary for full functionality, so things are looking really lean and minimal at this point!
More improvements have occurred in the stream repository that help out iOS users with the app, like this issue where iOS users would see miniscule back arrow icons. There are a few other areas the icons are still small for iOS users, but now that we know how to address the problem those should be sorted soon as well. This was the most glaringly/immediately obvious bug for iOS so it’s really exciting that this is getting addressed.
I’ve also created an issue for @CPacaud’s /e/ setup that we’re looking for a solution for.
3 Likes
I think I am on iOS 12.12 something. (I’m on an iPhone 6, the last one with a headphone jack!) My iPad is newer though. So I figured I would test there. Good to know about the known issues. I will try to read up on that so I dont make more logs of things already known. Also I appreciate knowing that there are some issues that are tied to the site wide player. Would it be useful for testing purposes to be cross checking across both? You tell me what is most helpful and I will do my best.
3 Likes
@KallieMarie, iPad testing would be great. I’ve done very little of it myself so far, so that would be super helpful!
And yes, the issues for the stream repository will pretty much all apply to and impact the app. (Issues that can be fixed in the app’s code live here, and issues that will need to be fixed in the website’s code live on the website’s issue’s page). I’d pay extra attention to the ones labeled [mobile only] or [mobile/iOS only], as those are all ones that I added personally after noticing it while testing or they were reported by others in this thread. The mobile in this case includes both situations when the website player is viewed in a phone’s browser and with the stream-app.
Because of how the phone app works and how it’s essentially porting the website to app form, there probably won’t be many situations that impact the website’s user interface but not the app, but there will be “higher level” improvements for iOS such as a slightly more app “feel” when you interact with the user interface and continuous background playback (which the website player fails to provide on iOS).
Speaking more generally - a new release, 1.1.4, will go live tomorrow after it is reviewed by Google/Apple.
1.1.4 Release Notes
- On crash, refresh latest page user was on instead of taking user back to homepage
- Allow background fetch, which should help some iOS devices with retrieving the next track for continuous playback when the phone is locked and the screen is dark
2 Likes
I have a question for Android users - does swiping horizontally move your forward and back through pages in the app as it does for iOS? Say you open the app and go to a release on the homepage and it takes you there, if you swipe from the left side of the screen to the right, does it take you back to the homepage (like the back button in your browser would)?
1 Like
Swiping doesn’t seem to do anything on my end (Android).
I think behaviour will depend on how you have the android phone set up.
There are ‘guesture settings’ under System settings for me and I can have 3-button or swipe guestures. I like 3 button so swiping as you describe does not work for me, but I wouldn’t expect it to with my set up.
When I changed to guestures to test, swipe left closed the window - minimise I guess.
Android 11, Nokia 3.4. Just downloaded the app.
Hope that’s useful.
In researching swiping gestures for Android, I believe I’ve found a way to make the System “Back” button take the user to their previous screen (like Back button in the browser would). This will be 1.1.6, and I’ll submit it to stores tonight so it should be available post-review for everyone tomorrow hopefully. After that’s available and we’re sure it works, I will iterate on that and hopefully be able to provide swiping back/forward gestures for Android as well (to match already existing functionality in iOS).
In other news, these adjustments to the website’s code should help the mobile user experience a great deal:
- Pressing a track’s title plays/pauses track #212 - On mobile there is no mouseover/hover, so user’s wouldn’t know that clicking the number would play a track. This makes it so pressing the track’s title also plays the track, making it way easier to play/change the song and widening the area where a user can click (which was quite small previously).
- Fix iOS back arrow size for tags, artists, labels, releases, login pages #206 - Fixes back arrows on remaining pages where it was tiny for iOS mobile.
- Disable zoom in on inputs when pressed for mobile devices #207 - This was causing the app to be ever-so-slightly zoomed in after a user logs in, cutting off the edges of the screen. The user might not notice or know to pinch out, so it seemed like the app was broken.
EDIT: @CPacaud (or any other Android users for that matter), the latest build (1.1.6 / 16), was reviewed and has now been accepted by Google and is available on Google Play, if you’d like, give it a whirl and let me know how the new Back button functionality for Android treats you.
Where are we over this way? Asking because I’m about to debut a show with some folks that spotlights Resonate (via exclusive audio drops), and will have a lot of eyes on it, and I think it would be ideal if we had the app live in stores by then! Let me know. 
@richjensen, let me know if we can connect this week to work out upload situation?
Also, if it’s better to wait, that’s cool too; we can just hold off on announcing anything re: Resonate.
1 Like
The app is in a pretty good place at this point I think. There are one or two fixes for iOS that had to be fixed on the website that will hopefully be reviewed and added to the live site soon, which I got done in the past few days.
It would be great if Android users could test the below item 
(I don’t have an Android device, so I can’t help test that side currently, unfortunately). Once we know that’s working, I can potentially implement swipe left/right to go forward on back for Android users (which works really nicely currently in iOS).
Also, currently our screenshots in the Google Play Store are all iOS and should be Android. If Android users want to take some screenshots (maybe similar to those that are there) on their Android phones and/or tablet devices that would be wonderful, and I can swap those out.
Overall, the app is feeling a lot more stable than the earlier versions. I’m not sure if it would be wiser to turn it on in the app stores after we make the transition off WordPress so it’s the same login across player and forums, or if that matters, since the vast majority of folks will be using it as a music player and not to browse this forum. I’m more than happy to flip the switch to on in the stores if we think it would be a good time to do it! 
2 Likes
