Live data from Hacker News

Android, evolvability and Comcast

abe-winter.github.io

61–70 of 71 posts

Re: Android, evolvability and Comcast

#61

Earlier quoted context omitted.

These are all developer centric points. What about users? Android already needs huge batteries, make everything run JavaScript and they'll need to be even larger. And forget computationally heavy apps? The hardware android runs on doesn't exactly have the best JavaScript performance.

I'm not sure you understand what react-native is... The app your users use isn't running javascript, it's not Facebook Cordova. You use javascript to compose the app, there's no javascript in the app you deliver to the users.

Pardon my incredulity, but if you use React, how can you not know that it uses a JS runtime? While it's not as bad as Cordova, you're hardly doing your users any favors in terms of performance by using React.

Re: Android, evolvability and Comcast

#62
post #19

My advice to a new Android developer: 1) The way things are done in the docs is often wrong on fundamental levels. Using libraries from the android team for e.g. network comm is often wrong , even if it's "new and friendlier" (nope). 2) The docs are often outdated. Also their examples are always for exactly not the case you need. 100% of the time. 3) Stackoverflow posts are often outdated. 4) You will eventually hit…

So it's not just me then. Good to know, I thought I was going crazy.

Re: Android, evolvability and Comcast

#63

I stopped taking the author seriously when I saw that he was using ListView. Maybe that's a factor of poor documentation, but there's no reason to use ListView (and the are many reasons not too). I'll admit there are issues with Android, but reducing them to the same tired arguments against Java is just lazy (and lack of config files?). [Developing for Android for close to 8 years]

So what do you use to display a scrollable list of items?

Re: Android, evolvability and Comcast

#64
post #6

Amen! I find Android programming excessively verbose and convoluted. I thought Google was supposed to be staffed by geniuses. The whole thing feels designed by a committee - like something Microsoft would put out. Why didn't they use Python? (Yes I've tried Kivy - meh)

> Why didn't they use Python Are you seriously suggesting using 50x the processing power as a native program on a mobile phone?

Did he even ever develop a single complex UI app (or any app actually) in Python?

Re: Android, evolvability and Comcast

#65
post #6

Amen! I find Android programming excessively verbose and convoluted. I thought Google was supposed to be staffed by geniuses. The whole thing feels designed by a committee - like something Microsoft would put out. Why didn't they use Python? (Yes I've tried Kivy - meh)

Probably historical reasons; when Android was created, was Python good enough? Particularly on underpowered processors with tight power requirements?

At the time Google started promoting Android OS, Google was well known to use primarily Python internally. So I was very shocked and discouraged by their choice of Java. I assume it was to reach the widest developer audience at the time. Maybe a case can be made for using Java otherwise, but Java is my least favorite language due to it's excessive verbosity and other pointlessly fussy restrictions.

Re: Android, evolvability and Comcast

#66
post #64

Earlier quoted context omitted.

> Why didn't they use Python Are you seriously suggesting using 50x the processing power as a native program on a mobile phone?

Did he even ever develop a single complex UI app (or any app actually) in Python?

he did :P

Re: Android, evolvability and Comcast

#67
post #21

Man, I knew this was a troll when I clicked the link. I'll briefly vent my spleen and get on with a substantive comment. I get real tired of web soft boys coming into native and complaining about how complicated it is on the metal. This stuff is hard cause you're not just churning html. It's harder work than writing a web page. Sorry. Specifically, mobile is resource constrained in a way that server-side work just is…

People who like this sort of thing, like things that are needlessly hard. Like climbing up a mountain by crawling backwards feet first. Sure it took a lot more sweat to get there, and maybe you are personally proud of conquering the large amounts of unneeded extra effort it took, and enjoying pointless cognitive overload as a way of life. Primary gain for such mindsets is it creates a barrier to entry for most people that doesn't really need to be there and perhaps allows a false sense of job security.

Re: Android, evolvability and Comcast

#68

Earlier quoted context omitted.

Probably historical reasons; when Android was created, was Python good enough? Particularly on underpowered processors with tight power requirements?

At the time Google started promoting Android OS, Google was well known to use primarily Python internally. So I was very shocked and discouraged by their choice of Java. I assume it was to reach the widest developer audience at the time. Maybe a case can be made for using Java otherwise, but Java is my least favorite language due to it's excessive verbosity and other pointlessly fussy restrictions.

Android was not started by Google; I presume when they bought Android Java was already entrenched

Re: Android, evolvability and Comcast

#69

I stopped taking the author seriously when I saw that he was using ListView. Maybe that's a factor of poor documentation, but there's no reason to use ListView (and the are many reasons not too). I'll admit there are issues with Android, but reducing them to the same tired arguments against Java is just lazy (and lack of config files?). [Developing for Android for close to 8 years]

So what do you use to display a scrollable list of items?

RecyclerView

Re: Android, evolvability and Comcast

#70
post #40

Earlier quoted context omitted.

You talking about the pseudo-restful activity/intent design? Cause I'm not gonna defend that , haha. It's a neat idea that simplifies corner cases at the expense of making a lot of common cases very counterintuitive. If the article was bitching about that, I'd take it a lot more seriously. I dunno, I have a soft spot for Java. Yes, the verbosity can be annoying, but compare that to the scavenger hunt that modern web…

My biggest beef with Android is the frequency with which stuff gets stuffed in a Bundle and sent off elsewhere. Which means the typing isn't "you don't have to worry about getting this wrong, the compiler will help you" but rather "yet another thing you can get wrong that will explode at runtime."

Ugh. From your lips to god's ears.

Don't get me wrong, the inter-application intent stuff is really cool and good, but sometimes, guys, it's all in-app stuff. I need to tightly couple these objects. I need to pass actual non-serializable objects amongst activities within my app. I'm sorry, I just do. Marshalling and de-marshalling data out to a bundle or the database isn't going to cut it.

Post reply on HN