<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 29, 2017 at 2:31 PM, Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel <span dir="ltr"><<a href="mailto:vsazel@redhat.com" target="_blank">vsazel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>for those who don't know Dynamic SDK Team is now working on decoupling FH Sync SDK from fh-android-sdk.</div><div><br clear="all"><div>But not everyone probably know how is it dependent on rest of the SDK. I have few points from my little digging into it:</div><div>1) Good news is that there it's very little dependency on rest of the sdk. <br><font face="monospace, monospace">FH, FHActRequest</font><span style="font-family:monospace,monospace">, FHActCallback</span>- for calling cloud service, basically only one method is used </div><div><font face="monospace, monospace">FHLog -</font><font face="arial, helvetica, sans-serif"> for logging, wrapper for Android Log</font></div><div><font face="arial, helvetica, sans-serif"><br></font>2) Most difficult part would be to replace remote calls, but it's still quite easy. <br><b>For discussion: </b>Should we use <a href="http://square.github.io/okhttp/" target="_blank"><b><i>OkHttp</i></b> </a>http client or more high level library like <b><i><a href="http://square.github.io/retrofit/" target="_blank">Retrofit</a></i></b>? Or even use plain Java HttpsURLConnection or something else??<br><br></div></div></div></blockquote><div><br></div></span><div>OKHttp because I think we will get a lot more milage out of that level of abstraction and the API is better (IMHO) and HttpsURLConnection.  </div></div></div></div></blockquote><div><br></div><div>+1 also offers Http/2 support, for more real-time nature </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Retrofit's use cases are very tied to RESTful APIs and I'm not sure that RESTful is the future of sync.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div><div>3) Determining URL to cloud app after decoupling. <b>@wtrocki</b> How was this done in JS Sync SDK? </div><div><br>4) QE would like to have most functionality written platform independent (not dependent on Android SDK). <br>Why to do that? We can have most tests running without emulator. This would result in much quicker and more stable execution. It's especially important when running tests on Circle CI, Jenkins or elsewhere.<br>How to do that?<br>We can have HTTP calls, logger and filesystem access written against interfaces. Then it can be implemented in Android or pure Java separately. Like this - <a href="https://github.com/feedhenry/fh-android-sdk/pull/107/commits/ae2c16a6b0dd2ff24ff45578b579f7cf5b04415f" target="_blank">https://github.com/feedhenry/f<wbr>h-android-sdk/pull/107/commits<wbr>/ae2c...</a></div></div></div></blockquote><div><br></div></span><div>-1 (ish).  I agree with the sentament and some of the conclusions, but this is an Android SDK and going out of our way to make it NOT an Android SDK is a waste of time IMHO.  Furthermore, Google has support for this exact use case in their testing docs (<a href="https://developer.android.com/training/testing/unit-testing/local-unit-tests.html#mocking-dependencies" target="_blank">https://developer.android.<wbr>com/training/testing/unit-<wbr>testing/local-unit-tests.html#<wbr>mocking-dependencies</a>).  </div><div><br></div><div>There are a few caveats to my -1 though.  First if we want to make a JavaSDK for use with desktop or server to server applications then you have my interest and we should investigate that route.  Second, if QE has looked at the testing tools available for Android and mocking their dependencies and found it to be lacking I defer to their judgement.  Finally, good code should have firewalls between system services and logic anyway so there will be a lot of code that currently has dependencies on Android APIs that won't in the future.</div></div></div></div></blockquote><div><br></div><div>-1 as well, like summers said, this is Android, and should not be treated like a lib that is sitting in a Java6 server (e.g. usage of HttpsUrlConnection)</div><div><br></div><div>-M</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br>This would also serve as PoC of proper design for other future SDKs for 5.x/mobile.next. <br><br></div><div>Thanks for your suggestions.</div><div><br></div>-- <br><div class="m_1734919711971476999gmail-m_8165379923349198123gmail-m_-3391282319618719581m_856055632370233063gmail-m_7171841738160411763gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>VOJTĚCH</span> <span>SÁZEL</span></p><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>SENIOR QUALITY ENGINEER, MOBILE QE</span></p><p style="font-family:overpass,sans-serif;margin:0px;font-size:10px;color:rgb(153,153,153)"><a href="https://www.redhat.com/" style="color:rgb(0,136,206);margin:0px" target="_blank">Red Hat <span><br><br></span></a></p><span style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:medium"><p style="font-size:10px;margin:0px;color:rgb(153,153,153)">Remote Czech Republic</p></span><span style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:medium"></span><p style="font-family:overpass,sans-serif;margin:0px 0px 6px;font-size:10px;color:rgb(153,153,153)"><span style="margin:0px;padding:0px"><a href="mailto:vsazel@redhat.com" style="color:rgb(0,136,206);margin:0px" target="_blank">vsazel@redhat.com</a>   </span> <span>IM: <span>vsazel</span></span></p><table border="0" style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:medium"><tbody><tr><td width="100px"><a href="https://red.ht/sig" target="_blank"><img width="90" height="auto"></a></td></tr></tbody></table></div></div>
</div></div>
</blockquote></span></div><br></div></div>
<br>______________________________<wbr>_________________<br>
feedhenry-dev mailing list<br>
<a href="mailto:feedhenry-dev@redhat.com">feedhenry-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/feedhenry-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/feedhenry-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Project lead AeroGear.org</div></div>
</div></div>