I write all my articles by hand for the first draft and the final polish. I do use LLMs in between to try to get a clearer message (to what I find appropriate).
I understand if you don't want to read it, but there is nothing dishonest about this article. I've lived through what I wrote with those 3 apps. Take it as you wish and have a good day.
Can't speak for everyone but personally, I'd much rather read a slightly-imperfect human writing than an LLM that has a very artificial tone. Trust yourself!
You can ask the LLM to "mention a few places where I can improve", rather than having it re writing everything, if you really want to.
My 2 cents: if you are big enough and the competition isn't as strong, users will give you a pass on some performance issues as long as they get the content they want.
I remember one time there was a random Philips TV that just kept crashing when the user tried to do "right" on the last item in a horizontal menu. The client kept testing on this TV, and we spent 3 weeks because my team lead at the time wouldn't trust me that I needed the TV to solve it.
They finally agreed to send us the TV. Solved the issue in 10mins.
Who do I send my TV to to figure out why launching the DR app (Danish public broadcaster) on my Philips TV will power on the PlayStation and then crash?
Normally I'd just use the AppleTV, but the kid stole the AppleTV to watch cartoons in the guest bedroom. I continuously surprised that a 10 year old AppleTV still a better option than using the apps that comes with the TV.
> Who do I send my TV to to figure out why launching the DR app (Danish public broadcaster) on my Philips TV will power on the PlayStation and then crash?
Bit me recently when I got a PS5 too, apparently there is a "new" thing called HDMI CEC, which for some stupid reason defaulted to "turn on TV turns on connected device" and vice-versa when first installed. I'm guessing the DR app somehow cares/sends CEC messages (not sure if that's the right terminology, but whatever) to the PS and turns it on.
Maybe forcing CEC off on both the TV and the PS can fix the issue, unless you actually use CEC for it's intended purpose.
Honestly I haven't look into it much, I just thought it was funny that this one app would boot the PlayStation... and then crash. None of the other apps does this. To me it's just a funny interaction that should even be possible in my mind. In the end I hooked the AppleTV up again so I don't have care.
I've noticed this as well. My best guess is either low hardware or just a bad solution.
If they planned to use a unified codebase for Prime app, they likely went with something HTML/CSS-based, which would explain the performance issues. I could be wrong, but it's just a hunch I have.
If there was other apps we use that had the same issue, I'd chalk it up to hardware too, but maybe they simply don't test it on representative hardware? That might explain it.
> they likely went with something HTML/CSS-based, which would explain the performance issues
Not sure, the web browser in the TV seems to handle things just fine, and much faster than Amazon's app, so I don't think HTML/CSS is to blame here. Probably shit architecture/software design, as usual.
> they likely went with something HTML/CSS-based, which would explain the performance issues.
This is the case with a lot of apps that still manage to be performant. So it's quite possible Amazon are writing bad HTML/CSS but that's possible in other languages too.
Indeed, YouTube uses some sort of stripped-down Chromium (Cobalt I think it's called) with the client UI authored in HTML (and friends) for all of their clients and it's not deficient in performance compared to others. The Prime client is notoriously janky, even on Apple TVs, IME.
Any state management approach requires you to adapt your way of thinking, whether that be BLoC, Riverpod, Redux or anything you want to use.
Rivepod gained popularity because it's really simple to pick up: create a Notifier, create a Provider for it, and observe, while some other approaches require additional boilerplate, setup, and understanding.
Your approach would work if you are only observing that state from a single widget, which might not always be the case. Additionally, assuming useState is using setState under the hood means it will rebuild the whole widget on change, while with Riverpod, you have the flexibility to wrap any part of a complex widget into a Consumer or listen to only part of the exposed state on the Notifier with .select().
To put it simply:
- Notifiers are used for app state
- Hooks are used for ephemeral state (local widget state)
SEEKING WORK | CET | Remote Senior Mobile (Android/iOS/Flutter) engineer looking for work. Creating high quality mobile & TV apps is my passion.
Mobile architecture, clean code, SOLID principles, Unit and UI tests, CI/CD.
Skilled with Android, Flutter, Dart, Firebase, MongoDB, MVVM, Kotlin, XML & Jetpack Compose, Swift, SwiftUI.
Experience in agile environments, leading smaller teams, code reviews, pair programming, and mentoring.
I understand if you don't want to read it, but there is nothing dishonest about this article. I've lived through what I wrote with those 3 apps. Take it as you wish and have a good day.
reply