Car Thing was only a remote for your phone's Spotify app. It was targeted towards people that had bluetooth or aux inputs to their car's stereo, but not Apple CarPlay or Android Auto that allowed you to control Spotify directly through the radio.
I have a Car Thing for my 2015 Chevy Volt, and I really enjoyed it. For exactly the reasons you mention, it lets me control Spotify with a great UI. I can also just play my phone over Bluetooth but it's not like I can select different playlists, browse songs, etc. from my car's dashboard - all I can do is go back or forward.
I'm also surprised they're bricking Car Thing. Given how it works, I didn't realize it would even need server data in the first place.
Seriously. I don't know anything about mobile development, but once it's working in the first place, how hard is it to just NOT delete its API hooks from the codebase. As a developer, I can only guess that maybe the code which supports it, or the code where it has to poke its fingers into into in order to be able to draw its UI, is poorly-architected and removing the Car Thing code across the board will allow them to more easily refactor or something.
My guess was that it was sending back analytics which was developed in such a way that if the servers are not responsive, the thing won't work. So if they unplugged the servers, then no more working Car Things. However, I wouldn't not consider that being bricked. So maybe they plan on pushing on OTA firmware update to brick them???
What would happen if you just stored the unit so that it was not able to receive OTA updates? How long would they keep the OTA update server up and running before assuming all units were bricked and could retire that server? Does part of the bricking process collect the serial number to add to a completed list that your rogue unit would not show updated?
Just curious how far one needs to go to avoid it getting bricked if it would be possible to avoid at all
> how hard is it to just NOT delete its API hooks from the codebase.
Someone has to maintain that API. Not only on mobile, but also potentially on the server as well. Those "hooks" become a nuisance and a hindrance when services change or get deprecated. When data schemas get updated. When new data types get introduced etc.
And that's before we get into discussion about architecture, code quality etc.
Most of the things in Spotify are done through the server. There are two major reasons why:
- customer-facing reason: Spotify Connect https://support.spotify.com/us/article/spotify-connect/ We have to be able to know which device you're playing on, show it in device pickers and even let you play stuff on devices not in the same network
- second major reason: most of the decisions of what to play cannot be made on the client. This has to do with licensing and related analytics. Even different types of devices will have different licensing applied to them. So to even simply say "play next song" you have to tell the server you're going to listen to a track. And that track might not be available for the specific combination of account/device/country/phase of moon which client has no way of knowing about.
Source: I work at Spotify, but I can't answer any questions about CarThing (didn't work on it, and it would be NDA anyway)
That's one use case. The other use case is people who want a dedicated Spotify display in their car. It's especially nice in a new car because you can have your Nav or something else on your car screen and have a second display for your music. Yes, you can also use your phone for that, this is just another option.
I think it was more so for people who want a dedicated spotify app - as in they want to go through their likes, playlists and radios without using their phone.
