How to Keep Top Scores in CloudDB via TagList

This is a sample app to show how to gather a top scores list from CloudDB.

Sample output:

In this sample, I avoid ListViews and just use Labels to show the top 5 scores and their player names, to benefit from text alignment in Labels.


The top Horizontal Arrangement has the data entry components:

  • A Texbox for the Player Name
  • A Textbox for that player's Score
  • A Button to enter the new player and score.

The bottom Arrangements have the Labels for the top 5 player scores. To make adding them easy, I set up their names, sizes, and alignments in Horizontal Arrangement harScore1, then copied the har using Ctrl-C. I then highlighted the enclosing Arrangement, VerticalArrangement1, and pressed Ctrl-V 4 times. I benefited from AI2 auto-numbering the Labels, making it easier in the Blocks Editor later when I needed lists of Label components.

Tag Design:
Unlike other tutorials on top scores, I am avoiding keeping a central list of top scores in my data base. Instead, I am saving each player's personal high score under his name, and using a CloudDB TagList call to gather the names and scores.

Adding a new score:

This design decision makes adding new scores simple, with no chance of fighting over central lists. On the other hand, gathering the top scores requires us to download every tag/value every time. If you want to avoid filling up your CloudDB with low scores, this is a good place to compare the new score with the worst of the displayed scores before deciding to store it in CloudDB.

At app startup:
when Screen1 Initialize
We also request a TagList when data has been updated:
when CloudDB1 UpdateDone

When the TagList arrives, we start the process of gathering all the scores and we clear the table where we will keep our top scores:

Global variables:

global max_pairs_limit

The high_scores table is built up by insertion, one score at a time, as they arrive in the CloudDB GotValue event, so it must have a stopper at its end, to stop loops looking for insertion points from falling off the end.

Walking the Tag List:

We use the global variable player_tags as a temporary queue of tags to read, one by one. We do not machine gun all the read requests at once, but instead ask for them one by one, depleting the saved global tag list player_tags as we request them. This benefits us by letting us test if we have depleted the tag list. If it is empty, we know we got all the tag values back, and it is time to call procedure loadLabels to load our high scores table into Labels.

Processing a CloudDB GotValue:

An incoming tag/value has the player name in its tag, and that player's score in its value. We call a procedure to possibly add that score to the high scores table, then we call load_next_score to see if there is another tag to request from the global tags list.

Adding a High Score:

To keep the high scores table in descending scores order, we loop past the scores that are higher than the new score to find a good insertion point into the table. Column 1 has the scores. To keep the table small, we check if we are past the global max_pairs_limit.

If load_next_score runs out of player names to request from CloudDB, it is time to display the high_scores table.


This is done in 2 passes:

  • clear all the labels in global ScoreLabels
  • walk the high scores table and the scores label table row by row, assigning the player names and scores into the labels, taking care not to fall off the end of either table.

max_score_cloudDB_taglist.aia (6.2 KB)

All blocks: