Updated 22/04/19 to include Kotlin code samples and use latest version of Dagger Android.

The typical method of implementing a binding adapter using the Android Data Binding Library is to create a static method using the @BindingAdapter annotation, such as this commonly quoted example:

This has been widely documented and discussed on the Internet already and fits many use cases.

But, what if your adapter has external dependancies, or you don't want to define it in a global scope?

Binding adapters don't have to be static...

Creating a non-static binding adapter

This functionality of the data binding library is completely lacking from the official documentation, but there are a few examples floating around on Stack Overflow.

Let's create a simple adapter similar to the above example:

Rather than creating a new Picasso instance each time, Picasso is now passed to the constructor as a dependancy. For Picasso in particular this could be useful if you want to use the builder to create a custom instance and avoid having multiple instances of Picasso.

When creating a binding adapter in this way, the data binding library generates the DataBindingComponent interface^[1]. This interface contains a getter for each separate adapter defined:

Looking at the DataBindingUtil docs we can see there are a number of methods that utilise the DataBindingComponent, such as setDefaultComponent, inflate and setContentView (more on this later).

One way to use the adapter is to create a concrete implementation of the DataBindingComponent, this could be done manually or with Dagger 2 to also utilise the graph to provide any external dependancies.

Building the DataBindingComponent with Dagger

It should be possible to create either a component or a sub-component, in this example I chose to use a component as it's not really necessary to expose the entire graph to the binding adapters.

A component requires a scope so I created @DataBinding for this.

Here's the module which provides the ImageBindingAdapter:

And here's the component:

In order to satisfy the dependancy for Picasso in BindingModule, it also has to be exposed by the AppComponent (this step would not be required if using a sub-component):

Dagger automatically implements all the methods from the DataBindingComponent. Here's a snippet of what gets generated under the hood:

Using the component

The easiest way to use the new component is to create it in the Application class, particularly if using Android injection in Dagger 2.10+ as you no longer need to expose the main component to activities. It's now a standard Dagger component so it simply needs to be built in the usual way and then passed to DataBindingUtil.setDefaultComponent().

Here's a sample Application:

This of course is effectively still in the global scope, the component can also be used with a specific layout:

In an Activity:

In a Fragment:

What is DKIM?

DKIM or DomainKeys Identified Mail is an email authentication system that can help prevent spoofing by signing outgoing mail. More information can be found on Wikipedia or Google.

DKIM uses a private and public key pair for signing, the public key is stored in a TXT record in the DNS zone, similar to SPF.

Simple setup on Ubuntu 14.04

Install OpenDKIM

sudo apt-get install opendkim opendkim-tools

Generate a private and public key pair

opendkim-genkey -t -s default -d example.com

The -s switch defines the name of a selector, it's used later in both configuration on the server and the TXT record.

This generates 2 files, based on the name of the selector, e.g. default.private and default.txt

Add the TXT record

The txt file created by opendkim-genkey uses a bind record format and looks something like this:

default._domainkey	IN	TXT	( "v=DKIM1; k=rsa; t=y; "
  "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDbpMiQR1EMmOmCYzzuHYlXho97NnX1/nFCftJLjY2NVkGlCdxMpnnoVI3oGeM1DmzdbC9eySW+GbFnPs0FrPB5Tqod1XXYI3gwrMihIyMJfsIMAU0EPJKvJjwsELNYj4UHWBhWIjusGw0AeDQuUH0sCYOkdPkOSvM2wpZsvHkDZwIDAQAB" )  ; ----- DKIM key default for example.com

You can extract the necessary information from here to use with most registrars or DNS services.

Record name

The record name should be ._domainkey prefixed with the selector name:

default._domainkey.

Any sub domain information should be appended, which opendkim-genkey doesn't do. for sub.domain.example.com you should use:

default._domainkey.sub.domain

TXT value

The value should include a minimum of the DKIM version, key and key type:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDbpMiQR1EMmOmCYzzuHYlXho97NnX1/nFCftJLjY2NVkGlCdxMpnnoVI3oGeM1DmzdbC9eySW+GbFnPs0FrPB5Tqod1XXYI3gwrMihIyMJfsIMAU0EPJKvJjwsELNYj4UHWBhWIjusGw0AeDQuUH0sCYOkdPkOSvM2wpZsvHkDZwIDAQAB

Configure OpenDKIM

On Ubuntu the config files OpenDKIM uses are:

/etc/opendkim.conf
/etc/default/opendkim

Copy the private key

Many guides suggest copying files into /etc/mail, but OpenDKIM complains about permissions and won't start so it was easier to create a new folder in /etc and copy it there:

sudo mkdir /etc/opendkim
sudo cp default.private /etc/opendkim

Update /etc/opendkim.conf

As a minimum the domain, key path and selector are required:

Domain                  example.com
KeyFile                 /etc/opendkim/default.private
Selector                default

Update /etc/default/opendkim

Ubuntu uses a socket by default, but Sendmail complains that this is insecure so it's necessary to use a port instead, the following can be appended to the end of the file:

SOCKET="inet:8891@localhost" # listen on loopback on port 8891

Start the service

sudo service opendkim start

Configure Sendmail

Update the configuration

Append the following to /etc/mail/sendmail.mc:

INPUT_MAIL_FILTER(`opendkim', `S=inet:8891@localhost')

Regenerate the Sendmail config file as root:

sudo -i
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Restart the service

sudo service sendmail restart

Checking everything works

From server logs

By default OpenDKIM logs to the syslog, so you can tail the log to see if signing is successful using:

sudo tail -f /var/log/syslog | grep -i dkim

You should see something like this example taken from one of the web servers that host this blog:

Mar 16 09:25:02 web2 sm-mta[7705]: u2G9P2Dp007705: Milter insert (1): header: DKIM-Signature:  v=1; a=rsa-sha256; c=simple/simple; d=web2.lon.codacity.net;\n\ts=linode; t=1458120302;\n\tbh=C8sxHQz0QeFsCiNzhPYF8u2GVHRax8cSsYISckkpuEk=;\n\th=Date:From:Subject:To:From;\n\tb=ymr4SQ67DqXBMkVPPfjTJUEWBPFpO4jix7oZXsranp6MQrzcXg8ysbwkL0+6VdcqA\n\t DrzTrz3O6SfVh9Aok6H+tGcPIb9jMGTn1ceLlAZhy18O5qmjkZOTHr2MWtKeaf1u2M\n\t FfBBOID4M9vef7FZBJaUa0j+Zg9LarLaYW518TEo=

From your mail client

View the source of an email sent from your server and look for the Authentication-Results header. It should contain dkim=pass if everything is working. There is also a DKIM-Signature header which contains the signing data.

Further steps

This guide will get you up and running for a single domain, for multiple domains a few extra steps are necessary. I will update this post at a later date to include this.

Background

I recently purchased a Nexus 6P and being on O2 it's a requirement to download the O2 Wifi app and register it to get access to the London Underground wifi. I downloaded the app on my new phone and entered my phone number, only to get an error message saying, "Please download the latest version of the O2 Wifi App from the App Store". I called O2 technical support and spoke to a somewhat confused guy who didn't really understand the problem. I got a vague "Have you tried turning it off and on again" type of response but he said that he would report the issue.

Charles Proxy

I use Charles a lot when building mobile apps, often to simply monitor network requests coming from an app and less often to intercept and modify requests and responses to test abnormal and hard to reproduce situations. I happened to have it setup for some testing when it occurred to me to test the O2 app to see if I can determine and even fix the problem myself with some creative use of Charles. I was surprised with what I found next...

Summary of requests

I reinstalled the app on my Nexus 5 to log these requests, the process for a clean install (e.g. new device, new number) is a little different. New registrations prompt for additional details, they are sent to the O2 API in a similar way.

Step 1: Enter your phone number

Request 1

GET http://api.o2wifi.net.uk/v1?client_id=momac&method=customer.mobile_login&mac_address=f8-a9-**-**-**-**&sig=aef5daa90057d5674bc56b65ac80c052

Response 1

{
    "data": {
    "name": "Phil",
    "device": {
        "id": "79******",
        "last_sent": null,
        "mac_address": "f8-a9-**-**-**-**",
        "verified": true
        }
    },
    "state": "loaded"
}

OK, this one isn't so bad, but my MAC address has just been sent twice over the insecure connection.

Request 2

GET http://api.o2wifi.net.uk/v1?client_id=momac&countrycode=183&device_id=79******&method=sms.send_challenge&mpn=7*********&sig=359902eff609a14701b2ad1d5bb88e6c

Response 2

{
    "data": {
        "sent": true,
        "device_mpn": "unchanged"
    },
    "state": "saved"
}

There goes my phone number!

Step 2: Enter the text confirmation code

Request 1

GET http://api.o2wifi.net.uk/oauth2/token?client_id=momac&grant_type=sms_challenge&device_id=79******&verification_code=065168&scope=offline

Response 1

{
    "token_type": "Bearer",
    "access_token": "7524b243-****-****-****-************"
}

This is a custom OAuth2 grant request, although it somewhat resembles a password grant (if you consider the device_id and verification_code the username and password). Nothing wrong with that as such, but again it's sent insecurely over HTTP. Also, for what it's worth, I'm sure OAuth2 spec says to use POST for these kind of requests.

Request 2

GET http://api.o2wifi.net.uk/v1?access_token=7524b243-****-****-****-************&client_id=momac&method=customer_detail.secure_get&sig=1eeeb293ffe7a1a6744525b659564f3a

Response 2

{
    "data": {
        "customer_id": "5*******",
        "title": "Mr",
        "forename": "Phil",
        "surname": "Bayfield",
        "email": "phil@***************",
        "cust_type": "",
        "post_code": "ME10***",
        "dob": "1981-**-**",
        "signup_origin": "momac",
        "password": null,
        "signup_ssid": "",
        "opt_in_partner": "0",
        "opt_in_o2": "1",
        "created": "2015-05-07 07:55:22",
        "modified": "2015-05-07 07:56:59"
    },
    "state": "loaded"
}

There goes my personal details! Name, email, date of birth, postcode...

Request 3

GET http://api.o2wifi.net.uk/v1?access_token=7524b243-****-****-****-************&client_id=momac&method=device.secure_activate&sig=8bd7973a3253e276722512a0b77d197a

Response 3

{
    "data": [],
    "state": "updated"
}

Nothing to see here, although amusingly the request methods on the last two were secure_get and secure_activate.

Step 3: We're in!

O2 seem to be using http://momac.net/ to measure customer engagement. I've never heard of it, but at least they are using SSL to send my MAC address this time:

GET https://wapsbts.momac.net/pl/app/o2devid?devid=f5c948d702cdf629&msisdn=447557856876&devtype=Android&mac=f8-**-**-**-**-**

If you search for a hotspot, off go my device id, MAC address and phone number, merrily along their way over HTTP:

GET http://api.o2wifi.net.uk/v1?client_id=momac&id=7*******&limit=500&mac_address=f8-**-**-**-**-**&method=venue.find_all&mpn=7*********&offset=0&sig=105dc752929a71d60ace8801a6f0a0b4

Conclusion

A company the size of O2 should know better. If they are going to be transmitting your personal data, they should not be sending it insecurely in plain text. If they're going to use OAuth 2, they should stick to the guidelines and not completely ignore them.

If you use this app over your phone's data connection or a secure network, you probably don't have too much to worry about. Public access point, forget it!

After a long time in the making and a number of public preview releases, the first official release of my Bootstrap Default theme for Piwigo is available for download.

It can be downloaded from the themes section in the Piwigo admin area, or directly from the Piwigo website.

Check out my own photo site for a demo.

Just over a week ago at Google I/O Google announced the new Data Binding library.

If, like me, you were keen to give it a try and dropped it into an existing project with Robolectric, upon runing your test suite you will find that every single unit test fails with an exception:

java.lang.RuntimeException: build/intermediates/res/debug/values is not a directory

There seems to be a trivial change in the file structure of the build/intermediates/res folder when the Data Binding library is included - The res/buildtype folder becomes res/merged/buildtype.

Fortunately, there is an equally trivial fix. The RobolectricGradleTestRunner class has a line which defines where the resources are:

final FileFsFile res = FileFsFile.from(BUILD_OUTPUT, "res", flavor, type);

With a simple modification to the test runner, you can test to make sure the directory exists and fall back to the merged directory so that everything works nicely with the Data Binding library:

final FileFsFile res;
if (FileFsFile.from(BUILD_OUTPUT, "res", flavor, type).exists()) {
	res = FileFsFile.from(BUILD_OUTPUT, "res", flavor, type);
} else {
	// Use res/merged if the output directory doesn't exist for Data Binding compatibility
    res = FileFsFile.from(BUILD_OUTPUT, "res/merged", flavor, type);
}

I created a custom runner called RobolectricDataBindingTestRunner and used it in place of the RobolectricGradleTestRunner and everything worked great after this.

Full source:

public class RobolectricDataBindingTestRunner extends RobolectricTestRunner {

    private static final String BUILD_OUTPUT = "build/intermediates";

    public RobolectricDataBindingTestRunner(Class<?> klass) throws InitializationError {
        super(klass);
    }

    @Override
    protected AndroidManifest getAppManifest(Config config) {
        if (config.constants() == Void.class) {
            Logger.error("Field 'constants' not specified in @Config annotation");
            Logger.error("This is required when using RobolectricGradleTestRunner!");
            throw new RuntimeException("No 'constants' field in @Config annotation!");
        }

        final String type = getType(config);
        final String flavor = getFlavor(config);
        final String applicationId = getApplicationId(config);

        final FileFsFile res;
        if (FileFsFile.from(BUILD_OUTPUT, "res", flavor, type).exists()) {
            res = FileFsFile.from(BUILD_OUTPUT, "res", flavor, type);
        } else {
            // Use res/merged if the output directory doesn't exist for Data Binding compatibility
            res = FileFsFile.from(BUILD_OUTPUT, "res/merged", flavor, type);
        }
        final FileFsFile assets = FileFsFile.from(BUILD_OUTPUT, "assets", flavor, type);

        final FileFsFile manifest;
        if (FileFsFile.from(BUILD_OUTPUT, "manifests").exists()) {
            manifest = FileFsFile.from(BUILD_OUTPUT, "manifests", "full", flavor, type, "AndroidManifest.xml");
        } else {
            // Fallback to the location for library manifests
            manifest = FileFsFile.from(BUILD_OUTPUT, "bundles", flavor, type, "AndroidManifest.xml");
        }

        Logger.debug("Robolectric assets directory: " + assets.getPath());
        Logger.debug("   Robolectric res directory: " + res.getPath());
        Logger.debug("   Robolectric manifest path: " + manifest.getPath());
        Logger.debug("    Robolectric package name: " + applicationId);
        return new AndroidManifest(manifest, res, assets, applicationId);
    }

    private String getType(Config config) {
        try {
            return ReflectionHelpers.getStaticField(config.constants(), "BUILD_TYPE");
        } catch (Throwable e) {
            return null;
        }
    }

    private String getFlavor(Config config) {
        try {
            return ReflectionHelpers.getStaticField(config.constants(), "FLAVOR");
        } catch (Throwable e) {
            return null;
        }
    }

    private String getApplicationId(Config config) {
        try {
            return ReflectionHelpers.getStaticField(config.constants(), "APPLICATION_ID");
        } catch (Throwable e) {
            return null;
        }
    }
}

Update

A similar change has been merged into the master branch of Robolectric 3, it's not incuded in the latest RC but will make the final 3.0 release.

I much prefer the look of OS X Yosemite over Mavericks and earlier versions, but unfortunately it's taking some apps a while to catch up, Google Drive is a prime example:

In some cases it might be possible to drag and drop a replacement icon into the info screen (via "Get Info") but this doesn't work for Google Drive as it refreshes it's icon for the root shared folder every time the app starts.

Fortunately it's quite easy to change the icons over permanently and someone has even gone to the trouble of creating new icon files for a number of popular apps and shared them on Google Drive.

OS X uses files with the extension icns for folder and app icons, you simply need to find the offending file within the app package and replace it.

Changing Google Drive icons

1. Go to your Applications folder and find the Google Drive app.
2. Right click and choose "Show Package Contents".
3. Browse to Contents/Resources/lib/python2.7/resources/images.
4. Replace the files "folder-mac.icns" and "sharedfolder-mac.icns" with the icns file from the link above or another icon of your choice.
5. Quit and restart Google Drive.

After a short delay, you should see the updated icon:

I started work on this back in September but it stalled due to other commitments and sat on the hard drive of my Mac for a few weeks.

The release of Android 5.0 came and went which left my code already outdated before it even saw the light of day, time to start over.

During my train journeys over the last couple of weeks I've made some good progress and the new version features Lollipop material styles (plus backwards compatibility of course). I'm hopeful it'll be ready to hit the Play Store in early January.

There is more information about this project on my Projects page.

Earlier versions of the AppCompat-v7 library conveniently exposed a huge number of styling attributes that were hidden in the standard holo themes. A number of these attributes allowed customisation of the SearchView widget on the ActionBar.

I'll quickly summarise the way to style the SearchView with AppCompat v20 for completeness, then discuss the differences with v21.

The old way

In v20 there are a number of attributes defined which apply to the SearchView widget:

<attr name="searchResultListItemHeight" format="dimension" />
<attr name="searchViewAutoCompleteTextView" format="reference" />
<attr name="searchViewCloseIcon" format="reference" />
<attr name="searchViewEditQuery" format="reference" />
<attr name="searchViewEditQueryBackground" format="reference" />
<attr name="searchViewGoIcon" format="reference" />
<attr name="searchViewSearchIcon" format="reference" />
<attr name="searchViewTextField" format="reference" />
<attr name="searchViewTextFieldRight" format="reference" />
<attr name="searchViewVoiceIcon" format="reference" />

These are defined within the various AppCompat themes, including Theme.AppCompat, Theme.AppCompat.Light and Theme.AppCompat.Light.DarkActionBar.

You can customise the SearchView styles in your theme as follows:

<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
    <item name="actionBarWidgetTheme">@style/AppTheme.WidgetTheme</item>
</style>

<style name="AppTheme.WidgetTheme" parent="Theme.AppCompat.Light.DarkActionBar">
    <item name="searchViewSearchIcon">@drawable/ic_action_search</item>
    <item name="searchViewCloseIcon">@drawable/ic_action_close</item>
</style>

The new way

In v21 the attributes have been re-organised and found their way into the declare-styleable section for SearchView:

<declare-styleable name="SearchView">
    <!-- The layout to use for the search view. -->
    <attr name="layout" format="reference" />
    <!--
         The default state of the SearchView. If true, it will be iconified when not in
         use and expanded when clicked.
    -->
    <attr name="iconifiedByDefault" format="boolean" />
    <!-- An optional maximum width of the SearchView. -->
    <attr name="android:maxWidth" />
    <!-- An optional query hint string to be displayed in the empty query field. -->
    <attr name="queryHint" format="string" />
    <!-- The IME options to set on the query text field. -->
    <attr name="android:imeOptions" />
    <!-- The input type to set on the query text field. -->
    <attr name="android:inputType" />
    <!-- Close button icon -->
    <attr name="closeIcon" format="reference" />
    <!-- Go button icon -->
    <attr name="goIcon" format="reference" />
    <!-- Search icon -->
    <attr name="searchIcon" format="reference" />
    <!-- Voice button icon -->
    <attr name="voiceIcon" format="reference" />
    <!-- Commit icon shown in the query suggestion row -->
    <attr name="commitIcon" format="reference" />
    <!-- Layout for query suggestion rows -->
    <attr name="suggestionRowLayout" format="reference" />
    <!-- Background for the section containing the search query -->
    <attr name="queryBackground" format="reference" />
    <!-- Background for the section containing the action (e.g. voice search) -->
    <attr name="submitBackground" format="reference" />
    <attr name="android:focusable" />
</declare-styleable>

Theme has also gained a new styleable attribute specifically for the SearchView:

<!-- Style for the search query widget. -->
<attr name="searchViewStyle" format="reference" />

There are some new styles defined specifically for the SearchView such as Widget.AppCompat.SearchView and Widget.AppCompat.Light.SearchView.

So, to implement the v20 example above in v21 we would end up with something like this:

<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
    <item name="searchViewStyle">@style/AppTheme.SearchView</item>
</style>

<style name="AppTheme.SearchView" parent="Widget.AppCompat.SearchView">
    <item name="searchIcon">@drawable/ic_action_search</item>
    <item name="closeIcon">@drawable/ic_action_close</item>
</style>

Final thoughts

Theming in Android has not always been the easiest thing to do and it looks like things have been greatly improved with Lollipop. The simplicity of the material theme is a huge time saver and it's good to see that this extends down into common use widgets too. The new SearchView attributes and themes are a much more logical and organised approach than we've had in the previous versions.

In a number of Android projects I've worked on we've had a requirement for a PIN code entry screen, something which is sadly lacking from the Android SDK. I started working on this a while ago but when the requirement came up again recently it prompted me to give it a quick Android 5 revamp and publish it on Github and Maven Central.

Here is a demo of the current version:

There are a number of ways that this kind of widget can be created, ranging from a complex custom editable view to a number of separate EditText views with a mass of event listeners. I went for something somewhere in the middle - A custom ViewGroup that uses an "invisible" EditText to delegate input to.

This is a surprisingly simple and effective way to create a view that has all the features of an EditText but looks completely different. Provided the EditText is visible and of at least 1px in size it can receive focus, then with a single TextWatcher the user input can be displayed however you want.

Details and updates to this project can be found on my Projects page.

Over the last couple of weeks many of the Google Android apps have been updated to support the Lollypop material theme. One of the noticeable changes is the new spinning hamburger for apps that use a navigation drawer such as the Play Store and Google Music.

As I mentioned in my previous post it's very easy to update to the new compatibility libraries which support the new material theme and the new navigation drawer style is included, again with a very simple modification.

Update import

The new ActionBarDrawerToggle is found in the v7 support library, so you need to update your imports.

The old style:

import android.support.v4.app.ActionBarDrawerToggle;

The new style:

import android.support.v7.app.ActionBarDrawerToggle;

Update constructor

The new ActionBarDrawerToggle also has a slightly different constructor, you no longer need to provide a drawable resource for the hamburger.

The old style:

ActionBarDrawerToggle(Activity activity, DrawerLayout drawerLayout, int drawerImageRes, int openDrawerContentDescRes, int closeDrawerContentDescRes)

The new style:

ActionBarDrawerToggle(Activity activity, DrawerLayout drawerLayout, int openDrawerContentDescRes, int closeDrawerContentDescRes)

With the release of the Android Lollypop SDK, Google have also updated the support libraries. The good news is that the AppCompat library already contains support for the new material theme so you can update your existing apps with very little effort.

It would probably be a good idea to read about using the material theme and using the new support library before proceeding.

Java 7+

The Lollypop build tools require Java 7 upwards, just download JDK 7 or JDK 8 and install it, if you haven't already done so.

Note: The Android Studio application plist still requires Java 1.6, if you don't want to have multiple versions of Java floating around it seems to work without issue if you edit the plist.

Update build.gradle

Simply update all the SDK versions below 21 to 21 throughout your build.gradle, typically this will be as follows:

android {
    compileSdkVersion 21
    buildToolsVersion "21.0.2"
    
    defaultConfig {
        targetSdkVersion 21
    }
}

Then update any support library dependencies:

dependencies {
    compile 'com.android.support:support-v4:21.0.0'
    compile 'com.android.support:appcompat-v7:21.0.0'
}

Build and run and you should now have the material theme!

If you run into a gradle error about the Java version, you will need to point Android Studio at the correct JDK.

Implement the matherial theme for v21

Now that you have updated the support libraries, you should proceed with implementing the v21 material theme for Lollypop devices.

Although most of the good Android libraries are open source, occasionally you get stuck with a third party JAR or two that doesn't have source available, or good documentation, or both.

Music streaming services in particular seem to prefer the closed source route. Many of them provide SDKs for Android such as Spotify, Deezer and Rdio but they're all in various pre-compiled formats.

Fortunately, there is a fantastic IDEA plugin to solve this problem called JD-IntelliJ. Android Studio appears to be fully compatible with IDEA plugins and this one works very well. It's not faultless and a small number of methods are output as "described byte code" but this itself isn't too tricky to follow.

Here is a quick example taken from Deezer's library:

M-5

The name M-5 comes from an episode of the original Star Trek series titled "The Ultimate Computer". Admittedly, I've never actually seen the episode, but I felt the title of the episode was quite fitting for this project. In the episode the computer actually attacks two other starships and kills tonnes of people before eventually shutting itself down. As modern PC technology is yet to incorporate human engrams and it'll be installed on my desk rather than a starship, I'm not too worried about a repeat occurrence.

New parts

My previous build log is already documented on this blog here and here and it's only a couple of years old so my main goal was to move to a cube shaped case and move from X79 to Z97. This may sound like a downgrade for some, but I personally don't think the Intel enthusiast platform is really the best choice for gaming. The majority of the games that I play are CPU bound so 6 or 8 cores provides zero benefit, however a higher speed single core will maximise my graphics performance. Hence, I went with the quad core Devil's Canyon 4790K along with the ASUS Maximus VII Hero board.

The choice of cube shaped cases is quite limited and after considering a few different options I happened to come across this video on YouTube of the Lian Li D600 case at Computex:

This case is ideal for water cooling as it's possible to fit multiple radiators, with maximum sizes of up to 420 mm in the front left, 480 mm in the back right and 240 mm in the top left. There is even room in the right hand side for an 80cm wide radiator in push pull.

There are 10 5 1/4" bays, giving tonnes of room for expansion as well as various mountings for up to 6 3.5" and 4 2.5" drives - way more than I would ever consider installing.

I was very impressed with the build quality and accessories that Lian Li provided. The D600 is second to none in comparison with the previous cases I've owned, although the Corsair and Silverstone were not far behind. Here it is, just out of the box:

So this covers the main changes I'm making to my PC, in the next part of the build log I'll cover the cooling components.