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.
Android, evolvability and Comcast
61–70 of 71 posts
Re: Android, evolvability and Comcast
#62My 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…
Re: Android, evolvability and Comcast
#63I 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]
Re: Android, evolvability and Comcast
#64Amen! 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?
Re: Android, evolvability and Comcast
#65Amen! 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?
Re: Android, evolvability and Comcast
#66Re: Android, evolvability and Comcast
#67Man, 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…
Re: Android, evolvability and Comcast
#68Earlier 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.
Re: Android, evolvability and Comcast
#69I 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
#70Earlier 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."
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.