From corinnekrych at gmail.com Fri Mar 4 09:03:30 2016 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 4 Mar 2016 10:03:30 +0100 Subject: [feedhenry-dev] Let's talk about Swift: async completion closure In-Reply-To: References: Message-ID: Hello iOS Lovers, Here is some follow up on the discussion. The Swift SDK development has evolved and we now have an initial version of fh.init and fh.cloud. You can fellow the development of Swift SDK in this repo [1]. To see the usage refer to blank-ios-swift template [2]. With the usage of default parameter we simplify the call to: *FH.init* { (resp:Response, error: NSError?) -> Void in if let error = error { self.statusLabel.text = "FH init in error" print("Error: \(error)") return } self.statusLabel.text = "FH init successful" *FH.cloud*("hello", completionHandler: { (response: Response, error: NSError?) -> Void in if let error = error { print("Error: \(error)") return } print("Response from Cloud Call: \(response.parsedResponse)") }) print("Response: \(resp.parsedResponse)") } As always, thoughts, feedback are welcome, ++ Corinne iOS Tech Lead [1] https://github.com/feedhenry/fh-ios-swift-sdk [2] https://github.com/feedhenry-templates/blank-ios-swift On 26 February 2016 at 16:05, Corinne Krych wrote: > Hi M?t? > > [posting to the mailing list, to carry on the discussion together] > > Delegates trend to be tagged "old-school" because there were the initial > way to deal with async calls. Blocks get introduced much later in 2010 with > iOS4. Actually depending on your use case you'll use either. NSURLSession > is a perfect example, it got both. You use blocks completion handler if > you're not interested in progression whereas you'll implement `NSURLSessionDataDelegate` > ans use its delegate method `URLSession:dataTask:didReceiveData:`. See > [1] for some blog posts on the subject. > > For FeedHenry SDK, given that we work with static methods (we could start > another discussion on that topic) blocks offer a nicer syntax and much > convenient usage. With Swift coming on, block become closures. And this is > the good news: closures/functions/methods got a unified syntax, so nice and > easy you will love. With closure and the power of Swift FP feature, you > can get to fancier API discussion see S2, S3. > > Lest to answer, your question about more iOS over JavaScript feel for our > API, this is exactly why I'm in favor of merging `onSuccess` and > `onFailure` blocks into one `completionHandler` see S1 syntax as it's > closer to iOS libraries usage. > > I hope it's answer your questions. > I love the discussion :) > > ++ > Corinne > [1] block vs delegate post: > http://blog.stablekernel.com/blocks-or-delegates/ > > http://www.abdus.me/ios-programming-tips/blocks-vs-delegates-ios-comparison/ > > > On 26 February 2016 at 15:08, M?t? R?cz wrote: > >> Hi Corinne, >> >> Thanks for quick response. My main question is, do we prefer blocks over >> delegates? And is it only because we want to have a uniform-ish API in JS, >> iOS and Android, or is there some deeper reason, such as delegates are >> old-school and blocks are the new way? I'm not in the loop with iOS dev >> anymore, so I'm not sure what the trends are these days, but it always felt >> like we're abusing blocks in this case. :) >> I also understand we can't/won't just change the API from one version to >> the next, so my q is more theoretical than practical. >> >> Kind regards, >> M?t? >> >> On Fri, Feb 26, 2016 at 2:00 PM, Corinne Krych >> wrote: >> >>> >>> >>> On 26 February 2016 at 12:23, M?t? R?cz wrote: >>> >>>> Hi Corinne, >>>> >>>> Somewhat unrelated, I always wondered why the ObjC API followed the JS >>>> API so closely with blocks, instead of a more idiomatic syntax based on >>>> protocols and delegates could possibly be more obvious for the end-users, >>>> similar to how NSURLConnection is used. (I see there is an >>>> FHResponseDelegate already, but it is only used internally by FHAct.) >>>> >>> >>> As FHAct as been deprecated for quite a while, this would be out of >>> Swift SDK 4.x and therefore there will be no Delegate any more. >>> Indeed it will narrow down the usage. >>> >>> >>>> If we changed the ObjC API that way, would it narrow down the choices >>>> for the best syntax for the Swift API? The client code would look very much >>>> like Summers' Java example, and a few indentation levels could be spared, >>>> compared to using blocks. >>>> >>>> Kind regards, >>>> M?t? >>>> >>>> On Thu, Feb 25, 2016 at 5:00 PM, >>>> wrote: >>>> >>>>> >>>>> @summers That would go even deeper in FRP. >>>>> We should list it as: >>>>> S4: More reactive way >>>>> I don't have code snippet for it but i'll do some. >>>>> btw all the other code snippets comes have an "trial" implementation >>>>> [1]. >>>>> pro: >>>>> Rx way fits for asynch data stream >>>>> con: >>>>> A bit far from the other Java/JS/C# existing syntax >>>>> >>>>> For the initial Swift SDK, I'd stick to S1 to be in sync with other >>>>> language SDK. >>>>> But I see where you're coming from Summers and I like the discussion. >>>>> Let >>>>> me come back to you with some Swifty code snippets. >>>>> ++ >>>>> Corinne >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corinnekrych at gmail.com Fri Mar 4 09:33:20 2016 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 4 Mar 2016 10:33:20 +0100 Subject: [feedhenry-dev] GSoC FeedHenry/AeroGear iOS proposal Message-ID: Hello Student, For GSoC2016, here is the proposal for FeedHenry/AeroGear client iOS SDK. ------------ WatchKit SDK for AeroGear/FeedHenry Summary of idea: Bring the features of AeroGear/FeedHenry libs to the ? Watch: - push notification - data sync - networking: how to extend aerogear-ios-http to be used from the watch - oauth2: send a tweet from your wrist? Provide an extension to the existing FeedHenry/AeroGear SDK/libs to make them fit for Apple Watch. Focus on high quality sdks also include work on how to unit test (mocking?) your app. Knowledge prerequisite: iOS8/9, Swift Skill level: Medium Contact(s) / potential mentors(s): Corinne Krych (ckrych at redhat.com, corinnekrych at gmail.com) Associated project(s): AeroGear, FeedHenry, Keycloak ------------ Do not hesitate to spread the word around you if you know students. Any questions, just ask. ++ Corinne -------------- next part -------------- An HTML attachment was scrubbed... URL: From timur at redhat.com Tue Mar 8 07:45:06 2016 From: timur at redhat.com (Timur Tatarshaov) Date: Tue, 8 Mar 2016 08:45:06 +0100 Subject: [feedhenry-dev] Mock libraries to use for unit test for Swift iOS SDK Message-ID: As we develop unit tests for fh-ios-swift-sdk we need to evaluate which mock libraries to use. 1. Mock http For fh-ios-sdk (ObjC) we used to work with Nocilla to dynamic mock (through swizzling) the HTTP layer. For aerogear-ios-http (one of the lib we're going to use in fh-ios-swift-sdk), we mocked HTTP layer with OHHTTPStubs. Nocilla was picked for FH sdk over OHHTTPStubs because it supports ASIHTTP lib, but since we're now working with plain NSURLSession, we could unify the libs to use. 2. dynamic Mock in ObjC we used to work with OCMock (dynamic mock), in Swift, with the static type aspect of the language, mocks are done by implementing protocol, more "hand crafted". But still libraries like the one written by Tadeas are worth investigating: https://github.com/SwiftKit/Cuckoo 3. BDD style Evaluate if BDD libs like Quick/Nimble could help writing test that read nicely -------------- next part -------------- An HTML attachment was scrubbed... URL: From corinnekrych at gmail.com Tue Mar 8 13:07:45 2016 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 8 Mar 2016 14:07:45 +0100 Subject: [feedhenry-dev] Reachability and FH.init Message-ID: Hello guys, Working on offline detection on the Swift FH SDK, I bumped into this behaviour: if FH.init fails due to offline mode (no Wifi or Cell connection) the failure callback is executed (as expected). As the connection is back, a FH.init with a null completion handle is executed again (silently). See - for iOS: https://github.com/feedhenry/fh-android-sdk/blob/master/fh-android-sdk/src/main/java/com/feedhenry/sdk/FH.java#L192-L194 - for Andrdoid: https://github.com/feedhenry/fh-ios-sdk/blob/master/fh-ios-sdk/FH.m#L203-L205 My question is: What is the use case for this behaviour? If you do you call with imbricated callback as the initial init failed, even though the init is retried with a null callback, the app has no mean to know the FH.init has succeed and the app is ready. If you use this feature, feedback is welcome. ++ Corinne. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Tue Mar 8 20:43:00 2016 From: weil at redhat.com (Wei Li) Date: Tue, 8 Mar 2016 20:43:00 +0000 Subject: [feedhenry-dev] Reachability and FH.init In-Reply-To: References: Message-ID: Hi Corinne, I think the intention of this feature is that the developer doesn't need to call init again if the initial init call is failed due to network issues. Developer can continue use FH.cloud calls and the error callback will be invoked if the init is failed again. It is not a feature that will be used explicitly, and I think it is ok if we want to change it. Just need to make it clear how reconnection should be handled. On Tue, Mar 8, 2016 at 1:07 PM, Corinne Krych wrote: > Hello guys, > > Working on offline detection on the Swift FH SDK, I bumped into this > behaviour: if FH.init fails due to offline mode (no Wifi or Cell > connection) the failure callback is executed (as expected). As the > connection is back, a FH.init with a null completion handle is executed > again (silently). > > See > - for iOS: > > https://github.com/feedhenry/fh-android-sdk/blob/master/fh-android-sdk/src/main/java/com/feedhenry/sdk/FH.java#L192-L194 > - for Andrdoid: > > https://github.com/feedhenry/fh-ios-sdk/blob/master/fh-ios-sdk/FH.m#L203-L205 > > My question is: > What is the use case for this behaviour? > If you do you call with imbricated callback as the initial init failed, > even though the init is retried with a null callback, the app has no mean > to know the FH.init has succeed and the app is ready. > > If you use this feature, feedback is welcome. > > ++ > Corinne. > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Wei Li Red Hat email address: wei.li at redhat.com Senior Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttatarsh at redhat.com Thu Mar 10 12:39:18 2016 From: ttatarsh at redhat.com (Timur Tatarshaov) Date: Thu, 10 Mar 2016 13:39:18 +0100 Subject: [feedhenry-dev] Mock libraries to use for unit test for Swift iOS SDK In-Reply-To: References: Message-ID: I assume preferable approach would be to decline usage of third-party libraries since Swift is fast evolving and quite perspective language, but I'm not that familiar with current SDK's complexity yet, to define where tooling of the language is enough and where third-party should be used. So I'll spend some time for to get familiar with SDK. 1. Nocilla(https://github.com/luisobo/Nocilla) is Objective-C oriented, no docs/examples for Swift. Supports ASIHTTP, it's powerful but probably too much for what's needed for our unit tests. We could use native or Alamofire( https://github.com/Alamofire/Alamofire) So here choice for OHHTTPStubs(https://github.com/AliSoftware/OHHTTPStubs) most likely. It's actively developing, supports Swift out of the box, documented and has MIT license. 2. Cuckoo(https://github.com/SwiftKit/Cuckoo) for mocks generation. It feels that, complexity is too high for our needs and it doesn't fit language structure well. It adds extra entity in a build process, since uses command line tools to integrate for generation of mocks on the fly before actual build, which could add additional overhead for the automatic build process at the beginning. But it could help if amount of data to be mocked is high and we need some cross-integration of the data. Could be used in a process, if it would feel like amount of data to be mocked is going to be increased. 3. BDD style. I checked Kiwi(https://github.com/kiwi-bdd/Kiwi) and Cedar( https://github.com/pivotal/cedar) and we used this style for some uart tests, but it's a tests that run from outside and testing the existing box. I don't see it fits nicely into unit tests and Swift syntax. Quick/Nimble(https://github.com/Quick/Nimble)(Apache License Version 2.0) suits for the different than BDD style needs. It's positioned as a way "to express the expected outcomes of Swift" and inspired by Cedar, which is BDD style helper lib, in a sense of checking values only. It allows to evaluate result object easily and useful if objects are complex. I'm not aware about complexity of the output data of SDK's so far, but if it's needed library is welcome to be used. There are two approaches: - to start without it and integrate once complexity will increase - to use it right away if it's already required In a case of post-integration, it should go smoothly since it's just another way of evaluating expressions and doesn't interfere with the logic of the code. If we are at the beginning and not sure about complexity, I would recommend first way. Quick/Nimble is recommended. Opinions are very welcome. On Tue, Mar 8, 2016 at 8:45 AM, Timur Tatarshaov wrote: > As we develop unit tests for fh-ios-swift-sdk we need to evaluate which > mock libraries to use. > > 1. Mock http > For fh-ios-sdk (ObjC) we used to work with Nocilla to dynamic mock > (through swizzling) the HTTP layer. > For aerogear-ios-http (one of the lib we're going to use in > fh-ios-swift-sdk), we mocked HTTP layer with OHHTTPStubs. Nocilla was > picked for FH sdk over OHHTTPStubs because it supports ASIHTTP lib, but > since we're now working with plain NSURLSession, we could unify the libs to > use. > > 2. dynamic Mock > in ObjC we used to work with OCMock (dynamic mock), in Swift, with the > static type aspect of the language, mocks are done by implementing > protocol, more "hand crafted". But still libraries like the one written by > Tadeas are worth investigating: > https://github.com/SwiftKit/Cuckoo > > 3. BDD style > Evaluate if BDD libs like Quick/Nimble could help writing test that read > nicely > -- Timur Tatarshaov Quality Engineer, Red Hat Mobile mobile: +420 773 234 993 bluejeans: https://bluejeans.com/ttatarsh/ mail: *ttatarsh at redhat.com * Slack: Timur Tatarshaov(famers) my calendar -------------- next part -------------- An HTML attachment was scrubbed... URL: From corinnekrych at gmail.com Thu Mar 10 13:55:29 2016 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 10 Mar 2016 14:55:29 +0100 Subject: [feedhenry-dev] Mock libraries to use for unit test for Swift iOS SDK In-Reply-To: References: Message-ID: On 10 March 2016 at 13:39, Timur Tatarshaov wrote: > I assume preferable approach would be to decline usage of third-party > libraries since Swift is fast evolving and quite perspective language, but > I'm not that familiar with current SDK's complexity yet, to define where > tooling of the language is enough and where third-party should be used. So > I'll spend some time for to get familiar with SDK. > > 1. Nocilla(https://github.com/luisobo/Nocilla) is Objective-C oriented, > no docs/examples for Swift. Supports ASIHTTP, it's powerful but probably > too much for what's needed for our unit tests. We could use native or > Alamofire(https://github.com/Alamofire/Alamofire) > > So here choice for OHHTTPStubs(https://github.com/AliSoftware/OHHTTPStubs) > most likely. It's actively developing, supports Swift out of the box, > documented and has MIT license. > +1 we used it in aerogear-ios-http too. > > 2. Cuckoo(https://github.com/SwiftKit/Cuckoo) for mocks generation. It > feels that, complexity is too high for our needs and it doesn't fit > language structure well. It adds extra entity in a build process, since > uses command line tools to integrate for generation of mocks on the fly > before actual build, which could add additional overhead for the automatic > build process at the beginning. > But it could help if amount of data to be mocked is high and we need some > cross-integration of the data. Could be used in a process, if it would feel > like amount of data to be mocked is going to be increased. > Yeap no real need atm but we can revisit. > > 3. BDD style. I checked Kiwi(https://github.com/kiwi-bdd/Kiwi) and Cedar( > https://github.com/pivotal/cedar) and we used this style for some uart > tests, but it's a tests that run from outside and testing the existing box. > I don't see it fits nicely into unit tests and Swift syntax. > > Quick/Nimble(https://github.com/Quick/Nimble)(Apache License Version 2.0) > suits for the different than BDD style needs. > It's positioned as a way "to express the expected outcomes of Swift" and > inspired by Cedar, which is BDD style helper lib, in a sense of checking > values only. > It allows to evaluate result object easily and useful if objects are > complex. I'm not aware about complexity of the output data of SDK's so far, > but if it's needed library is welcome to be used. > There are two approaches: > - to start without it and integrate once complexity will increase > - to use it right away if it's already required > In a case of post-integration, it should go smoothly since it's just > another way of evaluating expressions and doesn't interfere with the logic > of the code. > If we are at the beginning and not sure about complexity, I would > recommend first way. > Good I started that way too > Quick/Nimble is recommended. > > Opinions are very welcome. > > On Tue, Mar 8, 2016 at 8:45 AM, Timur Tatarshaov wrote: > >> As we develop unit tests for fh-ios-swift-sdk we need to evaluate which >> mock libraries to use. >> >> 1. Mock http >> For fh-ios-sdk (ObjC) we used to work with Nocilla to dynamic mock >> (through swizzling) the HTTP layer. >> For aerogear-ios-http (one of the lib we're going to use in >> fh-ios-swift-sdk), we mocked HTTP layer with OHHTTPStubs. Nocilla was >> picked for FH sdk over OHHTTPStubs because it supports ASIHTTP lib, but >> since we're now working with plain NSURLSession, we could unify the libs to >> use. >> >> 2. dynamic Mock >> in ObjC we used to work with OCMock (dynamic mock), in Swift, with the >> static type aspect of the language, mocks are done by implementing >> protocol, more "hand crafted". But still libraries like the one written by >> Tadeas are worth investigating: >> https://github.com/SwiftKit/Cuckoo >> >> 3. BDD style >> Evaluate if BDD libs like Quick/Nimble could help writing test that read >> nicely >> > > > > -- > Timur Tatarshaov > Quality Engineer, Red Hat Mobile > > mobile: +420 773 234 993 > bluejeans: https://bluejeans.com/ttatarsh/ > mail: *ttatarsh at redhat.com * > Slack: Timur Tatarshaov(famers) > my calendar > > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: