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.
No comments:
Post a Comment