Weekly PR's Week 4: Dependency Injection & Obsidian Organization

Hello There! Each week I try to write about the interesting stuff I dabble with whether it’s programming related or not, purely for self entertaintment purposes. Feedback is most welcome!

What This Week is About

This week I want to talk a bit about dependency management. We use Dagger at work for injection dependencies to the Android application I’m working on. While it would be best to migrate to Hilt as it simplifies the whole process across the application, I wanted to learn the internals of the Dagger as well. Also, I wanted to talk a bit about Obsidian, a note taking app that I’ve been using over a year. And while I aim to keep my digital tool stack simple, this app slowly becomes the single point of failure in my note system. also couple of extra small things as well.

Working with Dagger and Hilt

Over the last week, I learned the internals of how dagger works inside an Android Project and how we can better leverage from it. The new recommended solution for Dependency injection is Hilt. But the Hilt is built on top of the dagger and I wanted to learn how things work under the hood.

In my opinion, you don’t need DI solutions for simple personal projects that won’t change with time, especially not Dagger. But as the app grows and reusability and swapping dependencies becomes necessary for testing, it is a necessary evil.

There is a potential downside of code generation of Dagger leverages. As the app grows, the code required to build the injection graph for the app will grow and it will become a definite bottleneck in your application build time. But for what it does and what it provides in the long run. It is a justified tradeoff. At least for now.

Main Keywords

I think understanding what Dagger does by looking at a project that uses dagger is harder than building a graph in the simple application. The main keywords for most of what dagger does are component,scope, module, inject, provides and binds. If we summarize what these are and what they are responsible for:

• Component: Annotation to mark a class or interface that It will provide certain dependencies. Can be marked with scopes. Component that has the singleton scope and does not have any dependency becomes the entry point to the injection graph.
• Scope: Lifecycle annotation. There are predefined ones like Singleton. Or you can define new ones based on the usecase of your app. It says to Dagger how long the objects should be kept alive.
• Module: Extra class or object that provides additional information to the components. Each component may have multiple modules.
• Inject: Annotation used to let Dagger know how can a specific class can be instantiated. Also can be used to define the dependency in the class.
• Provides: Used for dependencies that Dagger can’t create. Usually used for third party objects in your application that needs manual creation. You provide how to create an instance to Dagger
• Binds: Used for connecting to interfaces to their respective implementations. Most common use case is to define a specific data layer interface and create separate implementations. The alternate implementation might include another Library (Google vs Huawei library depedency) or might be used for testing purposes (Fake Repository implementations)

Simple Use case

Let’s say that we have an Android Application with one activity. For the application wide dependencies we can create an ApplicationComponent. For each Activity we can crete a distinct ActivityComponent. AppComponent can be responsible for objects that will be kept alive as long as the app is in use, while the ActivityComponent can provide instances for each activity. Since the Activities can contain multiple fragments (therefore multiple screens), providing activity specific dependencies can be organized in this manner.

@Singleton
@Component(modules = [AppModule::class])
interface AppComponent {
	fun Application(): Application
	fun Context(): Context
}

@Module
class AppModule(val application: Application) {
	@Provides 
	fun provideApplication() = application
}

@ActivityScope
@Component(depedencies = [AppComponent::class], modules = [ActivityModule::class])
interface ActivityComponent {
	fun context() : Context
}

@Module
class ActivityModule(val activity: AppCompatActivity) {
	@Provides
	fun provideContext() = activity.context
}

Example above is basic graph creation for an Android application. There are other concepts like subcomponents, multiple bindings and creating specific scopes for the components. I might write a longer version for this topic and explore further.

Using Obsidian as a Organization Tool

Obsidian is markdown editor that supports wikilink style backlinking. It provides a simple canvas to work on and offers much, so much more via its plugins. The community of developers that creates the various plugins give Obsidian its true advantage.

I started to use Obsidian mainly as a note taking tool because I am very used to writing with markdown and I wanted something that doesn’t use my data, content wise. One year and couple of hundred notes later. I use it to write these newsletters (using Longform Plugin), keep track of the projects that I’m working on (using Kanban Plugin) and keep all my writing here (Templater plugin, daily notes, Calendar and lots more).

![[Pasted image 20220123150103.png]] Current State of my notes

Honestly I am very tempted to ditch TickTick and use Obsidian as a task manager on top of everything else but I think It is better to separate those two things for longevity.

Book Update: Creativity Inc

I diverted from my original plan and decided to start to read Creativity Inc . It’s been on my reading list for a while (since 2021) and it’s been popping up on the top of my ereader constantly so now you know how I choose what to read. The Economics 101 was similar to economics text book but better in terms of explaining the main concepts and their connections. I didn’t see the need of summarizing that book but I am thinking of a format for key insights for the books I’ve read in 2022. Another potential idea that I will force myself to realize it. Great.

Conclusion

I guess I can conclude this week’s pull request. See you around next week.