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

[Oleh Mackiv]

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

We would also like to eventually automate some integration tests, and "Java
sync SDK" would be great for that. Android sync SDK would then use Java
sync SDK and have only limited test set for integration/system tests.

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


-- 
Oleg Matskiv
Associate Quality Engineer
Red Hat Mobile Application Platform
omatskiv at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20170829/58ab9484/attachment.htm>