Android bloggers

For me, by far the worse aspect of the Android ecosystem is the community of bloggers surrounding it.

On one end of the spectrum, you have the professionals.  These folks are technically proficient, so their sites are at least partially useful.  But being professionals, they absolutely need to attract (and maintain) a large readership.  What that usually translates into is an extreme focus on only the latest and greatest devices.  When you constantly remind people that they are behind the times (even if their phone is brand new), it messes with them psychologically.  They will perpetually lust for gizmos which are out of their reach, and so they will constantly revisit these sites to get their fix.  When people get into this gadget frenzy, they forget that the bloggers themselves live in a tech writer bubble that in no way reflects the habits of the average user.  They get demo units and early access; they often have a new primary phone every month (or every other week!).

I find that these professional sites a great resource when you're in the market for a new phone, but once you find the right one, there's no good reason to come back.  You're not going to find much in the way of tips and tricks for your new hardware, and after a couple of months, you might not even get timely news in regards to OS updates.

On the other side, you have the amateur/barely professional bloggers.  These sites are run by writers whose bylines state that they've had an Android phone for a year or less.  They refuse to do anything resembling journalism.  Their news pieces are instead culled from rumors, speculation, and bullshit.

To give you an example, do a search for news on the 4.0.4 software update for the Verizon version of the Galaxy Nexus.  It's been mysteriously absent for months, and no one's sure what's happening, or when it will arrive as an Over the Air update.  But if you do a Google news search, you'll find tons of Android sites stating that the update is already out on OTA.  Their proof?  Other shitty Android sites, who in turned linked to yet another.  Follow the trail far enough, and you'll realize that there was never any concrete evidence supporting these claims.  It appears as if the entire community is linking to each other in a neverending circle of BS.

Staying with the Nexus, the other typical news piece announces that the update is available directly from Google, and is ready to be installed manually.  You just need to make sure you unlock your phone.  And root it.  Or maybe you don't need to root it.  Who knows, because everyone gives a different set of instructions on how to apply it (and their comments sections are filled with people asking why it isn't working).  Most of these sites have no idea what they're talking about, and I find myself uncomfortable trusting anything they provide, be it news, tips, or a download link.

It's unfortunate, because it means that a lot of the potential inherent in the platform will be inaccessible to a huge number of users who simply don't want to be given the runaround.  Whenever I see someone express their fears of rooting their phone, I completely understand where they're coming from.  With some of these sites, it would be akin to driving your sedan into a shady chop shop for repairs.

Android Development

Last winter I was inspired to try my hand at iOS development. The experiment didn't last very long.  I just couldn't get the hang of any of its key components.  The Xcode IDE, the Objective C language, none of it clicked.

In a similar fashion, I recently tried to get into Android phone development, but this time I'm actually making progress.  I can think of at least one obvious reason - thanks to my work experience, I'm already familiar with Java development and the Eclipse IDE. The question on my mind is just how much of a difference this makes.

For example, regardless of the language being used, I feel like Google's documentation is better than Apple's.  But is that really accurate?  Or is it simply that the Android tutorials were easier to get through because I wasn't also trying to learn a new language? On the same note, I feel like working with Eclipse was much simpler than Xcode.  I know why I like using Eclipse, but is Xcode really as bad as I think?  I know my perspective is clouded, but I can't tell if it is warping my expectations.I'm not surprised that working on iOS proved harder at first, but did I give up too quickly because it wasn't exactly what I'm used to?  In other words, I don't want to give up on something unless I know it really, truly isn't clicking with me.

All I can do is describe the differences in my two experiences.  If you're out there, feel free to tell me where I'm being too harsh or too lenient on either platform.

IDE's - XCode VS Eclipse

Xcode has a weird way of switching between contexts.  One minute the interface looks like this:

And the next, like this:

and sometimes there seems to be no obvious way to switch between one and the other. Technically, this isn't much different than how Eclipse displays its features across multiple perspectives (each with different visual configurations), but the saving grace of Eclipse is that it never takes away your control.  You can add, remove, and relocate a feature to any part of the IDE that you want, and you can always access a list of available perspectives.  In Xcode, I would find a way to go back to a previous screen layout, only to find it was missing a window somewhere.  Where did it go?  Did I follow the right workflow?  I have no idea.

Additionally, XCode is laid out very much like iTunes.  Aside from the sense of visual unity, I don't think there is any benefit to this decision.

Documentation

The documentation for the two platforms differ in both content and ideaology.  Here's a clip of Apple's "Getting Started" page for iOS development:

Set aside the fact that this looks like a generic search result page, and notice that the first document listed covers such topics as App Store submission.  This is supposed to be developer documentation - monetization shouldn't be the first priority for such an audience.  

Furthermore, the subsequent topics each tackle a very narrow aspect of App development.  It's important to understand Networking and Data Management, but until you understand the general structure of an application, how will you know where (and how) to apply these topics?

Ultimately, I gave up on relying on exclusively on Apple's provided documentation, and started looking elsewhere.  I found that no matter where I looked, every guide on iOS development shared an obsession with MVC design model. Let me be clear - there's nothing wrong with MVC.  In fact, it is crucial for the purpose of most apps.  But the thing about design models is that they're guidelines.  There aren't many hard and fast rules governing them.  This means that different people will interpret them differently, and and there's no way to establish a definitive, "right" way of doing something.  Breaking up your code according to the MVC model can have its benefits, but it won't magically make your code work better or run faster.  But iOS developers don't seem to agree with me on this, and so they focus on adhering to the model at the expense of explaining the actual code.  A typical line from a tutorial would read like this:

We need to start off with our Model, so here's some code that will create one for us.  Don't worry too much right now about what this all means, just know that this is how you set up Objects/variables/messages/etc in Objective C.

If there's one objective observation I can make, it is that these iOS tutorials are at a disadvantage, in that they assume (understandably) the reader is not well versed in Objective C.  They're trying to teach two things at once, and since most app developers are more interested in making piles of cash money than in learning the nuts and bolts of a programming language, the details of ObjC are deferred on as much as possible.  That being said, it is important to know why you are doing something the way you are, even if you don't entirely know how it works.  The sample applications I read through were made purposefully over complicated, and by the end of each I had no better handle on Objective C than I did before I started.

Google's Android documentation takes opposite approach.  It is clearly by developers, for developers.    If you work through the beginner guides, you'll barely see a word written about MVC.  When writing a basic app, there's not enough code to justify separating the model from the control, and the view is little more than a few lines of XML. The authors of the dev. docs understand that there's little reason to introduce MVC until there's an actual benefit to using it.  Until then, they are more than happy to help you build a simple app from the ground up.  Here is a snippet of the Android Development site:

Notice that the focus is entirely on how to build applications, with additional info on individual topics.  If you take advantage of the Android dev. docs, you can get a solid foundation upon which you can add the specific features you need.  The progression feels entirely natural.

The major disadvantage of the dev. docs is that instead of assuming you don't know the language (like Apple does with Objective C), Google assumes you're already well familiar with Java (and in some cases, the concepts behind the Android SDK).  One early tutorial (a simple notepad app) namedrops both anonymous inner classes and the Dalvik VM.  If you know what any of this means, the tutorial is a joy to work through.  If not, you may find yourself completely lost.  This isn't necessarily a good thing, but at the very least there's no mistaking who the intended audience is (and I'd still argue that the articles do a pretty good job at explaining each method call, right down to what the arguments are for).  

Final Verdict

There are a lot of idealogical differences between iOS and Android, and it isn't surprising to see them bleed into the development practices for both platforms.  That being said, the situation with iOS isn't as bad as I've made it out to be.  Apple's introductory material may be general and useless, but the full documentation set manages to cover every concept with great detail.  If you're a serious programmer, you'll sort through it all if you really want to, and I think Apple knows that.  They don't take care of this audience because they know we'll take care of ourselves if we have to.