I am working on an application in which I need to migrate the whole code of it from carbon to cocoa.I have experience in programming of C,C++,python and Java during my college time and internship but have never touched objective C or have done any programming for Mac(Carbon and Cocoa) before this.
So Can you please suggest me some sources to start with, also how should I go about the whole migration ?
After researching on net I have found that most the people have suggested following books
Cocoa Programming for Mac® OS X, Third Edition by Aaron Hillegass
Programming in Objective C - Stephen Kochan
I have got both these books.
Should I read them first and then should start with the code change? (it will take some time to read both of these)
OR
after having a decent fimiliarity with Obj C and Cocoa, should I directly get started with code migration?
Also,
since I don't know carbon , what should I refer to learn carbon to have sufficient knowledge to migrate the carbon code to cocoa?
First, learn Carbon so you can read the program and understand how it's currently implemented.
Install the Legacy documentation set in Xcode to gain access to the Carbon guides. You'll want to read the Carbon Overview, then Getting Started with Carbon, then everything that Getting Started links to. You'll also need to learn Core Foundation, which some of the more modern parts of Carbon use; read Core Foundation Design Concepts and the Memory Management Programming Guide for Core Foundation.
Then, learn Cocoa.
I didn't learn by the Hillegass book, but a lot of people swear by it. My current favorite Cocoa book is “Cocoa and Objective-C: Up and Running” by Scott Stevenson. The way I learned Cocoa was using Apple's own docs. Start with The Objective-C Programming Language, the Cocoa Fundamentals Guide, and the Memory Management Programming Guide for Cocoa. Much of the last document will seem really familiar, but skip nothing. Read every one of those guides from beginning to end and all the way through.
Once you've learned Cocoa's general concepts, you can move on to more application-specific material. Start with the Application Architecture Overview and most of what that document links to. The Cocoa Guides list has the full list of guides.
Down the road, you'll also need to make the application compatible with 64-bit mode. If you still have any Carbon code by that point, you'll need to read the 64-bit Guide for Carbon Developers; either way, you'll also need the general 64-bit Transition Guide and the 64-bit Transition Guide for Cocoa.
I am working on this process myself right now, and it's a fairly complex undertaking for a full document-based application that uses a few frameworks. My Carbon app has dozens of menu items, the interface is built with Carbon Nibs and implemented using Carbon event hooks. The programming language is C++. Going back in history, the original Mac classic version was implemented in straight C, so there's a little bit of legacy from that era too. Resource-based PICS for example!
There are several approaches one can take, so it depends on your particular situation how to proceed. In my case I decided to start with a bare Cocoa document-based project and start building the document loading code, because the hooks for that are already in place in the empty project. This seems like a good place to start for me, because it gets me into the mode of working with Cocoa and thinking about the app in terms of smaller pieces.
You really have to take a methodical approach and look at what your app depends on in Carbon versus which parts of your app are independent - for instance your abstract classes. If your app is in C++ there may be some pitfalls with converting over to pure Objective-C. Operator overrides can be tricky to notice, for example.
You can mix C++ with Objective-C, as described in Apple's Carbon-Cocoa Integration Guide and around the web you can find plenty of C++ wrappers for Cocoa foundation objects like NSStrings. So if you already have C++ classes that wrap CFString, these can come in handy.
Generally-speaking, you can leave your data storage just as it is. If you use malloc() and calloc() to make a linked list of structs, there's no special reason to move over to an NSArray. You won't get better performance. The real change comes in the interfaces, the way you call and access that data from other objects. If you decide to mix C++ and Objective-C objects in the same app it helps to encapsulate as much as possible. That is, as much as possible make your abstract C++ classes only refer to their own data and that of other C++ objects. Eventually this will make it easier to transition them to Objective-C.
If you're transitioning from one event model to another or from Carbon port-based imaging to Cocoa's views-based imaging, it's probably best to start with a fresh Objective-C app and bring over your model classes first. Add some test functions to make sure they all work within the new language. If your app is anything like mine (old) then it probably needs to display some things larger, and to have more polish in the interface. This is a good time to rebuild those parts piece-by-piece.
There's definitely no great shortcut. The PDF linked above is the best document I've found on the topic.
Related
This question pops up quite often here, even if just implicitly when users mistag their iOS questions. So, what’s the difference between Xcode, Objective-C and Cocoa?
Objective-C is a programming language. It could be said that it’s just a description of what valid Objective-C programs look like and what they mean. If you have a source code listing written in Objective-C, you need an interpreter or a compiler to put the listing to work. Languages like Objective-C are usually compiled, so most people use a compiler (like LLVM). Objective-C is almost exclusively used to develop for iOS and OS X, but there are other uses, too – as an example, some people write Objective-C for Linux.
You can use a text editor to write the sources and a compiler to turn them into an actual programs, but with modern technologies there’s much more to take care of, so that there is another program to make your job easier. These are called Integrated Development Environments, or IDEs. An IDE offers you a convenient way to edit the sources, compile them, debug the resulting programs, read the documentation, and many other things. Xcode is one such IDE. An important observation here is that Xcode does not compile your sources itself, it just calls the standalone compiler (LLVM). And Xcode is not the only IDE you can use to develop Objective-C apps – there’s AppCode, for example.
Writing iOS or OS X apps from scratch each time would be very time-consuming. That’s why Apple provides the developers with a good set of libraries. The libraries are simply a huge amount of source code written by Apple, and this source code takes care of most things that apps have in common. These libraries are called Cocoa.
Now, if you can’t figure out how to extend a class, you are most probably talking about Objective-C. It doesn’t have anything to do with Xcode or Cocoa, you could be very well writing some GNUstep code for Linux using Vim as an IDE and GCC as a compiler. On the other hand, if your Xcode build process fails because of some mysterious setting, or if you’re trying to build a static library in Xcode, that’s clearly an Xcode issue. And if you can’t figure out how to use some NSObject facility or the NSFileManager class, that’s Cocoa. (But it doesn’t have to be Xcode-related, as you could use AppCode or TextMate as your IDE!)
Originally available on my blog. Feel free to link to the blog post or this question when retagging or explaining the difference.
Xcode is the integrated development environment (IDE)—the application—that developers use to write software for iOS and/or OS X. It includes the editor, the build system (determining what to build to produce the desired target), and quite a few other things.
Objective-C is the main language that developers write such software in. They may write bits of it in pure C, use C++ or combine it with Objective-C (producing Objective-C++), or write some or all of the program in another language entirely, such as MacRuby, Java (with j2objc), or C# (with MonoTouch).
Xcode includes the Clang compiler, which turns code written in Objective-C, C, and a few other languages into executable code. Most error messages come from Clang, and Xcode relies heavily on it for search indexing, syntax highlighting, and name completion of Objective-C code.
Cocoa and Cocoa Touch are application frameworks. Each one is a suite of many individual frameworks (libraries stored in folders named blahblah.framework), such as:
Foundation (both): General object-oriented utilities, including NSString, NSURL, NSFileManager, etc.
Core Foundation (both): Mostly the same thing, but different, mainly in having a C-based API rather than Objective-C
Application Kit (Mac): Application and windowing framework
UIKit (iOS): Application and windowing framework
Core Graphics (both): Drawing
Core Animation (both): Sprite-management and animation framework
(and many, many more where they came from, especially on the Mac)
So:
You can use a framework besides Cocoa or Cocoa Touch, but you'll have to have some Cocoa/Cocoa Touch code, at some level, in order for your application to talk to the system, receive events, draw, etc. Frameworks that specifically target Mac and/or iOS will include the relevant wrappers for you, at varying levels of quality.
You can use a language besides Objective-C, but you'll have lots of syntactic awkwardness, as most of Cocoa and Cocoa Touch are designed for Objective-C's unique syntactic features (particularly selectors).
You can use an editor besides Xcode, and you can even use a build system besides Xcode (such as make), but Apple's App Stores expect apps built a particular way (especially with regard to code signing), so unless you're not targeting the App Stores, any other build system has to replicate what Xcode does or risk its users getting rejections.
A clear mistake is failing to differentiate Xcode from everything else. Xcode is the tool you are using to program in - to edit code, run code, etc. So if you are having trouble with the tool (e.g., the window doesn't show you your code properly, or you're having trouble drawing your interface, etc.), that's an Xcode problem.
If you don't understand why your code doesn't work, you're probably having an Objective-C problem or a Cocoa problem. But you won't necessarily know which.
It's an Objective-C problem if the root of your trouble is that you don't know how the language works (e.g. you don't know what the asterisk is for, or that declaration is not instantiation, or that messages to nil do not error out but don't do anything either).
It's a Cocoa problem if you don't grasp the delegate architecture or how a view controller works.
But my experience of the way people pose questions is that you may be ignorant of which of these you are ignorant of. I don't mean you personally, I mean all of us. This can make it difficult to pose the question properly because you don't know what exactly it is that you don't know — if you did, you'd know it and you probably wouldn't be having a problem (you'd be fixing the problem and on to the next thing).
It appears the language is the same for either device ios or mac os on a mbp, but if I learn Objective-C in a tutorial, won't I also need to learn cocoa or cocoa touch to program effectively?
I'm not sure how to start on my path of learning to program an ios device. I know I need to learn objective-c and that appears to work on all apple products. Then do I move to cocoa touch for ipad and iphone? What comes after objective-c?
The type of project is akin to a web app but native objective-c app instead. Have ui, buttons, the app hits some back end location, returns data, I put it on that same ui. Only, as stated, use objective-c and whatever framework and library to do it (that's my dilemma. I dont know what to do next after objective-c).
thanks.
Cocoa and Objective-c go hand in hand. For getting started, I would suggest going over some old WWDC footage and following some of the examples there.
As far as Cocoa and Cocoa touch are concerned, they are very similar in many aspects, same name conventions, similar structure, etc. Learn one, and you can easily pick up the other.
#craig adds:
I would further this answer by also mentioning that Objective-C is a programming language, while Cocoa/Cocoa Touch are collections of frameworks that are provided by Apple, and used by developers to add functionality to their programs. (Which are written in Objective-C.) The Cocoa frameworks contain various UI components like buttons, table views, sliders, etc. in addition to various fundamental classes like NSString and other text- and graphics-based APIs
I started my learning by watching thenewboston's xcode tutorials:
you can begin with this one
Good luck :)
I prefer books for some strange reason and I found that the Apress series of IOS development is really good. The book goes through developing iPhone and iPad apps using all kinds of Cocoa libraries. There's a lot of good books out there on the subject; I would go find one that looks like it would suit your needs.
I have some basic familiarity with Objective-C, but prefer Ruby, so I'm thinking of playing around with MacRuby. Is it possible to use MacRuby to develop applications for the Mac App Store, or do I have to use Objective-C? (Note that I don't care so much about iOS/the iPhone and iPad store right now, just the Mac OS X app store.)
And to answer the actual question, yes, see http://lists.macosforge.org/pipermail/macruby-devel/2010-November/006475.html.
Short answer: Yes, you can, technically, build such an app. You need to revisit the store guidelines to know what requirements must be met to submit to the various stores.
This comes up sporadically; beyond the guidelines that #NSResponder mentioned, the reality is that you'll just be spending a lot of extra & unnecessary time if you decide to use MacRuby unless you plan on using some large chunk of already written Ruby code in your app.
Learning Objective-C is about 2% of the overall learning needed to be an effective Cocoa developer. The other 98% is everything from memory management model to standard idioms like KVC/KVO/delegation to NIB files to the myriad of classes & APIs throughout the system.
All of those things are written in Objective-C (or C) with documentation targeting Objective-C and examples written in Objective-C.
As well, the entire tool chain is focused on validating, compiling, indexing, debugging, and manipulating Objective-C.
If you want to use MacRuby to build a real Cocoa app, you are going to have to know Objective-C through and through anyway. And you are going to have to deal with whatever bugs and impedance mismatch is in the bridge layer, too.
Yes. As the Mac developer forums says:
My Mac app is not written in
Objective-C. Is this allowed on the
MacApp Store?
Yes, provided it also adheres to the
Mac App Store Review Guidelines at
http://developer.apple.com/appstore/mac/resources/approval/guidelines.htmland
the Mac Developer Program License
Agreement at
http://developer.apple.com/programs/terms/mac/mac_program_agreement_20101020.pdf
(via alloy)
Read the submission guidelines here: https://developer.apple.com/appstore/mac/resources/approval/guidelines.html
I'm trying to build a dual platform application for a company of my own I'm trying to start at night.
I have the .NET version done, but have not finished the UI part. I'm thinking of buying some 3rd party controls.
If I buy these controls, however, they clearly will only work in my Windows version. I'm wondering if I should try to do the UI in GTK# and use Mono with CocoaSharp or just build the thing in MS technology and teach myself the Mac side?
I'm just really unfamiliar with the Mac world and am wondering how much of a learning curve there might be.
I've thought perhaps of rewriting my core logic in Ruby or Python. This why I could use the .NET version with .NET controls and presumably hook the same code up on the Mac.
It's an educational app targeted at consumers. As such, it shouldn't require a lot of technical sophistication to install.
If the non-visual part of the .NET application is quite big compared to the UI, then you can go full .NET and adopt the following two-steps strategy:
Non-Visual Part
Develop the non-visual .NET part to be the most platform independent.
Platform dependent code for non-visual code should be isolated in small classes that provide the same interface so they could be plugged according to the platform.
User Interface
Use System.Windows.Forms (or your favorite toolkit) for Windows
Use a Cocoa bridge (see this page for the choices) for Mac OS X.
You still can benefit from learning Objective-C: as the Cocoa bridges are usually heavily based on the Apple's API, you will find a lot of help in the Apple's sample code (which are in Objective-C).
On Windows, the application will run with the Microsoft .NET runtime and on Mac OS X, the application will run with the Mono runtime.
The DeepMeta application uses this strategy. As you can see the user experience is quite good on both platforms.
Avoid using cross platform UI tools; the result will never be as good as a native implementation, which is especially bad on the OS X where most customers expect a certain level of polish in their applications. Implementing the core logic in a platform independent language like C++ and maintaining a different code base for the interface on each platform can be a good solution, especially if you have a very complex model.
Anyway, you shouldn't have too much difficulty learning Cocoa if you're a good .NET programmer; I did the reverse several years ago and didn't have much trouble. Objective-C is more C oriented than C#, but if you know the basics about pointers and such you're going to be okay. Cocoa and .NET definitely have their differences in certain areas, but they're both high level frameworks which you shouldn't have too much trouble understanding. Get a good book (Hillegass is the go-to author) and go through it so you understand how the two APIs use different design patterns in certain areas, and don't try to fight the framework if it's different than what you're used to.
In my experience this will make you a better programmer in the long run by expanding your knowledge, even if you don't write any more Cocoa applications.
I've been developing for Windows and *nix platforms for quite some time, and am looking to move into Mac development. I am tossing up between using ObjC/Cocoa and C++/Qt4.5.
The C++/moc semantics make more sense to me, and improving knowledge in Qt seems like a sensible thing to do given that you end up with a skill set that covers more platforms.
Am I likely to handicap my applications by skipping Cocoa?
The sample Qt applications look pretty Mac-native to me, but they are quite simple so potentially don't tell the whole story. Are there other pros to the Xcode way that Qt doesn't have, such as packaging, deployment, etc.?
Here's an easy way to answer it:
If you were developing a Windows app with .NET or MFC, would you handicap your applications by using Qt? If the answer to that is yes, then the situation is likely to be the same on the Mac.
A few negatives I can think of off the top of my head:
Licensing
Qt apps, while good, are not completely a native UI experience and there's things a native UI designer can do in Cocoa which boggle the mind. While I can't be sure that all the same functionality isn't available in Qt, I doubt it.
Qt is always a little behind. If Microsoft or Apple come out with a great new technology, you have to wait for the Qt developers to update Qt.
However, with all that said, only you can determine the business value of using Qt. If you think cross-platform development is going to be a major part of your development, then Qt might be worth it, despite the issues mentioned.
Ask yourself: how many of the best Mac applications that you know of use Qt instead of native Cocoa?
For our robotic systems, we originally wrote our control software in C++ using the cross-platform wxWidgets library (we avoided Qt due to some licensing concerns), because we felt that we had to target Windows, Linux, and Mac platforms for our end users. This is what we shipped for over a year until I started tinkering with Cocoa.
Right away, the thing that most impressed me was how quickly you could develop using Cocoa. Eventually, we decided to drop support for Linux and Windows and rewrite our entire control applications in Cocoa. What had taken us years to put together in C++ required only three months to completely reimplement in Cocoa.
Aside from the "lowest common denominator" interface issues that others have pointed out, the rapid development allowed by Cocoa has become a competitive advantage for our company. Our software has advanced far more quickly since our conversion to Cocoa, and it has allowed us as a new company with one developer to pull even with 10-year-old competitors that have 20-man development teams. This appears to be a common story in the Mac development space, where you see a lot of small teams who are able to create products that compete with those of much larger companies.
As a final note, using Cocoa gives you the ability to stay on top of the new APIs Apple is continually rolling out. We're now working on a new control interface that will make heavy use of Core Animation, something that would be painful to deal with using Qt.
I'm currently developing both with QT (actually PyQT, but it makes no difference to your question) and native Cocoa app. For me it's no brainer, I'd chose Cocoa. It's really worth time to explore Cocoa in general, there are many great concepts within the Cocoa framework, and Objective-C 2.0 as well.
I'd use Qt if you want this to be a crossplatform application.
You can have a look at the QMacCocoaViewContainer class. It acts as some kind of wrapper for generic Cocoa views, so you can also have Cocoa elements which are not officially supported by Qt.
Of course this means learning a little about Cocoa and Objective C and how a Cocoa UI would need to look like. But if you already know Qt well and if it’s not like your application is all and only about the GUI this could be a good way to go.
And don’t forget about the QMacStyle::WidgetSizePolicy or you won’t understand why your tables come out so huge.
Obviously, the best option is to use a cross platform suite that supports native widgets.
With QT4 you can build your base user interface. Then just add native support for your specific target platform.
Sure, Cocoa has a lot of fancy stuff (and you can still use them trough QT4), but let me be clear. I see a lot of fancy Apps on the AppStore, pretty ones, but most of then are just crap, expensive.. what ever. I really missed my Kate text editor, my okular viewer, my krita drawing software... those are just better than the commercial and expensive alternatives and are free. so i just tweak the source code a little bit too have a REAL native and great experience.
What if i have to use a linux app on my main computer with is a mac os x? or windows? or whatever? only?
For example, why on earth i have to buy a expensive ,fancy but far less featured image editor software for my mac like pixelmator when i can use a full featured real image manipulation software like Gimp? YES Gimp is gtk2 based which is a pain on any platform, specially on Mac because is really ugly. Gimp should be ported to QT4. Inkscape should be ported to QT4 too, and it would feel so great.
Is so simple to do.. gosh!
http://doc.qt.nokia.com/4.7-snapshot/demos-macmainwindow.html
Even you can add support for the the new native lion fullscreen feature, unified title and toolbar menus, etc
I , as a user, i really care about efficient, featured, good and cross platform apps, i don't really care about developer's convenience or laziness .
I do a lot of cross-platform development (Mac, Windows, Linux), and for some projects use Qt. It is a fine framework, and provides a rich class library. If you need to deploy on multiple platforms, cannot afford to spend the time/effort on platform-specific front-ends, or the "generic" support for each platform is sufficiently good, then use Qt.
However, Qt inevitably suffers in some ways from the lowest common denominator syndrome, and sometimes does not feel quite native enough. There are also certain features that are either difficult to support, or are simply not provided in the Qt libraries. So if you can afford the time and effort, or your app really demands the attention to detail and fit & finish, then developing separate front-ends may be worth it.
In either case, you ought to be writing your back-end (aka domain) code in a platform-neutral and front-end neutral manner. This way, the front-end is easily replaced, or modified between platforms.
You could always start with a Qt front-end and go for a quick time to market, then develop a native front-end down the line.
In practice, I've noticed that a Qt app on Windows looks most "native", while on Mac there are certain subtle telltale signs that make it look/feel not quite right. And Mac users tend to have much higher expectations when it comes to UI/UX!
Since posting this, i've been learning the Cocoa / Objective-C way, and have been quite impressed. Despite what I initially thought was quite a quirky syntax, Objc appears to be a very effective language for implementing UI code, and the XCode sugar - things like Core Data and bindings - make short work of all of the boring bits.
I spent a while with the QT examples and documentation before digging into cocoa, and tend to agree with what has been said above w.r.t being slightly behind the curve and less 'aqua-ish' - albeit from a fairly trivial inspection. If I absolutely had to be build a cross-platform app i'd probably use QT rather than trying to separate out the UI code, as it seems like it would provide close-enough visuals, but for mac only purposes, Cocoa seems like a definite win.
Thanks all for your responses, they've all been very helpful!
DO NOT use Qt for a Mac app. You will get no hardware acceleration for 2D rendering, and you will not be able to deliver ADA compliance.
Depending on what kind of apps you want to write, another contender is REALbasic now called Xojo.
The move from C++ is pretty easy (I have 15 years C++ experience) and the framework and IDE extremely productive. You have the added bonus of being able to deploy to Linux and Windows with trivial effort. Their framework compiles to native code and uses native widgets so you don't have an emulated look and feel.
The big reason for learning Cocoa and coding in Objective-C is if you want to hone your iPhone skills or are chasing a really fancy user experience. If you wanted to rival the cutting edge of WPF development then I'd recommend Cocoa.