É como eu. Na realidade acredito que a maioria esteja no mesmo barco. Para coisas a sério ainda não. Quem já trabalha à anos com Objective-C, irá continuar mesmo após o Swift se tornar uma realidade viável.
Terminei o meu primeiro projecto HTML5 e correu muito bem. No final demorei muito menos tempo do que previa e já tenho agora uma base para fazer o próximo mais rapidamente. Quando houver tempo irei recriar um projecto em Flex com HTML5 e mais tarde outro (se isto algum dia vier a acontecer) e depois disso acho que não voltarei a usar o Flash ! O AIR vou continuar a usar e abusar e também muito código nativo com Android. Também acho que o Swift será uma realidade para mim só para o ano que vem ! 2014-09-04 16:48 GMT+01:00 Apintex <[email protected]>: > Hugo, para já é pura curiosidade no Swift. Instalei o Xcode 6 beta e nem o > abri. :( > Vou vendo alguns exemplos para ir aprendendo alguma coisa e partilho com > vocês os que acho importantes. > Estou a terminar um projecto (MoneyEX Pro) e só no início do próximo ano > começarei a trabalhar com o Swift. > > Att, > > António Pinto > > No dia 04/09/2014, às 16:10, Hugo Ferreira <[email protected]> > escreveu: > > APintex, > > Acabei à pouco tempo de ler 2 bons livros de desenvolvimento Android. > Já desenvolvi diversas ANE's para Android e já me sinto suficientemente > confortável para desenvolver qualquer app para Android ou mesmo ANE. > > Em breve gostaria de entrar no desenvolvimento nativo para iOS (tanto apps > como ANE's) e aqui ficam algumas dúvidas: > 1. Não faz sentido nesta altura do campeonato investigar em Objective-C > (thank you god); > 2. Será que não vale a pena esperar por um bom livro que seja uma > compilação do desenvolvimento Swift (de preferência em PT). Ainda não vi > nenhum na Fnac; > 3. Será que irá ser possível desenvolver ANE's com swift. Penso que aqui a > única coisa que falta é a lib que actualmente é para Objective-C (para > alguém transcrever tem de saber bem Objective-C) ou será possível usar a > actual ? > > As minhas expectativas são: > - Dentro de 1 ano o iOS8 tenha mais de 80% de market share para valer a > pena; > - Existam bons livros e exemplos; > - Exista um lib para Swift (a Adobe tem de fazer) ou ser possível usar a > actual (não sei); > - Exista uma framework para Bluetooth LE (para mim é importante) tal como > já existe com Objective-C ou se possa usar as actuais. > > > > 2014-09-04 15:58 GMT+01:00 APintex Gmail <[email protected]>: > >> >> António Pinto >> [email protected] >> >> >> >> http://realm.io/news/swift-enums-pattern-matching-generics/ >> >> Sign up to be notified of future videos >> >> We won't email you for any other reason, ever. >> ------------------------------ >> Enums (0:40) >> >> Enums are a kind of abstraction that allow you to give a variable one >> value among several related values. For example, when building a state >> machine you could have an enum that describes the state of an object from a >> set number of states. There are three types of enums in Swift. >> Basic Enum (1:12) >> >> The most basic Swift enum simply has a bunch of cases and is declared >> using the enum key word. In this example, the enum is called Direction and >> can only be one of the four provided cases. To declare an enum, you use the >> enum name, followed by a dot and then one of the possible values. Unlike in >> Objective-C or C, enums are not typedefs of aliases for integers. >> >> enum Direction { >> case North >> case South >> case East >> case West } >> let myDirection = Direction.North >> >> Raw Value Enum (2:00) >> >> The second type of Swift enum is a "raw value" enum, which is the same as >> the basic enum but has additional raw values associated with each case. In >> this enum Title, each case has an associated string that is the name for >> the title. Important to note is that the raw value and the enum itself are >> not interchangeable. The toRaw and fromRaw methods help to go between the >> value and the enum. >> >> enum Title : String { >> case CEO = "Chief Executive Officer" >> case CTO = "Chief Technical Officer" >> case CFO = "Chief Financial Officer"} >> let myTitle = Title.CEO let myString : String = Title.CEO.toRaw() let >> anotherTitle : Title = >> Title.fromRaw("Chief Executive Officer")! >> >> For integer type raw enums, integer numbering remains implicit if you do >> not specify values. Swift automatically counts up from the last provided >> explicit value. This can be seen in the following example: >> >> enum Planet : Int { >> case Mercury = 1 >> case Venus, Earth, Mars // 2, 3, 4 >> case Jupiter = 100 >> case Saturn, Uranus, Neptune // 101, 102, 103 } >> >> Associated Value Enum (3:52) >> >> The third type of enum is one with associated values. Each case in the >> enum can carry associated data. In this example from the Swift book, the >> bar code enum allows you to associate different QR codes with different >> strings. >> >> enum Barcode { >> case UPCA(sys: Int, data: Int, check: Int) >> case QRCode(String) } >> let myUPC = >> Barcode.UPCA(sys: 0, data: 27917_01919, check: 2) let myQRCode = >> Barcode.QRCode("http://example.com";) >> >> Associated values are especially useful in handling JSON, because arrays >> and dictionaries are actually types. Thus, you can create an enum to >> represent a JSON structure as a tree, with JSON nodes wrapping different >> types. >> >> enum JSONNode { >> case NullNode >> case StringNode(String) >> case NumberNode(Float) >> case BoolNode(Bool) >> case ArrayNode([JSONNode]) >> case ObjectNode([String:JSONNode]) } >> let x : JSONNode = .ArrayNode( >> [.NumberNode(10.0), >> .StringNode("hello"), >> .BoolNode(false)]) >> >> Switch Statements (Pattern Matching) (6:17) >> >> Switch statements is where most of the pattern matching functionality in >> Swift comes from. A basic switch statement looks very similar to an >> Objective-C switch statement, where there is a clause followed by cases. >> Two things to note: Swift switches don't have breaks, so for old style >> fallthrough behaviour, your code must have an explicit use of the keyword >> fallthrough. Switch statements must also be comprehensive, so default cases >> are required, which may help prevent errors. >> >> let value = 10switch value { case 10: println("ten") case 20: >> println("twenty") case 30: println("thirty") default: println("another >> number") } >> >> Ranges (8:35) >> >> In Swift, you can also pattern match on anything that's comparable. You >> can even match strings now to a case (and printout emojis for a fun parlor >> trick!). Anything that can be compared with the double equals operator can >> be matched. Swift also allows matching on ranges, where ranges can be the >> pattern inside a switch state. >> >> let v: UInt = 10switch v { case 0...9: println("Single digit") case 10...99: >> println("Double digits") case 100...999: println("Triple digits") default: >> println("4 or more digits") } >> >> Tuples (9:00) >> >> Tuples are composite data types - they contain multiple elements that can >> all be of different types. A tuple is then represented by the types of its >> elements. In this tuple-based switch statement, a tuple is the input. Each >> element in the pattern tuple is actually a sub-pattern, so you can match >> against patterns in each element. The underscore represents a "I don't >> care" value. In this example, the last case functions as a default because >> the (_, _) says the same thing as a default - none of the other cases >> match, and we don't care about other possible values. >> >> let person = ("Helen", 25) switch person { case ("Helen", let age): >> println("Your name is Helen, and you are \(age)" + " years old") case (_, >> 13...19): >> println("You are a teenager") case ("Bob", _): >> println("You are not a teenager, but your name" + " is Bob.") case (_, _): >> println("no comment") } >> >> Binding in Cases (10:56) >> >> If you have case statements, there may be associated data that needs to >> be used in the case statement body. The let binding is how you can do that. >> The first two cases in this example take the tuple elements and create the >> bindings X and Y to represent those elements. >> >> let myTuple = ("abcd", 1234) switch myTuple { case let (x, y): >> "The string in 'x' is \(x); " + "the integer in 'y' is \(y)"case (let x, >> let y): >> "Another way to do the exact same thing"case (_, let y): >> "We don't care about the string in 'x', " + "but the integer in 'y' is >> \(y)"} >> >> Enums (12:22) >> >> You can also switch on enums, but for enums with values wrapped inside, >> switch statements are the only way you can access those values. The >> following switch statement uses let to bind each case and use the value. >> >> enum ParseResult { >> case NumericValue(Int) >> case Error(String) } >> let a = ParseResult.NumericValue(1) switch a { case let .NumericValue(v): >> "Success; numeric value is \(v)"case .Error(let err): >> "Failed; error message is \(err)"} >> >> Types (13:20) >> >> The main type of switch is the type/sub-class pattern. If your switch >> conditional in this clause is a class, then class will have sub- or >> superclasses. In this example, the UIView is matched against the different >> possible types of views: UIImageView, UILabel, and UITableView. The "as" >> keyword differs from the "is" keyword in that "as" allows you to use the >> let binding and do something with myView, while "is" is used simply to >> check the type. >> >> let myView : UIView = getView() switch myView { case is UIImageView: >> println("It's an image view")case let lbl as UILabel: >> println("It's a label, with text \(lbl.text)") case let tv as UITableView: >> println("It's a table view, with"+ " \(tv.numberOfSections()) sections") >> default: >> println("It's some other type of view") } >> >> where clause (14:33) >> >> Another important thing about switch statements is the where cause. This >> clause can be added to any case and acts as a boolean expression that >> returns true or false. The case is then taken only if this where clause >> returns true. This switch example relies not on pattern matching but >> instead on these where clauses, following through with the case if myView >> is of a certain size or other characteristic. >> >> let myView : UIView = getView() switch myView { case _ where >> myView.frame.size.height < 50: >> println("Your view is shorter than 50 units") case _ where >> myView.frame.size.width > 20: >> println("Your view is at least 50 units tall," + " and is more than 20 >> units wide") case _ where >> myView.backgroundColor == UIColor.greenColor(): >> println("Your view is at least 50 units tall," + " at most 20 units wide, >> and is green.") default: >> println("I can't describe your view.") } >> >> Expression Operator (15:28) >> >> A final important feature in Swift is the expression operator. >> >> func ~=(pattern: Type1, value: Type2) -> Bool >> >> This operator takes the pattern and the value, and then uses pattern >> matching to return true or false. It can be overloaded as well to implement >> custom matching behaviour. The following piece of code is Swift pseudo-code >> to demonstrate what you could build. In an array four elements long, you >> could create cases that matched any combination of the elements. >> >> let myArray = [1, 2, 4, 3]switch myArray { case [..., 0, 0, 0]: >> doSomething()case [4, ...]: >> doSomething() case [_, 2, _, 4]: >> doSomething() case [_, _, 3, _]: >> doSomething() case [_, _, _, 3]: >> doSomething() default: >> doDefault() } >> >> Expression Patterns (17:42) >> >> The following extended example is a custom implementation of the pattern >> match operator. This custom operator turns the elements of an array into >> the enum values. >> >> enum WCEnum { >> case Wildcard >> case FromBeginning >> case ToEnd >> case Literal(Int) } >> func ~=(pattern: [WCEnum], value: [Int]) -> Bool { >> var ctr = 0 >> for currentPattern in pattern { >> if ctr >= value.count || ctr < 0 { return false } >> let currentValue = value[ctr] >> switch currentPattern { >> case .Wildcard: ctr++ >> case .FromBeginning where ctr == 0: >> ctr = (value.count - pattern.count + 1) >> case .FromBeginning: return false >> case .ToEnd: return true >> case .Literal(let v): >> if v != currentValue { return false } >> else { ctr++ } >> } >> } >> return true} >> >> Protocols (21:06) >> >> In order to understand generics, you have to understand protocols, which >> are something that existed in Objective-C as well. Protocols are basically >> a contract that can define nothing at all or any number of methods and >> properties. However, protocols can't have any implementation details - they >> can only have method signatures and property names. MyProtocol in this code >> defines just one property as requiring a getter and setter, as well as one >> method. >> >> protocol MyProtocol { >> var someProperty : Int { get set } >> func barFunc (x: Int, y: Int) -> String} >> >> Types can conform to none, one, or multiple protocols. Protocols can also >> inherit from other protocols, thereby getting all the parent protocol's >> methods and properties. >> Conformance (23:18) >> >> With protocols, you can make classes, structs, and enums conform to them. >> By making a type conform to a protocol, you are telling the compiler that >> your type will match the definitions set in the protocol. MyClass conforms >> to MyProtocol in providing implementations that match. >> >> class MyClass { >> // Nothing here... >> // This won't compile!} >> class MyClass : MyProtocol { >> var myProperty : Int = 0 >> // Property conformance >> func barFunc (x: Int, y: Int) -> String { >> return "\(x) + \(y) = \(x + y)" >> } >> var someProperty : Int { >> get { >> return myProperty >> } >> set { >> myProperty = newValue >> } >> } } >> >> Uses (24:06) >> >> There are a few reasons you may want to use protocols. The first reason >> is parent-child relationships, where you don't want all the children to >> have a specific class of a parent. For example, UITableView comes with >> Cocoa and is a list of objects that specifies the number and content of >> cells. For the delegate to provide that information, it just has to >> implement the protocol which has methods for the cells. This way, you can >> avoid specifying the delegate as a sub-class of a class. >> >> A second major use for protocols can be seen in the Swift Standard >> Library, where they add functionality to a type, piece by piece. Equatable, >> LogicValue, and AbsoluteValuable are all protocols that are implemented by >> different types in the library. The LogicValue protocol has a method that >> takes an object and turns it into true or false, so if you create a custom >> type and implement this protocol, you can use that type in an if >> statement's clause. >> >> One final use for protocols is to allow different types to be described >> by the same generic type parameter. For example, if you wanted to put >> different types into an array, you could give the objects a protocol and >> then declare the array with the protocol. You then have an array of >> equatables and anything that conforms to the equatable in that array can be >> added. >> >> protocol JSONType { } extension String : JSONType { } extension Float : >> JSONType { } extension Bool : JSONType { } extension Array : JSONType { } >> extension Dictionary : JSONType { } >> let b : Array<JSONType> = [10.1, 10.2, "foo"] let a : Array<JSONType> = >> [10.0, "bar", false, b] >> >> Generics (28:36) >> >> Generics did not exist in Objective-C. THey are basically the statically >> typed languages' answer to the flexibility of dynamically typed languages. >> Generics are used to allow you to use the same code for different types. >> The type parameter allows you to do this generically. >> >> func swapItems<T>(inout this: T, inout that: T) { >> let tempThis = this >> this = that >> that = tempThis } >> >> With generics, you can also enforce more constraints, as in the following >> example. The ": Equatable" allows you to constrain T to any type that >> conforms to Equatable, or is valid with the double equals operator. >> >> func firstAndLastAreEqual<T : Equatable> >> (someArray: Array<T>) -> Bool { >> let first = someArray[0] >> let last = someArray[someArray.count - 1] >> return first == last } >> >> You can also use generics for either functions or type declarations. Type >> information is available at runtime, which is helpful. The compiler can >> optimize by creating specific versions for each type that's being used >> (like C++ templates), but it can also fall back to the generic >> implementation. >> Extended Example (33:56) >> >> In the extended example, the goal was to create a function that was >> typesafe and could handle every case that involved the following types: >> Array, Dictionary, SquareMatrix, TreeNode. The function was to take a >> collection of one of the above types, take an array, and append the items >> in that collection to the array. >> >> A protocol was defined to specify that a type can give back all of the >> elements inside of it. You have containers that can implement >> "AllElements". On a generic level, you might need to know the type of the >> elements inside the collection, and so a wildcard is called "ElementType". >> And so, you specify the element type when you implement the function >> itself. >> >> protocol AllElements { >> typealias ElementType >> // Return an array containing all the objects >> // in the collection >> func allElements() -> Array<ElementType> } >> >> Another thing you can use is the NilLiteral protocol, the point of which >> is to take nil and turn it into something equivalent to nil in that type. >> For an int, it would return 0, or maybe for a string, it would return "". >> In the following example, you would want it to return something of type >> self. >> >> protocol NilLiteralConvertible { >> class func convertFromNilLiteral() -> Self} >> >> Extensions then add methods, computed properties, and protocol >> conformance to existing types. Array and SquareMatrix are both fairly >> straightforward - you just return the arrays themselves. For the >> Dictionary, you iterate through all the elements, create a buffer, and >> return it with the elements inside. Finally, for the tree, you go through >> the tree in a recursive traversal and again add the elements to a buffer. >> >> Put together, the final function appendToArray calls AllElements and >> gives "a", which is an array with all the elements on the source. Then each >> of those elements is just added to the array in "dest". This works because >> the generic argument "T" has to implement AllElements, and U has been >> constrained to the same type as T. The where clause is included in case you >> want to do more than have this type implement one protocol. Before the >> where, you declare type arguments, which can conform to either one or none >> protocols. If you want T to conform to 2+ protocols, add a "where" clause >> to constrain. You can then constrain any free type arguments you declared >> earlier and any associated types associated with the type arguments via >> protocols (e.g. T.SomeType). >> >> func appendToArray >> <T: AllElements, U where U == T.ElementType> >> (source: T, inout dest: Array<U>) { >> >> let a = source.allElements() >> for element in a { >> dest.append(element) >> } } >> var buffer = ["a", "b", "c"] appendToArray([1: "foo", 2: "bar"], &buffer) >> >> Now you've created five methods for this one process. In actuality, you >> would have your containers implement Sequence and use a for-in loop to go >> through all the elements. This requires knowledge of Generators, >> EnumerateGenerators, and other material. >> Q&A (46:05) >> >> *Q: In the extension example, are we extending all arrays of anything?* >> Austin: Yes, which is why this is a bad idea in practice. You can't >> actually say that you only want arrays with JSON type objects to also >> implement JSON array, which is needed to ensure that you have valid JSON. >> >> *Q: Is the type T built-in? Where does it come from?* >> Austin: T is actually coming from the declaration of array. If you >> command-click an array in XCode, the declaration of the array shows that it >> declares a generic argument T that has some constraints. >> >> *Q: Is there any kind of trace for generics and the way it works? Is it >> traceable to an existing language or is it brand-new?* >> Austin: I don't know the answer, but I'm sure there are precedents. >> Generics in Swift kind of de-emphasize object oriented programming because >> they're built more around protocols than around class hierarchies. You >> might get a closer procedent if you looked at Haskell. >> >> *Q: What is the exclamation point used for?* >> Austin: The exclamation mark is for optionals. Everything in Swift is >> non-nilable by default, so if you want to set something to nil, it must be >> declared as an optional. The question mark after the type signifies this. >> Then, the exclamation mark, or bang, takes the value out of the optional so >> you can use it. >> >> *Q: Is there something like value template parameters in Swift? Or should >> we just type in, type template?* >> Austin: I don't think so, I don't think Swift generics are as powerful. >> >> *Q: Can you explain let? It seemed like it would sometimes check the case >> and othertimes it would set it to the constant.* >> Austin: A let pattern kind of matches everything, but also takes a value >> and puts it in the constant for later use. When we use "as", it both checks >> the type and also puts it in the constant. >> ------------------------------ >> Sign up to be notified of future videos >> >> We won't email you for any other reason, ever. >> >> -- >> Recebeu esta mensagem porque subscreveu ao grupo "Mailing List da >> Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" do >> Grupos do Google. >> Para anular a subscrição deste grupo e parar de receber emails do mesmo, >> envie um email para [email protected]. >> Para publicar uma mensagem neste grupo, envie um email para >> [email protected]. >> Visite este grupo em http://groups.google.com/group/riapt. >> Para mais opções, visite https://groups.google.com/d/optout. >> > > -- > Recebeu esta mensagem porque subscreveu ao grupo "Mailing List da > Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" do > Grupos do Google. > Para anular a subscrição deste grupo e parar de receber emails do mesmo, > envie um email para [email protected]. > Para publicar uma mensagem neste grupo, envie um email para > [email protected]. > Visite este grupo em http://groups.google.com/group/riapt. > Para mais opções, visite https://groups.google.com/d/optout. > > -- > Recebeu esta mensagem porque subscreveu ao grupo "Mailing List da > Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" do > Grupos do Google. > Para anular a subscrição deste grupo e parar de receber emails do mesmo, > envie um email para [email protected]. > Para publicar uma mensagem neste grupo, envie um email para > [email protected]. > Visite este grupo em http://groups.google.com/group/riapt. > Para mais opções, visite https://groups.google.com/d/optout. > -- Recebeu esta mensagem porque está inscrito no grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" dos Grupos do Google. Para anular a subscrição deste grupo e parar de receber emails do mesmo, envie um email para [email protected]. Para publicar uma mensagem neste grupo, envie um e-mail para [email protected]. Visite este grupo em http://groups.google.com/group/riapt. Para mais opções, consulte https://groups.google.com/d/optout.
