Protocoale si extensii – Swift 3

De ce este nevoie să introducem protocoale în Swift atât timp cât avem de-a face cu clase și putem subclasa?
Swift este Protocol Object Oriented. În Swift protocoalele reprezintă o modalitate bună de a defini un set de funcționalități necesare pe care clasele sau structurile le pot adopta.
Pentru a fi mai clari, un protocol oferă informații despre ce poate face o clasă, nu neapărat ce este o clasă.

De ce protocol și nu sub-clasare?

Să luăm un exemplu de sub-clasare:

class Animal {
    func ceZgomotFace() { fatalError("Implementeaza cod pentru functie!") }
}

Bun, avem deci de-a face cu o clasa abstractă care nu poate fi instanțiată direct ci de către subclase.

Acum introducem o subclasă numită Caine care va încărca metoda ceZgomotFace

class Caine: Animal {
    override func ceZgomotFace() { print("HamHam!") }
}

let rex = Caine()
rex.ceZgomotFace() //prints "HamHam!"

Ce se întâmplă dacă ori uităm să încărcăm în subclasă metoda ceZgomotFace sau să apelăm direct o instanță de Animal?

let iepure = Animal()
iepure.ceZgomotFace() //CRASH

class Cat: Animal { }
let pisi = Cat()
pisi.ceZgomotFace() //CRASH

Prin urmare, aspectul cel mai deranjant este că în orice subclasă am avea pentru o clasă abstractă, trebuie să implementăm metodele din clasa mamă – Animal.

Swift vine cu o abordare interesantă în acest caz – protocolul.

protocol Sunet {
    func ceZgomotFace() 
}

Nu ne interesează în acest moment de ce tip este și cine va implementa protocolul Sunet, important pentru noi va fi doar faptul că metoda ceZgomotFace va fi definită în clasa conformă cu protocolul.

class Caine: Sunet {
    func ceZgomotFace() {
        print("Woof!")
    }
}
 
class Arbore: Sunet {
    func ceZgomotFace() {
        print("Fasssss!")
    }
}
 
class iPhone: Sunet {
    func ceZgomotFace() {
        print("Clinc-clinc!")
    }
}

Nimic spectaculos până acum. Cam același lucru-l fac și subclasele.

Dar… avem protocol extensions care de fapt definește Swift ca și limbaj obiectual orientat protocol.

class Fiinta {
    func mananca() {
    print("mi-e foame!")
    }
}

protocol Sunet {
    func ceZgomotFace() 
}

Avem o clasă Fiinta care implementează metoda mananca() și un protocol Sunet pe care dacă cineva îl va folosi va trebuie să implementeze ceZgomotFace()

extension Sunet where Self: Fiinta {
    func rade() {
        print("HAHA!");
    }

    func plange() {
        print("HOHO!");
    }
}

Extensia protocolului Sunet va fi valabilă doar pentru clasa Ființă și pentru subclasele sale, doar ele având acces la metodele rade și plange

Și acum să vedem puterea protocolului.

class Om : Fiinta, Sunet { 
    func ceZgomotFace() {
        print("Pot face ce zgomot vreau!");
    }
}

class Iphone : NSObject, Sunet { 
    func ceZgomotFace() {
        print("Clinc-clinc!");
    }
}

Clasa Om va mosteni clasa de baza Fiinta și, de asemenea, va putea folosi toate metodele din extensia Sunet.
Prin urmare, o instanta Om va putea accesa metodele din extensia Sunet: rade() și plange() dar va implementa și metoda din protocol – ceZgomotFace().

Prin urmare,

let georgel = Om()
georgel.ceZgomotFace() // Pot face ce zgomot vreau!
georgel.rade() // HAHA!
georgel.plange() // HOHO!

Clasa Greiere va putea folosi doar metodele definite în protocolul Sunet, neavând acces la extensia de protocol deoarece nu are ca Fiinta ca și clasă de bază.

Share Button

NotificationCenter – transmiterea de mesaje în interiorul aplicației – SWIFT 3

Am următorul context: atunci când un utilizator se autentifică, aplicația trebuie să “știe” acest lucru și să execute un task în consecință.
Acest lucru poate fi realizat prin “postarea” unei notificări la autentificare reușită.
În acest sens:

1. Definim un Notification.Name – “UtilizatorAutentificat”. Acesta nu este String, el putând fi folosit oriunde e cerut un Notification.Name.

let myNotification = Notification.Name(rawValue:"UtilizatorAutentificat")

2. “Observăm” apariția notificării mele numită anterior myNotification, atunci când ea va apărea fiind apelată metoda catchNotification

let nc = NotificationCenter.default
nc.addObserver(self,selector: #selector(catchNotification),name: myNotification,object: nil)

3. Definim metoda catchNotification, apelată la generarea notificării:

func catchNotification() {
    print("Catch notification")
}

4. În momentul în care user-ul s-a autentificat postăm notificarea noastră definită ca myNotification

let nc = NotificationCenter.default
nc.post(name: Notification.Name(myNotification), object: nil)
Share Button

sendSynchronousRequest Swift 3

Am de migrat o aplicație din Swift 2.3 în Swift 3 pe un Deployment Target 10, adică aduc aplicația astfel încât ea sa folosească avantajele IOS 10+.
Aplicația pe care o upgradez folosește la un moment dat următoarea funcție de verificare în mod sincron a conectivității la server:


private func isServerReachable_Swift2() -> Bool {

        var Status:Bool = false

        let url = NSURL(string: "URL dorit")

        let request = NSMutableURLRequest(url: url! as URL)

        request.httpMethod = "POST"

        request.cachePolicy = NSURLRequest.CachePolicy.reloadIgnoringLocalAndRemoteCacheData

        request.timeoutInterval = 10.0

        request.allowsCellularAccess = true

        var response: URLResponse?

        _ = (try? NSURLConnection.sendSynchronousRequest(request as URLRequest, returning: &response)) as NSData?

        if let httpResponse = response as? HTTPURLResponse {

            if httpResponse.statusCode == 200 {

                Status = true

                Log.d("server reachable")

            }

        }

        return Status;

    }

Ceea ce este depreciat în IOS 9+ este tocmai folosirea acestui sendSynchronousRequest(_:returning:). Corectă ar fi fost și folosirea unui try-catch pentru sendSynchronousRequest sub forma:

do {
    let data = try NSURLConnection.sendSynchronousRequest(request as URLRequest, returning: &response)
} catch (let e) {
    print(e)
}

Chiar dacă această problemă legată de synchronous este destul de delicată, SWIFT oferă întotdeauna o cale de a rezolva o astfel de problemă printr-un asynchronous pattern, adică prin adăugarea unui completion handler funcției mele.

Însă am preferat să explorez partea de Semaphores din SWIFT care mă va ajuta să realizez un request synchronous și să astept răspunsul de la server.

   private func isServerReachable() -> Bool {
        var status:Bool = false
        let dispatchSemaphore = DispatchSemaphore(value: 0)

        let url = NSURL(string: "URL dorit")
        let request = NSMutableURLRequest(url: url! as URL)
        request.httpMethod = "POST"
        request.cachePolicy = NSURLRequest.CachePolicy.reloadIgnoringLocalAndRemoteCacheData
        request.timeoutInterval = 10.0
        request.allowsCellularAccess = true
        
        let task = URLSession.shared.dataTask(with: request as URLRequest, completionHandler: {data, response, error -> Void in
            if let httpResponse = response as? HTTPURLResponse {
                if httpResponse.statusCode == 200 {
                    status = true
                    dispatchSemaphore.signal()
                    Log.d("server reachable")
                }
            }
            
        })
        task.resume()
        // blochez thread-ul pana cand apare signal pe dispatchSemaphore
        dispatchSemaphore.wait()
        
        Log.d("Response in main thread status = \(status)")
        return status;
    }
Share Button

RemoveGestureRecognizer – SWIFT 3

Sunt într-o situație destul de inedită în care pe un subview – fullScreenConnectView –  am definit în viewDidLoad un TapGestureRecognizer pe care l-am atașat subview-ului.

        let gestureClickFullScreen = UITapGestureRecognizer(target: self, action:  #selector(self.connectClickFullScreen(_:)))

        self.fullScreenConnectView.addGestureRecognizer(gestureClickFullScreen)

Totul e bun și frumos însă trebuie la un moment dat sa elimin acest GestureRecognizer pe care l-am adaugat în viewDidLoad. Nu mai am de-a face cu instanța de UITapGestureRecognizer, aceasta existând doar în viewDidLoad. Poate o soluție pentru eliminarea TapGestureRecognizer este să-l declarat global. Însă am căutat o cale prin care să elimin acest TapGestureRecognizer fără să am acea instanță ținută inutil pe tot parcursul aplicației.

O soluție la îndemână pentru această problemă este: 

        self.fullScreenConnectView.gestureRecognizers?.forEach(self.fullScreenConnectView.removeGestureRecognizer)

Acest lucru este posibil deoarece agregatorul UIView.gestureRecognizers este în IOS 10 un vector, deci numai bun de parcurs și eliminat din el tot ce este în plus. 

    public var gestureRecognizers: [UIGestureRecognizer]?

Pe baza acestei ultime observații putem scrie un cod mai puțin swifty sub forma:

for recognizer in subview.gestureRecognizers ?? [ ] {
subview.removeGestureRecognizer(recognizer)
}

Share Button

Swift 3 – JSON – extragere informatii dintr-un fisier si transformare in Data

Avem urmatorul scenariu. Un fisier local ServerData.json care serveste continut pentru aplicatie; e o situatie putin atipica, in general content-ul vine din exterior.

Revenim, fisierul ServerData.json este adaugat in proiectul nostru si are in Target membership – File Inspector activat numele proiectului pentru a fi inclus la compilare.

Pentru a extrage informatiile din JSON si a le transforma in Data definim urmatoarea metoda:

 

public func dataFromFile(_ filename: String) -> Data? {

    @objc class TestClass: NSObject { }

    let bundle = Bundle(for: TestClass.self

    if let path = bundle.path(forResource: filename, ofType: “json”) {

        return (try? Data(contentsOf: URL(fileURLWithPath: path)))

    }

    return nil

}

bundle va fi un “container” care va incarca din path fisierul cu extensia json in caz ca exista (if let) urmand a obtine content-ul in format Data al json-ului.

 

Share Button