SWIFT DOMINARÁ O MUNDO! POR QUE USAR?

Por que usar a linguagem mais bacana de todos os tempos, na visão de uma pessoa imparcial :)
Nesta palestra, abordo de forma bem descontraída, pontos que julgo evoluções importantíssimas em vários quesitos: Segurança, Performance e Facilidade na manutenção.

Transcript

1. Swift dominará o mundo! Por que usar? Porque usar a linguagem mais bacana de todos os tempos, na visão de uma pessoa imparcial !
2. Bruno Isola Reginato facebook: brunoireginato twitter: brunoireginato github: brunoreginato email: brunoireginato@gmail.com
3. Ísola != Isóla (pode chamar de Isóla)
4. Há 1 ano atrás quando me perguntavam sobre Swift...
5. "Já é hora de usar swift?"
6. “Ahhh tá muito cedo ainda, a linguagem parece promissora, mas eu ainda não trocaria."
7. “Está muito instável, acho melhor aguardar"
8. E agora?
9. “Veiii sáporra é perfeita " !!!!
10. Brincadeiras a parte...
11. Swift está... → Bem mais maduro → Virou open source → Comunidade aderiu de forma bem rápida. → O "time de desenvolvimento" está ouvindo muito a comunidade para que a linguagem evolua baseada no que realmente importa, o usuário (noixxx)!
12. Nesta talk, abordo pontos que julgo evoluções importantíssimas em vários quesitos: Segurança, Performance e Facilidade na manutenção. Além de outros pontos que não gostei no Swift
13. Agenda → Joinhas para o Swift ! → Pontos de atenção ⚠ → Mancadas do Swift # → O que esperar para o futuro? $
14. Joinhas para o Swift !!!
15. Optionals: Cara, se vc conseguir que a sua app crashe por uma referência a um ponteiro nulo, PARABÉNS, você merece tudo de melhor, trabalhando com Javascript !
16. Brincadeiras a parte, o Swift nos dá muitas formas de chegarmos a ZERO erros de persistência, eles só acontecem se você realmente assumir o risco.
17. Exemplo: var optional:String? //risco optional!.characters //seguro guard let safe = optional else { throw Generic.DeuRuim }
18. Capture Lists: Referências ao objeto self dentro de blocks/closure sempre foi um assunto confuso. Em Objective-c normalmente criava-se um objeto que segurava uma referência fraca ao self e referenciava o mesmo dentro do block.
19. Em objective-c... __weak MyObject *weakSelf = self; [self setMyBlock:^(id obj, NSUInteger idx, BOOL *stop) { [weakSelf doSomethingWithObj:obj]; }];
20. Em Swift, pensando nisso, foram criadas as Capture Lists, elas têm a função de ser uma lista de referências que serão passadas para dentro do closure.
21. Qual a diferença entre o unowned e weak? → weak = Não acrescenta 1 (usado para objetos opcionais, que podem ser nil) → unowned = Não acrescenta 1 (usado para objetos NÃO opcionais, que não podem ser nil)
22. Exemplo: //Eu, como programador, tenho a certeza de que 'self' existirá quando o clousure for chamado MyApi.request("users") { [unowned self] (result) in self.update() } //Eu, como programador, NÃO tenho a certeza de que 'self' existirá quando o clousure for chamado MyApi.request("users") { [weak self] (result) in self?.update() }
23. Selectors (Swift 2.2): A nova forma de definição dos seletores ficou muuuuuito mais segura do que a anterior, os seletores são criados através de referências aos métodos como objetos:
24. Exemplo: selector: #selector(AppDelegate.meuMetodo)
25. O que ganhamos com isso? Consegue-se checar se o selector é válido, em tempo de compilação!
26. Porém... O Swift ainda não valida o número de argumentos esperados para aquele seletor
27. Sdds .h .m
28. Mentira, saudades nada. No Swift, como vcs devem saber, temos decoradores de métodos/funções/ propriedades que discriminam qual o nível de acesso aos mesmos, sendo eles:
29. → internal: visível no namespace do projeto → private: só na classe → public: \o/
30. let e var (willSet, didSet) Além da função de separar variáveis de constantes, o let e o var nos apresentaram algo muito interessante, os Property Observers.
31. willSet Executa um closure quando uma propridade será setada...
32. didSet Executa um closure quando uma propridade foi setada...
33. Exemplo: var totalSteps: Int = 0 { willSet(newTotalSteps) { print("About to set totalSteps to \(newTotalSteps)") } didSet { if totalSteps > oldValue { print("Added \(totalSteps - oldValue) steps") } } }
34. Enums Enums ficaram extremamente interessantes. Dentre seus novos atributos, está a definição de funções em seu corpo...
35. Exemplo: enum HTTPStatus { case Success case Error(code:Int) }
36. Com a function... enum HTTPStatus { case Success case Error(code:Int) func message() -> String { switch self { case .Success: return "All was good :)" case .Error(code: let code) where 500 ... 599 ~= code: return "Internal server error :(" case .Error(code: let code) where 400 ... 499 ~= code: return "Resource not found :(" case .Error(code: let code): return "Something goes wrong :( \(code)" } } }
37. Error handling ! Uma das features mais importantes do Swift, nada mais é do que especificações de ErrorType. Definidos como enums...
38. Exemplo, definindo os erros: enum GenericError : ErrorType { case Parse(String) case InvalidURL case InvalidEncoding }
39. Lançando-os: guard let name = dict["name"] as? String else { throw GenericError.Parse("Error parsing 'name' property") }
40. Capturando-os: do { guard let name = dict["name"] as? String else { throw GenericError.Parse("Error parsing 'name' property") } print(name) } catch GenericError.Parse(message: let msg) { print("Opss \(msg)") }
41. Funções que lançam exceções func contactFromDict(dict: [String:AnyObject]) throws -> Contact { guard let name = dict["name"] as? String else { throw GenericError.Parse("'name' must be a String") } guard let phone = dict["phone"] as? String else { throw GenericError.Parse("'phone' must be a String") } return Contact(name: name, phone: phone) }
42. Chamando funções... do { try contactFromDict() } catch let error { print("Ops, something goes wrong! \(error)" }
43. Ignorando a possibilidade de erro! ! try! contactFromDict()
44. Importante... A Apple sugere que o uso dos erros para todo e qualquer tipo de validação... → Validação de campos → Checar se um recurso está disponível para aquele OS → Não encontrar um registro em um banco de dados...
45. Pontos de atenção ⚠ → iOS <= 7 → Dynamic Libs (Parece besta, mas dá uma googlada numa lib em swift que dá suporte para iOS 7) ! → Evite o bridging para Objective-c, isso é muito custoso! → Ignore o quanto puder o uso de objetos "NS", use- os em caso de vida ou morte, a maioria dos tipos
46. O que esperar para o futuro? ! → PackageManager (nativo) → Server Side Swift → Swift 3.0 → WWDC vem ai...
47. Mancadas do Swift ! → ARC x Garbage Colector → Ainda não gosto da forma que nós temos que fazer classes abstratas em Swift, me pareceu algo obsoleto no meio do tanto que se fala em linguagens funcionais/ reativas
48. Obrigado :)