An Easy to Use Android App Rating Library

After recently releasing some new Android apps I found myself in that same place again; how can I get people to leave  app reviews? In my experience reviews need to be solicited, as emotions towards your app are not always strong enough for a user to go out of their way to leave a review.

Step number one, lets look for good open source solutions to this problem. In comes an App Rate Library which I have used in the past. App Rate allows your users to rate your application and encapsulates that knowledge into a library for easy use.

Some of its key features are:

  • Configure when to prompt for a rating such as after 5 app launches and 3 days from the first launch of the app
  • Customize all the button and dialog text
  • Attach listeners on all dialog button clicks to allow running code when the user interacts with the dialog




They like us, they really like us!

This is all great, but its missing some key features that I really needed for my project. First, its pretty common now to see an initial popup that asks if you like the app or not; and if you do not then don’t ask the user to rate the app. So I forked the library and added (optional) support for this. If the user likes the app then they are directed to the existing rate the app dialog; if not then they are now prompted to leave feedback for the app.


Drop Us A Line

If the user would like they can now leave us some feedback by sending an email with whats on their mind. This can be helpful both to let users vent without having to do it via our rating, as well as get ideas for ways to make the app better. And of course everything on this dialog and in the email can easily be customized.




Email Screenshot

We Love Developers!

The feedback email that is crafted also adds useful information like OS version, app version and the user’s phone type.







Great so how do I get it?

The fork of the library can be found right here.


Do you find this sort of work interesting? Do you love quaint Bucks County Pennsylvania? Are you an amazing Android Developer? Then we would love to hear from you!

SKCore – A Simplification Toolset (Core Graphics, Autolayout and more)

What is SKCore?

SKCore is a set of classes and categories created to simplify layout and drawing in code. The objective of SKCore is to take underlying technologies and make simple wrappers around them to reduce the amount of code needed.

SKCore GitHub Repo


One of the most powerful things that SKCore simplifies is drawing with Core Graphics. Some of the messiest code I have come across is drawing code. Part of the reason for this, is that it is written in C instead of Objective-C and C tends to get verbose. SKCore offers some simple Objective-C wrappers that can make drawing code a lot easier to read, maintain and update. A good use case for this is to create a generic button skin that can be used across your app without the need to include an image asset. This is useful when the design for something is simple to recreate in code. Small design tweaks and color changes can then be as simple as changing a hex value or measurement variable. Below is a link to a gist that demonstrates how to make a stretchable button skin with SKCore. The resulting output can be seen in the image below.

View Drawing Code



SKCore has a set of categories to simplify the management and creation of Auto Layout constraints. The main problem with Auto Layout, in my opinion, is the verbose nature of the methods used to create constraints. Below is an example which shows the code needed for the layout of a screen using default methods. It also shows the SKCore alternative. Both ways used the exact same VFL strings to create the layout. The SCKore version cuts the code down from 2,058 characters to just 582. The result can be seen in the image below.

Auto Layout Comparison Code


UITextField attributedPlaceholder Doesn’t Work

The Problem

In my efforts to build an easier way to create forms I stumbled across and interesting bug in UIKit. Apparently the attributedPlaceholder property doesn’t work. Not only does it not display based on the attributes you set, but it also strips them out completely. This means to retain access to the attributes you set, you have to override the setter and store it before it is tainted.

The Solution

Note: Keep in mind that this fix has only been tested on iOS 6.0 and up.

To work around this bug, you have to create a subclass of UITextField and override the -setAttributedPlaceHolder to store the result in an ivar. Then you have to override the -drawPlaceholderInRect method and enumerate over the attributes and draw the text using -drawAtPoint method of NSAttributedString+NSStringDrawing (the only iOS 6 specific method). This allow support for custom attributes which can help when tweeking a design.

A Helpful Subclass

Below is a link to a subclass I wrote to work around the problem. It has support for the following…

  • Substring colors
  • Substring fonts
  • Substring baseline offset
  • Substring left offset

With these select attributes you should be able to match the placeholder text to any design.

See the code

On the benefits of speaking

I enjoy speaking in front of an audience.  This doesn’t mean I don’t get nervous. Oh, I get nervous enough that I really do need that drink of water. I still love it – the challenge of reacting to the audience, the desire to impart what I know into something meaningful for them.

The greatest feeling I can get from a talk is someone coming up afterwards to thank me for saying what I said. For someone quoting me to me. Hell, for rephrasing what I said more eloquently. But really, it’s about connecting.

But beyond that joy, what real benefits does it give me as the speaker? And, at the same time, what benefits could it provide you?

I want to share my recent revelation with you, something I truly discovered after my most recent talk at Atlassian Summit 13. I had submitted the talk proposal four months earlier. I proposed to talk about a project I was currently on, and about the lessons we had learned in trying to do all that we would try to do. It was a lessons-learned talk, a retrospective. At the time, I had no clue as to what I would end up talking about. I just knew that between the time I proposed the talk and the time it came upon me, I would have learned a few things along the way.


It was because of accepting this talk that I forced myself to really explore what was going on in the project. What I mean is that while I knew there were problems, I couldn’t just point to the problems and say, “See! Don’t do that!” I had to understand why the problems existed, and more importantly, I had to offer up solutions.

I also started going around to certain individuals to try and understand their point of view. That means discussing matters with members of QA, and the other programmers on the team. From them, I not only gained better insight, but also uncovered wonderful metaphors I could use to describe the problems we were facing.

My initial slide deck was structured in the same what that a refactoring recipe is often presented: a smell, followed by why these are problems, followed by solutions. It seemed simple enough. But this was really just the first step. When I started practicing the talk, I came to the realization that while the presentation was factual, it was also fairly negative, and focused too much on the problems. I had very specific points I wanted to make, and most of these points were small bullet points in the third slide of each Smell/Problem/Solution set. I was burying my lead at every point!

The process of practicing my speech, of doing the research to put it together, of talking to individuals drove me to the point of understanding not only the problems, but also how I could properly present the solutions.

But that’s the point. By accepting my role as a speaker, by agreeing to get in front of people to speak on a topic, I need to make sure I know what I’m talking about. So that means I’m going to research the heck out of my topic of choice. That might seem backwards, but it’s not. You see, you’ll want to speak on a topic you’re already familiar with, but once you realize you need to speak on that topic, you’ll force yourself to work extra hard, understanding the additional nuts and bolts.

In the same way that teaching something requires you to learn about it, speaking on a topic means you’ll spend that extra time. And it’s also a great way to learn something. Normally, we are trying to learn something so we understand it. However, when you have to speak about a topic, you have to learn how to describe it easily. You have to impart that knowledge onto others. That means not only understanding it, but understanding it well enough that you can share that information with your audience.

Basically, giving a talk forces you to learn more than you normally would.


Since as far back as I could remember, I’ve never had an issue being in front of people. That’s not to say I don’t get nervous, but rather that I overcome that nervousness. I’ve been in plays, I’ve given talks on topics at local events, I’ve stood alone in front of hundreds, I’ve been a member of a panel; but a talk at a national event is distinctly different. Unlike most other cases, a talk at a conference is one where you are very much aware money was involved (usually a significant amount) and people are choosing to use some of their limited time at that conference to listen to you. You are keenly aware that they did not pay to listen to you, but rather, paid the conference in the hopes that they chose correctly when allowing you to speak.

It wasn’t until I got to Atlassian Summit that I fully realized the gravity of my decision to speak. It was far larger than I’d anticipated, and the audiences in each of the tracks easily went beyond 200 people. And not only were there a lot of people, but the caliber of these people were intimidating. Lockheed Martin, NASA, Disney and LG just to name a few. I’m pretty sure I’m forgetting even larger ones. The point for me was learning this, and knowing that I had to give a talk in front of these people Thursday morning. It’s not that I didn’t think I could give the talk. Rather, it was worry that my talk might not be worth their time. Will my talk make them feel as if that hour had been a waste?

Basically, I wasn’t confident my talk was of any value to the audience I was presenting in front of. I shouldn’t have been worried. A large company is still made up of small teams, and those small teams still have the same problems other small teams have. It wasn’t until after the talk that I truly understood that. In the end, the confidence I gained from giving that talk would help me reach higher and farther than I would normally.

I’m talking about the confidence you get after a talk. That feeling you get when you finish, several people come up to you, thanking you personally and wanting to talk further about what you just spent thirty-minutes to an hour talking about already. The thrills of having someone come up and quote you to you. Reaching people.

That confidence can’t be found any other way. You can only earn that confidence after speaking. And that confidence will stay with you far longer than other kinds. And in the end, it will help you drive yourself farther along, to push yourself further.


The opportunities to speak can also help bring new friends. I’m not speaking about the act of speaking. But speaking in front of new people means you are meeting new people. You are visiting new places. And that brings you new opportunities to make new friends that you would not have made otherwise.

And beyond just making new friends, you can also learn from other people. I’ve been lucky enough to hear interesting stories from people sharing what they’ve done. Even when what they do has nothing to do with what I’m going to talk about, I’m still learning, and making new friends.

The desire to share my knowledge, the desire to speak, gave me the opportunity to make new friends. Meeting up at local user groups and offering to share my knowledge put me in the spotlight. When I moved back to the US, the first friends outside of work that I made were those I made at user groups. Being active in the user group with talks presented me with opportunities to work with them, and in the end, become friends.

You should speak

You really should. You won’t start out in front of a large crowd. You’ll do it first in front of people you know such as coworkers at your company. You’ll branch out into local meet up groups, speaking on carefully selected topics. And maybe that’s as far as you’ll ever want to go. That’s fine. But maybe you’ll want to go farther. And you’ll love it.

You really should try. It can be scary. It is a challenge. It does take work. But it can be worth it. And it can take you places you would have never gone otherwise.