Putting Platty Soft on hold

This post is part announcement, part post-mortem and part rant, but which post-mortem does not have its share of ranting?

The announcement

I’ll have started working for Daqri recently, and since Platty Soft is a one man company, it will be put on hold. This means that all the projects will receive only maintenance releases which I’ll do in my spare time, instead of as part of my daily job as I’ve been doing until now.

For MTG Tracker, this means that new sets will be added, but most likely there won’t be any new features (maybe some small ones, but don’t hold your breath).

The post-mortem

I’ve been running Platty Soft for 4 years. My original idea was to do contractor work to guarantee an income and then dedicate the rest of the time to my own projects, namely apps and games.

Ideally, those apps and games would gradually generate more income so I could do less contracting work and more of my own projects until I could just work on my projects full time.

Obviously, it has not worked as expected.


Along these years I’ve improved MTG Tracker a lot, released Codemon and updated it, co-created AppAffinity (now discontinued) and also published a few small apps like KendamApp, Learn To Hoop and Spin Off.

A while ago it was already clear for me that the plan was not going to work. In fact I started advising people to not go indie (or at least be aware of the difficulties) already at the end of 2013 with the talk The (mobile) Indie Game Developer Survival Guide. You can watch the video from the talk at DroidConNL.

All in all, the indie road is a very tough one. There has been a perfect storm forming for some time now which I’ve been calling “The Appocalypse: the apocalypse of the apps”. Funny enough, people are now talking about Zombie apps, which fits into the theme. I already talked about the Gold (but not the rush) being over also in 2013.

However, things have gone from bad to worse. Over the past year, the monthly gross income I was getting from all my apps and games combined has been decreasing at an alarming rate. To the point of it being 1/3 of what it was a year ago. That is, going from 1200 EUR a month to just 400.

With the figures of one year ago, it was hard to consider that I was making “a living” out of it, but with the current ones it is definitely impossible.

Obviously all my projects are in long tail now, but that long tail is getting thinner in mobile.

To put it in perspective, there was only one time when the income was lower: the first month when I released MTG Tracker Pro. Yes, back to 2011, and at that time MTG Tracker was only one app I had.

But I know what you are asking. Why did I kept doing it? Well, there were several reasons:

  • I had an international move planned from Amsterdam to Dublin, so I didn’t want to get a full time job to just quit short after.
  • I had a nice contractor work with Squla, which is an awesome startup, that allowed me great flexibility.
  • Contractor work pays well, so I didn’t need to change that. I just stopped making new projects.
  • Once I was already decided to get a full time job, I got contacted by Packt to write a book about Game Development for Android, which had kept me busy for a few extra months.
  • I hadn’t found a really interesting full-time job until past week.

Now, let’s get ranting

The income from Google Play comes mostly from MTG Tracker, and then a little bit from Codemon.

MTG Tracker has never recovered the top search spot it had a few years ago (after it was taken down by WoTC), and that is the largest factor in its income decrease. I am not “demanding” to be at the top of the search, but right now the app is around position 20 (depending of the search criteria) and for at least 15 of the apps that appear before it MTG Tracker has:

  • Better average rating
  • More downloads
  • More ratings
  • Better ratings per download ratio
  • Updates more often

This rant about the crap search results on Google Play is not new. It was even one of the reasons I made AppAffinity back in 2012! And it has not improved. If something, it has become worse.

I have talked about this with people that works at Google Play and they seem to agree with me, I rank good in all the factors that are considered important, yet I am appearing very low in the search. Not being one of the top 5 apps is close to not existing. I am sure I got most of my downloads from word of mouth.

In the case of Codemon, while it has a decent conversion rate and ARPPU, the volume has been quite small to pay the time I invested in building it, but at least it paid all the other people that I hired to make it happen. Still, the past 2 months have seen a huge drop in In-App Purchases.

I have one more project in progress: GeoDefense. It is a cooperative GPS based tower defense, currently in private beta, and given the current situation, it may never get out of that state.

Now, talking about new projects. I considered for a while making games based on third party IP. I talked with the webcomics Spindrift and El Sistema D13, but ultimately I was not sure any of those projects was going to even cover expenses, and I was feeling tired.

The thing is, unless you put serious effort (and money) in promotion, your app is going to disappear in the swarm that Play Store is (and the App Store, for what is worth). Your only chance is to go for a very niche market, like Codemon does for barcode scanning games, and then you still need to be lucky and worry about many things.

So, it is clear to me that Google and Apple need to take action and fix the search of their app stores or you’d keep reading this stories from more and more indie developers. It has been a winner takes all for a long while, but it is evolving to have less winners and they take even more.

Let’s put everything together: Increasing user acquisition cost, flooded market, huge marketing budget for the ones on top to remain on top, almost non-existing visibility for the rest, a race to bottom in prices… Do I need to continue?

It is just not worth it.

Ultimately the reason why I decided to move on was my feelings each time I thought about a new possible project on the last year.

When thinking about a new project I was not feeling excitement or joy, but despair. Despair about how I was going to deal with visibility, discoverability and promotion. And that was not even considering the headaches of monetization. Sadly, this is a quite common feeling among indie developers today.

The only time I have not felt that way is when I worked on the  CounterClockWise Watchface I made for Android Wear a few weeks ago. The reason is that I built it for myself and didn’t care about monetization, downloads, reach and so on. I just did it because I wanted to and it was merely 2 days of work. It got 50 downloads in a week, actually, more than I thought it would.

That’s not how I want to feel about a new project. And if what it needs to be done to get interested in them again is to make them side projects and don’t give a shit about who finds them, so be it.


But now, for the foreseeable future I’ll be doing some innovation at Daqri, and I’m really excited about it.

Book: Mastering Android Game Development

I’ve been busy the past few months writing a book titled Mastering Android Game Development with focuses on using the Android SDK for building games. The book is now available online.


If you are an intermediate-level Android developer who wants to create highly interactive and amazing games with the Android SDK, then this book is for you.

This book is a progressive, hands-on guide to developing highly interactive and complex Android games from scratch. You will learn all the aspects of developing a game using a space shooter game as the example that will evolve with you through the chapters. You will learn all about frame-by-frame animations and resource animations. You will also create beautiful and responsive menus and dialogs and explore the different options for playing sound effects and music in Android, the basics of creating a particle system, how to configure and use Google Play Game Services on the developer console and port our game to the big screen.

Snapping items on a horizontal list

The Problem

We want to have a horizontal scrolling view that holds several items and that snaps to the selected one once the scroll stops, placing it centered on the screen.

Essentially something that works like this:


In old versions of Android we had the Gallery class that allowed us to do something similar, but it has been deprecated. It is also similar to what you can do with a ViewPager, but those are normally designed for full width Fragments.

The Solution (TL;DR)

What we will do is to listen for the event of scrolling stop on the list. Then we will check which item is currently in the middle of the screen and make the list scroll until it is positioned on the center.

The code for this example is available on GitHub as the project SnappingList

The detailed solution

You probably want something more detailed, so let’s get into it.

Some considerations

We are going to use a RecyclerView because the OnScrollListener allows us to know the pixels that have been scrolled, and that is not possible with a standard ListView. Its OnScrollListener does not provide enough information. Besides, a RecyclerView is more fancy.

We will know the with of the items on the list beforehand. This is very important to be able to calculate the center of the screen and which item is the selected one.

We are going to have two extra items in the list, one at the beginning and one at the end, to be able to position the first and last items centered on the screen. The width of these extra items need to be large enough for it.

The list items

As we mentioned, we will have two different items in the list. The normal ones and the ones we will add at the beginning and the end.

The layout for the extra items is defined in the layout file list_item_padding.xml and looks like this:

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout  xmlns:android="http://schemas.android.com/apk/res/android"

On the other hand, the normal items we are going to use are just a square shape in the background and a number in the center. They are defined in the layout list_item.xml which looks like this:

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout  xmlns:android="http://schemas.android.com/apk/res/android"

        android:layout_height="wrap_content" />


These layouts have the width defined as a dimension. This allows us to tweak it for different screen sizes and also to be able to read the width in code without the need of waiting for the views to be measured. The values we are using for the example are:

    <dimen name="item_width">200dp</dimen>
    <dimen name="padding_item_width">300dp</dimen>

The Adapter

Then, we are going to create an adapter that just adds the two extra items. We call it ExtraItemsAdapter and the code is like this:

public class ExtraItemsAdapter
        extends RecyclerView.Adapter<ViewHolder> {

  private static final int VIEW_TYPE_PADDING = 1;
  private static final int VIEW_TYPE_ITEM = 2;

  private final int mNumItems;

  public ExtraItemsAdapter(int numItems) {
    mNumItems = numItems;

  public int getItemCount() {
    return mNumItems+2; // We have to add 2 paddings

  public int getItemViewType(int position) {
    if (position == 0 || position == getItemCount()-1) {
      return VIEW_TYPE_PADDING;
    return VIEW_TYPE_ITEM;

  public ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
    // create a new view
    if (viewType == VIEW_TYPE_ITEM) {
      View v = LayoutInflater.from(parent.getContext())
        .inflate(R.layout.list_item, parent, false);
      return new ViewHolder(v);
    else {
      View v = LayoutInflater.from(parent.getContext())
        .inflate(R.layout.list_item_padding, parent, false);
      return new ViewHolder(v);

  public void onBindViewHolder(ViewHolder holder, int pos) {
    if (getItemViewType(pos) == VIEW_TYPE_ITEM) {
      // We bind the item to the view

The adapter receives a number that says how many elements to display as a parameter of the constructor.When asked for the item count it will return that number+2.

When asked to create a view, it uses the item view type to check if it is either a padding or a normal item.

To use this on a real world example, you should pass a list of items instead of just an integer and do proper binding inside onBindViewHolder.

Controlling the RecyclerView

Now that the basics are set, we can move into the really interesting part: handling the RecyclerView.

As we mentioned before, the idea is that when the scroll is stopped, we calculate which item is the current position, then, make the list scroll to that position.

To be able to calculate all that, we need some initialization, mainly to know the width of the items (both normal and extra ones) and also the padding needed, which is calculated based on the screen width and the item width.

We also keep track of the current amount of scroll -in pixels- of the RecyclerView in the allPixels variable.

All this can be done inside the onCreate method of the Activity.

Display display = getWindowManager().getDefaultDisplay();
Point size = new Point();
firstItemWidth = getResources().getDimension(R.dimen.padding_item_width);
itemWidth = getResources().getDimension(R.dimen.item_width);
padding = (size.x - itemWidth) / 2;

allPixels = 0;

We also need to initialize the RecyclerView by creating and setting a LayoutManager.

final RecyclerView items = (RecyclerView) findViewById(R.id.item_list);
LinearLayoutManager itemslayoutManager = new LinearLayoutManager(getApplicationContext());

Finally, we set the OnScrollListener to the RecyclerView:

items.setOnScrollListener(new RecyclerView.OnScrollListener() {

  public void onScrollStateChanged(RecyclerView recyclerView, int newState) {
    super.onScrollStateChanged(recyclerView, newState);
    synchronized (this) {
      if (newState == RecyclerView.SCROLL_STATE_IDLE) {

  public void onScrolled(RecyclerView recyclerView, int dx, int dy) {
    super.onScrolled(recyclerView, dx, dy);
    allPixels += dx;

This listener does two things:

  • When the scroll stops (the scroll state changes to SCROLL_STATE_IDLE), it calls calculatePositionAndScroll to make the list snap.
  • When the list scrolls, it updates the value of allPixels.

Then we have the utility method calculatePositionAndScroll which is where the action is:

private void calculatePositionAndScroll(RecyclerView recyclerView) {
  int expectedPosition = Math.round((allPixels + padding - firstItemWidth) / itemWidth);
  // Special cases for the padding items
  if (expectedPosition == -1) {
    expectedPosition = 0;
  else if (expectedPosition >= recyclerView.getAdapter().getItemCount() - 2) {
  scrollListToPosition(recyclerView, expectedPosition);

private void scrollListToPosition(RecyclerView recyclerView, int expectedPosition) {
  float targetScrollPos = expectedPosition * itemWidth + firstItemWidth - padding;
  float missingPx = targetScrollPos - allPixels;
  if (missingPx != 0) {
    recyclerView.smoothScrollBy((int) missingPx, 0);

To calculate the position we use the values of allPixels, padding,  firstItemWidth and itemWith. Note that we are rounding the result.

We check for the special cases of the first and last items -the extra ones- and then tell the list to scroll to that position.

Scrolling to the position calculates the point in which the list needs to be positioned for a specific item, subtracts the value of allPixels from it and tells the list to do a smooth scroll.

Finally, we initialize the adapter with the number of items we want to be displayed.

ExtraItemsAdapter adapter = new ExtraItemsAdapter(NUM_ITEMS);

While the code works, there are a couple of situations we want to fix to make it nicer.

Finishing touches

The first problem is that rotation does not work properly. RecyclerView does remember the state, but the value of allPixels gets reset when the Activity is destroyed. This is very easy to fix, we just need to save and restore it using the methods from the Activity.

protected void onRestoreInstanceState(Bundle savedInstanceState) {
  allPixels = savedInstanceState.getFloat(BUNDLE_LIST_PIXELS);

protected void onSaveInstanceState(Bundle outState) {
  outState.putFloat(BUNDLE_LIST_PIXELS, allPixels);

The other finishing touch is to make the list start in a selected position, since now it starts at the beginning of the list, where an extra item is.

If we call calculatePositionAndScroll directly it will create a wrong state where the value of allPixels is incorrect because the view has not been completely measured yet. To fix that we have to call that method once the layout has been completed and we do that via the OnGlobalLayoutListener class.

ViewTreeObserver vto = items.getViewTreeObserver();
vto.addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
  public void onGlobalLayout() {

I recommend that you place this code inside onResume (as oposed to onCreate) to ensure that it is called after onRestoreInstanceState. Although the layout is most likely never completed before onResume is called, the logic of positioning the list to the right position makes more sense inside onResume.

Final considerations

There are some considerations for this to be used on real world applications. Nothing major, but still worth commenting:

  • We chose the size of the items for an optimal view on a Nexus 5 in landscape. You should consider qualifying the dimensions based on the screen smallestWidth.
  • Removing the ViewTreeObserver has two different methods, one that is valid for minSDK < 16 and another one for SDK 16 on. This example only considers minSDK 16.

You can see all the code in the SnappingList project on GitHub.

Google Developer Expert

I can proudly say that since January, I have become a Google Developer Expert for Android (GDE in short). The first -and at the moment only- one in Ireland.

Google Experts are a global network of experienced product strategists, designers, developers and marketing professionals actively supporting developers, startups and companies changing the world through web and mobile applications.

As part of the activities of the GDE program I spent some time at the Office Hours during Google I/O helping people and I also gave a 20 minutes talk in the sandbox about Playful Design (slides coming shortly).

MTG Tracker 6.1 – Supporting casual formats

We just published version 6.1 of MTG Tracker, and is all about casual formats.

We were the first ones to support EDH more than 3 years ago. Long before it got the name changed to Commander. We love casual formats, that’s why It was time to include some other formats that are getting more and more popular lately.

  • Tiny Leaders is getting steam quickly, it is a smaller Commander mode with cards of converted mana cost of 3 or less, decks of exactly 50 card, 25 life points and no Commander damage. Check it out at the official site.
  • Pauper is a format when you can only use commons. Very cheap to build, lots of fun. It has been a format for Magic Online for a while.
  • Duel Commander is a modified version of Commander designed to play one-on-one. Different ban list and 35 life. Check the official site for details.

These formats have now a slot under the formats section, a deck type that checks for invalid cards and in the case of Tiny Leaders and Duel Commander, a game mode.

New Formats

Also, business as usual, the latest set “Dragons of Tarkir” has been added to the app. The cards from “Duel Decks: Elspeth Vs Kiora” have been also added.


MTG Tracker 6.0 – Material Design

MTG Tracker has been updating a lot, usually UI changes are made gradually, but sometimes they are big. This update is one of the big ones, and I want to take the chance to look back to all the journey.

MTG Tracker UI journey

The app started with a single screen with a life counter for 2 players. Nothing really flashy. New features were added as tabs, Mana Pool, then Stats, then Decks. Tabs were cool on the early days of mobile apps.

1st_versionThen the ActionBar was presented, and with that, MTG Tracker moved to ActionBar + Dashboard. That is the other time the app had a considerable redesign.


Moving forward, and adding features, at some point the app had so many features that a Dashboard was not enough. Also, a new pattern was emerging: Menu Drawers. So, we added one, not a big change, but still important.


MTG Tracker with Material Design

And with this, we get to Material Design, the big push from Google with Lollipop. We are adopting quite some new patterns. An image is worth a thousand words.

material design_small

Toolbar replaces ActionBar

The new toolbar has a more obvious drawer icon and the icon is removed from the bar, leaving some space for options and titles. It also has a very nice animation when opening the menu drawer.

There used to be a blue bar under the action bar for extra options on some screens. This is now part of the toolbar, giving am ore consistent look and feel.

Bonus points: Decks also have a Quick Return Header pattern, which hides part of the header when you scroll down and shows it again when you scroll up.

Floating Action Button

In most of the screens, there is a floating action button for the most prominent action (like add a new deck or add cards to a deck or a list).

Popup Menu replaces Quick Action Menu

The extra options for elements on a list were displayed with a quick action menu, which was cool when we started using it, but now everyone is moving to the popup menu with 3 dots, which is also more clean, so that has changed as well.

New simpler, cleaner icons

We also changed the icons of the home screen and the drawer to simpler, more clear versions of them.

Search is now an option on the menu drawer as well as in the main screen. It is much more accessible there than from the icon on the action bar.


Deck Edit is no more

Deck edit has disappeared. It was confusing and was not adding much value. The decks can be edited now at any time. As it was for Card Lists and Trades.

Something else?

I want to change some other parts of the user flow, but that will have to wait another update. No spoilers on that one.

But of course, there is a bit more:

  • Added cards from Fate Reforged
  • EDH banned list has been updated.
  • Fixed a problem when adding the card “_______” to a deck or list.

MOGA controllers and Android TV

I just released SpaceCat HD for Android TV. What it should have been a very simple and straight forward process turned out to give me quite a headache.

If you have a game that is gamepad-ready. Chances are that you are supporting MOGA controllers, simply because they are one of the best. If that’s the case you may also have this problem.

The not-so-obvious problem

If you want to publish for Android TV, you essentially have to do a few things in your manifest (see the full article on developer.android.com):

  • Declare a TV Activity using an intent filter of the category CATEGORY_LEANBACK_LAUNCHER.
  • Add a banner to the application (android:banner=”@drawable/banner”).
  • Declare it as a game (android:isGame=”true”).
  • Specify that it knows how to handle controllers.
  • Specify that touchscreen is not required.

All these are very straight forward, but some of them require you to compile with targetSDK=21 (a.k.a. Lollipop) because is when they were introduced.

Another interesting change on Lollipop is the requirement of all service intents to be explicit. Any non-explicit one will throw an exception on runtime. This requirement is triggered when you compile with targetSDK=21.

And, obviously, the MOGA library does use a service with a non-explicit intent.

The invalid approaches

The first approach is to compile with a lower targetSDK, but then you can’t be on Android TV since the required manifest options aren’t available.

The second approach is to remove MOGA support, but then, the people that has those controllers will stop to have it supported.

The third option is to have multiple apks, one for Android TV with targetSDK=21 and another one for everyone else with a lower targetSDK. This sounds reasonable, but there is no clear way to separate Android TV from the rest and -as I was told by a Google Dev advocate- this was done in purpose.

But hold on, there is one more option, and it is the most obvious one, once you think about it.

The obvious solution

You just need to modify the code of the MOGA library to make it be an explicit intent. Except that the library is not open source.

It was pointed out to me by Robert Broglia, developer of Snes9x-EX+, that you could just use a decompiled version of the library, and then modify the init method. As you can see on his github project.

I’m really not a fan of having full libraries inside the source code, so I tried to just extend the controller to replace the init method for one using the explicit intent, that would have been a few lines of code, but the class is final.

At the end I created a new Controller that uses the explicit intent (and basically everything else is the same) and placed it under the package com.bda.controller.

It could have been easier

All this could have been much easier if

  • MOGA had updated the library
  • The Controller class wasn’t final

If you have a game that is MOGA-enabled and you want to port it to Android TV, I hope to have saved you some headaches.

Kendama SpinOff 1.0 Released

A while ago, the British Kendama Association released SpinOff, a physical game for kendama that includes several wheels with tricks and even 3 play modes.

Now, that game has made it to Android Phones (and to iOS soon), making it the second kendama related app of Platty Soft.



So, if you are a Kendama player and are quite bored of same old games, give SpinOff a chance!

Note: You need a real kendama to play this.

Kendama SpinOff on Google Play

Leonids Lib 1.2 – Meteor Shower

I just released an update of Leonids Lib. It includes feedback from previous versions both from github and the workshop I gave at GDGFestDublin.


From this version on, speed and acceleration are using dips. This makes a lot of sense, since the library should work together with the standard concepts of the Android framework. Animations should me much more consistent among different pixel density screens now.

Previous versions were using pixels, so you may want to review your parameters when you update.

New Features

There are some new configuration options:

  • emitWithGravity: Allows you to emit from a specific side of the View and particles will be emitted along all the edge of the View. i.e. Gravity.BOTTOM will create a rain-like effect. Default is Gravity.CENTER.
  • updateEmitPoint: Allows to dynamically change the point of emission for the particle system (useful to follow the touch along the screen)
  • stopEmitting: Will stop creating new particles, but the existing ones will keep animating (this is different from cancel, which also stops the already spanned ones)
  • emit now has methods to emit from a specific point on the screen given x and y instead of from a View.

New Examples

Also, new examples are being included to showcase the new features:

  • Emit with Gravity: Simulates a rain-like effect using Gravity.BOTTOM.
  • Follow touch: Creates a trail of stars following the touch on the screen.


You can also check Leonids Lib github page and/or get Leonids Demo from google play.

KendamApp 2.0

There is a new version of KendamApp – The Kendama App out there. It includes 32 new videos and my favourite feature so far: Self Certification.

MTG Tracker on Google Play

Self Certification

Until now you could track your accuracy per trick, and then see how close you were to pass an exam, but an actual exam… that is another story.

This new feature allows you to try for a self certification. It tracks all the attempts of all the tricks and it tells you if you passed or not the grading.

As in a real exam, you don’t have to keep going with a trick after you’ve completed the required hits, and as in a real exam, you stop as soon as you miss one trick.

It also keeps track of your attempts to the grading. Note that the tricks performed during the self certification are not added to the trick tracking feature, it is a different feature.

An image is worth a thousand words, so here’s a screenshot of the self certification in action.

KendamApp Self Certification

Happy clicking!