I need to make a bezier path, I have the CGPath
the only information I found was this:
Declaration
SWIFT
convenience init(CGPath CGPath: CGPath)
the first is written normal, the second in Italics and the third purple in the developers library
How should I use it? Please give me an example.
If you have a valid CGPath, just do this:
bezier_path = UIBezierPath(CGPath: your_cg_path)
The vast majority of the yWithX type methods from Objective-C were replaced with init methods in Swift. This Apple documentation has more information on the subject.
Related
It's not a big problem, but I was a bit confused when I faced it for the first time.
This was the original declaration for an Obj C delegate method:
- (void)serialPortWasRemovedFromSystem:(ORSSerialPort *)serialPort
And when I translated it in swift it became:
func serialPortWasRemovedFromSystem(_ serialPort: ORSSerialPort)
But later Xcode showed an error and suggested me to change the name, because it was deprecated, in this one:
func serialPortWasRemoved(fromSystem serialPort: ORSSerialPort)
Why did they change this delegate name so many times? Can you tell me why? Thank you! ~
Because that, in large part, is what Swift 3 is. The Objective-C APIs are "renamified" to make their names terser and more Swift-like.
To learn more, read this and the other two documents to which it links.
It's not possible to subclass DispatchGroup, how to do so?
Note:
this has finally been fixed in iOS 10+
Example, carry a stateful package with a group,
class PushDispatchGroup: DispatchGroup {
var sentIds: [(tableName: String, rowId: String)] = []
}
thanks to shallowThought for pointing out this is fixed in iOS10.
how to inherit from a class which is 'only visible via the Objective-C runtime'?
You don't.
This is not wrapped around a proper "object" the way you're thinking about it. It's wrapped around a dispatch_group, which is a C struct. This class is not designed to be subclassed and does not bridge in a normal way to ObjC, so you can't subclass it there either.
"Objects" that bridge directly to low level C types often have very unusual structures that parts of the system are hard-coded to know how to deal with (this happens all the time with toll-free bridging like NSString and CFString). In many cases, the types are designed to be identical in memory layout through careful choice of structure (I haven't picked apart DispatchGroup, but it looks like one from this group). When that's true, you can't add any storage because then the memory layout will be different and you break the bridging.
As various commenters have said, you also shouldn't be doing this, which is why there is no easy answer for how to do this. Classes that are not explicitly designed for subclassing are intentionally difficult or impossible to subclass in Swift (this comes up regularly around less tricky types than DispatchGroup, and the answer is the same: it's intentional; don't do it).
I have read some posts like this one about the difference between subclassing NSObject in Swift or just having its native base class with no subclassing. But they all are a bit old posts, and I am not clear about this topic.
When should you subclass NSObject? What is the actual difference between subclassing it and not subclassing? What is currently the recommendation in Swift?
Apple's documentation about NSObject states the following as an introduction:
NSObject is the root class of most Objective-C class hierarchies. Through NSObject, objects inherit a basic interface to the runtime system and the ability to behave as Objective-C objects.
As this would suggest, you need to subclass NSObject for types introduced in your code whenever instances of that type need to behave like an Objective-C object (or the class itself, in some rarer cases).
I am not aware of super explicit Apple provided written guidance on when not to subclass NSObject, beyond suggesting reducing dynamic dispatch or presenting code reuse paradigms using that do not relying on subclassing but protocol extensions, i.e. code reuse that is generally more static dispatch and value type friendly). I believe it is fair to say though that most Swift programmers have taken hints from Apple, and Swift language features as signs to avoid introducing NSObject based types when the above-mentioned need is not there. That is, as a general rule, only introduce NSObject based types when you actually need the Objective-C dynamism, most commonly when you need to interface with Cocoa APIs (especially common when your code is UI related: e.g. view controllers, views).
As pointed out in an answer to the question you link to, with Objective-C style dynamism comes the performance of objc_msgSend based method dispatch. Although methods in Swift classes are also virtual, the compiler is able to use faster means of dispatching methods when you don't explicitly mark the methods with the #objc attribute – especially when Whole Module Optimization is toggled on, and even more so in Swift 3 where classes are not by default open for subclassing beyond the module that defines the type.
Beyond avoiding NSObject, you can also avoid class based reference types altogether in many cases when writing Swift. Take a look at for instance the value type WWDC videos linked above, or for example this blog post as an introduction. Briefly, using value types you gain good local reasoning, often avoid dynamic memory allocation and reference counting overhead (though not universally so – structs with reference types as fields being the caveat).
One reason to subclass NSObject is if you need to save some data. NSObject and all it entails remains (AFAIK) the simplest way to get to NSCoding which you need to write to a file.
some insights can be found here or here
Another case when you must subclass NSObject is when you want your subclass to be an observer for KVO, i.e.
addObserver(_ observer: NSObject, forKeyPath keyPath: String, options: NSKeyValueObservingOptions = [], context: UnsafeMutableRawPointer?)
requires the observer to be an NSObject (or an array or set).
I was porting some ObjectiveC custom UIView subclasses to Swift this morning. Wanting to make it more "object oriented", I was following the example of extending CGContext with methods. E.g.
extension CGContext {
func fillColor(color:UIColor) {
CGContextSetFillColorWithColor(self, color.CGColor)
}
}
Because I was converting the objective C style messages (e.g. -(void) drawOutline: (CGContextRef) cr {...}) to Swift style ones without paying to much attention (e.g. func drawOutline(cr:CGContextRef) {...}), I didn't realize at first that I was passing CGContextRef arguments, but had extended CGContext (not Ref). But it worked!
What was weirder, was when I changed those CGContextRef's to just CGContext's. And it still worked. Not just compiled, but ran and drew correctly. For the fun of it, I changed to extension CGContextRef. And yet it still continues to work. It's as if Swift is smart enough to boil them down to the same thing. Is it? Or is there something more subtle/cool going on here?
There's nothing particularly magical here. CGContextRef and CGContext are just different names for (almost) the same thing. Swift just blurs the typedef for you.
<CoreGraphics/CGContext.h>
typedef struct CGContext *CGContextRef;
See also the Using Swift with Cocoa and Objective-C guide section on Core Foundation:
When Swift imports Core Foundation types, the compiler remaps the names of these types. The compiler removes Ref from the end of each type name because all Swift classes are reference types, therefore the suffix is redundant.
They just chose not to take away the Ref form of the name, I guess for old timers who are used to typing it :D
In iOS I know we can define methods with
1.) -(void)sum i.e. a instance method.
2.) +(void)sum i.e. a static method.
But what about method written as
3.) (void)sum i.e without -(hyphen) and +(plus) sign
Now the question is:
What we call method written in point 3?
When and how do we use them?
A link where I have seen this type of method is
Exception Handling in iOS.
Check method
void InstallUncaughtExceptionHandler()
To answer your first question:
your point number 3) is not a method, it is a plain C function prototype (even if to be correctly validated by compilers it should be followed at least by an empty couple of parenthesis so that the statement would be void sum()).
And, concerning your second question:
you could use plain C function declaration syntax wherever you want in your .h/.m files, and as Graham pointed out you could declare them even within #interface and #implementation sections; this way you could access ivars also.
As other answers correctly state in this thread, Objective-C is a superset of C, object-oriented, so mixing plain C declaration syntax and Objective-C syntax is ok at some extent, under the conditions mentioned above.
Generally speaking, one could make use of C-style functions in Objective-C (outside #interface and #implementation) when, for instance, that particular function is kind of general purpose and not strictly related to a specific class. The classical example in this direction is the already mentioned
CGRect CGRectMake(CGFloat x, CGFloat y, CGFloat width, CGFloat height)
As you may see it deals with coordinates and size, but not strictly related to something in particular. It is general. Additionally, this approach particularly fits when your function is not only general purpose, but it has to deal with C data types or C data structures also (like, in our case - CGFloat - basic type redefinition - and CGRect - C-style data structure).
Declaring C functions within #interface and #implementation sections is a way to implement functionalities accessing ivars without constituting a method, i.e. you could invoke those functions only from within the class where they belong.
Virtually, there's nothing of C-related you couldn't do from Objective-C methods, provided correct inclusions are made (e.g. stdio.h or fcntl.h); the programmer has just to question the merits of the functionalities he/she has to implement and, dependently on that, understand if writing a C-style function could be a good fit or if a class/instance method is more appropriated.
It's a C based function. Because Objective-C is a superset of C, you can still use and declare C functions.
CoreGraphics is written in C, an example is the CGRectMake function:
CGRect CGRectMake (
CGFloat x,
CGFloat y,
CGFloat width,
CGFloat height
);
As you know Objective-C is a thin layer on top of C, and moreover is a strict superset of C. So you can also use C and C++ code in Objective-C. The method written in point 3 is a C method(or function, whatever). If you need to use C or C++ methods (or functions) in Objective-C then you should follow this style.