Review Public API

Our current API is working fine for our needs, but we may be able to improve it aiming to reduce cognitive load of developers using the library for the first time. For example, instead of multiple annotations we could come up with a couple of annotations and make the compiler smarter enough to understand what type is annotating.

The following proposal recommends:

// Members Injection.

@ContributesAndroidInjection
class MyApplication : Application() {
    fun onCreate() {
        Whetstone.inject(application = this)
    }
}

@ContributesAndroidInjection
class MyActivity : Activity() {
    fun onCreate() {
        Whetstone.inject(activity = this)
    }
}

@ContributesAndroidInjection
class MyService : Service() {
    fun onCreate() {
        Whetstone.inject(service = this)
    }
}

// Constructor Injection.

@ContributesAndroidBinding
class MyFragment @Inject constructor() : Fragment()

@ContributesAndroidBinding
class MyViewModel @Inject constructor() : ViewModel()

@ContributesAndroidBinding
class MyWorkManager @Inject constructor() : WorkManager()

For cases where “injection” is not required:

Whetstone.install(application = this)
Whetstone.install(activity = this)

As you can see, we can pretty much infer the target type and reduce all features to a couple of annotations: ContributesAndroidInjection for members injection and ContributesAndroidBinding for constructor injection (by using assisted injection).

We could also validate by type on the compiler level and by including a custom lint rule.

[kingsleyadio]

Update: Currently, we have specialized annotations for different components. E.g ContributesFragment, ContributesViewModel, etc We also recently switched to automatic discovery of these annotations, so we don’t have to hard code them in the compiler The approach to discovery is as follows (simplified):

• Collect all project classes
• Retrieve their annotations
• Check if any of these annotations have the AutoScopedBinding meta-annotation
• Read all necessary configuration from there and proceed with codegen accordingly

Checking for meta-annotation requires loading the annotation class type, which is a little more expensive that simply reading the AST of the annotated class

Now, the proposal in this issue takes a different direction, and follows this (simplified):

• Collect all project classes
• Filter for those that have specific annotations: ContributesAndroidInjection, ContributesAndroidBinding
• Recursively find the supertype of these classes by loading each intermediate one, until we find known types: Fragment, Activity, Service, etc. This is the most important step to be able to figure out to which scope/component the generated code should belong
• Collect predefined configuration for these types and proceed with codegen accordingly

This makes all the difference For (1), there’s only a finite set of unique annotations, and we can cache the necessary info from any previously loaded one. However, loading full classes and their super types doesn’t lend themselves so much to caching (again loading types is more expensive that reading source AST). Best case, no need to do any loading if a class directly extends any of the known types. Worst case, a significant amount of super class loading until we finally get to the known types or nothing (we should always fail in case of nothing)

It’s a classic performance vs UX problem 😄

Given these concerns, we’d like some external opinions to give insight into potential use cases so that we can have a wholistic view that would help us make the most informed decision

[kingsleyadio]

Closing as won’t do. An alternative solution is now implemented in #60