/** | |
* Like Delegates.observable except it only calls the callback when the value actually changes. | |
*/ | |
public inline fun <T> uniqueObservable(initialValue: T, emitInitial: Boolean = false, crossinline onChange: (value: T) -> Unit): ReadWriteProperty<Any?, T> { | |
if (emitInitial) onChange(initialValue) | |
return object : ObservableProperty<T>(initialValue) { | |
override fun afterChange(property: KProperty<*>, oldValue: T, newValue: T) { | |
if (oldValue != newValue) onChange(newValue) | |
} | |
} |
import timber.log.Timber | |
import kotlin.properties.ReadOnlyProperty | |
import kotlin.reflect.KProperty | |
class MyClass { | |
// This will automatically have the TAG "MyClass" | |
private val log by timber() | |
fun logSomething() { | |
log.i("Hello") |
class WifiNetworksFragment : TonalFragment(R.layout.wifi_networks_fragment) { | |
// This automatically creates and clears the binding in a lifecycle-aware way. | |
private val binding: WifiNetworksFragmentBinding by viewBinding() | |
... | |
} | |
class WifiNetworkView @JvmOverloads constructor( | |
context: Context, | |
attrs: AttributeSet? = null, |
/** | |
* Fade a view to visible or gone. This function is idempotent - it can be called over and over again with the same | |
* value without affecting an in-progress animation. | |
*/ | |
fun View.fadeTo(visible: Boolean, duration: Long = 500, startDelay: Long = 0, toAlpha: Float = 1f) { | |
// Make this idempotent. | |
val tagKey = "fadeTo".hashCode() | |
if (visible == isVisible && animation == null && getTag(tagKey) == null) return | |
if (getTag(tagKey) == visible) return |
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!
\
/* | |
* Copyright (c) 2017 Emil Davtyan | |
* | |
* Permission is hereby granted, free of charge, to any person obtaining | |
* a copy of this software and associated documentation files (the | |
* "Software"), to deal in the Software without restriction, including | |
* without limitation the rights to use, copy, modify, merge, publish, | |
* distribute, sublicense, and/or sell copies of the Software, and to | |
* permit persons to whom the Software is furnished to do so, subject to | |
* the following conditions: |