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

Target SiriIntents: Split IntentHandler into smaller files (#6203) #6365

Merged
merged 18 commits into from
Jul 6, 2022
Merged

Target SiriIntents: Split IntentHandler into smaller files (#6203) #6365

merged 18 commits into from
Jul 6, 2022

Conversation

wtimme
Copy link
Contributor

@wtimme wtimme commented Jun 30, 2022

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.

Screenshot 2022-06-30 at 21 29 37

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

  • I read the contributing guide
  • UI change has been tested on both light and dark themes, in portrait and landscape orientations and on iPhone and iPad simulators
  • Accessibility has been taken into account.
  • Pull request is based on the develop branch
  • Pull request contains a changelog file in ./changelog.d
  • You've made a self review of your PR
  • Pull request includes screenshots or videos of UI changes
  • Pull request includes a sign off

@codecov-commenter
Copy link

codecov-commenter commented Jun 30, 2022

Codecov Report

Merging #6365 (6e761f8) into develop (730eafc) will increase coverage by 0.02%.
The diff coverage is n/a.

@@             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     
Impacted Files Coverage Δ
...SplashScreen/OnboardingSplashScreenViewModel.swift 11.53% <0.00%> (-42.31%) ⬇️
...les/Common/UserIndicators/UserIndicatorStore.swift 27.50% <0.00%> (-20.33%) ⬇️
...Modules/Common/ViewModel/StateStoreViewModel.swift 30.55% <0.00%> (-19.45%) ⬇️
...dules/Common/SwiftUI/VectorHostingController.swift 71.87% <0.00%> (-8.13%) ⬇️
...Common/UserIndicators/UserIndicatorPresenter.swift 8.88% <0.00%> (-4.45%) ⬇️
...ing/SplashScreen/View/OnboardingSplashScreen.swift 54.66% <0.00%> (-4.00%) ⬇️
Riot/Managers/Settings/RiotSettings.swift 87.82% <0.00%> (-2.36%) ⬇️
Riot/Modules/Application/AppCoordinator.swift 51.67% <0.00%> (-1.60%) ⬇️
Riot/Modules/TabBar/TabBarCoordinator.swift 30.24% <0.00%> (-1.24%) ⬇️
Riot/Modules/SplitView/SplitViewCoordinator.swift 34.64% <0.00%> (-1.05%) ⬇️
... and 27 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 730eafc...6e761f8. Read the comment docs.

@pixlwave pixlwave self-requested a review July 1, 2022 14:26
Copy link
Member

@pixlwave pixlwave left a 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 {
Copy link
Member

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.

Suggested change
withCompletion:(void (^)(NSArray<INPersonResolutionResult *> * _Nonnull))completion {
withCompletion:(void (^)(NSArray<INPersonResolutionResult *> * _Nonnull))completion
{

Copy link
Contributor Author

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.

Copy link
Member

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.


- (instancetype)init {
if (self = [super init]) {
_contactResolver = [[ContactResolver alloc] init];
Copy link
Member

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?

Copy link
Contributor Author

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 a strong reference, so the IntentHandler does not need to manage the instance of ContactResolver
  • Add a singleton property (ContactResolver.shared) to ContactResolver

What is your preference? Is there a fourth option that is even better? Thanks in advance for your input!

Copy link
Member

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

@wtimme
Copy link
Contributor Author

wtimme commented Jul 2, 2022

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

Copy link
Member

@pixlwave pixlwave left a 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];
Copy link
Member

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 {
Copy link
Member

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.

wtimme and others added 2 commits July 5, 2022 12:45
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>
…zation

In #6365, @pixlwave pointed out that

> If the resolver ever gained a cache or stored properties it would
> help keep the memory usage down in the extension
@wtimme
Copy link
Contributor Author

wtimme commented Jul 5, 2022

BTW, I don't think this one was resolved by your last commit.

My bad, I am still getting used to batch-commits in GitHub's pull request process.

I would lean towards option 2 in this instance.

I have adjusted the code accordingly.

Let me know if there's anything else I can do to further this pull request.

Copy link
Member

@pixlwave pixlwave left a 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.

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.
Copy link
Member

@pixlwave pixlwave left a 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 😎

@pixlwave pixlwave merged commit 2babca6 into element-hq:develop Jul 6, 2022
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.

3 participants