Monday, October 9, 2017
What is the Swift main advantage?
To mention some of the main advantages of Swift:
- Optional Types, which make applications crash-resistant
- Built-in error handling
- Closures
- Much faster compared to other languages
- Type-safe language
- Supports pattern matching
What’s Completion Handler?
Completion handlers are super convenient when our app is making an API call, and we need to do something when that task is done, like updating the UI to show the data from the API call. We’ll see completion handlers in Apple’s APIs like dataTaskWithRequest and they can be pretty handy in your own code.
The completion handler takes a chunk of code with 3 arguments:(NSData?, NSURLResponse?, NSError?) that returns nothing: Void. It’s a closure.
The completion handler takes a chunk of code with 3 arguments:(NSData?, NSURLResponse?, NSError?) that returns nothing: Void. It’s a closure.
Explain: NSCache
What is NSCache?
It's more or less just like a dictionary, with the following additional things (as mentioned by the docs):
Objective-c - benefits of using NSCache over a static NSMutableDictionary?
A cache has a number of quirks that make it work well as a cache while being poorly suited to use as a general purpose collection. As noted in the docs:
It's more or less just like a dictionary, with the following additional things (as mentioned by the docs):
The NSCache class incorporates various auto-removal policies, which ensure that it does not use too much of the system’s memory. The system automatically carries out these policies if memory is needed by other applications. When invoked, these policies remove some items from the cache, minimising its memory footprint.You might use it if your application has lots of data that it needs to work with, but you can't keep it all in memory. For example, if you had an app that pulled data from an SQL Lite database or a web service, you might store it in an NSCache after looking it up. Then, when you need it again, you can check the cache first and only need to hit the database if it isn't in the cache. The main advantage in this scenario over using a regular dictionary is that if you put too much stuff in the cache and it starts to fill up memory, it will automatically discard things to free up memory for you.
You can add, remove, and query items in the cache from different threads without having to lock the cache yourself.
Retrieving something from an NSCache object returns an autoreleased result.
Unlike an NSMutableDictionary object, a cache does not copy the key objects that are put into it.
Objective-c - benefits of using NSCache over a static NSMutableDictionary?
A cache has a number of quirks that make it work well as a cache while being poorly suited to use as a general purpose collection. As noted in the docs:
- NSCache objects differ from other mutable collections in a few ways:
- The NSCache class incorporates various auto-removal policies, which ensure that it does not use too much of the system’s memory. The system automatically carries out these policies if memory is needed by other applications. When invoked, these policies remove some items from the cache, minimising its memory footprint.
- You can add, remove, and query items in the cache from different threads without having to lock the cache yourself.
- Retrieving something from an NSCache object returns an autoreleased result.
- Unlike an NSMutableDictionary object, a cache does not copy the key objects that are put into it.
- These features are necessary for the NSCache class, as the cache may decide to automatically mutate itself asynchronously behind the scenes if it is called to free up memory.
What is Garbage collection(GC)?
Garbage collection (GC) is a dynamic approach to automatic memory management and heap allocation that processes and identifies dead memory blocks and reallocates storage for reuse. The primary purpose of garbage collection is to reduce memory leaks.
GC implementation requires three primary approaches, as follows:
GC implementation requires three primary approaches, as follows:
- Mark-and-sweep - In process when memory runs out, the GC locates all accessible memory and then reclaims available memory.
- Reference counting - Allocated objects contain a reference count of the referencing number. When the memory count is zero, the object is garbage and is then destroyed. The freed memory returns to the memory heap.
- Copy collection - There are two memory partitions. If the first partition is full, the GC locates all accessible data structures and copies them to the second partition, compacting memory after GC process and allowing continuous free memory.
Protocol
A Protocol in Objective-C is identical in functionality to an interface in Java, or a purely virtual class in C++.
A class can either declare adoption of a formal protocol or inherit adoption from a superclass. The adoption syntax uses angle brackets in the @interface declaration of the class. In the following example, the CAAnimation class declares its superclass to be NSObject and then formally adopts three protocols.
A class—and any instance of that class—are said to conform to a formal protocol if the class adopts the protocol or inherits from another class that adopts it. Conformance to a protocol also means that a class implements all the required methods of the protocol. You can determine at runtime whether an object conforms to a protocol by sending it a conformsToProtocol: message.
In addition to formal protocols, you can also define an informal protocol by grouping the methods in a category declaration:
@interface NSObject (MyProtocol)
//someMethod();
@end
Informal protocols are typically declared as categories of the NSObject class, because that broadly associates the method names with any class that inherits from NSObject. Because all classes inherit from the root class, the methods aren’t restricted to any part of the inheritance hierarchy. (It is also possible to declare an informal protocol as a category of another class to limit it to a certain branch of the inheritance hierarchy, but there is little reason to do so.)
When used to declare a protocol, a category interface doesn’t have a corresponding implementation. Instead, classes that implement the protocol declare the methods again in their own interface files and define them along with other methods in their implementation files.
An informal protocol bends the rules of category declarations to list a group of methods but not associate them with any particular class or implementation.
Being informal, protocols declared in categories don’t receive much language support. There’s no type checking at compile time nor a check at runtime to see whether an object conforms to the protocol. To get these benefits, you must use a formal protocol. An informal protocol may be useful when all the methods are optional, such as for a delegate, but (in Mac OS X v10.5 and later) it is typically better to use a formal protocol with optional methods.
- A protocol is means to define a list of required and/or optional methods that a class implements. If a class adopts a protocol, it must implement all required methods in the protocols it adopts.
- Cocoa uses protocols to support interprocess communication through Objective-C messages. In addition, since Objective-C does not support multiple inheritance, you can achieve similar functionality with protocols, as a class can adopt more than one protocol.
- A good example of a protocol is NSCoding, which has two required methods that a class must implement. This protocol is used to enable classes to be encoded and decoded, that is, archiving of objects by writing to permanent storage.
- A Formal protocol declares a list of methods that client classes are expected to implement. Formal protocols have their own declaration, adoption, and type-checking syntax. You can designate methods whose implementation is required or optional with the @required and @optional keywords. Subclasses inherit formal protocols adopted by their ancestors. A formal protocol can also adopt other protocols.
- Formal protocols are an extension to the Objective-C language.
- An Informal protocol is a category on NSObject, which implicitly makes almost all objects adopters of the protocol. (A category is a language feature that enables you to add methods to a class without subclassing it.) Implementation of the methods in an informal protocol is optional. Before invoking a method, the calling object checks to see whether the target object implements it. Until optional protocol methods were introduced in Objective-C 2.0, informal protocols were essential to the way Foundation and AppKit classes implemented delegation.
A class can either declare adoption of a formal protocol or inherit adoption from a superclass. The adoption syntax uses angle brackets in the @interface declaration of the class. In the following example, the CAAnimation class declares its superclass to be NSObject and then formally adopts three protocols.
@interface CAAnimation : NSObject <NSCopying, CAMediaTiming, CAAction>
A class—and any instance of that class—are said to conform to a formal protocol if the class adopts the protocol or inherits from another class that adopts it. Conformance to a protocol also means that a class implements all the required methods of the protocol. You can determine at runtime whether an object conforms to a protocol by sending it a conformsToProtocol: message.
In addition to formal protocols, you can also define an informal protocol by grouping the methods in a category declaration:
@interface NSObject (MyProtocol)
//someMethod();
@end
Informal protocols are typically declared as categories of the NSObject class, because that broadly associates the method names with any class that inherits from NSObject. Because all classes inherit from the root class, the methods aren’t restricted to any part of the inheritance hierarchy. (It is also possible to declare an informal protocol as a category of another class to limit it to a certain branch of the inheritance hierarchy, but there is little reason to do so.)
When used to declare a protocol, a category interface doesn’t have a corresponding implementation. Instead, classes that implement the protocol declare the methods again in their own interface files and define them along with other methods in their implementation files.
An informal protocol bends the rules of category declarations to list a group of methods but not associate them with any particular class or implementation.
Being informal, protocols declared in categories don’t receive much language support. There’s no type checking at compile time nor a check at runtime to see whether an object conforms to the protocol. To get these benefits, you must use a formal protocol. An informal protocol may be useful when all the methods are optional, such as for a delegate, but (in Mac OS X v10.5 and later) it is typically better to use a formal protocol with optional methods.
What does performSelector do? What is the difference between creating a new NSThread and the performSelector method?
All of these perform the same task, that is make the doStuff method on anObject execute synchronously on the current thread:
// 1
[anObject doStuff];
// 2
[anObject performSelector:@selector(doStuff)];
// 3
objc_msgSend(anObject, @selector(doStuff));
// 4
IMP imp = [anObject methodForSelector:@selector(doStuff)];imp(anObject, @selector(doStuff));
- Is how you normally should go about to do stuff.
- Is for dynamically dispatching a message. Use if the selector is unknown, or provided by a client, for example if you implement an target-action pattern. or if the class of anObject is unknown, usually used by first asking if the object has the method with -[NSObject respondsToSelector:].
- Is what no 1. is actually compiled down to. Usually never any real need to do this.
- Cached the actual IMP (implementation) for a method, and then call it directly. Can sometimes be faster than 1. if used in a tight loop. Just remember; premature optimization is evil.
What you need to grasp is that in Objective-C methods are more important than classes/interfaces. Usually you do not query an object if it belongs to a particular class, or conforms to any protocol, that is for the compiler to complain about. At run-time you instead query for specific methods.
In short: It does not matter what you are, just what you can do.
As a convenience NSObject also have several siblings to performSelector that are asynchronies. Most notably:
- performSelector:withObject:afterDelay: - To execute the method on the current thread after a delay.
- performSelectorInBackground:withObject: - To execute the method on a new background thread.
- performSelectorOnMainThread:withObject:waitUntilDone: - To execute the method on the main thread.
- performSelector:onThread:withObject:waitUntilDone: - To execute the method on any thread.
The asynchronous performers all depend on a NSRunLoop to function. This is not something you need to worry about unless you spawn a thread yourself. If you do then you need to also run the new threads run loop. Just skip that for now.
When is it better to use an NSSet over an NSArray?
When the order of the items in the collection is not important, sets offer better performance for finding items in the collection.
The reason is that a set uses hash values to find items (like a dictionary) while an array has to iterate over its entire contents to find a particular object.
The main difference is that NSArray is for an ordered collection and NSSet is for an unordered collection.
There are several articles out there that talk about the difference in speed between the two.
If you're iterating through an unordered collection, NSSet is great. However, in many cases, you need to do things that only an NSArray can do, so you sacrifice the speed for those abilities.
NSSet
- Primarily access items by comparison
- Unordered
- Does not allow duplicates
NSArray
- Can access items by index
- Ordered
- Allows duplicates
Subscribe to:
Posts (Atom)