<div dir="ltr">Hi <span style="font-size:12.8px">Máté</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">[posting to the mailing list, to carry on the discussion together]</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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 `</span><span style="font-size:12.8px">NSURLSessionDataDelegate` ans use its delegate method `</span><span style="font-size:12.8px">URLSession:dataTask:didReceiveData:`. See [1] for some blog posts on the subject.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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</span><span style="font-size:12.8px">. With closure and the power of Swift FP feature, you can get to fancier API discussion see S2, S3.</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I hope it's answer your questions. </span></div><div><span style="font-size:12.8px">I love the discussion :)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">++</span></div><div><span style="font-size:12.8px">Corinne</span></div><div><span style="font-size:12.8px">[1] block vs delegate post:</span></div><div><span style="font-size:12.8px"><a href="http://blog.stablekernel.com/blocks-or-delegates/">http://blog.stablekernel.com/blocks-or-delegates/</a></span><br></div><div><span style="font-size:12.8px"><a href="http://www.abdus.me/ios-programming-tips/blocks-vs-delegates-ios-comparison/">http://www.abdus.me/ios-programming-tips/blocks-vs-delegates-ios-comparison/</a></span><br></div><div><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 February 2016 at 15:08, Máté Rácz <span dir="ltr"><<a href="mailto:mracz@redhat.com" target="_blank">mracz@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>Hi Corinne,<br><br>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. :)<br></div><div>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.<br></div><div><br></div>Kind regards,<br></div>Máté<br></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 26, 2016 at 2:00 PM, Corinne Krych <span dir="ltr"><<a href="mailto:corinnekrych@gmail.com" target="_blank">corinnekrych@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On 26 February 2016 at 12:23, Máté Rácz <span dir="ltr"><<a href="mailto:mracz@redhat.com" target="_blank">mracz@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Hi Corinne,<br><br></div><div>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.)<br></div></div></blockquote><div><br></div></span><div>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.</div><div>Indeed it will narrow down the usage.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><div dir="ltr"><div>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.<br></div><div><div class="gmail_extra"><br></div><div class="gmail_extra">Kind regards,<br></div><div class="gmail_extra">Máté<br></div><span><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 25, 2016 at 5:00 PM,  <span dir="ltr"><<a href="mailto:feedhenry-dev-request@redhat.com" target="_blank">feedhenry-dev-request@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
@summers That would go even deeper in FRP.<br>
We should list it as:<br>
S4: More reactive way<br>
I don't have code snippet for it but i'll do some.<br>
btw all the other code snippets comes have an "trial" implementation [1].<br>
pro:<br>
Rx way fits for asynch data stream<br>
con:<br>
A bit far from the other Java/JS/C# existing syntax<br>
<br>
For the initial Swift SDK, I'd stick to S1 to be in sync with other<br>
language SDK.<br>
But I see where you're coming from Summers and I like the discussion. Let<br>
me come back to you with some Swifty code snippets.<br>
++<br>
Corinne<br>
<br></blockquote></div><br></div></span></div></div>
<br></span>_______________________________________________<br>
feedhenry-dev mailing list<br>
<a href="mailto:feedhenry-dev@redhat.com" target="_blank">feedhenry-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/feedhenry-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/feedhenry-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>