Skip to content

How To Build An Cocos2d iOS App Communicating With A RESTful API – The View

Let us start with the view part of our REST web service integration to iOS and Cocos2d. Actually, I want to provide the same solution with Sprite Kit once I finished this series. But first things first.

The Background Layer

So, first of all we need a layer for our game. The layer is the component that takes our views. My layer is named CombatUILayer and is a subclass of CCLayer.

Here is the header:

What you will recognise is that I use a TiledMap fightScreen that actually contains a set of objects (textfields) that I populate with the values retrieved from the web interface. Here is how this looks in Tiled. Awesome tool for tiled maps by the way and absolutely beginner friendly.

FightScreen image with objects

My Web Service response will be a json representation of monster data that I will map into the tile map object fields. This way it will look later on the screen:

CombatUILayer

Here is the implementation of the CombatUILayer part:

Let me spend some words on this code here. As you can see the fightscreen is a tmx file that is loaded initially and that is shown in the screenshot above. I add it as background to my layer and tag it with a typedef.

Next I get the group of objects on my tiled map and assign them to objectGroup which is a CCTMXObjectGroup class. Using the Tiled tool I created an object layer and named it “ObjectLayer”. Now it is easily accessible via the tiled map.

I will reuse this object group later and iterate through it to update the values displayed on the screen.

Now comes the interesting part. I am loading the Monster information using the MonsterController class:

This is an essential point where in the background an asynchronous HTTP request is sent out to our Play! Web API.
I am sending requests for all monsters I need information for.

Because I am not knowing when the asynchronous HTTP requests will return any content I am pre-populating my tiled map fields with the functions:

Additionally, it allows me to at least show some labels when there is no internet connection.

As an example of what that private methods do:

As you can see I am iterating through all the objects in my tiled map. Then there is some interesting portion which I learned from Learn Cocos2d.

This method returns the rectangle of the tiled map object. So I get the label for the offense value of the monster and it’s position with the rectangle. This makes it very easy to draw any information in it. It is already correctly placed and I don’t need to bother about the layout anymore.

Now, I am looking for the object name to actually determine which information to show.

I am creating a label located at the rectangle position with a text that makes sense.

At the end I am adding the label as child to my layer, of course with a tag, because I want to easily find it again to update the label text with the HTTP response information.

Providing a callback to update the view

What we reached until now is a Layer that loads some labels onto a tiled map. Not our data from the HTTP request. To enable this we provide an update method for CombatUILayer:

You could schedule this method for regular repetition. I want that every after call it is unscheduled again. We just need it once to render fetched JSON information.

So, but what does those other methods do? Yeah, let’s look into it:

Do you see it? Yes, it doesn’t do much more than in our initialisation method. Yes, I know I am violating DRY principle here.

The method is called after the HTTP request returned with a successful result, carrying JSON information of our monsters. In the background those information were assigned to the BaseMonster object and are now accessible for this view.

Because I stringently provided my labels with reusable tags, I just fetch them and render the label again with the new BaseMonster information.

So far to the view.
The next post will describe how the MonsterController is implemented.