« 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:
- The last turn of the selected game, along with its letters’ configuration (service
- The list of pivotal actions belonging to the game and to its last turn (service
- Periodically, the list of new actions to perform (service
where * stands for
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.
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.
Today I fixed a couple subtle bugs in Calliope core, and I am one step closer to releasing the first preview. To celebrate I’m going to publish some screenshots of the main interface in action, and a todo list of what is missing before the first preview/demo, hoping that will help keeping me on track.
Here comes the first screenshot:
You can already notice a couple differences here from the first screenshot:
- Buttons are labelled in English;
- The graphics of the letters has changed slightly;
- Rack has been redesigned too, and own letters have been highlighted in dark gray.
There are also some new elements: first of all there is a simple label on the top of the screen, indicating what the turn number is and what the current player is; there is also a green frame surrounding the word “preview”. That, as you can easily guess, means that the word is correct.
Now, if I move the letter “S” from my rack up into the board…
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.
As promised, I published a small online demo application that uses RaphaelWrapper (if you do not know what I’m talking about, read this other post).
Click here to see the demo
The code of the demo is open source and you can find it on github at this address, you can use it as a brief sample code for the library while I put up something more detailed.
Today I decided to publish the source of my Sproutcore-Raphael integration framework – called RaphaelWrapper – so that others can exploit it and hopefully help me extend it. I posted it on github, you can find it here: https://github.com/demerzel3/RaphaelWrapper.
RaphaelWrapper basically gives access to Raphael functions through a Sproutcore-friendly view called CanvasView. I’m using this framework as the basis for my bigger project Calliope, but since it is a completely independent component of the application I thought it could have been useful to make it public.
In the next days I will publish an usage example, and hopefully a little online demo as well.
Update (19/4/2011): New screenshots and Todo list of first preview
In the last post I introduced my latest effort: Calliope. As a further step I want to share with you a little more about the challenges and problems of the project, and about the solutions I came up with. Here is what I am going to write about:
- Data model – how the game is represented in SQL tables, and how this relates to real-time problems;
- Services Design – how the data model is being published by a series of RESTful web services;
- The Server – building the services to serve data using symfony 2;
- Sproutcore data sources – getting access to the data from the client;
- Sproutcore and Rapahel – something about the integration layer I built among the two libraries;
- Building the board – a little insight on how the game board – the main component of the client – has been built;
- Real-time magic – how real-time playing is ultimately achieved in the client.
I am going to publish one post (or more) for each point in the list, about once a week. If you have preferences about what topic I should cover first or questions about the project, just let me know in the comments (or even in private if you prefer) and I’ll do my best to answer.