Is it at all possible to have Xcode create a .playground file for Objective-C instead of Swift? Are there any available Xcode plugins that allow that?
You can quickly test code snippets using a test case in a new project. Just create a new project and go to the Navigator in the left pane and hit the Test Navigator button. Then follow this guide
The setup code will look a little different than a swift playground, but it still allows you to prototype and play around.
There is a very good library developed by Krzysztof Zabłocki in Github entitled KZPlayground that support both code in Playgrounds for Objective-C and Swift and a lot of cool features.
I hope this can help you.
If the only purpose is to test out Objective-C snippets, i would really recommend you an OS X command line Tool project.
There are enough moving parts in a playground, and all of those would have to be reimplemented for Objective-C. Reliable playgrounds also depend on definite initialization which Objective-C does not have.
For instance consider:
var d: NSData // this is not initialized, so I can't use it
vs.
NSData *d; // this is also not initialized, but now I can use it
If I am the person storing the description of your NSData for the sidebar, now I know that I am not supposed to do
describe(d)
in the Swift case, but for the Objective-C case, I don't have equal knowledge and I run the risk of saying
[d description]; // even though d is a random pointer now.. oops, I just crashed!
In short, I don't think any such thing exists, and making one work would also involve some trickery
Related
trying to use the initwithcoder init method in my custom NSControl Class.
It works just fine and does what I need it to do. However and this leads me to asking this question on this here forum -> in the class reference of NCControl when you scroll down to initWithCoder and click on it it states SDKs
macOS 10.10+ which leads me to believe that it would not work and do what I need it to do on versions prior to that... Unless Apple's documentation once again is wrong...
BTW - from Apple's own reference (Online as well as offline) apparently the NSCoder Class is also suffering from this SDKs macOS 10.10+
https://developer.apple.com/reference/foundation/nscoder
The strange thing is that in the documentation describing how a NIB is loaded and which init methods it calls on various objects, it describes initWithCoder as being the designated initializer but that documentation is from before 10.10.
Thanks to anyone who can set my mind at ease ;-)
Yes it will not work before defined version. I think you are checking versions of Swift, if you select objective-c you should see version 10.0+ which i think should work fine for your need. If you change the language, you can put your mind to ease :)
I am assuming if you would like to support things that far back you are going to use objective-c over swift.
Check the below image for NSCoder documentation after you select objective-c on right hand side.
My crash reporting service is showing a large number of mystery crashes for an iOS app. For a few reasons I suspect the code is trying to perform a selector on an object that doesn't have the particular selector.
How can I statically analyze the code to find the erronous selector?
I'm writing Objective-C code using Xcode 4.6 on OS X 10.8. I'm ok with a tool that doesn't pick up things like calling performSelector where the selector is built from a string etc. I think a basic tool will work.
Select "Analyze" from the "Product" menu in Xcode. Or press shift+command+B.
It's invaluable for identifying routine memory management stuff in MRC. But it's still useful for ARC programs.
You might also want to try setting an exception breakpoint for all exceptions.
I'd also refer you to the Debug and Tune Your App section of the Xcode User Guide. Or Ray Wenderlich's My App Crashed, Now What? series.
By the way, while the analyzer helps, I don't think it will find incorrect selectors. You might want to share how you're using selectors, because it you're using performSelector, there are often better patterns. Sometimes you have to use it, but frequently there are other patterns that are more robust. Or if you absolutely need to use selectors, add runtime respondsToSelector checks. For example:
NSAssert([object respondsToSelector:#selector(someMethod:)], #"%# does not respond to selector someMethod:", object);
Or, conditionally perform the selector if it responds to it (this is how you perform a method that might be conditional on a particular iOS version):
if ([object respondsToSelector:#selector(someMethod:)])
[object performSelector:#selector(someMethod:)];
I am a novice in Objective-C and I am trying to understand how pre-defined methods work. I went through the documentation of XCode and the *.h files where the method is defined. However I am eager to read the *.m file or any other document that can help me understand how the method works.
For instance - isEqualToString:(NSString *) checks if two strings (of the type NSString) are equal or not. I am not satisfied with this description. I am eager to see how the method works internally or what is the algorithm it follows. Where can I find this information?
Thank you for your help.
isEqualToString:(NSString *) is a method defined in the NSString class. Apple provides you with the framework, but they do not provide the implementation of those methods. Therefore, you can't see the source behind the standard framework's libraries.
Edit: you can create a binary and use this app to check the assembly code: http://itunes.apple.com/us/app/hopper-disassembler/id422856039?mt=12
Unfortunately, a lot of the implementation (.m) files for Apple's frameworks aren't provided publicly. You have a couple alternatives:
As Matthias suggested in a comment, use the debugger and inspect the assembler code generated for that method.
Browse through the repositories for the GNUstep project, which has some equivalents to Apple classes.
i a newbie for iphone development. I got some questions here.
I know IB is a convinience tool for UI desgin and you also can do most things programmatically. I am just wondering, when should I create an interface controll without IB and why so. I am trying to form a good habit for this. Thank you very much. A friend told me that when efficiency should be considered for the application, then i should create interface controller programmatically, any other cases?
I am studying Learn Objective c on Mac now. It says that "Apple suggests you avoid using autorelease on your own code". So, does it mean I cannot use "autorelease" or just i should avoid using it. For example, can i use following code in my own code for iphone development?
#Interface Test {
A* a;
}
#Implementation {
a = [[[A alloc]init]autorelease];
}
Thank you for your time to read this. I am looking forward to answers :D.
Sometimes creating custom controls will require you to build them programmatically.
No, it's not that you can not use autorealease, it's just that using it adds to the burden of memory management. But in some cases you probably don't have an option, such as when you have a method that returns a temporary object. Using retain/release method to manually control object lifespan is the recommended way of doing things in iPhone development. Please see Autorelease pool for more details.
See Matt Gallagher's blog post for a discussion of efficiency. Simply put, one method is probably no more efficient than the other. This depends on your specific application, of course. Generally speaking, do what is most comfortable in designing your user interface. Make optimizations as needed.
1) If you are doing basic views that interface building has the widgets ready to go for, then use interface builder, it will make your life easier. Plus if you are just starting out it will let you get some sample code out the door faster. I'm not a huge fan of interface builder, but if you have to maintain code, you'll come across it so good thing to get familiar with it.
2) I don't think that autorelease is a bad thing. If you are writing single threaded code there is not as much to worry about. However, the thing that can come back to bite you is that you don't actually know when things will be released. So if you have programmed poorly, and try to reference an object that you have autoreleased later in code then you may get inconsistent behavior. I autorelease, but I also am very good about retain/release in other parts of my code that is passed these objects.
Not knowing Obj-C I could use some help to traslate this one line of code:
[[TVOutManager sharedInstance] startTVOut];
into a C# version I can use in MonoTouch.
I've managed to get the XCode project compiled to a static library, now I'm trying to figure out how to turn it on... The orginal project is posted here: http://www.touchcentric.com/blog/
TIA,
Rick
[obj myMsg] is Objective-C syntax for sending the myMsg message to the obj instance. It is, at first blush, a lot like obj.myMsg() in C#. Objective-C uses message passing rather than function calls, however, so the two are actually very different semantically. You can often gloss over the differences, but if you are going to do any significant work on OS X or iOS, it's worth reading the Objective-C language guide carefully. I'm not a MonoTouch/MonoMac expert, but I believe that the answer to your specific question is:
TVOutManager.sharedInstance.startTVOut();
assuming sharedInstance is mapped as a static property of type TVOutManager, or
TVOutManager.sharedInstance().startTVOut();
if sharedInstance is mapped as a class method in Objective-C.