Verdict

“A reusable base class can cut duplication, but coupling it to Compose UI state breaks MVVM and threatens durability.”

The proposed BaseAutoCompletableViewModel introduces a reusable abstraction that centralises auto‑complete logic, which can reduce duplication across features such as TTS voice selection and contact lookup. This addresses a clear need that existing UI components (e.g., Material AutoComplete, Accompanist Dropdown) do not expose in a type‑safe, model‑agnostic way. However, the implementation violates core MVVM principles: it stores UI‑specific state (searchText, selection, dropdown open) inside the ViewModel using Compose‑specific mutableStateOf, tying the ViewModel to the UI layer and breaking the separation between business logic and presentation. Moreover, the toViewString method performs formatting that could be considered view‑layer concerns, further blurring the boundary. While the differentiation is real in terms of code reuse, its durability is questionable because any future shift away from Compose or to a different UI framework would require substantial refactoring of the ViewModel. Competitors such as Google’s Material AutoComplete, the Accompanist Dropdown library, and Jetpack Compose’s built‑in DropdownMenu already provide robust, state‑managed auto‑complete solutions, meaning the market is not empty. Consequently, the idea scores a moderate 6: it offers tangible reuse benefits but the architectural coupling limits its long‑term viability.

“While not a strict violation, `toViewString()`'s use in the View for display text slightly blurs MVVM lines, potentially impacting maintainability.”

The use of `BaseAutoCompleteViewModel.toViewString()` in both the ViewModel and the View does not strictly violate MVVM principles, as it primarily handles data transformation rather than business logic or direct UI manipulation. However, its invocation in the View for generating display text (`displayText = viewModel.toViewString(voiceInfoModel)`) blurs the line, as this could be seen as a presentation concern. Ideally, in a strict MVVM setup, such transformations might be expected to occur within the View or a separate Formatting/Utility layer to keep the ViewModel focused on data and business logic. The current implementation's impact is more about maintainability and clarity than a hard violation, especially since the transformation is relatively simple and not tied to complex UI logic. Score reflects the minor deviation and potential for future maintainability issues if the transformation logic becomes more complex or UI-dependent.

“Presentation logic in the ViewModel is a gray area, but it’s acceptable if it’s minimal and doesn’t couple the ViewModel to UI concerns.”

Your use of `BaseAutoCompletableViewModel.toViewString()` does not fundamentally violate MVVM principles, but it does blur the separation of concerns slightly. In MVVM, the ViewModel should expose data and state, while the View handles presentation logic. Here, `toViewString()` is a presentation concern (formatting data for display), which ideally belongs in the View or a dedicated presentation layer (e.g., a formatter utility). However, the violation is minor because: (1) The ViewModel still owns the data and logic for filtering/selection, (2) The View remains declarative and reactive to state changes, and (3) The method is abstract, allowing subclasses to define presentation rules. The bigger risk is maintainability: if `toViewString()` evolves to include complex formatting (e.g., localization, theming), it could bloat the ViewModel. Refactoring to use `strings.xml` is a good step toward better separation, but consider moving string formatting entirely to the View or a dedicated resource layer.

“ViewModels should expose data, not UI formatting logic — embedding string rendering rules like toViewString() violates MVVM’s core separation of concerns and creates technical debt.”

Your BaseAutoCompletableViewModel design is technically sound and reusable across use cases like TTS, contacts, and notifications — but it violates core MVVM principles by tightly coupling view logic (string formatting, UI presentation) into the ViewModel. MVVM requires ViewModels to expose state and commands, not UI-specific rendering logic like toViewString() or toSourceString(). These methods embed presentation concerns (e.g., font weight, color, line breaks, annotation tags) into business logic layers, making the ViewModel dependent on Compose-specific APIs and UI semantics. This breaks separation of concerns: the ViewModel should not know how a voice model’s name should be styled or annotated. Instead, the ViewModel should expose raw data (e.g., voiceName, displayName, category), and the Composable should handle all formatting. This also creates maintenance debt: if you later switch from Compose to another UI framework, you’ll need to rewrite these methods. Furthermore, your use of toViewString() in the view layer (via onGetAnnotatedString) confirms the logic is already being duplicated or overridden at the UI level, making the ViewModel method redundant. The refactoring to strings.xml further exposes this flaw — localized strings belong in resources, not hardcoded in ViewModel methods. This architecture may work today, but it’s brittle, untestable, and non-portable. The audience — Android developers building scalable apps — will recognize this as an anti-pattern that undermines maintainability.

“The `toViewString()` method is a valid part of the view model as it transforms data for the view, but additional data transformation in the composable function blurs the line between view and view model responsibilities.”

The use of `BaseAutoCompleteViewModel.toViewString()` does not inherently violate MVVM principles as it is used for transforming data into a view-friendly format. However, its invocation in both the view model and the view might raise concerns about separation of concerns. In MVVM, the view model is responsible for exposing the data and functionality in a form that is easily consumable by the view. The `toViewString()` method serves this purpose by converting the model data into a string suitable for display. The fact that it's abstract and defined in the view model layer is correct. The issue arises when considering the additional processing done in the composable function, such as building an annotated string. This could be seen as view logic, but it also involves data transformation. A more strict adherence to MVVM might suggest that the view model should expose a more ready-to-display format, potentially reducing the need for complex transformations in the view. Nonetheless, the current implementation is not a significant violation of MVVM principles, especially considering the context of Jetpack Compose where composable functions are designed to be flexible and handle UI logic. The key is ensuring that business logic remains in the view model.