[feedhenry-dev] Let's talk about Swift: async completion closure

[Corinne Krych]

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 <corinnekrych at gmail.com> 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 <mracz at redhat.com> 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 <corinnekrych at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 26 February 2016 at 12:23, Máté Rácz <mracz at redhat.com> 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, <feedhenry-dev-request at redhat.com>
>>>> 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: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20160304/cc025991/attachment.htm>