Thanks Mittineague for sharing your experience with me.
I was on pretty much same ground like you, started off by picking up on BASIC (basica / qbasic, during the 90s, who wasn't at that time?
But I then left programming in late 90s for study, chose to pursue a subject which didn't require coding knowledge. It wasn't until 2002 i started doing php for like 2-3 years (mainly as hobby where i wrote for fun and made little side income), after which it was another 'lost decade'.
To me OOP wasn't as scary like some said. Recently I went to local bookstores, did a few sessions of "free readings", managed to gobble up the ideas behind it, because it makes sense in most part.
However, Android development, on the other hand, looks a lot like a giant beast, which is hard to be tamed. To developers, it's more like putting together the scattered pieces of jigsaw puzzles, rather than working the code from ground up.
The more classes and samples one could memorize, the better coder he is (as an android developer). It defies the purpose of "there's more than one way to do it" - a popular belief in many programming languages. There's actually only a few ways (if not one) to make it work in android while a lots more ways to break it, one must abide a few dozens rules and coding patterns to make the code works. Like mentioned above, I still don't understand when or why should i used 'context' in some functions while not in others, though I briefly understood its main purpose is parsing the current environmental resources for other components to be interpreted.
E.g., when we use Toast.makeText(context, strings, duration), what's the 'context' doing there? It serves no 'obvious' purpose rather than some internal data parsing. Some serious programmers would argue how useful the context is for code efficiency especially in multiple activities, but really we are falling back to low-level or even assembly language with that thinking. Why not Android team make 'context' optional by following the current 'activity' state and save all the confusions?
If, 'context', must be parsed without altering its content (most of the time, 'this' or getBaseContext() could not be modified), what's the exact reason we must make it as an argument?
And as for the coding patterns, say, I want to make a specific marker on a map where a user input its GPS in EditText(textbox). Sounds pretty basic. But it's not, at least not to me. (I wonder how many could write from scratch without referring to any references. )
What I would do was finding all resources available about map marker, the perfect case would be there's an exact recipe ready for use, if not, I would copy out those similar codes with classes that make sense (MyLocationOverlay(), addOverlay(), etc) filter out the unwanted lines, joined all the codes together, praying that it will work.
Not sure if it's only me, but that really puts me off. Can't it be much simpler. Calling a map with a rectangle (2 point GPS -top left & bottom right), then place a specific marker with GPS on it, set zoom level, navigable logic (true/false), etc. Done.
When we need multiple locations, we'll recall same class with different objects. Then depend on our needs, we could draw a straight line to calculate distance, a real streetview path with real distance, etc. That's it! Is that too much to ask?
I don't know if that's the reason. On Google Play, though there are near 800,000 apps, but many among those apps rendered not much useful, even among the 'useful' ones perform very basic functions like 'show me the car park location', 'your friend's current location at xxx via sms' etc.
Perhaps the difficulty in coding practice limits the apps usefulness and creativity. I have a dozen ideas which (in my humble opinion) works better than FourSquare, but just could not realize it into app, though they were just performing basic GPS marker functions, storing into SQLite (and these data will be fetched into server's for public sharing), Store ratings and comments, near-distant ads auto displayed (via wifi or bluetooth) etc. I was thinking if every laptop/pc equipped with gps and the data was embedded into browser's headers, I would have managed to create a script like this in PHP with not much problems at all.
Well, I shouldn't complaint too much. Maybe I have not dig far enough and am not there yet.
But I'm seeing some replacements to the native way of coding that might come in the near future, not HTML5 (Mark Zuckerberg's FB web app should endorse HTML5 more than anyone else on earth, but he has not), maybe something similar to AppInventor, but with greater flexibility and features. Maybe an improved version of AppInv will make creating apps much easier and innovative. Creating Angry Bird on adroid should be as easy as doing it in Flash.