Splitties Documentation

repository·main·Indexed 25 days ago

https://github.com/louiscad/splitties

A collection of small, modular Kotlin Multiplatform libraries designed to reduce boilerplate and improve productivity for Android developers. It features a modular architecture allowing users to import only specific modules, such as splitties-activities for Activity launching, splitties-appctx for safe Application Context access, and various alert dialog DSLs (Material, AppCompat, and native Android). It also includes arch-lifecycle for ViewModel instantiation and null-safe LiveData observation.

Tokens
31.7K
Snippets
55
Records
208
Agent score
82%

What's inside Splitties

  1. Introduction to Views DSL

    main

    Splitties Views DSL allows you to create Android UIs using readable Kotlin code instead of XML. It is designed as a collection of extension functions and properties rather than a new class hierarchy, making it easy to discover and use within existing Android projects.

    Key characteristics:

    • Interoperability: Seamlessly works with existing android.view.View objects and XML layouts.
    • Stability: The API is stable and built on the foundation of the standard Android View API.
    • Simplicity: You don't need to learn a new framework; you simply use extension functions to configure views.

    Example of creating a button:

    val launchDemoBtn = button {
        textResource = R.string.go_to_the_demo
    }
  2. Overview of Splitties

    main
    Splitties is a collection of small, independent Kotlin Multiplatform libraries (with Android as the primary target). The project is modularized so you can add only the specific libraries you need, helping to keep the final binary size small. It provides simplified syntax for common tasks like starting activities, showing snackbars, and managing coroutines, similar to the functionality once offered by Anko.
  3. Use Material Design list item Views

    main

    The material-lists module provides Android View implementations for Material Design list components and controls. These views are designed to be used within a RecyclerView to implement standard Material Design list patterns.

    Available list item View implementations:

    • IconOneLineListItem
    • IconTwoLinesListItem
    • IconTwoLinesSwitchListItem
    • IconTwoLinesCheckBoxListItem
    • SwitchTwoLinesIconListItem
  4. Use Selectable Views for Android

    main

    The views-selectable module provides selectable versions of LinearLayout and platform TextView. These are useful for list items or other UI elements that require visual feedback when clicked.

    They include a foregroundSelector property that behaves like the foreground property on API 23+ views. By default, this is set to android.R.attr.selectableItemBackground, which provides a ripple effect on Android Lollipop and newer versions.

  5. Explore additional Views DSL modules

    main

    The views-dsl core module can be extended with specialized modules to provide support for specific Android components and styling systems:

    • AppCompat: Provides proper styling for standard widgets like Button, TextView, EditText, and others.
    • ConstraintLayout: Adds support for ConstraintLayout.LayoutParams when laying out views.
    • IDE preview: Enables the ability to preview user interfaces directly within the IDE.
    • Material: Provides extensions specifically for Material Components.
    • RecyclerView: Provides extensions for handling scrollbars and managing proper itemView layout parameters.
  6. What is a Splitties split?

    main
    A "split" is a single module of the Splitties library. Each split only includes its required transitive dependencies, allowing you to minimize your app's size by only including what you actually use. For example, WearOS apps can use the views-dsl core module without being forced to include the heavy AppCompat library.
  7. What is checkedLazy and when to use it

    main

    The checkedlazy module provides specialized Lazy delegates that execute a validation check every time the property is accessed.

    While standard Kotlin lazy only runs the initializer once, checkedLazy runs the provided check function on every access. This is primarily used on Android to enforce thread safety (e.g., ensuring UI-related objects are only touched on the Main thread) or to catch illegal access patterns during development.

    Note: In many modern Android use cases, Kotlin Coroutines can replace the need for these specific splits.

  8. Module categorization and capabilities

    main

    Splitties is organized into several functional areas. Depending on your target (Android or Multiplatform), you can use different modules:

    Android Only

    • System Interaction: appctx (Application Context), systemservices (System Services).
    • UI & User Input: snackbar, toast, alertdialog, permissions, views (and its variants like views-appcompat, views-material, views-recyclerview), views-dsl (for building UIs with Kotlin DSL), resources, dimensions, views-selectable, typesaferecyclerview, material-colors, material-lists.
    • Communication: activities, intents, fragments, fragmentargs, bundle.
    • Concurrency: lifecycle-coroutines, mainthread, mainhandler, checkedlazy.
    • Debugging & Legacy: stetho-init, exceptions, arch-lifecycle.

    Multiplatform

    • Concurrency: coroutines.
    • Data Persistence: preferences (supports Android SharedPreferences/DataStore and macOS/iOS/watchOS NSUserDefaults), arch-room.
    • Utilities: bitflags, collections.
  9. Use the ConstraintLayout tailored lParams() extension

    main

    The lParams() extension function on ConstraintLayout provides a DSL for defining child layout parameters. It differs from LinearLayout or FrameLayout extensions in two ways:

    1. Default Dimensions: The default width and height are set to matchConstraints instead of wrapContent. You must explicitly set height = wrapContent for components like TextView or Button if you don't want them to stretch.
    2. Optimized matchParent: Using matchParent is automatically rewritten as matchConstraints with the appropriate parent-relative constraints. This avoids the performance penalties associated with using match_parent in XML-based ConstraintLayout.
  10. How Splitties Views DSL differs from Anko layouts

    main

    Splitties was designed as a lighter, more explicit, and more modular alternative to Anko. While Anko requires specific subclasses for every View used in a layout and implicitly adds views to a ViewGroup, Splitties avoids these patterns to provide more flexibility and prevent common layout mistakes.

    Key differences include:

    • No required subclasses: Unlike Anko, Splitties does not require a specialized subclass for each View. You can use any view by passing its constructor reference to the view function.
    • Explicit View addition: Splitties never adds a View implicitly. You must always supply LayoutParams to the add function, which prevents the common issue of forgetting to specify layout parameters.
    • Modular architecture: While Anko commons requires importing the entire library to use even a single helper, Splitties is highly granular. You can include only the specific modules you need (e.g., Splitties Intents without Splitties Fragment Args), keeping your application size smaller.
  11. Understand the `Ui` interface concept

    main

    The Ui interface is a core abstraction in Splitties Views DSL designed to decouple UI code from business logic (like Activity or Fragment classes). Instead of writing UI logic inside a 'god' class, you implement the Ui interface in a dedicated class. This promotes modularity, makes testing easier, and allows for easy A/B testing or multi-form factor support by swapping implementations of the same interface.

    The interface consists of two mandatory properties:

    • ctx: The Context required to create Android Views.
    • root: The top-level View that represents the UI hierarchy.

    By using interfaces to define UI contracts, you can separate the what (the symbols exposed to the controller) from the how (the specific View-based implementation).

    interface Ui {
        val ctx: Context
        val root: View
    }
  12. Iterate over Lists without Iterator allocation using Splitties Collections

    main

    The splitties-collections module provides extension functions for List that allow iteration without allocating an Iterator object. This is specifically designed for performance-critical scenarios, such as code executed within an onDraw method or code running on the UI thread.

    Available extension functions:

    • forEachByIndex: Iterates through the list providing only the index.
    • forEachWithIndex: Iterates through the list providing both the index and the element.
    • forEachReversedByIndex: Iterates through the list in reverse order providing only the index.
    • forEachReversedWithIndex: Iterates through the list in reverse order providing both the index and the element.