-
Notifications
You must be signed in to change notification settings - Fork 503
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
Target SiriIntents
: Split IntentHandler
into smaller files (#6203)
#6365
Target SiriIntents
: Split IntentHandler
into smaller files (#6203)
#6365
Conversation
Nothing has changed about the implementation itself; this prepares the separation of this logic into a dedicated unit.
…6203) In `init()`, there might be some configuration being done that is required for the handlers.
Codecov Report
@@ Coverage Diff @@
## develop #6365 +/- ##
===========================================
+ Coverage 6.19% 6.21% +0.02%
===========================================
Files 1440 1444 +4
Lines 155105 155530 +425
Branches 62362 62500 +138
===========================================
+ Hits 9608 9672 +64
- Misses 145093 145453 +360
- Partials 404 405 +1
Continue to review full report at Codecov.
|
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.
Looking good to me, thanks for the PR. A couple of style comments and a question inline, otherwise nothing major.
Altogether, this restructuring brings the number of lines for IntentHandler down from 450 to 92.
Niiice 😎
@implementation ContactResolver | ||
|
||
- (void)resolveContacts:(nullable NSArray<INPerson *> *)contacts | ||
withCompletion:(void (^)(NSArray<INPersonResolutionResult *> * _Nonnull))completion { |
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.
Our objc style is to have {
on the next line.
withCompletion:(void (^)(NSArray<INPersonResolutionResult *> * _Nonnull))completion { | |
withCompletion:(void (^)(NSArray<INPersonResolutionResult *> * _Nonnull))completion | |
{ |
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.
Thanks for pointing that out! Nowadays, I do not spend time thinking about code formatting, since the projects that I am working on usually have automatic code formatting set up. Maybe that's something that could be incorporated into this repository, even though the Objective-C code will likely be discarded once Element-X sees mass adoption.
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 that would be nice. We're currently adding swiftformat to ElementX which should make life much better over there!
BTW, I don't think this one was resolved by your last commit.
SiriIntents/IntentHandlers/SendMessage/SendMessageIntentHandler.m
Outdated
Show resolved
Hide resolved
|
||
- (instancetype)init { | ||
if (self = [super init]) { | ||
_contactResolver = [[ContactResolver alloc] init]; |
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.
Do you think it makes sense to have multiple contact resolvers, or might it be an idea to create one in IntentHandler
to pass into the initialisers?
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.
Thanks for the question! There are three options that I see:
- Let every intent handler have their own instance of
ContactResolver
(as is the case in this branch right now) - Let the
IntentHandler
create one single instance and pass it to the intent handlers during initialization. The intent handlers keep astrong
reference, so theIntentHandler
does not need to manage the instance ofContactResolver
- Add a singleton property (
ContactResolver.shared
) toContactResolver
What is your preference? Is there a fourth option that is even better? Thanks in advance for your input!
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.
I would lean towards option 2 in this instance. If the resolver ever gained a cache or stored properties it would help keep the memory usage down in the extension (very early optimisation, I know 😅).
SiriIntents/IntentHandlers/StartAudioCall/StartAudioCallIntentHandler.m
Outdated
Show resolved
Hide resolved
SiriIntents/IntentHandlers/StartVideoCall/StartVideoCallIntentHandler.m
Outdated
Show resolved
Hide resolved
Do you have an idea why the SonarCloud analysis might be failing, @pixlwave? I had a look at the coverage reports, but they indicate a decrease in files that my commits did not touch. 🤷 |
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.
Do you have an idea why the SonarCloud analysis might be failing, @pixlwave? I had a look at the coverage reports, but they indicate a decrease in files that my commits did not touch. 🤷
Ah don't worry about those. SonarCloud isn't configured for external repos so it fails due to a missing secret. And the test coverage is new on EI - from what I can guess, it fluctuates based on how long the splash screen is shown for whilst the tests are running.
|
||
- (instancetype)init { | ||
if (self = [super init]) { | ||
_contactResolver = [[ContactResolver alloc] init]; |
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.
I would lean towards option 2 in this instance. If the resolver ever gained a cache or stored properties it would help keep the memory usage down in the extension (very early optimisation, I know 😅).
@implementation ContactResolver | ||
|
||
- (void)resolveContacts:(nullable NSArray<INPerson *> *)contacts | ||
withCompletion:(void (^)(NSArray<INPersonResolutionResult *> * _Nonnull))completion { |
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 that would be nice. We're currently adding swiftformat to ElementX which should make life much better over there!
BTW, I don't think this one was resolved by your last commit.
This ensures that the code follows the style that is present in other Objective-C files. Co-authored-by: Doug <6060466+pixlwave@users.noreply.github.com>
My bad, I am still getting used to batch-commits in GitHub's pull request process.
I have adjusted the code accordingly. Let me know if there's anything else I can do to further this pull request. |
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.
Thanks for the updates. I've added one last comment that I missed during the previous review, otherwise I'm happy to merge this.
SiriIntents/IntentHandlers/SendMessage/SendMessageIntentHandler.h
Outdated
Show resolved
Hide resolved
Per @pixlwave, this helps prevent build failures: > We had random cycle errors while building a while back and it was > eventually solved by removing all imports of `GeneratedInterface-Swift.h` > in every [Objective-C header] file.
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.
LGTM, thanks for the contribution 😎
Introduction
This branch splits the
IntentHandler
and moves the functionality into dedicated classes.This makes the code easier to read and maintain, and prepares the structure to add unit tests.
The intent handlers depend on
ContactResolving
, a protocol for what was previously a private method. By moving the shared functionality to this dedicated class, the dependency can later be injected and mocked for unit tests. As for the implementation of the handlers, I have merely moved the code to another place.Altogether, this restructuring brings the number of lines for
IntentHandler
down from 450 to 92.Signed-off-by: Wolfgang Timme element-signoff@milchbartstrasse.de
Pull Request Checklist