Sync decoupling from fh-android-sdk

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Sync decoupling from fh-android-sdk

Vojtech Sazel
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 client or more high level library like Retrofit? Or even use plain Java HttpsURLConnection or something else??

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

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 

Remote Czech Republic

[hidden email]    IM: vsazel


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Sync decoupling from fh-android-sdk

supittma
Administrator


On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel <[hidden email]> 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 client or more high level library like 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...

-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 

Remote Czech Republic

[hidden email]    IM: vsazel



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Sync decoupling from fh-android-sdk

Daniel Passos
In reply to this post by Vojtech Sazel


On Tue, Aug 29, 2017 at 9:12 AM, Vojtech Sazel <[hidden email]> 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 client or more high level library like Retrofit? Or even use plain Java HttpsURLConnection or something else??

I'd say let's use Retrofit, and if we need something specific let's use OkHttp since Retrofit is using it behind of the scene it will be there is we need.
 

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

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 

Remote Czech Republic

[hidden email]    IM: vsazel




--
-- Passos

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Sync decoupling from fh-android-sdk

Oleh Mackiv
In reply to this post by supittma
-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 <[hidden email]> wrote:


On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel <[hidden email]> 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 client or more high level library like 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...
 
-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 

Remote Czech Republic

[hidden email]    IM: vsazel





--
Oleg Matskiv
Associate Quality Engineer
Red Hat Mobile Application Platform
[hidden email]

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Sync decoupling from fh-android-sdk

Vojtech Sazel
On Tue, Aug 29, 2017 at 2:54 PM, Oleh Mackiv <[hidden email]> 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.

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Sync decoupling from fh-android-sdk

Wei Li
In reply to this post by Vojtech Sazel


On Tue, Aug 29, 2017 at 1:12 PM, Vojtech Sazel <[hidden email]> 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 client or more high level library like Retrofit? Or even use plain Java HttpsURLConnection or something else??

I would vote for OkHttp, as sync endpoints are not really RESTFUL endpoints. Using OkHttp provides more flexibility.
 

3) Determining URL to cloud app after decoupling. @wtrocki How was this done in JS Sync SDK? 

At the moment, the sync endpoints are always like this https://<cloud_app_url>/mbaas/sync.  I believe the url of the cloud app is passed in as part of the initialisation in the js sync sdk. For now, we should do the same for the android sync lib.

In the long term, I think there should be another module that is responsible for service discovery - resolve the url of the services and pass the them to each service's module.
 

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

I think create interfaces to abstract some the android dependencies are fine, but that should be the aim for supporting another environment (e.g. Java), not for running the tests - to make sure the sdk is properly tested, we should run them in the emulators anyway. Creating the interfaces for the tests seems to be the wrong motivation (if we are running integration tests).
 

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 

Remote Czech Republic

[hidden email]    IM: vsazel


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Sync decoupling from fh-android-sdk

supittma
Administrator
In reply to this post by Vojtech Sazel


On Tue, Aug 29, 2017 at 9:09 AM, Vojtech Sazel <[hidden email]> wrote:
On Tue, Aug 29, 2017 at 2:54 PM, Oleh Mackiv <[hidden email]> 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.

I think it is the right thing to do (coding to interfaces), I think making a separate SDK for testing is wrong.

As an aside I am holding out hope that desktop Java is almost ready for a revival ;) . 


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Sync decoupling from fh-android-sdk

Matthias Wessendorf
In reply to this post by supittma


On Tue, Aug 29, 2017 at 2:31 PM, Summers Pittman <[hidden email]> wrote:


On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel <[hidden email]> 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 client or more high level library like 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...

-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 

Remote Czech Republic

[hidden email]    IM: vsazel



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Sync decoupling from fh-android-sdk

Matthias Wessendorf
In reply to this post by Oleh Mackiv


On Tue, Aug 29, 2017 at 2:54 PM, Oleh Mackiv <[hidden email]> 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 <[hidden email]> wrote:


On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel <[hidden email]> 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 client or more high level library like 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...
 
-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 

Remote Czech Republic

[hidden email]    IM: vsazel





--
Oleg Matskiv
Associate Quality Engineer
Red Hat Mobile Application Platform
[hidden email]

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Sync decoupling from fh-android-sdk

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

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

IM: wtrocki


On Tue, Aug 29, 2017 at 4:04 PM, Matthias Wessendorf <[hidden email]> wrote:


On Tue, Aug 29, 2017 at 2:54 PM, Oleh Mackiv <[hidden email]> 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 <[hidden email]> wrote:


On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel <[hidden email]> 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 client or more high level library like 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...
 
-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 

Remote Czech Republic

[hidden email]    IM: vsazel





--
Oleg Matskiv
Associate Quality Engineer
Red Hat Mobile Application Platform
[hidden email]

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Sync decoupling from fh-android-sdk

Matthias Wessendorf


On Wed, Aug 30, 2017 at 1:57 PM, Wojciech Trocki <[hidden email]> 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

IM: wtrocki


On Tue, Aug 29, 2017 at 4:04 PM, Matthias Wessendorf <[hidden email]> wrote:


On Tue, Aug 29, 2017 at 2:54 PM, Oleh Mackiv <[hidden email]> 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 <[hidden email]> wrote:


On Tue, Aug 29, 2017 at 8:12 AM, Vojtech Sazel <[hidden email]> 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 client or more high level library like 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...
 
-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 

Remote Czech Republic

[hidden email]    IM: vsazel





--
Oleg Matskiv
Associate Quality Engineer
Red Hat Mobile Application Platform
[hidden email]

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev





--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev