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

[Corinne Krych]

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/20160226/b99a9f2e/attachment.htm>