<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><br>
<br>
On 7/30/2013 12:26 PM, Yavuz Selim YILMAZ wrote:<br>
</div>
<blockquote
cite="mid:FBB918BC-FEC8-4D9A-AA13-F0BE7602A950@buffalo.edu"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Thanks for the comments. I now get more sense of it, and have a
few "thoughts" inline.
<div><br>
</div>
<div>Kind regards,<br>
<div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; "><br
class="Apple-interchange-newline">
---</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">Yavuz Selim Yilmaz</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">SUNY at Buffalo</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">Computer Science and
Engineering</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: medium; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: 2; text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">PhD Candidate</div>
</div>
<br>
<div>
<div>On Jul 26, 2013, at 10:42 AM, Summers Pittman <<a
moz-do-not-send="true" href="mailto:supittma@redhat.com">supittma@redhat.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Be warned I'm only on my
first cup of coffee :)<br>
<br>
On 07/25/2013 12:20 PM, Yavuz Selim YILMAZ wrote:<br>
</div>
<blockquote
cite="mid:7AED7482-3445-4C01-99E9-A637B3141223@buffalo.edu"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>Hi all,</div>
<div><br>
</div>
<div>When I was using AeroGear iOS, I needed to read
from pipe and execute the success and failure blocks
in background (for background data syncronization, a
basic one which provides eventual data consistency).
What I did first was this:</div>
<div><br>
</div>
<div>dispatch a thread</div>
<div> read from pipe</div>
<div> --- READ ---</div>
<div> success</div>
<div> --- SUCCESS BLOCK ---</div>
<div> failure</div>
<div> --- FAILURE BLOCK ---</div>
<div> </div>
<div>However, when I checked, I realized that the
success and failure blocks were being executed on the
main thread, not on the thread that I initiated the
read. Then I needed to modify the code and do like
this (I know all "--- READ ---"s are already in
background):</div>
<div><br>
</div>
<div>read from pipe</div>
<div> --- READ ---</div>
<div> success</div>
<div> dispatch a thread</div>
<div> --- SUCCESS BLOCK ---</div>
<div> failure</div>
<div> dispatch a thread</div>
<div> --- FAILURE BLOCK ---</div>
<div> </div>
<div>At that time, I was going to ask the reason behind
dispatching back to the main queue for success and
failure blocks, but then I thought the idea is coming
from Android's AsyncTask. So my wrong assumption made
sense as I thought having similar way of handling the
end-developer (hope you get what I mean by
end-developer) operations (in this case read from
pipe) would help to use same/similar software
architectures for different platforms (iOS and Android
in this case).</div>
<div><br>
</div>
<div>Then I started to taste AeroGear Android from the
last week. Keeping my hard times with multithreading
on iOS in mind, I was expecting to see the read from
pipe code something like this:</div>
<div><br>
</div>
<div>create AsyncTask</div>
<div> doInBackground</div>
<div> --- READ ---</div>
<div> onPostExecute</div>
<div> success</div>
<div> --- SUCCESS BLOCK ---</div>
<div> failure</div>
<div> --- FAILURE BLOCK ---</div>
<div> </div>
<div>However, what I've seen on RestAdapter was quite
different:</div>
<div><br>
</div>
<div>create new thread</div>
<div> --- READ ---</div>
<div> success</div>
<div> --- SUCCESS BLOCK ---</div>
<div> failure</div>
<div> --- FAILURE BLOCK ---</div>
<div><br>
</div>
<div>And here, success and failure blocks are being
executed on the background thread instead of on the UI
thread. I checked why not using AsyncTask for this
operation (as I was using it for my network operations
if I need to touch the UI thread at onProgress and at
onPostExecute), and I realized that there is a reason
behind using ThreadPoolExecutor (no deep research
though, I only know it is recommended considering the
operations might take longer). </div>
</blockquote>
The reason we use the thread pool executor is because the
onPostExcute method runs on the UI thread. If your Pipe
is running form a service that means that things happening
on onSuccess would block the UI thread. This wouldn't be
obvious to the user.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>Makes perfect sense. :)</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
<blockquote
cite="mid:7AED7482-3445-4C01-99E9-A637B3141223@buffalo.edu"
type="cite">
<div>So, in Android case, making sure the availability
of the UI thread when executing success and failure
blocks is left to the end-developer as far as I could
see (please correct me if I am wrong), </div>
</blockquote>
So the threading bits aren't explicitly defined in the
Pipes 101 doc. What the docs say to do will get you
around this issue though. If you use the Pipeline get
methods which take in some form of context (Activity,
Fragment, fragment activity, etc) then you will have
onSuccess run on the UI thread. Otherwise you want.<br>
</div>
</blockquote>
<div><br>
</div>
<div>The way pipeline handles the lifecycle of the request and
threads makes perfect sense. My concern now is, as an
outside developer, I start with getting started guides, and
going through step by step, pipe (RestAdapter - "first
example") provides me a way to read from endpoint, but it
doesn't fit to the "most common" scenario, which I think is
(as Christios mentioned) "networking on the background,
update UI on the success block" (though I can still update
the UI, the activity might or might not be available at that
moment). So I feel like, even if I don't know what pipeline
is (at that moment), the "first example" should fit to the
basic scenario so it should use pipeline (in current
aerogear-android implementation). But mine is just an idea.
:)</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
Sounds like a trip to the JIRA mobile for better docs.<br>
<br>
In general you want to use these methods because it tells
lets AG do some smart things behind the scenes with
respect to managing the network, data caching, etc.<br>
</div>
</blockquote>
<div><br>
</div>
<div>With pipeline, yes, aerogear does all the magic. :)</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
<blockquote
cite="mid:7AED7482-3445-4C01-99E9-A637B3141223@buffalo.edu"
type="cite">
<div>while in iOS case the execution of the success or
failure blocks indicates that the main thread is up
and running at that time. The difference is maybe
because of the way iOS and Android handles the
execution of the background threads. But, when first
tasting the libs for both platforms, I did not feel
comfortable with (it was not so obvious) on which
thread the success and failure blocks are executed.</div>
<div><br>
</div>
<div>So, my first question is, can somebody point me
where these threading designs were discussed? </div>
</blockquote>
Probably not. The best thread I can think of would be
back from February but it really doesn't define anything.<br>
<blockquote
cite="mid:7AED7482-3445-4C01-99E9-A637B3141223@buffalo.edu"
type="cite">
<div>I am curious about the idea behind these designs
(platform pushes that way? easy to implement? common
way of doing network operations? or any other specific
reason?), and hoping to learn new things from there
(actually I am sure I will).</div>
</blockquote>
The goals behind the design were to leverage as much of
than Android API to handle the activity lifecycle as
possible. It did mean that there are somethings which
just have to be "known" and the docs should highlight
them. IE if you are calling things from an Activity or
Fragment then you should pass the context to the
pipeline.get method. If the docs aren't clear (or if we
need to explain the full implications) then that is a
JIRA. <br>
</div>
</blockquote>
<div><br>
</div>
<div>This I think goes to my "the 'first example' should fit
to the most common scenario" statement, if the first example
does so, things are getting clear while going further. But I
won't expect everybody to go over "all" the guides and docs
before using AeroGear (e.g. maybe my bad, but I'm using many
libs which I didn't read "all" of their docs and guides
yet), and even if the developers don't know how AeroGear
does the things, they should be able to use its magic from
the start. :) (just an opinion though)</div>
<div><br>
</div>
<div>For iOS, I checked why AFNetworking defaults to the main
thread instead of whichever thread initiates the call, and
I've seen an odd explanation. Here is the brief scenario:</div>
<div><br>
</div>
<div>The first idea comes from this guy and he provides (to me
the solution which makes perfect sense) this PR:</div>
<div><a moz-do-not-send="true"
href="https://github.com/AFNetworking/AFNetworking/pull/107">https://github.com/AFNetworking/AFNetworking/pull/107</a></div>
<div><br>
</div>
<div>This simply works as follows: Whichever thread initiates
the request is default execution thread for success/failure
blocks, and developer has option to override (to some other
thread or to main thread). The AFNetworking maintainers find
this solution confusing. After 5 months, they provide this
PR:</div>
<div><a moz-do-not-send="true"
href="https://github.com/AFNetworking/AFNetworking/pull/202">https://github.com/AFNetworking/AFNetworking/pull/202</a></div>
<div><br>
</div>
<div>This uses the main thread as default, and developer has
option to override it (I think AeroGear developer doesn't
even have such an option for now). Here is the explanation
why not the first but the second solution is merged (from
one of the second option supporting developer): "<span
style="background-color: rgb(251, 251, 251); color:
rgb(51, 51, 51); font-family: Helvetica, arial, freesans,
clean, sans-serif; font-size: 13px; line-height: 22px; ">This
is discussable, but probably lead to may less bugs due to
people not understanding what they are doing :)</span>"
However, this solution and explanation doesn't make sense to
me at all. I think if I'm initiating the request from the
main thread, I might or might not know what I am doing, but
if I am dispatching another thread and requesting from
there, I at least know what multithreading is. :) And I did
expect my success/failure to run on the initiator thread
when I was trying it out (maybe it's only me, but I felt
it's the natural way - and AeroGear Android pipeline works
this way as far as I could see).</div>
<div><br>
</div>
<div>At the least, as Christos said, nothing prevents me to
work on the threading, and to deal with life cycles on my
own, but I'm just expecting all the magic (at least for the
common scenario) is done by AeroGear (it's in the end much
more powerful than what I can come up with in a limited time
:)). And to me, what AFNetworking provides does not seem to
be a full magic. :) Maybe it's only me who thinks the
common scenario is different.</div>
</div>
</div>
</blockquote>
Hrm... You know it probably wouldn't be too hard to check and see
if a request is on the main thread, set a flag, and let the
framework choose.<br>
<br>
One of the things which bugs me about the Android API for Pipes is
the Callback parameter. It makes developers want to put an
anonymous inner class there, but anonymous inner classes in Android
Fragments and Activities are bad if they leak outside of the
Activity (which it has to in AeroGear). The docs mention that you
shouldn't do that, but it is almost a throwaway line at the end of
the doc after the feel of the API is introduced. Part of me thinks
that it may be a good idea to throw an exception if you try to do
that (something like networking on main thread exception Android
does). Another part of me says I'm annoyed every time I come across
something which does that.<br>
<br>
<blockquote
cite="mid:FBB918BC-FEC8-4D9A-AA13-F0BE7602A950@buffalo.edu"
type="cite">
<div>
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
If people have better ideas then that is a ML thread and
then maybe a JIRA :)<br>
<blockquote
cite="mid:7AED7482-3445-4C01-99E9-A637B3141223@buffalo.edu"
type="cite">
<div><br>
</div>
<div>Second and the last thing, I think somewhere in the
guides and docs, the threading (best practices when
using AeroGear) should be
emphasized/mentioned/explained. Because, although
things are smooth and easy when the operations take
little amount of time, things are becoming more
complicated when the operations take longer as the
device users' app usage pattern is unknown. (e.g. for
Android, I needed to check thread name/id to actually
realize the success/failure blocks were being executed
on the background thread (e.g. Pipes 101 mentions to
be aware of Android Activity Lifecycle, but not so
clear what happens during the execution - is it going
to stop? is it going to execute on UI thread or
background? will I need to check if UI thread is there
or not? etc.). </div>
</blockquote>
<br>
<blockquote
cite="mid:7AED7482-3445-4C01-99E9-A637B3141223@buffalo.edu"
type="cite">
<div>And for iOS, I needed to have a really blocking
success/failure code to realize it was running on the
main thread, since then I was looking for some other
parts to see why scrolling was not smooth).</div>
<div><br>
</div>
<div>Kind regards,</div>
<div>
<div style="font-family: Helvetica; font-size: medium;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-align:
-webkit-auto; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing:
0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; "><br
class="Apple-interchange-newline">
---</div>
<div style="font-family: Helvetica; font-size: medium;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-align:
-webkit-auto; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing:
0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">Yavuz Selim Yilmaz</div>
<div style="font-family: Helvetica; font-size: medium;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-align:
-webkit-auto; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing:
0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">SUNY at Buffalo</div>
<div style="font-family: Helvetica; font-size: medium;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-align:
-webkit-auto; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing:
0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">Computer Science
and Engineering</div>
<div style="font-family: Helvetica; font-size: medium;
font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-align:
-webkit-auto; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing:
0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; ">PhD Candidate</div>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aerogear-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aerogear-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></pre>
</blockquote>
<br>
</body>
</html>