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

[Matthias Wessendorf]

On Tue, Aug 29, 2017 at 2:31 PM, Summers Pittman <supittma at redhat.com>
wrote:

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

+1 also offers Http/2 support, for more real-time nature


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

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

-M


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


-- 
Project lead AeroGear.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20170829/0771485c/attachment.htm>