Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android, evolvability and Comcast

abe-winter.github.io

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Android, evolvability and Comcast

#41

Post by warcher »

awinter-py wrote: post #22
warcher wrote: 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…

Then don't switch to JS, switch to C++ as the primary dev language. The performance-sensitive parts of the OS are already in C++ and the NDK exists, so this isn't that big a jump in terms of support from the android maintenance team. C++ is not slower than java on constrained hardware, also is more respectful of memory. Is it harder to use? I don't think so but I may be in the minority here.

I think this may have been intended as sarcasm, but yeah man. I do C development for my real high performance mobile development. Everybody does. If you saw an app and wondered "Oh wow, that was cool, how did they do that?!", more often than not, somebody wrote some nasty old C/++.

Re: Android, evolvability and Comcast

#42

Post by JustSomeNobody »

reilly3000 wrote: post #24
JustSomeNobody wrote: post #7

Earlier quoted context omitted.

There is something seriously wrong with our industry. How can this even be suggested as a solution?

Because Facebook has thrown tens of millions of dollars towards getting a unified cross platform method of having 60fps rich mobile apps. Because managing an app of more than trivial complexity on iOS and Android is massively expensive. Because this approach offers the most leverage with the least trade offs of performance, development overhead, and future viability. And because live coding mobile apps with a REPL is…

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.

Re: Android, evolvability and Comcast

#43

Post by pebers »

Parts of this definitely resonate with my experience; there's a reasonable amount of high-level documentation about fixing specific Android build issues, but nearly nothing describing how the system actually works. Lots of StackOverflow answers exist saying "add xyz to your build.gradle file" but there's a dearth of anything describing what the real build process for an Android app is. (For various reasons I didn't have to deal with a lot of the actual app coding, so the XML layout systems were less troubling to me than the author).

> When I get the call from G’s android team to build a better buildsystem

I can only hope that this is "when" and not "if" ;-) I can't believe the current system can't be improved upon though...

Re: Android, evolvability and Comcast

#44

Post by CyberDildonics »

diyseguy wrote: 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?

Re: Android, evolvability and Comcast

#45

Post by CyberDildonics »

Ultramax wrote: post #11
dingo_bat wrote: post #8

I never could put my finger on it till now, but this is why I found Android dev frustrating.

As someone who has had to deal with Assembly in the 80s for development projects, Java sounds and works great! I guess it depends on your experience, attitude and point of view.

Better than assembly in the 80s is not a high bar.

Re: Android, evolvability and Comcast

#46

Post by dboreham »

ZanyProgrammer wrote: post #26
ashark wrote: 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…

Based on your post I can't ever imagine wanting to develop Android apps.

Or any software ;)

But it's "situation normal" for most software development activities, no?

Re: Android, evolvability and Comcast

#47

Post by kabdib »

ashark wrote: 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…

N+1) Android vendors who think they know what they are doing will make customizations that utterly screw you (e.g., mucking with date/time pickers to the point that they are busted on some random set of phones).

N+2) Oh, so you want to make a buildbot that does stable builds based on known versions of tools and libraries? What a quaint notion.

[Can we just say that Activities and Intents died, or at least achieved effective bankruptcy as actual abstractions, around the time the 32nd flag modifying behavior was added? At some point you need to step back, take an honest look at what developers are actually doing and realize that things are simply not working out. All that anyone does with the UI framework is to try different things and "twist knobs" until the apps seems to work, and hope that it doesn't break much in the future.]

Re: Android, evolvability and Comcast

#48

Post by dllthomas »

warcher wrote: post #40
wvenable wrote: post #29

Earlier quoted context omitted.

> I get real tired of web soft boys coming into native and complaining about how complicated it is on the metal. I've done a lot of native development, real native development, not this fluffy Java stuff and Android is still overly complicated in both design and tooling. My needs as a developer on Android are far from cool and that shouldn't be unnecessarily hard -- but it is.

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."

Re: Android, evolvability and Comcast

#49

Post by pitaj »

ashark wrote: 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…

This kinda thing makes me glad I'm in web dev.

Re: Android, evolvability and Comcast

#50

Post by ZanyProgrammer »

dboreham wrote: post #46
ZanyProgrammer wrote: post #26

Earlier quoted context omitted.

Based on your post I can't ever imagine wanting to develop Android apps.

Or any software ;) But it's "situation normal" for most software development activities, no?

Is it? And if so, I can see the reluctance amongst some to call us a proper engineering field.
Post reply on HN