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

Wed Aug 30 12:55:38 UTC 2017

On Wed, Aug 30, 2017 at 1:57 PM, Wojciech Trocki <wtrocki at redhat.com> wrote:

> Really good points. I can create PR for IOS and Android to extend this
> conversation to some example implementation.
> The major problem I see is how we going to include sync into existing SDK.
>

I am all for a modular arch. That's what we did in AeroGear SDKs as well.
All features were small libs/JARs

>
> For Android Sync will need to have their own network implementation and
> use adapter pattern for elements expected by SDK (FHActCallback etc.)
> IOS itself should be easier as we can use same network library and sdk can
> just include sync as lib itself.
>
> Regards
> Wojtek T.
>
> WOJCIECH TROCKI
>
> Red Hat Mobile <https://www.redhat.com/>
>
> IM: wtrocki
> <https://red.ht/sig>
>
> On Tue, Aug 29, 2017 at 4:04 PM, Matthias Wessendorf <mwessend at redhat.com>
> wrote:
>
>>
>>
>> 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/f
>>>>> h-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
>>
>> _______________________________________________
>> 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/20170830/a0783a99/attachment.htm>