# Integration verbosity and good layering

DevFeed: [Integration verbosity and good layering](<https://devfeed.tech/articles/integration-verbosity-and-good-layering-20941.md>)

Original publisher: [Read original article](<https://jakewharton.com/integration-verbosity-and-good-layering/>)

Published: 2021-04-07T00:00:00Z

Content type: article

Language: en

Sources: [Jake Wharton](<https://devfeed.tech/sources/jake-wharton.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [XML](<https://devfeed.tech/topics/xml.md>), [Dagger](<https://devfeed.tech/topics/dagger.md>), [SQLite](<https://devfeed.tech/topics/sqlite.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [dagger](<https://devfeed.tech/tags/dagger.md>), [dependency](<https://devfeed.tech/tags/dependency.md>), [design](<https://devfeed.tech/tags/design.md>), [env-file-security](<https://devfeed.tech/tags/env-file-security.md>), [integrations](<https://devfeed.tech/tags/integrations.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [net-conf](<https://devfeed.tech/tags/net-conf.md>)

## AI overview

The article argues that integration verbosity can be a consequence of good layering. General-purpose libraries such as view binding, Dagger, SQLDelight, and RecyclerView must leave higher-level integration and configuration decisions to their callers, enabling more flexible libraries and platforms.

## Source excerpt

One of my favorite non-features from building view binding is that it lacks integration with activities or fragments. If you use view binding with activities or fragments, however, this fact might be to your disdain. Every activity using view binding is forced to do something along the lines of: override fun onCreate(savedInstanceState: Bundle) { super.onCreate(savedInstanceState) val binding = ProfileViewBinding.inflate(layoutInflater) setContentView(binding.root) // Do stuff with 'binding' } This is textbook verbosity, and some would argue boilerplate. It only gets worse with fragments (due to their poor design and to no specific fault of view binding which works the same as any View reference). View binding exists at a different layer of abstraction than is appropriate for integration with higher-level components like activities or fragments. It serves as a type-safe representation of a schema declared in an XML file and that's it. It has no more knowledge of activities and fragments than the associated R.layout.profile_view integer does. Higher-level libraries like androidx.activity and androidx.fragment have integrations with those R.layout integers. If you're upset that view binding has no turn-key solution for activities and fragments then this is the tree you should be barking up. View binding wasn't built with verbosity in mind. Hell, it's not even that verbose. It ended up this way because it's the design the layer of abstraction it operates at demands. The same pattern occurs in some of my other favorite libraries. Dagger offers you nothing and requires that you build up the dependency injectors, their hierarchy, and their lifecycle entirely yourself. SQLDelight makes you specify database info in the build configuration and a database driver in the runtime API. RecylerView requires at minimum an adapter subtype and to choose and configure a layout manager. The layer at which these tools operate is sufficiently general such that their good design requires