Put this in your config.fish
run
code path/to/project
/* | |
* Copyright 2013 Google Inc. | |
* | |
* Licensed under the Apache License, Version 2.0 (the "License"); | |
* you may not use this file except in compliance with the License. | |
* You may obtain a copy of the License at | |
* | |
* http://www.apache.org/licenses/LICENSE-2.0 | |
* | |
* Unless required by applicable law or agreed to in writing, software |
<?xml version="1.0" encoding="utf-8"?> | |
<manifest xmlns:android="http://schemas.android.com/apk/res/android" | |
package="com.trifork.example" | |
android:installLocation="auto" | |
android:versionName="@string/client_info" > | |
<!-- ... --> | |
<application | |
android:hardwareAccelerated="true" |
package com.cyrilmottier.android.citybikes.provider; | |
import android.net.Uri; | |
import com.cyrilmottier.android.avelov.BuildConfig; | |
/** | |
* @author Cyril Mottier | |
*/ | |
public class CityBikesContract { |
// add this to the general build.gradle, not in the subproject's build.gradle | |
// improved version of Xavier's tip http://tools.android.com/tech-docs/new-build-system/tips#TOC-Improving-Build-Server-performance. | |
// usage example default, preDex will be enabled: gradle clean build | |
// usage example disabling preDex: gradle clean build -PpreDexEnable=false | |
// preDexEnable parameter's value can be set as property of Continuous Integration build config | |
// this is the main difference from Xavier's workaround where he doing only hasProperty check | |
project.ext { | |
if (project.hasProperty('preDexEnable')) { |
/* | |
* Copyright (C) 2014 The Android Open Source Project | |
* | |
* Licensed under the Apache License, Version 2.0 (the "License"); | |
* you may not use this file except in compliance with the License. | |
* You may obtain a copy of the License at | |
* | |
* http://www.apache.org/licenses/LICENSE-2.0 | |
* | |
* Unless required by applicable law or agreed to in writing, software |
<?xml version="1.0" encoding="utf-8"?> | |
<resources> | |
<color name="action_pause">#FF8F00</color> | |
<color name="action_resume">#43A047</color> | |
</resources> |
Put this in your config.fish
run
code path/to/project
/* | |
* Copyright (C) 2016 Jesse Wilson | |
* | |
* Licensed under the Apache License, Version 2.0 (the "License"); | |
* you may not use this file except in compliance with the License. | |
* You may obtain a copy of the License at | |
* | |
* http://www.apache.org/licenses/LICENSE-2.0 | |
* | |
* Unless required by applicable law or agreed to in writing, software |
<?xml version="1.0" encoding="utf-8"?> | |
<!-- | |
Copyright 2016 Google Inc. | |
Licensed under the Apache License, Version 2.0 (the "License"); | |
you may not use this file except in compliance with the License. | |
You may obtain a copy of the License at | |
http://www.apache.org/licenses/LICENSE-2.0 |
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,