Live data from Hacker News

It’s Been Real, Android: Why I’m Retiring from Android

raptureinvenice.com

341–342 of 342 posts

Re: It’s Been Real, Android: Why I’m Retiring from Android

#341

Developers do need to pick a set of core technologies, and stick to it or a career can fall apart I bet. I don't know from experience. I've been a Java DEV ever since MSFT tried to hijack the Java language with a proprietary version back in 1998, and I abandoned MSFT and never went back. I can imagine trying to be both iOS and Android developer would be about as insane as trying to be both .NET and Java developer. Oi…

To clarify my original post: I do pick up new technologies when they come along. For example I'm using TypeScript in the two projects I'm working on, and I didn't even know it existed one year ago. My point about sticking with something for the long term to build up experience was more a long the lines of "If you think you can be both a Java developer AND a .NET developer" that is very wrong thinking. Pick one. Focus on it. It's just the "jack of all trades and master of none" effect I was getting at. Certain technologies are designed to compete with each other and using them both will only cut in half your "experience" level on each one. I appreciated (and agreed with) all the commenters saying how wrong it is to just lock onto something and try to make a career out of it: however the following are the winners: Java,JavaScript,TypeScript,HTML+CSS, and anyone who has those skills as primary on their resume has a bright future. If you don't, you're taking a risk that your "flavor of the week" will be obsoleted. 10 years from now those core technologies will ALL be in demand.

Re: It’s Been Real, Android: Why I’m Retiring from Android

#342

Earlier quoted context omitted.

This looks like absolutely the best approach, but there's one thing I don't like about it: communication between IntentServices and the UI thread feels so... wasteful. The sanest way to do it, I think, is keep communication to a minimum, relying solely on the local DB as a source of information. But then every operation you do to fetch remote data immediately results in at least a couple of DB operations (store it, r…

> As far as I know, there's no simple way to pass an object from the service to the UI. They are in the same process, you can communicate between them through all the normal Java mechanisms. For example, your UI can just register & unregister a callback on the service directly in its start/stop methods (or in onVisibilityChanged if you'd rather do this in a View instead)

Oh, that's better then. In documentation they always point you towards using complicated mechanisms for communication, but I suppose that only applies to services running in different processes. Thank you for the clarification.
Post reply on HN