inject repository using hilt

[violoncelloCH]

based on #32
requires #32 to be merged first done

this allows to use use the main repository implementation without passing it manually

[violoncelloCH]

@octogradiste I tried to add the dependency injection following what you've done in #26, but somehow it throws an error on the test. Do you have an idea where that comes from?

Error log output

/home/runner/work/echo/echo/app/build/generated/hilt/component_sources/debugAndroidTest/dagger/hilt/android/internal/testing/root/Default_HiltComponents.java:136: error: [Dagger/MissingBinding] com.github.swent.echo.data.repository.Repository cannot be provided without an @Inject constructor or an @Provides-annotated method.
  public abstract static class SingletonC implements EchoApplication_GeneratedInjector,
                         ^
  
  Missing binding usage:
      com.github.swent.echo.data.repository.Repository is injected at
          com.github.swent.echo.di.DependencyInjectionTest.repository
      com.github.swent.echo.di.DependencyInjectionTest is injected at
          com.github.swent.echo.di.DependencyInjectionTest_GeneratedInjector.injectTest(com.github.swent.echo.di.DependencyInjectionTest)

the original CI run can be found on #28 (this PR here is incomplete)

[octogradiste]

Hi, I checked out the code and the reason for the error is, hilt can't inject the Repository into the test because you have told hilt how to provide an IRepository but not how to provide a Repository. What you have done is correct! We want to tell hilt how to provide an interface, so that when we are coding the logic, we don't have to think about a concrete implementation but rather of an interface. To fix the error, you could change the type to IRepository inside the test...

But what I suggest is to change the naming of your interface to Repository and the implementation to RepositoryImpl. This is how I already did it for the AuthenticationService and I really like this convention. I think it avoids confusion for the one using the interface. In this case, it actually confused you too. :)

[octogradiste]

Note that the renaming will also affect #32 and #30

[violoncelloCH]

Ohh thanks, now I get it!
Well for me the confusion was actually the other way round. I'm used to the convention of having the interfaces prefixed by I. So when looking at you have done the test, I actually thought you were passing in the implementations and not the interfaces 🙃 . For me the prefixing with I actually makes a lot of sense especially in situations like these where we have only one implementation anyways. Also, we have got other classes where there just is no interface, so in these cases we also do not suffix them with Impl.
But in the end I guess it's just a matter of conventions and of course it makes sense to choose one of them. Not sure if that's worth to quickly discuss with everyone to vote on what the majority prefers?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[octogradiste]

LGTM, thanks for adding this!