HN user

ntlve

36 karma
Posts0
Comments21
View on HN
No posts found.

I've found that the best way to deal with this complexity is to ensure that any concurrent work is done in a fire-and-forget kind of style. Concurrent work is submitted to a IntentService (possible backed by a thread pool instead of a single worker thread to speed things up) and if it needs to talk back to the UI it does so via a local sql-db or similar construct. That way the UI can die and get restarted indepedently of the worker service and the worker service can update UI state without having to care about the UI existing or not.

They would also need access to the machine which you have your vault stored on which would be your laptop and your phone and nothing else.

Spotify used to be fully native, nowadays the UI is done in various web technologies while the heavy lifting (streaming audio etc) is done in c++.

I use a password manager along with Syncthing[0] which seems to be the compromise you are looking for. This setup works well as long as your devices are decently often on a wifi that allows local device discovery (since syncthing needs either that or static IPs) and it also keeps your password vault offline (i.e no cloud involved).

0: https://syncthing.net/

Programmer proverbs 11 years ago

What if preference is based on whatever makes you work the fastest? Or what if preference is based on objective, reproducible evaluation?

This is just me guessing but one of the initial goals of Dalvik was to use as little space as possible (due to memory constraints of hardware at that time). Perhaps they thought saving a a byte or two on method identifiers was a good idea. This would not be a problem if it weren't for the fact that dx also squashes all classes into one single class, meaning that instead of being 65K methods per class you now get 65K per apk.

The Android version is going to need a lot of polish. The menu is jittery and the wrong icons are used. Also the whole app lacks touch feed back so there is no way of telling if you are pressing a button or not until afterwards. Finally, a few idioms like long pressing to edit items and such remain unimplemented which atl east made me confused.