Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add multiple sensors observing feature #37

Merged
merged 2 commits into from Dec 29, 2019

Conversation

catalinghita8
Copy link
Contributor

Improvement that fixes #33.

Added the possibility of observing and getting data flow from multiple sensors.

Copy link
Owner

@pwittchen pwittchen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @catalinghita8,

Thanks for your PR and your effort. Unfortunately, you reformatted the whole file with different code style than the one, which is used in the project, so I cannot see your exact changes within PR without analyzing the whole file. Please, use code style described here: https://github.com/pwittchen/ReactiveSensors#code-style. Moreover, I don't see any unit tests related to the feature you introduced.

Regards,
Piotr

@catalinghita8
Copy link
Contributor Author

catalinghita8 commented Feb 17, 2019

Hi @pwittchen,
I completely missed the coding style - my bad on that - thus adjusted the changes properly now so you can review them.

Regarding adding unit tests, I am aware that I haven't added any, mainly because currently there are no unit tests (beside the basic one) and I don't want to add new dependencies (like Mockito) into the project. It usually requires some responsability and I believe that the creator should decide upon adding new dependencies as it might have repercussions on the library.

Also you might decide enforcing some style for the tests as well. Therefore, once you review the code and decide on including some basic tests, I will be more than glad to write some - following your pattern - for this feature as well.

All the best,
Catalin

@pwittchen
Copy link
Owner

pwittchen commented Feb 17, 2019

Hi,

Thanks for update. Can you squash your commits into one? It'll be easier to view changes in the PR and git history will be organized better. You can use this tool: http://rebaseandsqua.sh/.

Regarding unit tests, you're right. This project unfortunately has poor tests. I usually add them in my projects, but I didn't have more time to work on that in this case, so we can skip tests in your PR and test infrastructure/configuration can be improved later.

@catalinghita8
Copy link
Contributor Author

catalinghita8 commented Feb 17, 2019

Thanks for the feedback. Just rebased and squashed that redundant commit. Now it should be easier to read.

Catalin

* @param sensorTypes sensor type from Sensor class from Android SDK
* @return RxJava Observable with ReactiveSensorEvent
*/
public Flowable<ReactiveSensorEvent> observeSensors(final int samplingPeriodInUs,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rename this method to e.g. observeManySensors - observeSensor and observeSensors looks similar and it's easy to make a mistake while using such API.

StringBuilder errorMessage = null;
for (int sensorType : sensorTypes) {
if (!hasSensor(sensorType)) {
if (errorMessage == null) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, it can be simplified like that:

if(errorMessage == null) {
  errorMessage = new StringBuilder("Following sensors are not available on current device: ");
}

errorMessage.append(sensorType);
errorMessage.append(" ");

In such case, else block could be skipped.

* @param sensorTypes sensor types array from Sensor class from Android SDK
* @return RxJava Observable with ReactiveSensorEvent
*/
public Flowable<ReactiveSensorEvent> observeSensors(final int samplingPeriodInUs,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method has around ~50 lines of code. It's too many. Please, try to split it into smaller methods, so the max length of the single method will have 20 lines of code or less.

@pwittchen
Copy link
Owner

Thanks for that. I had a few issues in the code review. Please have a look at them.

@catalinghita8
Copy link
Contributor Author

@pwittchen apologies for the late response and cheers for the constructive suggestions!

Refactored the multiple sensor observing method naming as well as the the method's content in cause.
Extracted the error message creation outside of the main method, thus reducing the size from ~50 to ~30 lines.

Extra:
As you requested the method to be under ~20, I will have to insist in keeping it to the actual size. Any further trimming by extracting essential pieces of the code that make sense in the method's context, would result in external methods that have no modular actions or even meaning.
While I agree methods should not be large and should be kept as minimal as possible, please note that the observeSensor has ~30 lines itself, thus I see no valid points in reducing the observeMultipleSensors to under 30 lines.

@pwittchen
Copy link
Owner

pwittchen commented Apr 27, 2019 via email

@catalinghita8
Copy link
Contributor Author

Thanks, I'll have a look at it in one week from now. I'm away from home without my laptop now. :-)

-- Piotr Wittchen, http://wittchen.io sob., 27 kwi 2019, 15:27 użytkownik catalinghita8 notifications@github.com napisał:
@pwittchen https://github.com/pwittchen apologies for the late response and cheers for the constructive suggestions! Refactored the multiple sensor observing method naming as well as the the method's content in cause. Extracted the error message creation outside of the main method, thus reducing the size from ~50 to ~30 lines. Extra: As you requested the method to be under ~20, I will have to insist in keeping it to the actual size. Any further trimming by extracting essential pieces of the code that make sense in the method's context, would result in external methods that have no modular actions or even meaning. While I agree methods should not be large and should be kept as minimal as possible, please note that the observeSensor has ~30 lines itself, thus I see no valid points in reducing the observeMultipleSensors to under 30 lines. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFJYFZKY32RBXMSOG52JDDPSRPFRANCNFSM4GX6QKJQ .

@pwittchen Let me know if anything is needed.

@pwittchen
Copy link
Owner

pwittchen commented Jun 30, 2019 via email

@catalinghita8
Copy link
Contributor Author

@pwittchen As a follow-up, the changes you requested have been applied, I am still waiting for your actions.

@pwittchen
Copy link
Owner

Sorry, I've been quite busy, so I didn't take care of it. I'll try to push it forward soon.

@pwittchen pwittchen merged commit c599768 into pwittchen:RxJava2.x Dec 29, 2019
@pwittchen
Copy link
Owner

Changes merged. They'll be available in the next release.

I haven't released new versions of my libraries from some time.
I'll try to release them quite soon due to new updates and fresh dependencies.

@catalinghita8
Copy link
Contributor Author

@pwittchen thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Observing multiple sensors together
2 participants