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

Vojtech Sazel vsazel at redhat.com
Tue Aug 29 13:09:53 UTC 2017


On Tue, Aug 29, 2017 at 2:54 PM, Oleh Mackiv <omatskiv at redhat.com> wrote:

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

It would be possible to use Robolectric, but as I said Android dependency
was really almost unnecessary there in the first place. Only place it uses
Android Context is for opening files for datasets. I think yes, Destop Java
is dead but it still makes sense to have the logic of sync and Android
logic separately. Just for clarity. It's really not a deadly amount of work
to do.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20170829/48ca74a3/attachment.htm>


More information about the feedhenry-dev mailing list