pocket-casts-android
pocket-casts-android copied to clipboard
Automattic
Wear OS version
What problem does this address?
Currently, there is no way to listen to podcasts when the waer OS watch is not connected to the phone via bluetooth
What is your proposed solution?
Publishing a trimmed down version of the app targeted for wear OS which will enable the options to stream and Download episodes directly from the watch.
at the momment, none of the big players (besides Spotify) offer a watch version of there podcast app.
Did you search for existing feature suggestions?
- [X] I have searched for existing feature suggestions.
We have gotten a start on this, but it's really just a start. Other priorities are keeping us from spending much time on it at this time. Contributions would be welcome though! 😄
@mchowning Is there some coordination on this effort already? I would love to contribute.
I would love to contribute.
That would be great @Salzian !
Is there some coordination on this effort already?
We were mostly coordinating on private channels before now, but going forward this thread is probably the best place to coordinate now that we want to do that publicly (I'm open to other suggestions though).
We're largely looking to replicate the functionality from Pocket Casts' iOS watch app to start—not because we want the WearOS to be exactly the same as the iOS watch app, but more because that seems like the easiest way to create our first iteration for WearOS. You can do an iOS build yourself to explore the watch app on a simulator, but in case you can't (or don't want) to do that, this is what it looks like.
Our plan was to support offline playback as suggested in https://github.com/Automattic/pocket-casts-android/issues/490.
My inclination would be to focus on the Now-Playing/Up-Next functionality first since that seems like the core functionality. We might even be able to do a release with WearOS support with only that functionality. 🤔 If there's something else you're interested in working on though, feel free to tackle that.
I'm going to review progress on branch add/wear first. I agree that for the beginning, we should focus on getting playback working on Wear OS, especially for standalone users.
Ok, had a look and from what I can tell there's not much actual logic going on. Mostly initial setup of the app and the UI layout of it, am I right?
I think a first step would be to establish the connection between watch and phone to remotely control playback on the phone.
Mostly initial setup of the app and the UI layout of it, am I right?
That's right
think a first step would be to establish the connection between watch and phone to remotely control playback on the phone.
That makes sense to me. 👍
Since this is not yet available yet you can make do with a simple WearOS app created with Tasker + AutoWear for now: https://youtu.be/opzeAOuLOjI
This will be possible if this pull request is merged: https://github.com/Automattic/pocket-casts-android/pull/583
Hope it helps 🙂
I'm not aware of Tasker. Is this the preferred way of implementing the Pocket Casts Wear OS experience? That would make this PR / effort obsolete.
It is not the preferred way, but it's a DYI way of hacking around it 😁 A native Wear OS app would be much better, but in the meantime you can get it working with Tasker in a more basic/harder way.
I just want to say that i appreciate all you working on this. I just got a pixel watch and i'm so sad there's no app yet. Let me know what i can do to help. I'm only a web dev so my skills are not going to be the most useful. Please let me know if i can lend a hand :)
Small update from me, I wasn't able to dive much into it recently due to work stuff. Hope to have a fresh start into December.
The Tasker + AutoWear works great for me. I don't see a need for a dedicated app.
@krisdb like sure but it still enhances plus & who knows it might be quicker & easier to do it direct + if it syncs that will definitely save time, 17 people liked this post so it's - # still valued & appricated, I'm all for alternatives but I wouldn't shame development enjoy your app tho ☺️
I'm just saying don't prioritize it over other functionality as there's an option. If there was no option then I'd say but the work in but building for WearOS is not trivial.
Fair enough, I don't mind them focusing on this it's long requested, what do you want them to be focusing on just interested:)
what do you want them to be focusing on just interested:)
Let's try to keep this issue focused on WearOS. Feel free to open up a discussion though. 🙂
Another issue is developing for WearOS is annoying. I've made some small utility apps for WearOS and abandoned them because they would get approved then rejected. Google has some weird criteria for WearOS apps and approvals take forever. For example, a WearOS app has to look good on square screens even though there are no WearOS watches that are square. All I am saying is don't get into WearOS if you don't have to. Who knows, Google may abandon it like their other products.
The Tasker + AutoWear works great for me. I don't see a need for a dedicated app.
Not trying to restart debate here, but correct me if I'm wrong? The Tasker solutions doesn't support the ability to use PocketCasts without carrying a phone, does it? This a key overdue feature IMO. Appreciate the work on this very much.
Hey everyone! I might spend some time here and there contributing to the Wear OS app. Tonight, I did some investigation into syncing authentication credentials between the Wear OS app and the Android app (sadly, syncing credentials on iOS is not supported).
Google's official guide on this uses the DataClient in the Wearable Data Layer API. In my view, that is a very questionable choice, given that data stored using the DataClient API is synced to Google's servers, as per this table and the "synchronize data" section above it. I think they recommend it for ease of use and optimal user experience (since it makes the data available even if the watch isn't connected to the Android phone via Bluetooth at that particular moment), but it seems to me like a significant security tradeoff.
I believe the best alternative would be to use a MessageClient to send over the token via Bluetooth.
For an app like Pocket Casts, having that token stored on Google's servers probably isn't the end of the world, but I hate that the sample code does that. I could totally imagine an app containing much more sensitive data using that mechanism without realizing the implications. Either way, I'd like to get the Pocket Cast's teams opinions on this.
On my Galaxy Watch 5 (containing the fastest processor in any Wear OS watch on the market), scrolling performance is terrible with a debugProd build, even on the short top-level menu when you're not logged in. When I tried to build a release build, the Gradle task processReleaseGoogleServices errors out, which I'm guessing will be a dead end for me as a non-Automattician (if it matters, I have the #795 branch checked out, which I see seemed to add some Google server related stuff).
Is the scrolling performance good in release mode, or does it need improvement there as well?
I see that horologist has a not-yet-documented Auth Data library, so I started a discussion there as well. Their opinions will probably be valuable: https://github.com/google/horologist/issues/1036
👋 @NoahAndrews !
I might spend some time here and there contributing to the Wear OS app.
That's fantastic! 🎉 We've actually started more actively developing the watch app this week, so your timing is great! Just let me know if there's anything you'd like to work on so we can coordinate.
Google's official guide on this uses the DataClient in the Wearable Data Layer API. In my view, that is a very questionable choice...
You make a lot of good points. In the draft PR with an initial authentication POC that I just opened (I had actually already working on it when you left your comment) I decided to use the Data Layer API since it's the Google-recommended approach and I think it provides a slightly better user experience in because it doesn't require an active connection between the watch and the phone at the time of authentication. That approach is definitely not set in stone though, it's just what I went with for this initial POC. Don't hesitate to comment on that PR with any further thoughts you have.
I see that horologist has a not-yet-documented Auth Data library, so I started a discussion there as well. Their opinions will probably be valuable: https://github.com/google/horologist/issues/1036
👍 Thanks for opening up that issue. I'll be keeping an eye on that as well.
On my Galaxy Watch 5 (containing the fastest processor in any Wear OS watch on the market), scrolling performance is terrible with a debugProd build, even on the short top-level menu when you're not logged in.... Is the scrolling performance good in release mode, or does it need improvement there as well?
The performance is just as terrible on release builds when testing on an actual device 😞 (the watch emulator hides any performance issues).
I haven't had a chance to look into this at all yet, so I don't know what is causing the poor performance, but it is definitely a problem.
When I tried to build a release build, the Gradle task processReleaseGoogleServices errors out...
That's because you're using the fallback google-services.json file, which only covers the debug builds. When anyone tries to build the project without the actual google-services.json file, that fallback file gets copied to wear/google-services.json because and used for debug builds.
I think you may be able to create a release build if you add an applicationIdSuffix of ".debug" for release builds like debug builds have though. Firebase probably won't work, but I don't think that will have any effect on the watch app that would prevent you from testing performance.
We now have a project issue tracking our progress toward an initial release of a watch app. 🎉 If you'd like to contribute, please take a look. 😄
UPDATE: We've replaced that issue with a project board.
https://9to5google.com/2023/03/09/pocket-casts-wear-os-development/
We made the news 😂
Do you want to have someone for testing a beta / pre-release version and maybe get some useful feedback?
We're planning to start doing some open testing in a week or so. 😉
Just a quick question:
I've noticed it has been released now. Are you going to allow use without an account?
I'm somewhat tired of having to create an account for every small thing. My password database already has over 300 entries... :p
If not, I'd like to know why you think it is necessary to force logging in. :)
I'd like to know why you think it is necessary to force logging in. :)
👋 @erebion! There are a few reasons. I figure most users would want to have their playback progress, subscriptions, etc. synced between their watch and their phone. Also, since we just have independent watch playback now, and that's only a Plus feature, that requires login to verify if the user is a Plus user. Once we add the ability to control the phone app from the watch (https://github.com/Automattic/pocket-casts-android/issues/1096), which will be available for free users, then we'll revisit whether it still makes sense to still require login.
I'd like to know why you think it is necessary to force logging in. :)
👋 @erebion! There are a few reasons. I figure most users would want to have their playback progress, subscriptions, etc. synced between their watch and their phone. Also, since we just have independent watch playback now, and that's only a Plus feature, that requires login to verify if the user is a Plus user. Once we add the ability to control the phone app from the watch (https://github.com/Automattic/pocket-casts-android/issues/1096), which will be available for free users, then we'll revisit whether it still makes sense to still require login.
Thanks for the explanation!
Seems reasonable. I just want to point out that people are usually less likely to start using something if they need an account.
I, for example, often look for alternatives as soon as something starts to ask me to log in. Thus I mainly think of this as related to UX. :)
Have a nice day (or night, whatever it is over there :p).