Instead of the verbose setOnClickListener
:
RxView.clicks(submitButton).subscribe(o -> log("submit button clicked!"));
Observable
.just(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
package LifecycleDemo | |
import java.util.* | |
/** | |
* The purpose of this pattern is to give the ability to group actions that belong together | |
* but that have to be executed at a different point of the android activity lifecycle | |
* | |
* This extension function creates a delegate for all children of LifecycleActivity |
class Reader<C, out A>(val run: (C) -> A) { | |
inline fun <B> map(crossinline fa: (A) -> B): Reader<C, B> = Reader { | |
c -> fa(run(c)) | |
} | |
inline fun <B> flatMap(crossinline fa: (A) -> Reader<C, B>): Reader<C, B> = Reader { | |
c -> fa(run(c)).run(c) | |
} |
# Thanks to this post: | |
# http://blog.ikato.com/post/15675823000/how-to-install-consolas-font-on-mac-os-x | |
$ brew install cabextract | |
$ cd ~/Downloads | |
$ mkdir consolas | |
$ cd consolas | |
$ curl -O http://download.microsoft.com/download/f/5/a/f5a3df76-d856-4a61-a6bd-722f52a5be26/PowerPointViewer.exe | |
$ cabextract PowerPointViewer.exe | |
$ cabextract ppviewer.cab |
public class RxSchedulerHook { | |
private ISRxSchedulerHook() { | |
// no instances | |
} | |
/** | |
* this makes sure that when we run the tests all of RxJava | |
* operates on a single thread (Scheduler.immediate) | |
*/ |
Add the printProperties
task to your build.gradle
Run from both the command-line and intellij the gradle task printProperties
> Task :printProperties
Detecting what could cause incompatible gradle daemons
Run './gradlew printProperties' from the command-line and the same task Android studio
See https://docs.gradle.org/4.5/userguide/build_environment.html
See https://docs.gradle.org/4.5/userguide/gradle_daemon.html#daemon_faq
#Intro
Kotlin is a new programming language for the JVM. It produces Java bytecode, supports Android and generates JavaScript. The latest version of the language is Kotlin M5.3
Kotlin project website is at kotlin.jetbrains.org.
All the codes here can be copied and run on Kotlin online editor.
Let's get started.
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,