Também já não tenho feito novas funcionalidades com Flex-Flash há muito tempo. Apenas tenho 2 soluções nesta vertente e mantenho a tek para manutenção.
Gostaria de um dia rescrever ambas as soluções com HTML5 mas só se for em tempo disponível para tal. Curioso, o PHP é a tek que não muda e comum a todos :) Uma excelente tek para backed e muito rápida. 2014-09-04 17:01 GMT+01:00 APintex Gmail <[email protected]>: > de momento só estou a utilizar o AIR e PHP > > António Pinto > [email protected] > > > > No dia 04/09/2014, às 16:58, Hugo Ferreira <[email protected]> > escreveu: > > É 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 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.
