The Objective-C Runtime Reference says:
“Deprecated” below means “deprecated in Mac OS X version 10.5 for 32-bit code, and disallowed for 64-bit code.”
and I would like to use class_setSuperclass in Max OS X version 10.5 even though I still can do it the compiler gives warning telling me its deprecated but it still builds and the Bundle is still usable.
My question is what would be the equivalent in Max OS X 10.5?
On a guess using it is probably not a good idea. I know with the shift towards 64 bit several things in the runtime changed and didn't have a replacement.
The docs even explicitly say not to touch, and doesn't give exception to that.
You can however use class_addMethod to add functionality to a given preexisting class. However, that is also doable via categories.
You can use class_replaceMethod to override a method as well, another possible method is to use a category (or class_addMethod) to add a replacement method. Then using method_exchangeImplementations you can swap them so as to have the original still available for calling.
In general though most of this is kinda dark voodoo, and unless you're comfortable with and willing to test a lot, I'd look for an alternative design.
There may not be a direct equivalent.
I know every time I've played with the class hierarchy at runtime I've been burned. You should be able to achieve the same results, albeit more verbosely via delegation, and I'd imagine that's what they want.
Related
The Carbon framework will soon be deprecated in the near future.
My first question is whether the deprecation is targeted towards a particular release i.e. whether it's incompatible with 64-bit machines?
Also, since it is known to be deprecated, we are working towards removing the Carbon dependencies and using Cocoa framework instead. While removing some, I came across the use of EventRecord struct defined in the Events.h file. What should be the Cocoa equivalent of the above struct i.e. I should be able to loop through the Event records while using cocoa too.
Carbon does work with 64-bit machines, but it doesn’t work in a 64-bit mode, it works in 32-bit mode. You definitely want off it.
Cocoa has NSEvents (NSEvent.h), but a lot of what EventRecord appears to cover just isn’t relevant in Cocoa. Like, you don’t have to worry about “this portion of the window was uncovered” events—the system just calls “-drawRect:” on your NSView subclass.
I have developed a number of frameworks that I want to ship with my application. I don't want others to be able to use the frameworks, but i've seen utilities such as class-dump which can get the headers back easily.
My question is, how can I make my frameworks more secure? I know that they'll never be 100% secure, but are there some good general tips to follow?
Thanks!
In short, don't bother. The very nature of the Objective-C runtime is that there is significant metadata available.
The reality is that it would be exceedingly rare for someone to pick up your framework and try to embed/use it.
Note that code obfuscators don't really work very well; there is still quite a bit of metadata that must be exposed. You can go that route, but -- generally -- it makes debugging/crash analysis significantly more difficult without actually solving a real problem.
I see others have pointed you down the path of obfuscation (though I suspect that the answer of #define someSelector mmmrrrggglll wasn't really tested much).
Some specific points to consider as you go down this path (I'm sure I've missed many):
if you use KVO/KVC, make sure you obfuscate all those calls to addObserver:* and the like
if you are targeting Mac OS X, don't forget about Bindings, too!
Interface Builder's xib files will often contain references to instance variables and/or properties and/or methods. Don't forget about those!
Anything that uses runtime introspection will need obfuscation, too.
make sure you don't obfuscate anything that the system frameworks are dependent; wouldn't want to subclass NSView, say, and then obfuscate drawRect: or initWithFrame:.
In some cases, the Info.plist can refer to class names and entry points. Don't mess with those, either!
Also, make sure every use of #selector() is also properly obfuscated; nothing like setting up an NSTimer firing against a method that no longer exists.
Make sure your obfuscation plans also includes the engineering work necessary to create an un-obfuscator for crash logs.
You'll also want to consider how you are going to debug a production binary; assume your stack traces will be obfuscated. b mmmrrrggglll ftw!
If your framework has symbol exports control, make sure to obfuscate 'em, too! Keep in mind that the way symbols are created differs between architecture and compiler, in some cases.
You can use static libraries to link with your application instead of frameworks. However, if you want to ship frameworks, you can use code obsfucators to make your library more difficult to use.
EDIT:
This SO post has a pretty simple description of a basic obsfucation.
How can objective C classes be encrypted
There are products on the market that do this, but they are expensive.
Why doesn’t Objective-C have namespaces? It seems like a simple feature that would make some class names more readable (AVMutableVideoCompositionLayerInstruction anyone?) and axe the silly letter prefixes on class names. Is this mainly because of backwards compatibility? Is it harder to implement namespaces than it seems?
I don't know the answer but I suspect "it's harder than it looks" is probably it. You would have to introduce support in the compiler and linker in a way that doesn't break existing software. And while this is obviously possible (C++ has already done it) presumably the tool chain team have had higher priorities on their plate. e.g. in the recent past we have had garbage collection, GCD, blocks and Objective-C 2.0 appear so we can't say they have been doing nothing.
Namespace support is the one thing that I would dearly love to see introduced to Objective-C.
I don't know if you want to know if there is some official decision.
But namespace like many other feature are choice, choice made by the language contributor.
PHP only recently introduced Namespace, and for example Java use package that act like namespace or python use modules.
I think that there is an overhead in namespace implementation, mainly because Objective-c is dinamically typed so at runtime you have to make some check to resolve the namespace, to resolve default behaviour,etc.. and I can suppose that because Objective-c is also used in embedded enviroment (AKA iPhone) speed is very important.
You've to wrap everything I've said in a big IMHO ;D
Update:
I found this very interesting discussion http://clang-developers.42468.n3.nabble.com/Adding-namespaces-to-Objective-C-td1870848.html#a1872744 on the clang developer website explaining the reason why is definitely non-trivial to implement namespace in Obj-C.
I am trying to compile a library originally written for Cocoa. Things are good until it looks for the function marg_setValue(). It says there is a syntax error before char in
marg_setValue(argumentList,argumentOffset,char,(char)lua_toboolean(state,luaArgument));
(it's talking about the third argument, not (char) )
I am trying to port LuaObjectiveCBridge to the iPhone. It has two choices, either using Runtime or Foundation. I have discovered there are some problems with foundation so I am trying runtime. But the compiler is not co-operating.
Check to see if you can get rid of the marg_XXX macros:
they are deprecated and not considered as reliable.
marg_list is to be used with objc_msgSendv which is absent from modern runtime.
I suggest to go with NSInvocation. It is pretty simple to use, and powerful enough for a bridge. Check this entry for completeness.
The modern Objective-C ABI/API is available on Cocoa Touch. It lacks some of the legacy features of the 32-bit desktop runtime (namely, ones that were horrendously fragile).
marg_setValue() and friends are a part of that legacy runtime that is not supported in Objective-C 2.0. It was -- always was -- broken anyway. You aren't missing much.
The real question is: What are you trying to do?
I think Xcode is a good IDE, but having used Eclipse for Java development in the past I am quite underwhelmed by XCode's code completion and error/warning feedback. (Most of the time, XCode seems to simply try to match the beginning of a text fragment to "words" in the same document, without even using type information to try to determine the appropriateness of a suggested completion.)
Does anyone have ideas or tricks to make XCode approach Eclipse's cleverness, or to realistically develop Cocoa apps with other IDE:s than XCode?
EDIT: Worth keeping an eye on this: code.google.com/p/objectiveclipse/
The good news is, Apple’s working on the problem. One of the goals of the clang compiler project is to create a reusable parser which can be used for better code completion and refactoring support. Indications are that this has borne fruit in the latest Snow Leopard seeds.
Quite simply: no.
You can do almost everything by hand using your favorite text editor but it's not at all recommended. Try designing interfaces without Interface Builder for example.
My advice would be to just stick with Xcode and learn its way of doing things. Yes, it will be different and sometimes might not be "better" in your Eclipsed eyes. Console yourself in the fact that Apple's managed to release some great products using Xcode.
My personal experience is that, each time I use Xcode, I find a new trick which I can add to my bag. Xcode is far more full-featured than what you might think at first (or second) glance.
I've long voiced my rants about what's wrong with Xcode (and what's not wrong with Xcode). But you really don't want to use another tool. And without breaking NDA: Xcode 3.2 with SnowLeopard: Hooray. (Compared to what we have; not compared to what we might want.)
That said, to your original question about code completion, I personally turn off auto-completion in favor of on-demand completion. I find it far more useful and less distracting. In the Code Sense panel, set "Automatically Suggest" to "Never" and make sure the other two options are selected ("Show arguments in pop-up list" and "Insert argument placeholders...") This will do completion in a pop-up box when you hit Escape, making it easy to scroll through looking for what you want. I find that I have to type a lot less this way, especially for methods that are not unique for many characters. 80% of the time, it's highlighting the right thing already.
I have certainly felt your pain — as an experienced Java developer and frequent Eclipse user, I've wished for the same features myself. Unfortunately, I'm not aware of anything that fits the bill. I don't think there was any satisfactory resolution to this SO question, either.
However, I think you'll be quite happy with the improvements to Xcode code completion coming in Snow Leopard — it's vastly smarter about filtering the list of possible completions. Also, there are new conveniences for coding, such as inserting a starting bracket when you forgot one, etc. To my knowledge, there is still no predictive compiling like Eclipse, though.
Is anyone aware of an IDE other than Eclipse that supports predictive compiling and warning/error reporting? Does Eclipse itself support the feature for languages other than Java, such as C++? I'm led to wonder whether the fact that Java is built with independent .java files rather than .h and .c/.cpp/.m files makes it simpler to predictively compile. Also, anything compiled with gcc requires a little more care and attention than the comparatively simpler javac command. Any thoughts?
Check out JetBrains' new IDE called "App Code". It's still in the Early Access Program, but even with the Early Access bugs it is hands-down better than xcode 4.
http://www.jetbrains.com/objc/
emacs and/or vim
Xcode does have some context awareness, when you are sending a message to an object it will generally have the "ESC" list pull up meaningful arguments.
One thing I strongly recommend is looking into text macros. These are not really type aware, but they can save a ton of typing - for instance, after #implementation type "init" and then hit control-. (period) to activate the text macro. It will fill out a whole init method for you. You can create your own, or override the existing macros.