On Android I've been using Symfonium which is fantastic. https://play.google.com/store/apps/details?id=app.symfonik.m...
588 karma · joined July 5, 2011
On Android I've been using Symfonium which is fantastic. https://play.google.com/store/apps/details?id=app.symfonik.m...
Also the playback experience is painful and uploaded files are poorly supported across devices like Google Home, where it constantly wants to do playlists or mix in other music. I'm not sure Google Home even supported playback of uploads, though I abandoned the service shortly after the Play apps went away.
I highly recommend Symphonium as an Android client. It is receiving constant updates, highly polished, has an offline mode, Android Auto support, and so much more.
I don't believe this is worth it. The implementation is fairly dangerous and fragile as you point out, all in order to simplify something fairly clean/reacty such as `const value = useSignalValue(signal)` into `signal.value`.
In the article, it appears to be the opposite. Previously this math was required (`[ai] = 2 + parameter_count - i - 1`), but by reversing the arguments in the stack it's now always a constant offset, and they prevent indexing out of the passed arguments in the frame by ensuring there's at least as many arguments as formal parameters by stuffing the call with extra `undefined`s:
> But what happens if we reverse the arguments? Now the offset can be simply calculated as [ai] = 2 + i. We don’t need to know how many arguments are in the stack, but if we can guarantee that we'll always have at least the parameter count of arguments in the stack, then we can always use this scheme to calculate the offset.
While this looks useful, if `Foo` is an part of my application state I'm not too crazy about shipping that over to Facebook if I wanted to use this feature.
This approach also forgoes many of the nice side-effects of having a clear slide-server boundary like avoiding leaking implementation details into your front-end code. Also, a simple REST API can be reused across platforms, so when you want a native experience on Android, iOS, etc you wont have to replicate this architecture or the underlying logic on each of those platforms.
I do feel that this is one of those cases where you should be able to write in the way you feel best for you, and if the publisher insist on having the final document in a word format, it should be straightforward to convert your chosen representation to theirs. It's hard to say without knowing precisely how the publisher expects the file to be formatted, but if it's fairly straightforward, there are libraries that will write to doc files for you, or there are open formats that MS Word already knows how to convert into .doc files that you could target instead.
Perhaps Opera can perform the minification after reviewing the code and achieve the performance gains while still being able to prevent malicious code entering the store.
Personally, I much prefer the current UI. It's very concise, no space wasted with curves, perfect for people like me who tend to have 10 tabs open at once. I would rather they update the current style with a few of the nice hover effects and bolder colours, rather than change the shape of tabs and the menu location.
I think his use-case is a lot more common than yours! 99%+ of consumers don't have an external Thunderbolt RAID array, or even know what it is. They just want their photos all in one place, accessible from everywhere, in the same way you can have your music on all devices with iTunes match.