Phil,
My programming background is quite varied: I've been at this for 20 years, give or take, since I was a kid. Started with BASIC (Commodore, no less. Ack!), and worked out from there. Languages I've had experience with include Pascal, C, C#, VB (Unfortunately), PHP, PL/SQL, and Javascript, along with some other minor excursions into various other languages. I've been working in PHP and Javascript the longest, simply due their proximity to web development. What that ultimately means is that my sense of syntax and grammar is already very C-like, so I would mark that up as being a large help. [Though I still get trapped by the spurious "var" in obj-c, when it should be "int" or something similar.]
Probably the biggest thing that helped me wrap my mind around Objective C was something I read somewhere, and I wish I could remember where... but it boiled down to saying that Objective C is a marriage between C and Smalltalk. I've had enough experience with smalltalk (back in my college days) so that helped cement the underpinnings of ObjC's idea of objects, which is both similar and disimilar to a good portion of the languages I'd previously worked with. In reality the only difficulty in picking up the /language/ of Objective C was getting used to bracket notation when sending messages to objects instead of dot notation (which is reserved only for property accessors). Given that I might write "object.doThis()" in JS, the same would be written "[object doThis]" in ObjC. The next biggest thing was in getting over how parameters were handled. While it is great for readability, it does tend to get verbose. In away, ObjC's methods are more akin to methods with named parameters that are required than they are to regular parameter passing (where it is done by position). For example, in JS I might write a function declaration as "function doThis (a, b, c)", in ObjC, I'd do "doThis: (type) a withB: (type) b withC: (type) c". Not that you can't do the other in ObjC, just that it's the preferred convention.
Of course, being a C-based language means that all the C notation is there too: you declare a string as "NSString *", and you pass variables by reference using "&" [when appropriate]. You also have to deal with primitives not being boxed automatically, so an "int" isn't always something you can use without converting it to an NSNumber. Or vice versa. Further, given C's proclivity towards type casting, you also see this quite often in Obj-C. Consider that all objects are of type "id", you often will see something along the lines of this: "(MyViewController *)[subviews objectAtIndex:1]" whereby I'm taking an object from the subviews array (which contains any object, but typed to ID), and then I'm typecasting it to the type I need.
Becoming productive in the /language/ was pretty quick. It really is a matter of understanding the grammer and syntax, and then getting used to the differences. What took longer, I think, was the concept of how the libraries worked to build the user interface. I've written programs for both Windows and Windows Mobile (when it was CE), and so I had a pretty firm grasp of how Windows constructed its UI. Apple does things entirely differently when it comes to iOS, and I had to unlearn my personal concepts of how UIs really did work. Getting used to the view hierarchy really was the hardest thing for me to do, and I won't vouch that I'm there 100% yet.
This wasn't helped by going the "Apple Way" and jumping into storyboards immediately, either. I think they are great for mocking up a UI quickly, and even including a good deal of interaction. For simple apps, it could probably work quite well. But to me, there was too much magic going on. The same tended to apply to Interface Builder when desigining forms and such visually. Yes, great, visual design for a visual user interface, but I don't know... I've always preferred my UIs in code. Perhaps because of the flexibility, the lack of magic, and/or this is the way I'd always done things. ;-) So once I dropped going with StoryBoards and Interface Builder, I was a lot happier and much more productive. I bought various books and looked at lots of sites (
http://www.raywenderlich.com/ is a good one), and then got busy coding. After a couple misfires, the code that started to come out started making sense and actually working!
Consider this: the little objective C I /did/ know came from peering inside Phonegap and its plugins. Put that around January/February of this year. Now, by early March, with less than a month of intensive coding, I've got just over 5k lines of ObjC. Granted, to compare line count with performance, proficiency, efficiency, etc., is a fallacy, but it does indicate that there's plenty of stuff going on inside. Is the code excellent? No. Are there better ways of doing things? No doubt. Does it /work/? Yes. Is it working better than the non-native method? So far, /yes/. I don't want to think about how much of my non-native code was working around a webkit glitch, or was a tweak to get a little closer to native look & feel (lots), whereas here, the code is all doing app-specific work: loading data, displaying it, taking it from the user, etc.
That I'm probably a couple weeks away from feature parity doesn't necessarily indicate the effectiveness of ObjC as a language, or UIKit as a framework: a lot of this stuff I'd already developed for the non-native app. If anything, I could consider that non-native app a good mockup. The majority of the concepts can be used directly, and it's really just a rewriting of code. Along the way some changes were made, obviously, as would occur in any rewrite, but the concepts were already in place. Without those concepts in place, I'm unsure how long it would have taken to get here.
Okay, that's a long-winded answer, so the TL;DR of it is this: languages previously known: C#, C, PHP, VB, PL/SQL, BASIC, PASCAL, dabs of SmallTalk. Time from start to productivity: <3mo. [This is really closer to ~1.5mo, TBH, if you don't count my first failed attempt at storyboards. But it was part of the learning process...]
Further, let me state that I rather like most of the languages I know, so I'm not attempting to state that ObjC is an easier language, or that UIKit is necessarily a better framework than any other UI framework. Half the difficulty with the non-native solution was the lack of a good debugger that you could use while doing on-device work [And weinre is /great/, btw. But it's not a fully-fledged debugger yet.], and the other half was working around webkit's glitchiness. [Case in point: implementing native scrolling. Should be easy, right? Wrong. Scroll feels great, but then you'd find out that text wasn't rendering correctly. Fix? Add webkit-transform:3d-translate(0,0,0). Why the flip did that work? These are things that are less about fixing bugs in your actual app, and more about trying to get webkit to work the way it /should/ all on its own. Or stopping the bounce effect. Typical solution: stop the default event action via javascript. Turns out that nukes other things that you /might/ want in your app. Then you have to rebuild them. Turns out its easier to use some ObjC to turn it off. *sigh*]
And just to drag this out a little longer, I don't mean to say that PG and/or non-native development never has its place. Just that it wasn't working out for me with this particular app. Had it been a different app, things probably would have gone differently. What is the right tools for this app (native Obj C) may not be the right tools next time.
Hope that made some sense!
On Tuesday, April 3, 2012 3:07:24 PM UTC-5, Phil Mitchell wrote:
On Mon, Apr 2, 2012 at 10:41 PM, Kerri Shotts
<kerri...@gmail.com> wrote:
- Objective C and UIKit and Foundation, etc., are actually quite easy. You can get a lot accomplished with a few lines of code.
Thanks a lot for the insights. I'm curious to know where you were starting from when learning Obj-C? What languages did you already know and how long until you became productive in Obj-C?
You received this message because you are subscribed to the Google
Groups "phonegap" group.
To post to this group, send email to phon...@googlegroups.com
To unsubscribe from this group, send email to