Live data from Hacker News

Show HN: I Made an iOS Podcast Player with Racket

defn.io

71–80 of 91 posts

Re: Show HN: I Made an iOS Podcast Player with Racket

#71

Doesn't work! Clicking discover just shows a messagebox with a stack trace[1] - so I have no way of adding a podcast to try out the app. [1] Error string::1: bytes->jsexpr: bad input starting #"error code: 502" context..: .../syntax/readerr.rkt:15:2: -raise- read-error ../private/arrow-val-first.rkt:486:18 .../private/backend.rkt:45:9: get-trending-podcasts .../noise-serde-lib/backend.rkt:69:22

Sorry about that! Looks like the server got OOMKilled at one point and failed to recover. It should be back up now and I'll work on a fix.

Re: Show HN: I Made an iOS Podcast Player with Racket

#72

I’m getting an error going to the Discover tab and also when hitting “search” after typing a search term (newlines added): string::1: bytes->jsexpr: bad input starting #"error code: 502" context..: .../syntax/readerr.rkt:15:2: -raise- read-error .../private/arrow-val-first.rkt:486:18 .../private/backend.rkt:45:9: get-trending-podcasts .../noise-serde-lib/backend.rkt:69:22

A botched deploy that I didn't notice ended up crashing the server, which then failed to recover when the systemd unit tried to restart it (it couldn't bind the port and ran out of retries quickly) overnight, so that's why that was failing. It's back up now and I'll put a fix in today.

Re: Show HN: I Made an iOS Podcast Player with Racket

#73
"Boost voices" is a cool feature a lot of apps have, but what is really needed is a "compress voices" feature. So many podcasters speak loudly 75% of the time, but then trail off randomly or almost whisper. Then you turn it up and they're projecting loudly again and blow your ears out. It's especially annoying in the car trying to compete with road noise.

Re: Show HN: I Made an iOS Podcast Player with Racket

#74
post #73

"Boost voices" is a cool feature a lot of apps have, but what is really needed is a "compress voices" feature. So many podcasters speak loudly 75% of the time, but then trail off randomly or almost whisper. Then you turn it up and they're projecting loudly again and blow your ears out. It's especially annoying in the car trying to compete with road noise.

That's a great point! Shouldn't be hard to add.

Re: Show HN: I Made an iOS Podcast Player with Racket

#75
post #40

The app looks really good! Based on the title I thought it’d be something you made most as a testbed for Racket so I was surprised to see the app itself actually looks great :D I tried looking through your blog but couldn’t find anything except the 40 minute YouTube video for your other app. It sounds like both the UI and the audio-related code are in Swift? What code ends up actually being in Racket then?

That's right, the UI and the Audio Engine bits are in Swift, because it's easier to interface with those Frameworks directly from Swift (and not fight the platform). Everything else (the Database management & the models, the download manager, ID3 parsing, parsing release notes, syncing with the backend server, etc.) is implemented in Racket and is portable.

> Database management > syncing with the backend server

Do features like these, when implemented in Racket, consume more resources (battery, CPU, etc.) than if they were implemented using the native API equivalents (e.g., NSURLSession or whichever is more applicable)?

In the larger context of cross-platform apps with a common core written in a non-native programming stack, I often wonder this about network and disk I/O management. I understand using the native APIs for other "I/O" like UI, hardware interfaces (bluetooth, accelerometer, etc.), because they often don't have an equivalent API in the programming stack used to implement the common core.

As far as I know, Capacitor wraps over the native APIs.

Re: Show HN: I Made an iOS Podcast Player with Racket

#76
post #75
post #40

Earlier quoted context omitted.

That's right, the UI and the Audio Engine bits are in Swift, because it's easier to interface with those Frameworks directly from Swift (and not fight the platform). Everything else (the Database management & the models, the download manager, ID3 parsing, parsing release notes, syncing with the backend server, etc.) is implemented in Racket and is portable.

> Database management > syncing with the backend server Do features like these, when implemented in Racket, consume more resources (battery, CPU, etc.) than if they were implemented using the native API equivalents (e.g., NSURLSession or whichever is more applicable)? In the larger context of cross-platform apps with a common core written in a non-native programming stack, I often wonder this about network and disk I…

Ultimately, you end up calling some system API for I/O, so the only difference is how efficient the implementations of those Frameworks are compared to the embedded language's implementations. On iOS, embedding Racket requires using an interpreted mode (as opposed to Racket's usual native compilation mode), so there is a small hit, but it's not one that is really noticeable in battery or CPU consumption. In fact, Podcatcher seems to do better in battery consumption compared to the competition in my (and my friend's) testing, but I would guess that's not necessarily _because_ of Racket; it probably has more to do with how the system as a whole pays attention to perf.

Re: Show HN: I Made an iOS Podcast Player with Racket

#80
post #79

feedback: it's slow (clicking on subscribe, etc)

Thanks for the feedback. Subscribing in particular is slow, especially for podcasts with lots of episodes, because it tries to save all the episode metadata locally, to avoid roundtripping later. So, it’s slow initially so it can be fast later and work offline, but I understand how that can be annoying!
Post reply on HN