This question already has answers here:
Method load() defines Objective-C class method 'load', which is not permitted by Swift 1.2
(5 answers)
Closed 6 years ago.
As we knew, when an Objective-C class was loaded the +load method would be called. But in Swift we don't have +load method.
So I tried to invested this. I added a symbol breakpoint at call_load_methods. In Objective-C world. this function will call all the class's +load. But it didn't enter this breakpoint.
So I wondering how to load in Swift. Or can you guys give me more detail a about Swift runtime or something else?
Unfortunately, a load class method implemented in Swift is never
called by the runtime, rendering that recommendation an impossibility.
Instead, we're left to pick among second-choice options:
Implement method swizzling in initialize. This can be done safely, so
long as you check the type at execution time and wrap the swizzling in
dispatch_once (which you should be doing anyway). Implement method
swizzling in the app delegate. Instead of adding method swizzling via
a class extension, simply add a method to the app delegate to be
executed when application(_:didFinishLaunchingWithOptions:) is called.
Depending on the classes you're modifying, this may be sufficient and
should guarantee your code is executed every time.
source
Related
I find a c++ system method causes crash in ios and I try to swizzle the method. However, I do not how to do that because it's a method of a c++ class. Anyone know whether can I do that?
Method swizzling is unique to objective-c (and even there one has to use it carefully), and is not applicable to c++.
I suppose that you don't have access to the source code of the c++ class.
Then the only way to "exchange" the implementation of a method at a specific c++-class is to derive a subclass, override the method, and then make sure that the subclass is used instead of the other class. It is still unlikely that you have a chance; the method being not virtual, the class to be replaced being used in non-polymorphic ways, the class to be replaced already having several subclasses, each of these points will prevent you from being successful.
Good luck though!
This question already has answers here:
Singleton pattern in objc, how to keep init private?
(4 answers)
Closed 7 years ago.
I was trying something new so just going through a thought process to allow only my singleton class to create new instance for other classes which are hidden behind it.
I am able to restrict to call the init method using the "unavailable" attribute along with my init method but can I create an exception that only my Singleton class can call the init method.
but can I create an exception that only my Singleton class can call the init method
You can't know who the caller is — see this discussion of the matter — but you can certainly hide the init method by not putting it in your header. A commonly used solution is, if possible, to have the singleton factory method call a "private" initializer and throw an exception on the "public" initializer. Of course that doesn't ultimately prevent anyone from calling the "private" initializer - sorry, Objective-C is too dynamic for that - but it makes it harder to obtain a non-singleton instance by mistake.
While reading the 'objective c guide' from Apple's dev site, i got some question marks. From this question I already know that both sub and superclass 'initialize' methods get called. My question is; why does this happen? I know from that post also that the initialize is always called, but is that even true when I never use the superclass itself, and only the subclass?
A slight related question which came to mind on this topic:
Does a subclass 'contain' it's superclass, together with some new methods/variables, or
is everything copied from the superclass into the subclass?
In the first case i would understand that the initialize method would be sent to the 'contained' superclasses within the subclass, in the second option, I'd expect the subclass's initialize method to explicitely call [super initialize], which it doesn't.
Thanks!
The +initialize call is special and is explicitly called for every class. This is done outside of the normal inheritance chain you would be used to seeing. +initialize will be called on every class, subclass and category (yes, categories get their own initialize) the first time they're accessed.
I'm method swizzling a third party applications creation of NSMenuItems with SIMBL, but 50/50 of the time the menu-items are created before my method swizzling is initialized.
What is a clean way to make sure my swizzling always comes first? I guess I could swizzle applicationDidFinishLaunching: and continue my swizzling there. But I'm afraid I'm going to run in to the same error there, where applicationDidFinishLaunching will be called before my actual swizzle is in place.
John
You'd want the swizzle to happen as soon as the libraries are loaded. You can do that via +initialize, +load, or a constructor function.
#bbum's answer to this question has a bit more information, along with one of his blog posts on the caveats of using these special class methods.
(And I'm purposely not questioning the wisdom of what you're doing ;) )
You can use constructor functions like this:
__attribute__((constructor)) static void do_the_swizzles()
{
// Do all your swizzling here.
}
From GCC documentation:
The constructor attribute causes the function to be called
automatically before execution enters main().
Note: Although this is originally from GCC, it also works in LLVM.
I have just started to develop for the iPhone and am in the process of learning Objective-C. I have seen some code that implements a method in the #implementation side of a class like this:
-(void)myMethod; {
// method body
}
What makes this interesting is that there is no mention of myMethod in the #interface for the class. I tried a sample project with this and when I compile I get a warning from XCode that myMethod may not be seen by the calling code.
Can anyone tell me what is going on?
Thanks!
It's just like functions in C. You don't need a declaration (i.e. it doesn't have to be in the #interface) but if there's no declaration, any code before the method definition will generate that warning. Code after the method definition will not generate a warning.
In ObjC, method calls are resolved dynamically (dynamic binding), meaning that when you do [obj myMethod];, internally the ObjC runtime software will go through the class methods at that point in time and if it finds one called "myMethod" it will then call it.
Also it is possible to add methods to an object at runtime.
The method declarations in an #interface section is only there to help the compiler determine what methods are publicly available for a given class. If you do add a method in your #implementation only, the compiler may warn you about that, but the code will still compile and work.
I sometimes use this to add internal methods to my objects, which are only called from other methods after it, and never from outside. Though I don't remember seeing warnings about it... Make sure that the calling code is placed after the method implementation in the same file.