Sunday 9 December 2018

When to use unowned self or weak self?

When to use unowned self or weak self

The only time where you really want to use [unowned self] or [weak self] is when you would create a strong reference cycle. A strong reference cycle is when there is a loop of ownership where objects end up owning each other (maybe through a third party) and therefore they will never be deallocated because they are both ensuring that each other stick around.
In the specific case of a closure, you just need to realize that any variable that is referenced inside of it, gets "owned" by the closure. As long as the closure is around, those objects are guaranteed to be around. The only way to stop that ownership, is to do the [unowned self] or [weak self]. So if a class owns a closure, and that closure captures a strong reference to that class, then you have a strong reference cycle between the closure and the class. This also includes if the class owns something that owns the closure.

Specifically in the example from the video

In the example on the slide, TempNotifier owns the closure through the onChange member variable. If they did not declare self as unowned, the closure would also own self creating a strong reference cycle.

Difference between unowned and weak

The difference between unowned and weak is that weak is declared as an Optional while unowned is not. By declaring it weak you get to handle the case that it might be nil inside the closure at some point. If you try to access an unowned variable that happens to be nil, it will crash the whole program. So only use unowned when you are positive that variable will always be around while the closure is around

Friday 30 November 2018

How to cache content in UIWebView for faster?

In iOS we can use different mechanisms for caching.

By default web view content can cache by creating subclass of URL protocol.

external cache can be achieved by using below library.But make sure we use UIWebview for EVURLCache library.

https://github.com/evermeer/EVURLCache

Please comment if queries.Will soon communicate on that.

Tuesday 20 November 2018

Any vs AnyObject in Swift

Difference between Any vs AnyObject in Swift

What is the difference between these three enigmatic types? A sometimes confusing topic, and to confuse things further Swift 3 has shaken it up by removing implicit bridging between Foundation and native data types. 
Let’s look at the current situation with a good old Venn diagram:
AnyAnyObject
Let’s take a closer look at distinguishing these types with an example using arrays.
You probably know Swift is a type-safe language. For this reason, the compiler won’t permit you to type infer an array of different types that don’t share a common root:
1
2
//Error: Type of expression is ambiguous without more context
var test = ["a",0]
Strings and Ints in Swift don’t share a common root, so the compiler doesn’t know what you want it to do when type inferring the array.
There are three tricks for removing this error:

Solution 1: Array of NSObjects

If you import UIKit and cast the string as an NSString and the Int as an NSNumber the error goes away. Why?
1
2
3
import UIKit
//No error, test inferred to be [NSObject]
var test =  ["a" as NSString,0 as NSNumber]
UIKit Framework includes the Foundation framework. If you have imported the Foundation framework you can explicitly bridge common Swift data types to their Foundation Objective-C counterparts. (this bridging was automatic pre-Swift 3) String for example, bridges to NSString and Int can bridge to NSNumber.
Unlike in Swift, in Objective-C, most data types do have a root: NSObject is an actual class (docs here), that is the root of most classes if you’re using the Foundation framework.
If you option-click on the test variable, you’ll find that it has defaulted to [NSObject].
But then – out of curiosity – what happens if you add another variable to the array that does not have NSObject as a root, such as a class of your own?
1
2
3
class Test {}
//Error
var test = [Test(),"a" as NSString,0 as NSNumber]
The compiler can no longer find a root class to infer the array’s data type. You would need a way to indicate to the compiler that you know that the elements of the array are incompatible, and you’re ok with that.

Solution 2: NSArray

One solution would be to type the array as Foundation data type NSArray. NSArray is less strict than its Swift countertype; NSArray doesn’t enforce that elements it contains are the same data type.
1
2
//No error: test defined as NSArray
var test:NSArray =  [Test(), "a",0]

Solution 3: [Any] or [AnyObject]

If you specifically define the array as [Any], you are indicating to the compiler that you are aware that the elements are not of the same data type, and you are ok with that.
1
2
3
class Test {}
//No error, test is defined as [Any]
var test:[Any] = [Test(),"a",0]
You may be surprised to learn that unlike NSObject, Any is not actually a concrete data type. You won’t find a type description for it in documentation. Rather Any is an alias for any data type.
Similarly, AnyObject is an alias for any data type derived from a class. You can use it to define an array that contains more than one object derived from a class, that don’t share a common root class:
1
2
3
4
class Test {}
class Test2 {}
//No error, test is defined as [AnyObject]
var test:[AnyObject] = [Test(),Test2()]
(You could of course have used [Any] as well – [AnyObject] is just a little more specific.
Passing in a string and an integer for example, to an AnyObject array will cause an error, as these data types are structs in Swift.
1
2
//Error: String does not conform to element type 'AnyObject'
var test:[AnyObject] = ["a",0]
Of course, an Array which could contain any data type is unlikely to pop up in your code, and if it does, maybe you should double-check you’re following best practices!
Rather, this has been an exercise to explore Any, AnyObject, NSObject, NSArray and how Swift 3 now requires explicit bridging between Foundation and native data types. Hopefully this helps

203 Favorite JavaScript Utilities

https://1loc.dev/