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

[Wei Li]

On Tue, Aug 29, 2017 at 1:12 PM, 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??
>

I would vote for OkHttp, as sync endpoints are not really RESTFUL
endpoints. Using OkHttp provides more flexibility.


>
> 3) Determining URL to cloud app after decoupling. *@wtrocki* How was this
> done in JS Sync SDK?
>

At the moment, the sync endpoints are always like this
https://<cloud_app_url>/mbaas/sync.
I believe the url of the cloud app is passed in as part of the
initialisation in the js sync sdk. For now, we should do the same for the
android sync lib.

In the long term, I think there should be another module that is
responsible for service discovery - resolve the url of the services and
pass the them to each service's module.


>
> 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>
>

I think create interfaces to abstract some the android dependencies are
fine, but that should be the aim for supporting another environment (e.g.
Java), not for running the tests - to make sure the sdk is properly tested,
we should run them in the emulators anyway. Creating the interfaces for the
tests seems to be the wrong motivation (if we are running integration
tests).


>
> 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>
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>


-- 

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile <https://www.redhat.com/>

weil at redhat.com    M: +353862393272
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20170829/b101bd44/attachment.htm>