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

Refactor NimBLEAdvertisementData/NimBLEExtAdvertising #274

Closed
wants to merge 1 commit into from

Conversation

thekurtovic
Copy link
Collaborator

@thekurtovic thekurtovic commented Dec 21, 2024

  • NimBLEUtils added method to get UUID type from size.
  • NimBLEUtils added method to get service data UUID type from size.
  • NimBLEUUID added method to get location within payload.
  • NimBLEUUID added method as wrapper for NimBLEUtils::getUUIDType().

@h2zero
Copy link
Owner

h2zero commented Dec 21, 2024

Thanks! Good idea, I think changing the name to getUUIDType might be more appropriate?

@thekurtovic
Copy link
Collaborator Author

thekurtovic commented Dec 21, 2024

Done.
I thought it would be cleaner to move it into NimBLEUUID, but there were some other cases which didn't depend on a NimBLEUUID object, so I kept it in NimBLEUtils but created a wrapper.
Also moved some duplicate code and created NimBLEUUID::getLoc.

@thekurtovic thekurtovic force-pushed the misc-clean-up branch 3 times, most recently from 2164ed0 to ae270ac Compare December 22, 2024 00:48
@thekurtovic thekurtovic changed the title NimBLEUtils add method to get advertising type from UUID byte size. Refactor NimBLEAdvertisementData/NimBLEExtAdvertising Dec 22, 2024
@thekurtovic thekurtovic force-pushed the misc-clean-up branch 2 times, most recently from 1d504bf to 133a242 Compare December 27, 2024 16:17
* NimBLEUtils added method to get UUID type from size.
* NimBLEUtils added method to get service data UUID type from size.
* NimBLEUUID added method to get location within payload.
* NimBLEUUID added method as wrapper for NimBLEUtils::getType().
Copy link
Owner

@h2zero h2zero left a comment

Choose a reason for hiding this comment

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

I like the consolidation idea, I think another approach may be better though.

I'm thinking these utility functions belong more in the advertising data class and that extended advertising should use or inherit from the class to keep the code all in one place to reduce the duplication.

return 0;
}
} // getServiceType

Copy link
Owner

Choose a reason for hiding this comment

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

Since the return value of these only relates to and is only used for advertising I feel they would be better placed in the advertising classes.

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 we should also rename getServiceType to getServiceDataType

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good points

}
return -1;
} // getLoc

Copy link
Owner

Choose a reason for hiding this comment

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

I'm not sure these belong in the uuid class since the type returned is an advertisement uuid type and not the actual uuid type and getLoc probably isnt useful outside of advertising data. Not sure what the use case is as a public API.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Admittedly this one didn't really make sense to me, but was purely in the pursuit of avoiding duplicate code. I put it in NimBLEUUID since the snippet was accessing accessing a UUID object originally.
Has no business being public really.

@thekurtovic
Copy link
Collaborator Author

I had considered the same, and thought that would be more appropriate but didn't want to go down that route in case you had any objections to a big change.
I can close this PR if you'd prefer to refactor with inheritance.

@h2zero
Copy link
Owner

h2zero commented Jan 3, 2025

Since this isn't really essential at the moment I think it best to refactor with the larger scale approach so the changes make more sense to the overall classes. Not sure yet if inheritance is the best approach or if the extended advertising class should just have a member variable of NimBLEAdvertisingData.

@thekurtovic thekurtovic closed this Jan 3, 2025
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.

2 participants