I mean that in a very special way: its syntax is complex and extensive. Apple has been making strides in reducing the size of the Objective-C language, like their slow-but-steady transition away from classical C-style header files. So while the language is getting larger, the code used to express ideas in the language is getting less complex.
Among other things, Objective-C lets you do function currying, adding and removing methods from classes at runtime, and reflection. Lots of great things feel really weird the first time you try them, like broccoli or sexual intercourse. It would be like trying to write a web app in Ruby from scratch without Rails.
Cocoa is very old and very large. However, there is still a lot to learn when making even the most simplest of apps. While the header files and developer documentation provided by Apple are wonderful resources, there is still a lot of assumed knowledge. Take the contentStretch property on UIView, for instance. This is all the header file has to say:. What does it do? Now I build my foundation of Object-c.
I hope I can go further. An excellent introduction to XCode and Objective-C. The instructor illustrates all of the basic concepts with code examples, and walks you through most of the assignments, allowing you to learn by doing. The time requirements are quite modest. Well respected Universities in addition to Duke, Michigan and Virginia. Compared to the very short courses from other reputable Universities. The instructor is very knowledgeable about Objective-C and iOS programming. The walkthroughs were very well done.
It doesn't matter if you are a rookie or a veteran programmer, this course will help you start iOS development with ease. Great way to start iOS programming and using Objective C. The course covers programming basics in Objective C, xcode and cocoapods, basic user interfaces and goes deep in key aspects, like memory management. Thank you! Course is designed very well. One feedback though is I had to go through other books or sources for practice exercises and if they can be added to course it would be complete and give more confidence to students.
Awesome course. Great teaching style. Just love it. Wish I could get full scholarship for admission for the masters or phd degree as I don't have enough money to pay the application fee. Anyways love it. Great stuff. Unfortunately, i am only 15 and i don't have any money to buy a qualification but thank you so much anyway for taking time to create this amazing course and especially for making it free!
I am just a beginner and i Love apple inc and its products. I would love to learn this course and the instructors are cute and amazing. We will have a good communication and relation here. Enroll for Free Starts Nov About the Course An introduction to the Objective-C programming language. This will prepare you for more extensive iOS app development and build a foundation for advanced iOS development topics. Objective-C programming requires a Mac laptop or desktop computer.
An iOS device is optional if the learner is willing to working exclusively with the simulator. Some learners have been able to work with an OS X virtual machine on Windows, but explaining how to do that is beyond the scope of this course.
Upon completing this course, you will be able to: 1. Read and write Objective-C 2. Have a strong grasp of Objective-C objects 3. Organize their code professionally using objects and blocks 4. I'm not sure what you mean by not mentioning what is passed in. Keep in mind: I have never programmed in Objective-C.
I am going on intuition alone. No namespace support is a bummer - it means you're going to end up with long identifiers all over the place. That's one of the things I'm finding most annoying about learning Obj-C. The weird thing is that these extra long names make the language less readable to me, because I have to mentally diff very similar looking long strings.
I think the verbose method names are a Cocoa design decision. The design philosophy behind much of Objective-C is described in Brad Cox's book "Object-oriented programming: an evolutionary approach" [1]. Unfortunately, I don't have a copy handy to give you a quote.
It's a technical requirement. Parameter types are not part of the method signature, so you CAN NOT define both [string append:string] and [string append:int] methods. You must give them different names, like [string appendString:string] and [strig appendInt:int] , in order to give them different signatures.
I don't think Objective-C is hard at all. If you understand OO or come from a OO language you can pick it up pretty fast, like in a day or two. Cocoa on the other hand requires much more learning curve. Also apple could improve their documentation. If you compare Apple's documentation to Android's Here's a good example: I'm an iOS developer, and have been since pretty much day 1 of the platform.
I recently actually started playing around with the Android SDK, and environment. I followed Google's supplied tutorial for creating a tabbar app, and asked one of the Android devs who works with me to come take a look at the finished result. We don't do tab bars like that any more.
We use fragments instead". And sure enough, when I looked closely, Eclipse was telling me what I'd done was, in fact, deprecated and Google recommended a different approach. Except I'd followed their main tutorial for Android, step by step. Compare this with Apple, who have consistently updated their documentation for each API release. How Google could possibly think it's a good idea to deprecate a major platform feature for fragments a good thing and not update one of the most popular tutorials on their site to reflect this the 'Hello Views' tutorial is beyond me.
This is hardly consistent even in Apple's world. I recently went through your exact exercise myself, except instead of tabbars in Android, it's Core Data storage in iOS. I really don't think "shitty documentation" is a uniquely Android thing, nor is it something iOS has resolved. Why does a comment about Apple's documentation need to turn into a holy war versus Android? Do you have any examples of big libraries where "they could improve the documentation" is untrue?
I can't think of any offhand. This is not snark. I'm honestly interested if you do. APIs are perpetually under-documented, in my experience, so the parent comment's observation is essentially an empty statement. I never really worked with Android so I can't speak for it. But I completely agree with you on the updated documentation, I just feel that sometimes I get a little lost when I trying to learn how to use a class or framework. Comparing any other documentation to Googles is just too easy since Google is generally very poor.
I'm going to disagree. Programming for me at least isn't knowing the syntaxual elements of a language but leveraging paradigms I know to exist from one language to the next. Objective-C while looks different, is really no different than most languages. It definitely shouldn't be your first language, maybe not even your 2nd choice, but if you have a conceptional knowledge of programming languages and you're keen on diving into the deep end, there's enough resources out there you're not going to drown.
I love Objective-C for many reasons, but then again I equate programmatic choice to personalities. If that makes sense. Point being, don't be deterred.
What you should probably decide for yourself is if this article makes it seem harder than it is. His conclusion about Automatic Reference Counting is on the money, but that's about it. No is not. These are different. If anyone is considering learning this language, there's a bunch of unsolved problems that frequently include writing new libraries. It might be verbose, but you have a clear separation between C and Objetive-C.
If it doesn't contain "[]" or " ", my brain can just parse it as C code. It's best to think of Obj-C method call syntax as a sentence, written in english, which happens to also be computer code. If you name your methods and variables succinctly and explicitly, the language is extremely readable and documents itself assuming you know english.
Obj-C was the first language I learned after Python. I remember the 2nd month in, it went from being difficult to read, to extremely easy. Human eyes like simplicity, like right angles, and columns. The same is true of most programming languages. Simple things like layout improve readibility, and thus productivity, immeasurably. Syntactic sugar dynamic getter and setters using synthesize, property, allowing for dot syntax accessors is not new.
Nor is Garbage Collection. Objective-c 2. Blocks, at this point, are not really new either. So, I think it's incorrect to say that Apple is 'adding' these things. If a newcomer checked out the online documentation for contentStretch they would find: "Defines portions of the view as being stretchable. This behavior is typically used to implement buttons and other resizable views with sophisticated layout needs where redrawing the view every time would affect performance.
For instance, a someCALayer. However, you can't do myLayer. The introduction of the 'simpler' dot syntax, in that example actually makes things harder for a new programmer. So, I don't agree that syntax is why Objective-C is hard.
Intimidating because of syntax, perhaps. But, once someone begins coding IMHO it can be one of the easiest languages. My school taught Pascal in the intro to comp sci class. I found it incredibly difficult well, maybe dull is a better word. I then self-taught myself actionScript late 's. It takes years to become fluent, but I really think that when someone grasps the basics of Objective-C, over time it is one of the most intuitive languages.
AshFurrow on March 6, parent next [—]. I'm not saying that the information isn't available - I'm only saying that to someone new to the framework, it's hard to know what you don't know yet.
As a concrete example, you actually can do myLayer. The results might not be what you expect, especially if the CALayer exists in a hierarchy already and if the anchor point isn't the centre of the layer, but how would you know that if you hadn't experimented already? Right, it won't cause a crash -- just unpredictable results.
My point was more that dot syntax doesn't always equate to easier coding; In this particular case though, who would be playing with the CALayer class without ever having touched the documentation? The overview of view geometry frame, anchor point, bounds, position is second only after the Core Animation introduction in the docs. And it's pretty clear: when you get a frame from a layer, it is an implicit function of the anchor point, position and bounds -- but the frame itself is not stored when you set it.
So, if you're using dot syntax to store properties throughout your code, and then you use it on the frame property, a casual reading of the code might lead someone to think that you could retrieve that value later and have it be the same.
How many hackers out there always read the entire manual before playing around? I'd wager most. I agree that Objective-C is slightly schizophrenic about the dot-syntax, but I would argue that dot-syntax for getters and setters is easier for a newcomers to learn. I'm not saying one has to read the manual before playing around, but some things are simply not explorable with at least a little bit of introduction.
You had to read somewhere that [NSObject alloc]init] was how to create a new object; you didn't just guess at it. Similarly, how far would someone get creating a CALayer, and adding it to a view without ever looking at the docs? If someone is having a hard time learning Objective-C, maybe the real suggestion is to start by reading at least a bit of the manual. GC is deprecated as of Just to be clear, I was referencing the point in the original article where it said that apple was 'adding Garbage Collection' to make the 'code expressed in Objective-C simpler'.
The entire article is about how Smalltalk syntax is different from C syntax, something that any reasonably competent programmer gets over very quickly. And he gets it wrong. The article is a complete waste of time. I think it's very largely a question of what you're used to.
I don't know much about Objective C, but given my knowledge of Smalltalk, the use of keywords to identify arguments seems entirely natural. But then I've never really understood why people think it's acceptable for languages to insist that you do this: myfunction "First argument","Does this one really go second?
Anything you do not understand is inherently hard. The only thing i would say is uniquely hard about Objective C is getting your head around some of the APIs, but then again that can apply to any language. To me the hardest thing is the seemingly arbitrary CG functions in Quartz2D and why they're so interspersed throughout the code.
If I'm writing within the UIKit most of the time, and then have to make my own UIView for some custom drawing, I have a hell of a time remembering how, and always have to reference my earlier code, which I usually find on StackOverflow or somewhere else. CGFillSomething maybe? I guess I would just like to see the Quartz stuff conform more to UIKit naming conventions but because it's based in C, I understand why it's not.
Well, from my limited experience with Objective-C a few things made it hard. This always seemed to me to be a deception in a way.
Another pet peeve of mine is the same agony of choice that is object variables pointers versus values. When I want to return something or declare a variable, even when I am in the rose-tinted-glasses Cocoa world of beautifully-named methods, classes and keyword arguments I still have to put the dreaded death star in front of just the right things and to remember NOT to put it in front of exactly proper other things.
So I guess for me the most problematic Objective-C part is the one that has to do with C because it adds a level of complexities on top of C. The "Objective" part is actually very nice, once you get used to the call syntax and the brackets. Hard is OK. Over time, you become better at it, until it's no longer a problem -- it's a relative thing.
Example: I find Russian very hard to speak. That doesn't mean Russian IS hard, I just don't know russian. And some languages are harder more stuff to learn than others. Not looking for trouble here but writing an iPhone app should be no more difficult than creating a Keynote presentation, imho. If Apple is the leader in document development Keynote, etc , why can't they do the same with writing apps.
Look at what they've done with the complexities of video editing. Where is the consumer grade development app for iPhone? I've only learnt 2 programming languages 'thoroughly'. Pascal and Objective-C. I find Objective-C a much simpler to understand language than Java for example. I have worked in Java although not extensively and it just seems messy to me. Objective-C is much more human readable and better structured in my opinion. Yeah, I agree. It's a beautiful and expressive language.
The syntax? You pick it up within a week. Message passing versus method invocation? An important, but subtle distinction. So what makes Obj-C hard? For me, it was Apple's gigantic MVC-style framework. APIs are designed and interacted with in a certain way. Apple's API feel completely different. From building strings and making network connections to working with images and animations.
Apple's version just feels different. Of all these I'd rate Objective C as the easiest to learn and to handle. It's much more forgiving and easy on the programmer, and the syntax is trivial. You seem to make a big case of the message passing syntax, but your example is very poorly chosen. Named parameters may seem verbose but they are much more readable than 'performAction param1, param2 '.
In terms of complexity and ease of use, it's a different picture. The IO libraries are kind of a mess but I don't find the algorithms and containers significantly more difficult to use than similar implementations in other languages. Deinumite on March 7, parent prev next [—]. If there was a special syntax for just string and container classes, large swaths of my code would be smaller. UIKit view controller classes are also not flexible enough, and crap out in a lot of custom multithreaded operations when they shouldn't.
I could reproduce the same behavior with my own classes animations, transitions, view control, etc using just basic UIView classes and it would work significantly better. Beta version of XCode has dict[ 1] or dict[ "key"] for accessing members. It's great. I find Objective-C hard as well, but it has more to do with the nature of the message passing syntax that objective-c has. There are other items like that. Not much help when the app crashes, lack of Namespaces class name collisions , etc.
Then throw in all the fun of submitting an app to the store. Working with iAds and In App Purchases will make you want to hurt something. I don't understand all these comments about Objective-C being hard. Maybe it is because I am programming computers since the Z days, or because like it is expected in my country I did a good earned CS degree. If you think using a language like Objective-C is hard, maybe you should not be programming at all.
Rather than performAction:firstParameter withTwoParameters:secondParameter which is kind of confusing. Really the only thing that makes Obj-C the language hard is that the C layer pokes through often enough that you really do need to understand C as well and C presents a lot of pitfalls to a new programmer.
Not hard. People have a natural inclination to resist the new. My guess is that a competent programmer with OO experience should be comfortable with Objective-C within a week or two of study. I know this is a short article meant to explain the basics but I don't like how under the History section it makes no mention of NeXT or Stepstone which were the creators of ObjectiveC.
AznHisoka on March 6, prev next [—]. Before I took the jump to learn Objective C and iPhone development, I dreaded the huge learning curve needed.
Objective C isn't hard. Ruby isn't hard. Building a great app is hard. Building and running a great service is hard. Building and running a great company is hard.
0コメント