The language jump is OK. Once you get past the initial shock of [
and ]
. However, the libraries and Framework shock will be substantial.
The Cocoa and Touch frameworks are significantly lighter when compared with .Net Framework, so at least you can look at the bright side, you have less to learn. But their underlying philosophy, layout and historic evolution path is very different from the C#/.Net framework. Whether this will be easy or hard, is difficult to appreciate. Some personal opinions:
- The Cocoa way of building UI is light years ahead of anything .Net framework has today, Forms or WPF. It will be difficult to grasp at first, but if your grok it, it will make a LOT of sense. It is good ole' Model-View-Controller based on Smalltalk framework and will naturally guide you down a right path of designing UI.
- Graphics, video, media are going to feel as from another planet when coming from .Net background. But despite their apparent arcane appearance, the Cocoa offerings are very powerful, although somehow low level.
- Animation is going to be a huge sigh of relief. Cocoa animation is just plain easy to use, and there isn't anything equivalent in .Net
- If you do openGL instead of Cocoa native graphics, then is openGL and openGL is pretty much the same flavor on any platform.
- Network programming is poorer on Cocoa side. You have some basic support and gotta admit that at least the API is designed that is really hard to do stupid stuff (it forces you to use async programming, so no more one-thread-per-client non-sense), but I'd bet you'll miss the .Net sugar utilities (WebRequest, WebClient etc)
- XML parsing. Cocoa support is just plain primitive. At least, again, the XML parsing is event driven so is going to guide you toward better programs, but is complicated to put together.
- Database. Is going to be a different world. You have the choice of going raw SQLite or Core Data. Core Data is better imho. Is a high level ORM and active record kind of stuff, with all the intricacies of the underlying storage abstracted away. Easy to use and powerful, as long as you ask it to do something it knows how to do. Unbelievably cumbersome to force it to do something it doesn't know how to do. True for any ORM, ultimately. You'll miss LINQ, and you'll have to forget SQL. The gist of it is that the DB programming experience from .Net just doesn't transfer to Core Data world. The alternative of raw SQLite will look more familiar, but is very low level, will feel more like programing 1990 ODBC than 2010 .Net.
- Key-Value Coding Programming. This concept has no direct .Net equivalent. It may sound like some sort of simple dictionary, but in fact is way more powerful. It interweaves with the runtime engine of the Objective part of [Objective-C] and gives birth to some neat tricks. You'll need to understand Key-Value coding to make efficient use of Core Animation or Core Data. You can think at it as reflection on steroids. It can achieve some of the same tricks Linq-to-Objects can do, but is not going to be anywhere as elegant as Linq.
- Is C++. Objective-C is a superset of C++ and is backed by recent drops of gcc, so you can fall back to C++ anytime. STL, functors, template metaprogramming, they all work. You can mix and match in the same application pure Cocoa and Core Objective-C with C++. You won't be able to do something like inherit an Objective-C class as a C++ class, but you will be able to communicate between a C++ class and an Objective-C object. Not sure what is the current status of boost or Loki support.
Many of the areas covered poorly in Cocoa have various 3rd party libraries, but I can't enter into comparison all Cocoa 3rd parties vs. .Net 3r parties, I have a life...
Overall, I would sum it up shortly as In Objective-C the entry bar is higher. Bring a brain.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…