As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
MonoTouch is great for cross-platform app development. This makes a very strong business argument and I am on verge of developing using MonoTouch with prospects of branching into Android and WinMo. Before starting commercial development in MonoTouch I want to ask one last question, just in case I've missed something critical in my research so far:
What do you think is the biggest drawback of MonoTouch as compared to Objective C?
Barring games development, use whatever context comes to your mind.
Thanks
Steph
UPDATE: Following link probably best answers the question: http://docs.xamarin.com/ios/about/limitations. Conflict of interest is that it comes from Xamarin. Thanks to everyone who contributed!
In my opinion MonoTouch is just great, if you are an c#-developer. You can use almost everything from the full .net-framework and it works like a charm.
Your app gets a bit bigger in a meaning of filesize and you are at the mercy of Xamarin. The only real drawback I have found until now is that you have to change a lot between xcode and monodevelop IF you use the interface-builder. As I don't use the IB that wasn't a big dealbreaker for me (I don't use the visual studio designer either...)
If you know c# and would have to learn Objective-C -> go for MonoTouch!
If you don't know both, it might be a good choice to learn the "real way" to code native apps. Btw. you need some knowledge of Objective-C or iOS-development in general. So you know how to use Views and ViewControllers, what's the names of the methods and so on.
UPDATE: To answer your questions in the comment. The farest I have gone by now, was kinda migrating an existing opensource Objective-C-GUI-Library (kind of popoverControl) to an MonoTouch project. That was rather straightforward and easy. Direct using of Objective-C-Libraries wasn't in my needs by now. But you can read about it in the Xamarin-Docs.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Sorry if this is an annoying question, but I'm new to iOS development and since allot of people always tells me it's important to read Apple documentations, and there are alooot of them, so I though you can maybe list some of the Fundamental ones for newbies to begin with.
Appreciate it.
I read, in this order:
Object Oriented Programming with Objective-C
Your first iOS app
The Objective-C programming language
Cocoa fundamentals guide
Objective-C runtime programming guide (skimmed)
View controller programming guide for iOS
Text,web and editing programming guide for iOS.
Core Data tutorial for iOS
There is some repetition/overlapping between these guides so after the first three or so it will be a fast read.
Don't bother buying guides and cookbooks: they just regurgitate what's in the official documentation. Once you are finished reading the basic documentation watch some videos of Apple's WWDC (for free on iTunes) of topics of your interest, ad especially the talk about ARC (about memory management).
UPDATE:
Concerning classes you'll just check them as you need to use them. Probably the most used are the controllers (UINavigationController, UIViewController..), NSString, UIButton, UITextView, UILabel and all the containers (NSArray, NSMutableArray, NSSet, NSDictionary..). However I would not try to study them before you need them in your code. It's just the more you use them the easier it will be to do so.
Here are some links for iOS technology:
iOS App Programming Guide: Explains from basic to high level concepts of iOS programming
Programming with Objective-C: Regarding How to do programming in Objective-C
Coding Guidelines for Cocoa: A developer should follow language/platform specific coding rules/guidelines. Here is the Cocoa guidelines, so while writing your code please ensure that all this rules are getting satisfied.
While learning/searching, please refer Apple iOS documentation at first priority, otherwise search engines are there to help you out.
Hope this information will help you to start up in iOS application development.
There is a lot to read and with out knowing what you are looking for this is close to impossible. I'd suggest starting with CS 193P iPhone Application Development by the Stanford University online course (which you can find on iTunesU) that summarize everything in a more efficient way than just reading the documentation but if you insist the NSString class is a good way to start.
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/Reference/NSString.html
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
How does GameMaker compare to XCode/Objective-C for iPhone development?
I have an idea of GameMaker being really easy to use, but rather restricted in its functionality, while XCode/Objective-C is a lot harder to use but of course as flexible as can be (by design).
I am thinking about picking up a book on one of the two (GameMaker or XCode/Objective-C), as I would like to develop iPhone apps, but am finding it hard to figure out the pros and cons.
Any input will be appreciated :) :)
You can develop almost everything with Game Maker, but why you shouldn't is because it has really bad performance. I have read lot of reviews telling about games done with GM that are completely draining the battery. I won't choose this option.
I would rather look for something like Unity3D who's badass, or something cheaper like Corona SDK. The best way is still by using the native tools like xCode for iOS, and Eclipse Java for Android. But that's a choice that depends of the amount of time you want to spend for the development.
Update: The way to go is cocos2d-x.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm fairly new to Objective C, but have had some experience with Java. In Java tools like JUnit and JDocs can be extremely useful. Do these tools have parallels within Objective C, or are there even more useful tools for Objective C? At the moment I'm using X-Code and the iOS simulator.
Thanks for the help!
Off the top of my head...
Most useful are all the resources in developer.apple.com. They have docs, examples, references etc.
Also, use the Instruments app to help debug, analyse, and monitor your app. The various 'Instruments' therein are very useful.
For unit testing, you can include these when creating your app as standard (by simply checking the appropriate box). OCUnit is included. You can also try Google Toolbox, GHUnit, CATCH and OCMock to supplement this.
If I think of anything else, I'll let you know.
You can find about unit testing here. https://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/UnitTesting/00-About_Unit_Testing/about.html
For acceptance testing, KIF (Keep It Functional) from Square is a good option. KIF can simulate buttons clicks and text entries.
https://github.com/square/KIF/
Instruments is really useful tool to debug memory issues. Leaks and Allocations tools have been very useful. You can see who is retaining and releasing a particular objects in Allocation tools, which is useful in finding out retain-cycles. If you work with codes before ARC, 'zombie' tool is invaluable as well.
Static Analyzer in XCode can quickly point out some potential issues.
XCode--> Product --> Analyze
Other than Apple excellent documentation, you can also watch WWDC videos.
https://developer.apple.com/videos/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
So after having read a few different Big Nerd Ranch texts, as well as seen Paul Haddad of Tweetbot fame more or less say that he doesn't use Interface Builder, I've come to the conclusion that for one reason or another, there's something wrong with it?
I personally find myself gravitating toward Interface Builder solely due to my background with Visual Basic. It's easier, it's faster, and just (for me) far more pleasant to work with.
In the end, though, my question is this: Is there some reason due to efficiency (either through performance of the final app or in the development process) that developers gravitate toward programmatically designed UI's over the Interface Builder-generated counterpart?
Thank you.
Interface Builder can be fiddly at times, and until recently you couldn't do anything remotely complex with it in terms of laying out UI elements relative to one another. Since you'd have to dip down to code to do that, many people just do everything in code.
However, with the advent of AutoLayout and its amazing integration with Interface Builder, that may change.
I personally feel that you can manage your code better by coding the UI yourself.
Interface builders can be used to build GUIs quickly, and allows you to experiment without having to know the intricate details of all the GUI components supported by your pl.
Best approach would be to mix these two approaches, build quickly using the interface builder, then move the code around as you like.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is it worth studying COM MFC ATL WTL now?
Everything is worth studying:
Those who forget history are doomed to repeat it
You must understand the past to understand the present
Should you spend a majority of your time on it? Only if you expect that you will have to work with it. Otherwise, focus on the future.
Potentially yes for COM and ATL, if you're planning to program for Windows 7. All the new platform APIs coming out are COM-based: Direct 2d, Ribbon, Animation, Location & Sensors, Libraries, etc...
There will likely be .NET wrappers for some of these, but managed code is no longer the focus for the Windows team, at least for now and the near future.
The concepts of COM are really worth understanding. Especially the concept of interfaces, object creation strategies, proxies and Apartments.
Not really. If you want to make a COM object now, you could just use C++/.NET instead. If you want a UI, WinForms or WPF work fine.
Yes, you might get a job at Microsoft in their second most profitable business, Office, which is still based on COM. There are worse fates than that.
COM is totally worth it. The rest, not so much.
Only if you have to interface with some COM objects OR if you have to maintain some old COM/ATL code.
Same goes for MFC/WTL. Better and quicker UIs can be developed with latest .NET tools such as WPF and Winforms.