[feedhenry-dev] Sync decoupling from fh-android-sdk

[Summers Pittman]

On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel <vsazel at redhat.com> wrote:

> Hi,
>
> for those who don't know Dynamic SDK Team is now working on decoupling FH
> Sync SDK from fh-android-sdk.
>
> But not everyone probably know how is it dependent on rest of the SDK. I
> have few points from my little digging into it:
> 1) Good news is that there it's very little dependency on rest of the sdk.
> FH, FHActRequest, FHActCallback- for calling cloud service, basically
> only one method is used
> FHLog - for logging, wrapper for Android Log
>
> 2) Most difficult part would be to replace remote calls, but it's still
> quite easy.
> *For discussion: *Should we use *OkHttp* <http://square.github.io/okhttp/>http
> client or more high level library like *Retrofit
> <http://square.github.io/retrofit/>*? Or even use plain Java
> HttpsURLConnection or something else??
>
>
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.
Retrofit's use cases are very tied to RESTful APIs and I'm not sure that
RESTful is the future of sync.


> 3) Determining URL to cloud app after decoupling. *@wtrocki* How was this
> done in JS Sync SDK?
>
> 4) QE would like to have most functionality written platform independent
> (not dependent on Android SDK).
> 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.
> How to do that?
> 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 - https://github.com/feedhenry/fh-android-sdk/pull/107/
> commits/ae2c...
> <https://github.com/feedhenry/fh-android-sdk/pull/107/commits/ae2c16a6b0dd2ff24ff45578b579f7cf5b04415f>
>

-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 (
https://developer.android.com/training/testing/unit-testing/local-unit-tests.html#mocking-dependencies).


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.


>
> This would also serve as PoC of proper design for other future SDKs for
> 5.x/mobile.next.
>
> Thanks for your suggestions.
>
> --
>
> VOJTĚCH SÁZEL
>
> SENIOR QUALITY ENGINEER, MOBILE QE
>
> Red Hat
>
> <https://www.redhat.com/>
>
> Remote Czech Republic
>
> vsazel at redhat.com    IM: vsazel
> <https://red.ht/sig>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20170829/2b0f18c4/attachment.htm>