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

Tue Aug 29 15:04:06 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.
>

currently we don't have the need for that.
However, let's assume in the (near) future, there will be "cloud-apps",
powered by a modern java-stack (e.g. vertx).
The generic Java-SDK does not help you much here, since that's a completely
different platform (e.g. rxjava etc)

-M

>
>
> 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
>
> _______________________________________________
> 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/462c0a67/attachment.htm>