Minimal mobile apps for Android and iOS

A few more updates are on the way.

We’ve added a GitHub link to the Cookie Disclaimer as others suggested above. We also now let the user press a button before being prompted after they’ve read the policy, which makes the feel app a bit politer to the user. Again, this screen will only ever be seen by iOS 14+ users who have Tracking toggled on (which is 4% of users per the resource posted above in this thread).

Screenshots of this in action are visible here:

The new build (1.0.9) with this, along with disabling the pull down to refresh the page feature (it interrupts playback in a way that a user would not expect, and shouldn’t be necessary) has been reviewed and released on both Android and iOS platforms in the links in the first post in this thread.

1 Like

Today, @brndnkng asked if the app was ready/usable enough to post to social media accounts, as it could act as a boon to fundraising efforts.

I know @auggod had some reservations with respect to taking the app official/public on the App store

(perhaps because the UI was very preliminary at the time or because the beta player https://stream.resonate.ninja is not live yet), so I wanted to raise this question in this thread and get everyone’s feedback. Because those changes are not on the main website (namely https://github.com/resonatecoop/stream/pull/182, which makes the player match device theme preference the same as the status bar does) users will not have access to the absolute latest and greatest just yet. Update: as of March 2, 2022, these UI fixes are live!

Outside of this, in my testing things seem to be working pretty much as expected, with the exception of back arrow icons appearing as tiny/invisible on iOS and the Learn dropdown is non-functional on iOS.

As of the time of writing this, here’s the current strength/limitations breakdown - The way in which we’re wrapping the React Native code using the Expo platform is providing features that the Progressive Web App (i.e Resonate’s stream website when viewed on mobile) lack:

• Downloadable app from Google Play/Apple App stores and automatically creates a shortcut to the app on the user’s Home Screen
• The feel of the user interaction is improved: buttons and scrolling respond to user input in a less clunky and more app-like manner
• A more immersive user experience as the additional screen space because there is no browser address bar.
• (iOS 15+ only) A functioning Now Playing control visible from when the phone was locked or the user swipes to use their Control Center. (This was already functioning for the Android Progressive Web App [the website on mobile].)
• (iOS only) Playback continues even when the phone is locked, background play functions as expected.

Current limitations we’re currently aware of (which are also impacting the Progressive Web App [the mobile website], and will need to be solved by fixing them there):
• The UX for a listener creating account isn’t as intuitive as we’d like.
• (iOS only) the Learn dropdown in the top center is non-functional, pressing it does nothing.
• (iOS only) Back icon is invisible or tiny.

Edit: It was also emphasized (and I agree) that this a preliminary alpha created by one user, not a full fledged app created by Resonate at a whole. We don’t want to give the false impression that Resonate has a large dev team and does not need funding.

5 Likes

Imo phrasing it as a call for beta testers might be the best option.

  • sets expectations
  • gives hope
  • people will be happy with the app once they use it
  • it shows real buy-in from resonate

Edit: Something else - it invites users in as members, as people with something to contribute - their friendly and valuable feedback and collaboration, as opposed to never-satisfied customers.

6 Likes

Imo this line of thinking should be extended to the web player as well (and it should have beta clearly displayed in its header), for exactly all the reasons you listed. Wholeheartedly agree.

4 Likes

A couple of notes after using the player a little bit on Android;

  • App name appears as “stream-app” in launcher (Unlauncher, Bliss Launcher (/e/'s default launcher).

  • I’m being automatically logged back in when I open the app after logging out and closing the app - was expecting to have go through log in again.

  • I don’t get music player controls in the system notification area during playback.

  • The “currently listening” bar in the lower area of the app allows for only a very small number of characters for Track and Artist names.

  • This part of the log in flow is a bit confusing -


    there are two Log In button visible, the one at the bottom gets you to the Log In screen, the one in the middle actually logs you in. Pressing the bottom one while on the Log In screen does nothing.

  • System “Back” button takes me out of the app back to the launcher when I’d expect it to back away from the current screen / stay inside the app.

  • Artists/Labels/Releases Browse pages would benefit from having a “list”-like view. If you’d ask me, I’d like having a view similar to what’s on the Track page for those, and an even lighter list view for the the Track page (e.g. group all tracks under a group as a Release, with its associated artwork/artist only shown/listed once for the whole group.)

  • The Track browser page’s performance feels sluggish on my phone - not a powerful beast, but usually handles anything OK.

  • On the UX/look and feel side of things, I’m feeling a lack of feedback on button/UI interaction. For example, I would expect buttons to light up as I touch them, indicating interaction has been made. Sometimes during the few moments between a button press and the action actually happening, without any feedback, I’ll be tempted to press the button again (“maybe I missed it?”). Likewise, I cannot know if I misclicked anything as the unwanted action will occur and I won’t know what I did wrong.

4 Likes

This is great feedback @CPacaud, thank you for taking the time to write this all out!

Yes, this is an interesting subject I’d like to hear folks’ opinions on. I didn’t call the app “Resonate” because I didn’t want it to seem like it was an official app put together by a team of people as opposed to merely a contribution from a member of the community. I called it stream-app as it essentially ports Resonate’s stream repository to mobile. I’d be happy to rename it since there aren’t currently any other apps existing yet.

I think I know what’s causing this. I’m going to release a new version of the app with this fixed, and hopefully this will make this behave as expected (should be as simple as changing a true to a false).

According to the current MediaSession Browser Compatibility, I’m suspecting your phone’s default browser may be using WebView Android or a browser that hasn’t implemented MediaSession support yet. @CPacaud, if you want to test the stream player in your phone’s default web browser and let me know whether or not those controls show up for you there, that would be helpful! If they don’t, then it’s definitely a lack of MediaSession support from the browser.

Also, I see that the tracks screen is laggy/sluggish for you. Please let me know if using that page in your phone’s default browser is a lot faster or about the same so we can compare, when you get the chance! The app should be at worst slightly slower than your browser, but shouldn’t be by much.

The rest of your points apply to the player viewed on mobile, and it’s all really good feedback in my opinion. I’m going to add these as issues in that repository so they can be addressed.

Speaking more generally, some improvements went live today to the website player that make the status bar and the app both match the device’s theme preferences, so the status bar should always be dark if a user’s phone is in dark mode and the rest of the app will follow, etc. :tada:

3 Likes

I think the name of the app should 100% be “Resonate” once it’s live, if there is consensus amongst members on what we’re left with. For whatever that is worth. Anything else would just be confusing and inconsistent, in my humble opinion.

5 Likes

I agree. @piper you should just go with the confidence that the community validates your work to consider it “official”. We can decide about that through a vote if a formal process makes it feel more legitimate but I’m 100% confident we’re all ok calling it our own, it’s too critical of a feature to not have the official stamp and more basically it just looks good already.

4 Likes

Cool, I’ll test it on my iPad as my phone is too old to support it. But backwards compatibility is always nice? :slight_smile:

1 Like

Hi just testing on my iPad now. So far the “Learn” tab in the top left corner doesnt do anything… or is non responsive. There’s also, what I can only assume is a back button? Its a white square just under the resonate logo, once you’ve searched a style of music. Right now it just appears as a white square, but if I click on it it takes me back. However, when it takes me back, while it takes me to the previous page, it orients me to the bottom of the page.

I dont know if this is useful?

2 Likes

With respect to the app name: that’s great feedback everyone, I totally agree. As of the latest version out today, 1.1.0, the name is Resonate! :tada: I suspect the yellow dot next to the name just means it’s in Open Testing and not an official release in the App Store yet. Check it out:
IMG_9178

Along with (hopefully) fixing @CPacaud’s session being persisted even after being logged out, this new version also seems to have fixed an issue where clicking the dropdown would turn the user’s status bar text the same color as the background (making the text almost completely invisible to the user). @CPacaud, when you get a second, could you please let me know if version 1.1.0 still keeps you logged in even after you’ve logged out?

As far as next steps for the app, one of the remaining things to fix that I want to target next is the user gets flashed the Cookie Policy for a brief second while the app checks the users Tracking preferences (i.e they’ve already been asked to accept or deny permissions and the app is checking which one they picked basically). It would be ideal to just keep the Resonate logo front and center here until the player loads, and only show the Cookie Policy if the user hasn’t made that decision yet.

After that, it will be a matter of addressing issues and UX problems inherent to the player itself. Thank you all so much for your ideas and feedback!

Interesting, @KallieMarie, what iOS version is your phone on? It might be Apple being snooty about only letting more recent OS versions use TestFlight. I was able to use it with iOS 14, so I’m guessing you’re on something earlier than that. Note that only iOS 15 supports the Now Playing widget.

Unfortunately, this is a known bug inherent to the player. I’ve been digging into the player code and my knowledge of it has improved in recent weeks, but I still have a long way to go with my understanding of everything. Hopefully we can figure out how to get this one fixed soon!

The functionality of this app is tethered to the functionality of the website player. If we have a bug or UX weakness in the website player’s code it will typically also affect the app. But this can also be a strength - when we fix bugs with the website player we also improve the app for everyone. So it can be bit of a double-edged sword. With the news this week I’m hoping we get a few more software developers keen on volunteering their time to help tackle some of these issues.

5 Likes

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! :tada:

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.

Getting the same behavior, sadly. Could be a good idea to report this on the /e/ forums?

1 Like

That’s a great idea! Maybe they might be able to tell us how to sort it out.