Skip to content

Instantly share code, notes, and snippets.

View kpgalligan's full-sized avatar

Kevin Galligan kpgalligan

View GitHub Profile
<?xml version="1.0" encoding="utf-8"?>
<manifest package="co.touchlab.sessionize"
xmlns:android="http://schemas.android.com/apk/res/android">
<uses-permission android:name="android.permission.INTERNET"/>
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
package timber.log
internal actual class NativeBox<T> actual constructor(t:T){
actual var value:T = t
}
internal actual inline fun <R> synchronized2(lock: Any, block: () -> R): R = synchronized(lock, block)
@kpgalligan
kpgalligan / gist:46cff64649348f304cd0
Created July 19, 2015 15:27
Maven annotation processing config
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
<executions>
<execution>
@kpgalligan
kpgalligan / gist:8595c2522164ab316f9c
Last active November 16, 2018 13:15
Bad Activity
public class MistakesActivity extends ActionBarActivity
{
public static final String TABLE_NAME = "names";
ExecutorService executorService = Executors.newFixedThreadPool(4);
@Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_mistakes);
try
{
Thread.sleep(1000);
}
catch(Exception e)
{}
@kpgalligan
kpgalligan / gist:7cb184a7f5493e87f208
Created December 4, 2014 18:41
Default exception handler on wear
package co.touchlab.wearcrashanalytics;
import android.content.Context;
import android.util.Log;
import com.google.android.gms.common.api.GoogleApiClient;
import com.google.android.gms.wearable.MessageApi;
import com.google.android.gms.wearable.Node;
import com.google.android.gms.wearable.NodeApi;
import com.google.android.gms.wearable.Wearable;
import com.google.gson.Gson;
@kpgalligan
kpgalligan / gist:7a2c9e85c088dfcd2012
Created October 12, 2014 23:41
Item 64: Strive for failure atomicity

After an object throws an exception, it is generally desirable that the object still be in a well-defined, usable state, even if the failure occurred in the midst of performing an operation. This is especially true for checked exceptions, from which the caller is expected to recover. Generally speaking, a failed method invocation should leave the object in the state that it was in prior to the invocation. A method with this property is said to be failure atomic.

There are several ways to achieve this effect. The simplest is to design immutable objects (Item 15). If an object is immutable, failure atomicity is free. If an operation fails, it may prevent a new object from getting created, but it will never leave an existing object in an inconsistent state, because the state of each object is consistent when it is created and can’t be modified thereafter.

For methods that operate on mutable objects, the most common way to achieve failure atomicity is to check parameters for validity before performing the opera

@kpgalligan
kpgalligan / gist:a85171130106b615fc8f
Created October 12, 2014 23:36
Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors

We generally hold to this, although sometimes a checked exception from client code means an unrecoverable exception to us, and is rethrown.

The Java programming language provides three kinds of throwables: checked exceptions, runtime exceptions, and errors. There is some confusion among programmers as to when it is appropriate to use each kind of throwable. While the decision is not always clear-cut, there are some general rules that provide strong guidance.

The cardinal rule in deciding whether to use a checked or an unchecked exception is this: use checked exceptions for conditions from which the caller can reasonably be expected to recover. By throwing a checked exception, you force the caller to handle the exception in a catch clause or to propagate it outward. Each checked exception that a method is declared to throw is therefore a potent indication to the API user that the associated condition is a possible outcome of invoking the method.

By confronting the API user with a checked exception, the API

@kpgalligan
kpgalligan / gist:e24d2e548b3538cab9b0
Last active August 29, 2015 14:07
Coding conventions

Java Style Guide

For now we'll stick to the guide below, with some added color/changes

Tabs

Tabs are 4 spaces

Brackets and Newlines