I've had one semester of Computer Science, and have zero clue of how people do stuff like this.
How does he get the UI working so fast and looking so good? How do you reverse engineer an API - this seems like some hacker stuff you'd see in Halt & Catch Fire, in my mind anyways.
I'm sure I'll get there, but right now there's a major disconnect between the C investment calculator text program I made, and these super functional, beautiful works of art.
Once you work in a domain enough - pretty much any domain - you begin to intuitively understand the assumptions that others in the field make. In the case of reverse-engineering the API, he would be able to take an educated guess that eliminates 95% of the possibilities because he can think of how he'd design the API, which is probably close to how other competent people would do it too. That experience is invaluable in making rapid decisions that are going to be 'close enough' a lot of the time.
W.r.t the UI, if you have a package of choice that you use frequently enough, you begin to be able to piece together the building blocks quickly. You have all of the boilerplate code required to make it work more or less committed to memory or, at the very least, in other examples that you can just copy/paste and modify.
Uni isn't really about this experience. The coding you do is essentially just a domain-relevant conduit to help you learn and demonstrate competency over the theories. Uni is usually about the theoretical, not the practical, and that's why a common complaint is that uni teaches stuff that isn't relevant to the 'real world'. What this complaint misses, though, is the ancillary benefits you gain through understanding the theoretical, which isn't necessarily easy to quantify.
In summary, don't be disheartened by the uni stuff not reflecting what you see in reality. Think of it as (an important) half of the puzzle. The other half is the practical experience you pick up along the way. In uni, this is probably going to be side projects - stuff you code and throw in Github and then mention in your resume. In later life, it's your professional work experience. This is no different to other technical disciplines - mechanical engineering, for example, teaches you theory but then undergrads go and do Formula SAE or other undertakings to get that practical experience.
There _is_ a major disconnect! You’re studying computer science and wondering how it applies to software engineering. When I studied CS (graduated a year ago) we never went over things like building a GUI, reverse engineering an API, or designing a UI. Those are software engineering topics. By the time I graduated I learned how to do those things, but it was by learning them on my own. If you want to learn these things you’ll need to take the initiative yourself.
It seems like many if not most computer science students are actually interested in software engineering and not CS. It is a shame that more schools don't offer separate software engineering programs or at least make the distinction between the two more apparent to prospective students.
I am sure I wasn't the only 17 year old told I should get a CS degree if I wanted to be a software developer. Meanwhile the most value I have gotten out of the CS classes that taught me to write a loop in MIPS or two build a XOR gate out of NAND gates is commiserating about those experiences with fellow CS grads. I would have much rather had a class about reverse engineering an API or other less theoretical and more vocational classes.
Knowing how a loop is implemented in MIPS means your now have enough knowledge to debug assembly, and perhaps do low level performance optimisations. It's not useless, just not directly and immediately.
You won't be able to lean on any foundational work if you hadn't learnt it, and you'll have a super hard time doing complex things later, like reverse engineering.
What percentage of developers ever have to debug assembly or do low level performance optimizations? I am 10 years into my career and I have only professionally seen assembly code once. We have abstracted most of these low level things out of the normal life of most developers. That isn't to say it isn't important for some, but there are a lot more developers who would benefit more from a class on design principles than a class on assembly.
For HTTP, this is about as easy as it gets in terms of reverse engineering. In firefox, just hit ctrl-shift-q while on any modern website. The network requests made will be displayed for you and you can then start making your own by guesses at what the programmer would have done.
e.g. on HN you can see that each upvote button press loads an image from
A lot of what class will teach you is theory. They'll cover enough programming so that they can use code to help illustrate theory, and probably not a lot more in the non-elective major classes. In my degree program, there were some electives for UI and graphics programming, some specific languages, and so on. I'm sure there'd be some things about web programming that wouldn't have been available when I was there.
A lot starts out as magic. Class gives you enough to get started and demystifies some things, but I'd recommend doing side projects with classmates, competing in programming competitions, reading about anything that interests you (you'll find things that you have a burning curiosity about; don't wait for them to teach you that in school, because they might not).
My opinion is that the degree gives you a solid theoretical basis, and a checkmark on job listing requirements. Other than that, you're surrounded by a bunch of smart people with overlapping interests. It as perfect a time as any to set up study groups, clubs, and any other group activities you can think of to encourage extra projects and experimentation.
At some point you learn to debug the network requests in your own apps or websites. Once you've done that, it doesn't take a big leap of imagination to realise you can use the same techniques to look at the network requests for other apps and websites. Once you have enough sample requests and responses, you can usually figure out how it all fits together. Sometimes networking might be obfuscated (intentionally or otherwise) to the point that it's much more challenging, but the vast majority of products out there are easily inspectable.
reverse engineering an HTTP api isn't particularly difficult- it's a pretty simple key-value protocol 99% of the time so you just figure out what the values do through experimentation and tampering.
It's very simple API with very basic functionality and this guy probably already did some GUI applications, so he just put few images, buttons, forms and lists together.
Reverse engineering HTTP API is not hard either, open developer console, inspect API requests, responses, etc. You need to have some web development experience, I guess.
Just read any introductory book for OS X programming and you'll be able to build this app yourself.
Honestly reverse engineering the API was probably the easiest part. Just use the app with the inspector open in chrome recording the request and responses, it's probably a REST API and you can assume a bunch based on that.
I think the things I've been happiest with, at least visually, have been a result of the things I've been the most unhappy with to the point where I want to fix them. Things where I understand how I use them and understand how I'd _prefer_ to use them end up working well.
> I've had one semester of Computer Science, and have zero clue of how people do stuff like this.
Just wait, I've had about a decade of front-end dev experience and I think I could reverse engineer an API like this (maybe not quite so quickly). What I couldn't do, however, is write a C investment calculator text program. You're a whiz :)
I might be taking you too literally, but I think “just wait” is bad advice. Many of my peers at college graduated without ever building anything of substance on their own. Don’t know where they ended up, but I doubt they got good jobs.
I think it’s super important for CS students to pursue their interests beyond what’s covered in school. It’s the only way to gain the skills you need to get a good job out of college.
>How does he get the UI working so fast and looking so good?
That's mainly just experience with whatever he's using for the design. I've gotten to the point where I can hack together some pretty looking CSS in a short amount of time.
>How do you reverse engineer an API
I have less experience with this, but from what I have done, I've learned that XHR breakpoints in chrome dev tools is your best friend.
Do something every day for 5-10 years and you get better at it? I think it’s good but he’s probably using electron or react native desktop, which cuts out time.
That's cool that he was able to get a whole Mac app finished. Unfortunate that none of it seems to be open sourced, at least the non-private API parts. But maybe he plans to use the code to monetize something different in the future.
On the other hand, for best iOS/Mac podcast app, I haven't been completely happy with any for years. New ones with smart speed - great feature, but I like one feature above all else.
My favorite app was Instacast for iOS because it let me add time stamped bookmarks/notes. Audible has something similar. None of the apps mentioned in Product Hunt or his blog post seem to support this. Such a bummer. I paid for Instacast 5 before it was removed. It started crashing at launch on iOS 10 however.
Edit: I recognize not many people, likely a single digit percentage of podcast app users would care for bookmarking/notes (thanks Void_)
Imagine if you could share the notes. And the notes could be structured. And you could tweak your player to react to notes in various ways. We could have crowd-sourced ad-'blocking' on podcasts!
Actually I have extensive time stamped notes for hundreds of podcast episodes including their ads starting and ending, but personally I'm against ad blocking. I've been in the process of removing those parts before publishing my bookmarks/notes.
I think I agree, much as I hate ads! There is something about podcast ads that I find much more acceptable than most other forms; the only slight downside is they tend to be quite repetitive, both within shows, and across them.
It would certainly be useful to have notes for a whole range of other benefits e.g. making it much easier to search an old episode for a specific topic.
That's actually why I started tracking the ad times. The same podcasts I listen to usually rotate through the same ads. So I would end up skipping them and noting it for fav episodes that I might come back to. Same issue ads on YouTube or Hulu when they become repetitive. I'm trying to not be against ad blocking, but when that happens, it's almost impossible to not be annoyed.
If you think about it as "bookmarking" - no, don't care. Bookmarking usually implies a manual, fragile process.
Being half way through on iOS, then being able to continue listening exactly at the same point on MacOS - yes. That's something iTunes and the iPod supported since day zero, and nobody else has yet properly replicated. And it's really useful if you listen to podcasts longer than about five minutes long.
I admit I always prefer iOS over Android, but I already use a 2nd device as a music player. I can use another spare Galaxy now as my music player and as my podcast player with MortPlayer. Thanks!
My suggestion to the developer would be to talk to the Pocket Casts people about offering the desktop client as an in-app purchase and share those revenues (easily traceable) with the dev. Maybe they could create a special authorization key that would allow access to the unofficial API without locking that account. The app gets a desktop version and the dev gets some revenue for his trouble, and Pocket Casts has some increased income to support any additional load on its servers (plus profits).
Just a thought. Tell me why I'm wrong / horribly naive / etc
One snag may be the collection of metrics. Marketing people seem to have realized that there's a burgeoning market that they haven't destroyed yet and they seem determined to correct this oversight. If they decide that they need to monitor listeners or make sure they can't skip ads, then third party clients are going to never happen.
They already make people pay separately for the web version (even if you already own the Android/iOS one), but it's understandable that there's much less people listening to podcasts on desktop, so they think it's not worth developing a proper desktop app.
My suggestion to the developer would be to offer the app to Pocketcasts for a fee based on his daily rate (to cover the time he took to wrote it) plus a reasonable royalty percentage per year. He could then have his app, not need to maintain it at his own cost and possibly make a bit of cash from the royalty. If the Pocketcast people give it away for free, he makes only the dev cost back - but doesn't lose much really - but he gains the app he wanted.
The only thing I don't get is why the desktop version would be an IAP of the mobile one, that makes no sense.
Though it would probably have been a better idea to do that before they discover you've spent the last week publicly tweeting about unauthorised use of their internal API.
I recently tried turning the PocketCasts webplayer into an app on chrome and while it worked well, it had a major flaw.
I'm stuck at my computer!
If I wanted to get a cup of water, check the mail, put clothes in the dryer, whatever, I would have to pause the podcast, or leave it on and lose part of the story.
This is fine when I had radio, since I can dip in and out and it doesn't matter much. But if I'm listening to something with a deep plot like Serial or that Halo thing, I don't want to miss a thing.
Spotify just needs to host more podcasts... I have become obsessed with how convenient it is to cast Spotify to my wifi speakers, phone, computer and back and forth. Easy to switch where it's playing by changing in the the mobile or desktop UI. Constantly switching between phone/speakers when moving around the house, or leaving the house.
There's a PocketCasts mobile app on Android that works reasonably well (can't figure out how to set >1x speed) and syncs progress. It should be included with price of web app, imo, but it's cheap enough for the pair that I was ok with it. You have to then carry headphones, and still have to pause, so that seems unsatisfying.
Consider getting Chromecast Audios and cheap speakers through your house and creating logical groupings (e.g. I have an "everywhere" group, and common room paths + destinations for various things, like Living Room through Hallway to Bathroom), and using the Cast feature of PocketCasts. Much cheaper than Sonos, etc. and you probably have a bunch of speakers anyway. Also Google Homes double as a good enough speaker in annoying rooms that don't have many outlets, if you're ok with having a microphone in those rooms, and they obviously synergize well with the Chromecast Audios.
You can't figure out how to set >1x speed? On the playback screen, there's one button in each of the bottom corners; bottom right lets you set a sleep timer, bottom left has a whole bunch of settings, including playback speed.
I suffer from the same issue, to the extent that I'm considering adjusting my flow so that I always listen to podcasts on a mobile device, even when I'm sat at my computer. This eliminates all the syncing issues, etc. The only tricky decision is which mobile device is better for podcast listening: my iPod or my android phone. iPod has far superior battery life, and generally better podcast-listening experience. The one advantage the phone has is that I can update podcast content when I'm away from my home desktop. If Apple has ever released an iPod classic with wifi support for syncing, it would probably have been my dream product!
What's a normal range for Bluetooth headphones? Because I was pretty amazed to still have audio playing on my AirPods being ~75m away from my phone. To be fair, there was nothing but a single pane of glass between the two, but still, that's quite the distance.
Just wanted to give a bump to this. I've been absolutely amazed with the range of my AirPods. They have the best range of any of the 3 pairs of bluetooth headphones that I own. Whereas my other 2 pairs will cut out if I leave my home office and go to the kitchen or the bathroom, my AirPods keep playing strong.
I'm really curious if this is a special function of the AirPods or Apple's W1 bluetooth chip in general. One of my other pairs is an older pair of PowerBeats sports headphones. I would definitely consider replacing them with a new set of BeatsX headphones if that's the case.
The main issue is likely to be latency and lack of existing low latency protocols - it's doable, I use jack over my network to watch video and voip apps like Mumble get pretty damn good with compressed audio, but most of the music oriented type stuff is high latency SHOUTcast or other http streaming type solutions, which tend to involve large buffers and stuff. There's just nothing existing which would feel correct for wifi headphones to my knowledge.
Battery life is probably an issue too, but with low power wifi SoCs like the espressif stuff, you can probably get away with similar to Bluetooth using the tech that's around now and doing as much possible in hardware and with interrupts as possible.
lol, it's just the solution I have when I work from home. I'm often up doing the dishes or what not and I just turn the volume up before I leave my desk.
Maybe! I didn't Google it; I searched in Overcast, but found nothing clearly relevant. Perhaps if I had the perfect podcast app...anyway, thanks! Even if this isn't the same podcast, I've always been much more fond of the Halo mythos than the actual games, and this looks like being very enjoyable.
I wonder if he could define the minimal API that his application needs, then write adapters for different podcast services. Maybe one day Pocket Casts will have a public API or perhaps be willing to officially license him to use their private API. Or maybe he should spend next weekend and write the backend part himself. He certain seems to have the talent to do so.
You know, it really is insane Apple continues to push this "we're a music company" narrative, especially with the release of The Defiant Ones. iTunes has been a car accident for over a decade, and the release of Apple Music has only further exemplified that the whole thing needs an overhaul.
What's wrong with Apple Music? I switched over from Spotify because it has better integration with iOS and it has a similar library and neither service has a distinguishing feature that makes it really stand out.
Apple Music has some things Spotify doesn't have, some out of the control of Spotify Inc, some they choose to ignore:
- Siri integration (this is Apple's fault, no reason not to open SiriKit to music services)
- An Apple TV App (This is on Spotify, it's been asked for forever)
- An Apple Watch App (This is also on Spotify, but there are rumors it's coming soon)
But there are some real downsides to Apple Music vs Spotify:
- Apple Music's playlists aren't as good, community playlists are tough to find. I've found links to Spotify playlists filled with interesting music, no luck for Apple Music.
- Apple Music's radio is subjectively worse. Repeats far too often.
- iTunes is a travesty and I'm forced to use it to listen on my desktop. It's slow, ugly, tough to navigate, terrible to search. It does 500 things and none of them well.
- The Apple Music app on iOS isn't much better. UI is scattershot and it is tough to do some things that shouldn't be.
- No cross-device play state sync. For example, if I start listening to a playlist on Spotify I can start at the same point in the song and pick up exactly where I was on any other device.
- Social integration - I can send Spotify previews to people via Facebook Messenger, and Spotify integrates with other social stuff. Apple Music is all by itself.
I think a big issue that Apple will run into is that they insist on tying releases of Apple Music to iOS releases. Spotify can release new versions whenever they want, but because Apple didn't announce something like cross device state sync there's no chance I'll get it until at least next year.
I have both Spotify and Apple Music, but I'm not 100% happy with either.
> Social integration - I can send Spotify previews to people via Facebook Messenger, and Spotify integrates with other social stuff. Apple Music is all by itself.
What about Ping? Doesn't it allow this kind of sharing?
I find the selection on Apple Music to be way better than any of the competitors. Got some weird EP from band on an obscure indie label? Pretty likely it'll be on Apple Music.
Or just let me delete iTunes. I've rm -rf'ed it a few times, and it goes away for a bit. And then when I'm not looking, it reinstalls itself in the background.
I just want to be free to accidentally press buttons on my headphones without launching iTunes.
I've generally been happy with Apple Music; I'm about 90% as happy with it as I was with Rdio in its heyday. I wish sharing playlists was easier, but the library coverage is much better.
I have no love for iTunes and haven't for about a decade. But thankfully, I don't need to use iTunes more than about once a year. My wife very occasionally needs to sync music from a CD to her iPhone and she can't get digitally.
I sync photos to Google Photos and movies to VLC using either iCloud Drive, Google Drive or the built in web server from VLC. The music I've bought from iTunes over the years is available to redownload.
Is there any reason not to just release it anyway? Users know the risks with using an unofficial app. Even though they reached out via Twitter with a polite "No," why not counter with a polite "I understand the issues, but I'd still like to release this"?
It sounds like Pocket Casts are rather overstating their case. The dev put a lot of work into it. Unless they get a lot of traction, none of the concerns seem to matter much. And if they do get traction, it informs Pocket Cast what they should be building.
I think that users knowing the risks of using an unofficial app is a bad assumption.
PocketCasts has many options for blocking the apps use. They can simple secure / update their API regularly, thus breaking the tool or they can simply send him a cease and desist for violating their IP and ToS.
PocketCasts would not want this app to exist, because they will be the ones that will have to deal with the influx of support tickets and customer problems related to this unsupported app.
Sure, but users understand the risks. If the dev throws up a splash screen saying "Proceed at your own risk. Your account might get locked," then they can't be held morally accountable for that.
I don't know. It would've been an interesting experiment to carry to its natural conclusion.
On one hand, I agree with you, on the other hand, I'm 100% sure some users will send angry emails to PocketCasts and demand refunds because this third-party app didn't work well (or they couldn't figure something out, or any number of things).
I think it might be a different story if you didn't have to pay to use the web UI (and consequently the desktop app). That's a pretty big risk, and would mean having an awkward conversation with a support person about why you were violating their ToS, and also not being able to use the web or mobile apps anymore.
I use Pocket Casts in its own window with Fluid[1]. It's too bad it doesn't support media keys, but someone could create a Chrome extension to control playback, similar to how it's done with Google Play Music.
ok i listen to a lot of podcasts and fundamentally dont understand why there is this small group of people who have this deep desire for a desktop podcast client. I don't question that these people exist, but I just don't understand why they prefer desktop over mobile especially when headphones are wireless/you can connect to bluetooth speakers. mobile dominates in every aspect.
I've been struggling with this, too, but then I realized that even through my home office has a bookshelf receiver that has Spotify capability, as does my iPhone, I still have Spotify installed on my Mac, and use it from time to time. As someone who jumps on video chats or calls pretty regularly, it's nice to have a keyboard key that can stop my music without the need to hop devices. Likewise, if I'm wearing my headphones already, I won't need to switch devices to the computer when one of those calls starts. There are reasons, I guess, and managed to talk myself in to a few.
Often I'm on my laptop doing something and want to listen to a podcast. Why should I use two computers instead of just the one? Why should I expend both batteries? Also, my macbook does wireless speakers just fine..
I've given up on finding a good desktop app. I'd like one though. When I'm in my home office I want to use the speakers built into my thunderbolt display and not the phone speakers or headphones. In practice I'm playing podcasts via phone and music via laptop/thunderbolt display. That's because Google Play Music since perfectly and is good for music, but the iPhone podcast app doesn't.
I admit that the times I want to play podcasts over my iMac speakers, I use Rogue Amoeba's "Airfoil Satellite" running on the Mac so I can airplay to it. Obviously this is a macOS/iOS-specific solution, but it works well enough.
Having said that, in practice I tend to just play podcasts over a Bluetooth speaker (a JBL Flip for years, but as of yesterday a Bose SoundLink Mini II, as the Flip's battery life is down to well under an hour and it was time for a replacement/upgrade).
Because I'm using my desktop for eight hours a day. I have media keys. I need to use the audio functionality on my computer (for phone calls/video calls etc.)
Also, because my laptop has a much more usable interface (keyboard and mouse) than my phone.
I agree that it does continue to be a problem. I've yet to find a suitable solution for recommendations that adequately surface more obscure titles. Likewise when you have a subscription / Premium podcast it gets even harder as things like Google Play dont seem to support custom feeds, at least in the Android App. It makes it all the more difficult to monetize and spread your Podcast.
Slightly off topic, but I'm a recurring voice actor on the NoSleep Podcast, featured prominently in the imaging on this post. Thanks for Listening!
If I were him I'd try to work out some sort of contracting deal where he sells them the codebase and agrees to support it for X years, for a reasonable price. They would get a finished and polished app with zero effort, while maintaining control on the internal api; and he would get a nice runway to work on this and other projects.
I know it's resource-heavy, but at least you can start tying your own dedicated hotkeys inand sending out notifications from it. And you can build your own features that make it its own similar to Google Music Desktop Player
Plus you don't have to worry about Pocket Casts breathing down your neck because it's still through their system.
The issue is, accepting Electron will encourage more people to make such garbage apps. We need to firmly say no until this fad dies off and people get back to writing proper apps.
Does anybody know who is actually hosting this content? Does pocket casts host the media files, or is it just a search platform for content hosted elsewhere? Seems like you could end up in a bunch of legal problems considering the number of people trying to own this market right now
can i just ask why you want this on desktop so badly vs just continuing on your mobile? its not like your phone ceases to exist when you are working on your desktop? just trying to better understand the psyche of users like yourself.
I like to have certain things available on both platforms. If I am using my laptop, I don't want to have to pull out my phone to listen to podcasts. I want to be able to play and pause on my computer.
I use email and messaging on both platforms, and I wish I could do the same with podcasts.
This sounds a lot like my own usage habits. If I'm using a computer of any sort, I don't want to have to pull out my phone for hardly anything. My phone is for times when a more capable machine isn't readily available.
I'm not sure why a Podcast app really needs an independent service, wouldn't it be easy enough to sync against a configuration stored on dropbox/drive, etc? Unless you are following a LOT of podcasts, or on a LOT of devices, it should be easy enough. (Or "self-host" to Azure/AWS/GCP tables/dynamo)
For that matter, electron and/or react-native could make it easy enough to create such an application.
ahh that should teach me to read the article :)
but I do disagree with 'the UI could use some work', and I've never found I need the marginal time removed by smart speed.
I realize that this is about Mac podcast apps (hopefully you won't mind a quick diversion), but I'd like to quickly plug my favorite iOS podcast app: Castro (no relation, just a happy user)
I tried Overcast and really loved the features (smart speed, etc.) but I didn't love the queue handling. It's not that there was anything wrong with Overcast in that regard. It certainly works fine (it's a great app), but it didn't map to the way I listen to podcasts.
Castro is ideal if you only have a few hours a week to listen to the occasional podcast and you don't always listen to every episode of every podcast. All other podcast apps (disclaimer: that I know of) have an on/off relationship with podcasts. You are either subscribed or you are not. If you are, you can specify how many of the podcast episodes to automatically download and put in your queue. So if you like to listen to occasional episodes of, say, a hundred podcasts, you will use a TON of storage.
Castro has a triage model. When you subscribe to a podcast, you can have the app automatically either queue it up immediately (like the traditional method) or have it appear in your inbox (along with a notification), which is a kind of temporary time-based view of recent arrived episodes, or you can have it put in the archive, which is where all of the older episodes eventually go. You can always queue up an episode from any of these locations.
The best part is that only things that you put (or specify to automatically add, which I never do) in the "listening to now" queue are actually downloaded. So if you keep that list at 5 podcasts, then only those 5 are downloaded. Very nice and a perfect match for my use.
How does he get the UI working so fast and looking so good? How do you reverse engineer an API - this seems like some hacker stuff you'd see in Halt & Catch Fire, in my mind anyways.
I'm sure I'll get there, but right now there's a major disconnect between the C investment calculator text program I made, and these super functional, beautiful works of art.