Building Calliope – Sproutcore data sources (Part III)

« Go to Part II

Game (aka Local) data source (..continues from Part II)

Before going further, let’s recap what data the application has to deal with during its operations:

  1. The last turn of the selected game, along with its letters’ configuration (service */turns/{number});
  2. The list of pivotal actions belonging to the game and to its last turn (service */actions?pivotOnly&turn={turnNumber});
  3. Periodically, the list of new actions to perform (service */actions?afterAction={actionId}).

where * stands for /me/games/{id}.

The first item – related to the current turn and letters – has been pointed out in Part II. In this part I’m going to dig deeper into the last two points.
Continue reading


Building Calliope – Sproutcore data sources (Part II)

Game (aka Local) data source

In the local scenario the user has logged in, has selected one of its open games (which list if handled by the global data source) and is taken to the board in order to be able to play the game. In this scenario, the application must load the current game state (that is, the position of all the letters in the game), present it to the user and update it continuously, replicating the actions of the other players.

Notice that this task is more complicated, and cannot be solved using the “load-all-retrieve-by-id” approach used previously: the data involved is potentially quite big (imagine a game with a hundred turns, for example) and could take more than a while to load; actions are pumped in continuously, and as such cannot be loaded once and for all, but must be refreshed constantly.
Continue reading

Building Calliope – Sproutcore data sources (Part I)

If you don’t know what Calliope is, please read this other post before continuing on.

In this post I’m covering the problems I encountered while implementing data access in the client-side of Calliope using Sproutcore data sources. If you are starting now to have a look at Sproutcore way of handling data, I suggest you have a look at these pages in the official documentation:

The official documentation is well written, but it uses very simplistic examples that fall short in real word applications (even a simple one like Calliope) and it is missing the “big picture” of how things work. These, I think, are the main reasons why I – and I am not the only one – had such a hard time figuring out how to use the data store effectively.

With this post I hope to fill some of the gaps of the official documentation, by showing what problems I faced and how I resolved them.

Continue reading

Building Calliope – Services Design

If you don’t know what Calliope is, please read this other post before continuing on.

In this post I’m going to describe how the web services forming the backend of Calliope have been designed and built. I didn’t concentrate much on designing them because I was eager to reach a visual result, so I know they’re not the best possible; I’m open to criticism and I hope with your help to improve the design.

Continue reading