Browsed by
Category: Abstract Android

Learning about Material Design

Learning about Material Design

I briefly talked about the module in my Nanodegree centred around Material Design in one of my previous blog posts. The module was called “Make Your App Material” and the main goal was to take an app which already contained much of its functionality and change the visuals to follow the material design guidelines. Here is a link to my Github page for this project.

Here is Google’s promotional video to give you an idea of what Material Design looks like:

It’s all about bold design and colours, tactile layers and dynamic and instructive movement. The app that was supplied as the starting point was called XYZ Reader and looked like this:

XYZ Reader Before

Looking at the current state it’s pretty obvious that a lot of things need changing before it can be considered an attractive app.

The most obvious aspect is probably the colour scheme (grey on grey with a murky green highlight).

We also need to change the photo’s to fill the area instead of showing up thumbnail size in the top left corner.

After that it would be useful to take a look at the font as a crisp and readable font can make a world of difference to an app (especially one based around reading).

It would also be nice to have optimised layouts for landscape views and tablet views.

Finally some animations will make the transitions between the list view and the detail view a lot more pleasing to the user.


I chose a colour scheme based on the logo provided:

The launcher icon for XYZ Reader

In Material Design you usually have a primary colour, a primary dark colour and an accent colour (which should highly contrast the primary colour). It is good practice to create a colors.xml file that holds all your colours and then to refer to them elsewhere in your code. This way if you need to change the colours you only need to change the xml file, not the code.

Here I use the colours to set the theme of the app:

The colour and style xml files

The colours are set in colors.xml and then referred to in styles.xml. The app them applies the style as its theme.


I decided to use the Roboto font which is a good all rounder and should be readable on lots of different pixel densities. To change the font I have to add the .ttf asset files to the project and then when the app is running these assets are accessed and then applied to the relevant text views:

Setting the fonts


Layouts are mostly defined in XML. You have to combine views in a hierarchy so that they display in the correct order, overlapping properly or splitting the screen the way you want it to. When making the layouts it’s important to make sure it will look good on any sized phone or tablet in portrait or landscape. You can do this by creating folders with size qualifiers:

Folders for different layouts

In this example you can see a folder for landscape and a folder for when the smallest width is 600dp (Density Pixel). The regular layout folder is for anything that doesn’t fit into the other qualifiers. When the app detects a device or device orientation that matches one of the qualifying folders then it loads the XML files from that folder instead of the default one.


For this project I decided to try my hand at the Shared Element Transition. I talked a lot more about this in my previous blog post called “That Shared Element Transition…

When the user clicks on one of the articles in the list view then the image for that article should expand to the size and position of the same image in the Detail View. This creates a smooth and interesting transition between the two fragments.

Other touches

Some other aspects of the design that were implemented was using a coordinator view for the List View so the toolbar would scroll with the list until it reaches a certain size and then the material would lift up to allow the list to pass underneath. The coordinator view seems very powerful and I’m looking forward to playing around with what else it can do in a future blog post.

There is also a parallax scroll used on the detail page which gives some visual interest. Here is what it all looks like in comparison with the originally provided app:

That Shared Element Transition…

That Shared Element Transition…

In this blog post I talked about an issue that I was having regarding the shared element transition for a project I was completing as part of my Android Developer Nanodegree. Around the time I was having this issue I wrote a short post for some close friends explaining my woes so I thought I would retell some of the story here.

So the app I was making used a thing called a recycler view. This lets you have a potentially infinite list without causing memory issues as it recycles views that are off screen to make the ones that are coming on screen when you scroll (probably a painfully simplistic way to describe it, but you get the point).

I was having an issue where if you scrolled to the bottom of the screen the shared element transitions would just stop working. Even if you scrolled back up they would just not work any more, unless you refreshed the data or restarted the app (below is a video of a working version of this transition so you know what it should look like).

I had been working on this issue for an entire day before finally discovering the reason and eventually fixing it.

To make a shared element transition you have to give the image in the list a transition name and then the matching image in the details view the same transition name (so that they are linked).

Shared element transition names

This was done on run time as the images in the list are generated from a database so you can’t be sure how many results you will get.

To make the transition name unique I would use the transition name that was set in the layout files (hardcoded to “transition photo“) and then concatenate the id of the individual image (which would be unique). The code would look like this:

String transitionName = holder.thumbnailView.getTransitionName() + id;

So lets say the ID was 5, we know the original transition name is “transition photo“. So the above  basically translates to:

transitionName = "transition photo5"

The issue is I’m using a recycler view, which likes to recycle… so when I would scroll down it would recycle an old view, and then I would call getTransitionName(), which would return “transition photo5“, but it’s still trying to make it unique so it adds on the new id (e.g 6) so it would set the transition name to “transition photo56“.

So when that item is selected in the list view the code would generate the transition name for the detail activity using the logic of “I want to join “transition photo” with the ID, which is 6“. It would then go “hey, ‘transition photo56’ doesn’t equal ‘transition photo6’ … so there’s nothing to transition“.

My problem was I was using the default transition name to build the current transition name but then overwriting the default transition name with the current transition name.

What a numpty.

A box of numpty

My Time at Udacity – Part 2 of 2

My Time at Udacity – Part 2 of 2

In my last post I talked broadly about the experience I had completing my Android Developer Nanodregree at Udacity. In this post I’d like to go into more detail about the work that I did during the course and what I found particularly interesting or challenging.

Project 0: My App Portfolio – Github

The first project to start us off was to make a very simple app which would have a button for each app we’d be making throughout the Nanodegree. Clicking on the button would then show a toast describing which app would be launched. I actually expected there to be a callback to this project later in the course where we would hook up our apps to these buttons, but I suppose that was left as an optional extra.


This project falls in the free trial period so it’s the time where you can decide if you think you’ll be capable of continuing. Looking back it looks pretty awful but I learned about toasts (the little messages what pop up when you click a button), alternative layout files for landscape orientation, and a little about layout (it took way longer than I’d like to admit for me to figure out how to make that final button taller and thinner than the rest of them).

Key Moment

For this project I was most proud of the smallest wee snippet of code:

if (toast[0] != null) {

Which would make the latest toast appear immediately by cancelling the current one, instead of queuing behind the one that was currently being displayed.

Project 1 & 2: Spotify Streamer – Github

This was where it started to get real. This project contained a custom Adaptor, a master/detail layout, a Service, Callbacks and a DialogFragment. I think I must have spent the better part of a week trying to figure out how to make a SQLite database with my own content provider before admitting defeat and using the data straight from the API calls. I eventually conquered my fear of databases in a later project, but it defeated me here.


Key Moment

What I was most proud of in this project was getting the Service to work so that the music would continue to play without interruption when the screen was turned, or if you navigated back to the menu to select another song.

It would have been nice if some music controls followed you back so you could actually pause the song after leaving the “Now Playing” screen, but unfortunately I couldn’t manage that in the time I had.

Project 3: Super Duo – Github

For this project we were given two apps that already had a lot of their functionality already developed. We were tasked with fixing bugs and responding to some mock feedback to improve the applications.

I struggled with motivation for this project which I think showed a weakness which I hopefully overcame later in the course. The weakness was not being able to get invested in a project that I didn’t see from the start. Since it’s a lot more likely that I’ll end up working on projects already in production I’m glad that this project helped to highlight this weakness so I could do something about it.

I also wish we had a BBQ right now Sophie…

Key Moment

For this project I was most proud of the work I did getting the barcode scanner to work. It meant learning how barcodes are generated, including how to determine if it’s a valid ISBN13 or 10 number, and also how to use the ZBar Library.

Project 4: Build it Bigger – Github

This was one of my favourite projects of the course as the course material was particularly well put together. I felt like it was challenging but also clear and concise so hopefully some of the other modules at Udacity take the structure of this project into account when designing others.

For this project I had to build a joke telling application that would utilise Gradle to:

  • Add free and paid flavors to an app, and set up the build to share code between them
  • Factor reusable functionality into a Java and Android library
  • Configure a multi project build to compile the libraries and app
  • Use the Gradle App Engine plugin to deploy a backend
  • Configure an integration test suite that runs against the local App Engine development server


This is the first project where I actually attempted to make it look good. I mean… I failed, but I at least attempted it! In the video you can see me switch from the free version, which has a banner ad and an interstitial ad when you press the joke button; and the paid version which has none of those things.

Key Moment

There were a lot of things I enjoyed with this project but I think the most satisfying was having a project with a tight and intelligent Gradle setup. It’s something I hope to continue to implement going forward.

Project 5: Make Your App Material – Github

I was looking forward to this project as up until this point all the apps I had made had functioned pretty well but looked like garbage with buttons. We were given an app that had its functionality but looked horrible and we were tasked with giving the app a facelift to make it fall in line with material design principles. The following video shows the before and after:


The most challenging aspect of this project was the optional feature I decided to implement; the shared element transition.

I had so many issues getting this transition to work such as if I scrolled too far down the screen it would just stop working, or if I swiped to a new article on the detail page the return transition would link to the wrong image. It took a lot of work to finally get it working and it STILL sometimes doesn’t fire when clicking for the first time after the app has loaded (see video).

Key Moment

I was tearing my hair out trying to get the shared element transition to work, so when it finally started to behave it was quite a relief since the deadline was right around the corner.

Project 7 & 8: Capstone – Github

Part 1 of this project was to design the app and part 2 was to build it. By the time this project came around I was pretty exhausted but I could see the finish line so I went for it. My app would take news articles from the Sky News RSS feed and then summarise the article into 5 bullet points. The user could then click on a bullet point to see more content related to that bullet point, or click the Floating Action Button to go to that article on the Sky News website.


At some point I’d like to go back and make it so you can pick your RSS feed and it will summarise any article, but this is what I handed in. Some of the things I implemented were:

  • A SQLite database and content provider
  • Google Admob and Analytics libraries
  • Multiple third party libraries
  • A collection widget
  • Material design features
  • A custom library that handled the generating of the bullet points

Key Moment

This whole project was a whirlwind from the get go (as you can see from my commit history for this project on my Github page) so there were a lot of highlights that I could mention, such as getting my bullet point generator to work or finally getting the hang of databases and content providers. I think what stands out though is finally handing in the project at 2:30am Monday morning and then waking up at 6am for work and the project review was waiting for me, so I could go to work brain dead, but content.

If you read this whole thing then thank you, it’s been a crazy journey. Also, if you’re wondering where Project 6 went, it was a new project that was added to the course late so I wasn’t required to do it.

My Time at Udacity – Part 1 of 2

My Time at Udacity – Part 1 of 2

In the build up to starting my Android Developer Nanodegree at Udacity I was fairly unsure where I wanted to take my development career.  It was whilst watching the 2015 Google I/O conference that made me think that building Apps could be a really interesting direction to head in.

I decided to view the prerequisites for the Nanodegree on Udacity’s website and found a few red flags for why maybe I shouldn’t jump straight in. Here are a couple quotes:

  1. This is not a “Zero to Hero” program. Entering students are expected to have prior experience building applications (web or mobile) in Java or another object-oriented programming language.”

I didn’t have experiences building web or mobile applications in Java (or another OOP language)…

  1. You should have at least 1-2 years of experience in Java or another object-oriented programming language prior to enrolling.”

I also didn’t have 1-2 years of experience in Java (or another OOP language). I had learned a bit of C++ a couple years back though so… that should do right?

  1. Grit: Ability to work through challenges and persevere when code breaks and tests fail.

Hells yes I have grit! I’m all grit! I’m built of grit! Grit is my middle name… it’s Steven Grit Blakemore; a name I had considered a curse up until this point!

One out of three ain't bad

I decided, after asking the opinion of a few valued friends, that I wouldn’t let being painfully inexperienced stop me so I committed to learning Java alongside Android and I jumped straight in.

The prerequisites also mentioned that “This will be a challenging and rewarding journey that will take a novice programmer 9 months or longer to complete, spending an estimated 10 hours per week on the coursework.

This course took me 12 months to complete, spending an average of 20 hours a week (sometimes less, sometimes a lot more) and when I handed in my final project at 2:30am after a 100 hour work week (32 of those at my actual day job) I felt and looked like this:

The next few days at work I don’t think I was good to anyone (fortunately my Boss was very understanding), and I still feel fairly exhausted, but I did it and came out the end having learned so much and having created something I’m really proud of.

On Monday I’ll go through some examples of the work I completed during the course and explain where I struggled the most.