Code to add:

import android.support.annotation.IdRes
import android.support.design.widget.TextInputEditText
import android.support.design.widget.TextInputLayout
import splitties.viewdsl.core.add
import splitties.viewdsl.core.matchParent
import splitties.viewdsl.core.wrapContent
import android.widget.LinearLayout.LayoutParams as LP

inline fun TextInputLayout.addInput(
        @IdRes id: Int,
        initView: TextInputEditText.() -> Unit = {}
) = add(::TextInputEditText, id, LP(matchParent, wrapContent), initView)

The following code fixes this issue.

val iconSize = dip(24)
add(icon, lParams(iconSize, iconSize) {
    ...
})

Should be put in all list items with a 24dp icon

With already prohibited suspension points thanks to crossinline modifier on the lambdas, this will completely rule out usage that could lead to inconsistent states

This is a subtask of #7

This is misleading and should be renamed to fragmentScope. activityScope can be provided using the host activity ViewModelProvider though.

Snapshots would be helpful for development and testing in other projects before making a release.
The goal is to use the artifactory gradle plugin to publish the snapshot versions to oss.jfrog.org.

See PR #43

Experiment was successful. PR to follow.
It also uncovered an issue on AppBarLayout preview on Lollipop Preview and more recent: https://issuetracker.google.com/issues/73092289

Since the code referring to platform Fragments has not been published in a jcenter release, it can be dropped before the 2.0.0-alpha1.

See comment on Platform Fragments upcoming deprecation: android/android-ktx#161 (comment)

This will help dogfooding the newest version (currently have to import the projects you need manually, which is impractical and is more and more inconvenient).

Any help to improve the publishing scripts and add snapshots publishing to nexus sonatype right from gradle is welcome.

This will make the code cleaner, and it'll allow to get rid of SelectableViewsUtils in the future.

This module would provide helper functions ready to use in the View DSL for common AppCompat xml defined styles such as Button and ProgressBar styles.

If other support libraries have such xml only themes that are needed by users of this library, a similar issue may be created for these to create their respective modules

(What a shame!)

This will be useful for use cases where you need a reference to the View only when building the UI.
Thanks to this change, it will no longer be required to put the View you want to reference elsewhere in your UI as a property of the class where it's used.

Don't forget to keep source compatibility with a deprecated typealias to the old name, and don't forget to update the docs.

NestedScrollView is present in the sample and in the viewdsl-support-compat module. This is a very unreliable view, so I'll remove it completely from Splitties. That means the viewdsl-support-compat split will be removed, without having been released in any version (except snapshots).

RecyclerView can replace it without any issue:
https://gist.github.com/LouisCAD/2877b893f26f7f63cec1cea918a5b3c9

A new split could be done to provide this adapter, plus a helper to use it with the simplicity of a ScrollView from View DSL standpoint.

Just got this idea as I knew I'd need to use appCtx in an enum for use in its toString() method so it displays localized strings from resources in an ArrayAdapter for a Spinner.

The StringSet prefs delegates should undergo the same changes

This is important since editing the returned value from a string set pref delegated property will not propagate changes to the preferences. This will have no runtime impact since the SharedPreferencesImpl wraps the string set in a HashSet regardless of it there was already a HashSet.

Example for FragmentActivity.activityScope extension:

inline fun <reified VM : ViewModel> FragmentActivity.activityScope(noinline factory: () -> VM) = uiLazy {
    ViewModelProviders.of(this, TypeSafeViewModelFactory(factory)).get(VM::class.java)
}

@PublishedApi
internal class TypeSafeViewModelFactory<VM : ViewModel>(
        private val factory: () -> VM
) : ViewModelProvider.Factory {
    @Suppress("UNCHECKED_CAST")
    override fun <T : ViewModel?> create(modelClass: Class<T>) = factory() as T
}

Example usage:

private val viewModel by activityScope {
    val repoType = withExtras(ExtrasSpec) { repoType }
    SubRedditViewModel(ServiceLocator.instance(this@RedditActivity).getRepository(repoType))
}

Before:

val cheeseDb = roomDb<CheeseDb>(name = "CheeseDatabase") {
    addCallback(object : RoomDatabase.Callback() {
        override fun onCreate(db: SupportSQLiteDatabase) {
            fillInDb()
        }
    })
}

After:

val cheeseDb = roomDb<CheeseDb>(name = "CheeseDatabase") {
    onCreate { db ->
        fillInDb()
    }
}

Some modules have their own README (which is great!) but not all of them do. For the sake of consistency (and also to complete the root README file) I think we should finish them. The ones that are missing are:

• arch-lifecycle
• arch-room
• bitflags
• bundle
• exceptions
• fragmentargs
• initprovider
• mainhandler
• preferences
• resources
• selectableviews
• snackbar
• stetho-init
• support-fragmentargs
• systemservices
• toast
• typesaferecyclerview
• uithread

We have BleGattCoroutines to showcase along with any apps depending on it.

Useful for tests which are not run on the UI thread, and if you just want to prepare an intent from a background thread.

Improvement path:

• Add snippets to compare with and without, as done in Android KTX README
• The list of the splits can be made thinner by replacing headings by bullet points
• The related splits may be grouped (views group, viewdsl group, others group…)

Any other ideas to improve it further are welcome!

Can you spot the error in the snippet below?

add(::verticalLayout, lParams(width = matchParent) {
    val inputLParams = lParams(width = matchParent)
    add(firstNameInput, inputLParams)
    add(lastNameInput, inputLParams)
    add(emailInput, inputLParams)
    add(mobilePhoneNumberInput, inputLParams)
})

Here's the fixed version:

add(::verticalLayout, lParams(width = matchParent)) {
    val inputLParams = lParams(width = matchParent)
    add(firstNameInput, inputLParams)
    add(lastNameInput, inputLParams)
    add(emailInput, inputLParams)
    add(mobilePhoneNumberInput, inputLParams)
}

Did you notice? I hopefully managed to notice my mistake. I added the views from the lParams lambda instead of from the add lambda, which made them be added to the parent of the verticalLayout instead of in the verticalLayout itself.

A lint should be able to catch such mistake and show an error

A persistent lint warning should be present for any Context.injectAsAppCtx() usage since it's potentially unsafe to use. This should escalate to fatal if directly called with a subclass of the types know to Context.canLeakMemory().

There could also lint warnings when using appCtx to get resources that are commonly invalidated with common configuration changes (dimensions with screen rotation for example) or which rely on theme.

Currently the room module uses appCtx for the context when referencing a Room database - https://github.com/LouisCAD/Splitties/blob/master/arch-room/src/main/java/splitties/arch/room/Room.kt#L25

This will be okay in most cases, but we should make it a default parameter so the user has the option to provide a specific context if they prefer.

Example of how it could be done:

class IconOneLineListItem(
        context: Context,
        disableDefaultTint: Boolean
) : SelectableConstraintLayout(context) {

    constructor(context: Context) : this(context, disableDefaultTint = false)

    val icon = v(::imageView, R.id.icon) {
        if (!disableDefaultTint) imgTintList = styledColorSL(android.R.attr.textColorSecondary)
    }

    // Class body
}

Also, the AttributeSet and style parameters could be removed since the one that only takes a Context is the only one needed. This would decrease the methods count (View constructors even if useless, are not proguarded).

The current short description is "A collection of light, general purpose Android libraries. Kotlin friendly."

Since the library is now 99% Kotlin and GitHub shows it, "Kotlin friendly" is no longer necessary.
Also, I'm not so satisfied with this description that is old. The upcoming 2.0.0-alpha1 version has more features, and I'm looking for an appropriate description. This will probably get easier once the doc is updated though (which is very WIP).

When in the same file you want to use lParams(…) extension function for both LinearLayout and AppBarLayout, you get an overload resolution ambiguity that prevents compilation because the LinearLayout extension could also work for AppBarLayout. Same when using CoordinatorLayout and FrameLayout in the same file.
Using named imports can solve this issue, but it's not ideal and it can make naming unconventional.

To avoid this issue, only the classes that have ViewGroup as their direct parent class (like FrameLayout, LinearLayout and ConstraintLayout) should have an lParams extension function. Subclasses should follow a different naming convention.

defaultLParams(…) could replace lParams(…) for these indirect ViewGroup child classes.
If anyone has a better name idea, please, comment here (even if the issue is closed).

See issues KT-22770 and KT-22323 for more details.

Snippets for switchMap:

import android.arch.lifecycle.LiveData
import android.arch.lifecycle.Transformations

inline fun <X, Y> LiveData<X>.switchMap(
        crossinline transform: (X?) -> LiveData<Y>?
): LiveData<Y> = Transformations.switchMap(this, { input -> transform(input) })

inline fun <X, Y> LiveData<X>.switchMapNotNull(
        crossinline transform: (X) -> LiveData<Y>?
): LiveData<Y> = Transformations.switchMap(this, { input: X? ->
    input?.let { transform(it) }
})

Should be pretty easy to do for anyone as there's a README that explains how to use it.

Any help is appreciated as this library is a lot of work for me, and this is (very) far from being the only project I work on.

Example of what could be included in the module:

/**
 * Iterate the receiver [List] using an index instead of an [Iterator] like [forEach] would do.
 * Using this function saves an [Iterator] allocation, which is good for immutable lists or usages
 * confined to a single thread like UI thread only use.
 * However, this method will not detect concurrent modification, which may lead to unpredictable
 * behavior.
 *
 * @f the action to invoke on each list element.
 */
inline fun <T> List<T>.forEachByIndex(f: (T) -> Unit) {
    for (i in 0..lastIndex) f(get(i))
}

Helpers for Android SparseArrays could also be added in this module, or in another module.
If you have some opinions about this, please, add them in a comment.

Fixed by using this code:

add(firstLine, lParams(height = wrapContent) {
    startMargin = dip(72)
    topMargin = dip(8)
    endMargin = dip(8)
    startOfParent()
    topOfParent()
    endToStart = switch.id
})

Thanks to such extensions, the following snippet:

add(container, lParams(width = matchParent) {
    topToBottom = appBar.id
    bottomToTop = bottomNav.id
})

could become:

add(container, lParams(width = matchParent) {
    topToBottomOf(appBar)
    bottomToTopOf(bottomNav)
})

Also, there could be a check for a valid View id

So extensions like contentPadding can be added:

import android.support.v7.widget.CardView

var CardView.contentPadding: Int
    @Deprecated(NO_GETTER, level = DeprecationLevel.HIDDEN) get() = noGetter
    set(value) = setContentPadding(value, value, value, value)

The module would simply provide color resources for what is defined in the Material Design guidelines.

I already have this in a personal project, should be included before 2.0.0-alpha1 release

The setter value is not used, and current text is used instead. This needs to be fixed ASAP.

The IDE should have reported it, so I created an issue for it: https://youtrack.jetbrains.com/issue/KT-23710

There's multiple ways to test (JUnit, Espresso, kotlintest, spek, etc). I'm not sure which one should be picked at the moment, but I know checkedlazy is a module that can greatly be tested, and should be to make sure any change that could be made to it never breaks it.

Louis and I discussed this on Slack, to pull the paragraphs out and just leave the module name and link to documentation in README. (Wanted to create an issue as to not lose the idea).

Some people in the Android team had the wonderful idea to only allow scrollbars enabling from xml, so need to write methods to get them from code.
This implies new View DSL modules for recyclerview and support core Ui.