Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Improve characteristic interactions #151
Improve characteristic interactions #151
Changes from 24 commits
9469199
3bd5d74
f1904d0
96b5e05
ff36d52
d891a68
6eacfe1
91860ef
d324467
b6641fa
ce7a768
4835725
7472d41
b551c7c
fa55978
cb8915a
54dc667
6959861
2934ea8
4a9c320
edd3a8a
1c58d4b
ae68984
000d1e1
9f7bfc4
e6bca74
016e68f
9577581
39ed273
c924901
23b13fb
1faee8d
5fe0463
a6d1738
49d1991
ccbab50
00f2d0d
2e2984c
3ec80b5
394cba9
1d49296
9ff71f1
adb1c9b
3603109
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could be incorporated into a method in the GapConfig?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I didn't do that was because if the user attempted to create a second GapConfig then it would panic. Admittedly this implementation would panic if the user attempted to create a second instance of the type decorated with
#[gatt_server]
, but that would happen anyway due to the characteristic data stores.If a user is only ever going to create one GapConfig then moving this code to a GapConfig method removes some duplicate code, which I'm always for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a6d1738
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, being able to create multiple instances of a
#[gatt_server]
will likely come up in some applications. I'd suggest just putting an ownedheapless::String
directly in theGapConfig
so you don't have to worry about lifetimes.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah interesting - we were discussing this earlier and thought that creating multiple
#[gatt_servers]
in the same application wouldn't be required.In that case I will need to revert a6d1738 as it will not allow for a second
GapConfig::Peripheral
to be made (whereas previously you could make as manyGapConfigs
as you desired but could only create one instance of a particular#[gatt_server]
(but declaring a second#[gatt_server]
and instantiating that would work fine).I notice you said "putting an owned
heapless::String
directly into theGapConfig
" rather than using a statically allocatedheapless::String
- the reason I haven't done that is that theGapConfig
only exists for a short period of time, so the user would need to hang on to theGapConfig
for the lifetime of the#[gatt_server]
.I originally tried passing ownership of the
GapConfig
to the#[gatt_server]
, but this ends up in a chicken-and-egg situation where a reference to theString
in theGapConfig
is required for the attribute, but theGapConfig
needs to be moved into the#[gatt_server]
to complete its initialisation, thus invalidating the reference. Moving theGapConfig
into the#[gatt_server]
first and then adding the attributes has the same problem, as the#[gatt_server]
is returned from the function at the end of initialisation, again causing a move and invalidating the reference.I encountered this issue a few times during the course of this work - is there a pattern to get around it without using statics?