Android and iOS Market share – Who’s ruling the roust!

I recently came across this great article on techcrunch and thought it a worth while mention to you budding game and app developers.

According to this article Android now has 41.8% of the US market (up a staggering 5.8% on last quarter), whilst Apple’s iOS has a very respectable 27% (up 1% on last quarter). RIM also has a very respectable 21.7% (4% drop) and Microsoft a 5.7% share (1% drop).

From these figures it looks like Android is stealing the share from RIM and Microsoft and probably a few other lesser known platforms that share the bottom 2% of the market. I’m quite surprised to see Microsoft losing ground already considering that their offering hasn’t not long since left the gates. Maybe the new Mango update and Nokia alliance will help fix that.

With the imminent launch of Amazon’s tablet the Kindle Fire, does Apple have a fight on their hands I wonder. I think its a distinct possibility as its priced at less than half the price ($199) and Amazon have a large existing user base. Will we see Apple lose shares to Android when the Kindle Fire hits mid November 2011.

Marmalade SDK News – Marmalade 5.1.7 now available for download

The guys over at Marmalade have just released v 5.1.7 of the Marmalade SDK, changes include:

– All platforms: Fixed IwHTTP failing due to network failure during an operation
– PlayBook: Added detailed PlayBook setup and distribution information to
the Platform Guide and fixed distribution deployments.

– PlayBook: Add support for S3E_DEVICE_LOCALE and S3E_DEVICE_LANGUAGE.

– Symbian: Changed s3eCamera to clear out the GL context after stopping. This is
to free up VRAM on the Symbian Anna devices.

– PlayBook: Add support for assing to shared data folder via rst:// drive.
App must specify new playbook-access-shared deployment option
since accessing will bring up user confirmation dialog.

– iOS: Fixed s3eIOSGameCenter not working on devices running iOS 5.

Very welcome news on the IwHttp fix and great news for those deploying to Playbook and those using Game Center on iOS 5

Keep up the great work Marmalade!

You can grab the latest version of the Marmalade SDK from

if you’ve just returned from a recent trip to Mars and don’t know what the Marmalade SDK is then take a look at

Blog Expansion

Because I’m thoroughly enjoying blogging I am expanding my blog to other areas. As you may or may not have noticed, I have started adding new pages to the blog. The new pages include:

Jobs & Projects – Here I will post jobs or projects that you would like to fill or put out for tender. Please note that I will only post jobs related to the subjects specified as my readers probably aren’t interested in the latest cleaning or accountancy vacancies 🙂

Projects – A list of my recent, current and future projects

Test – You can safely ignore this section, I just use this section for testing various word press / web related things code out

Think Tank – I am expanding my blog to other areas as programming is not my only interest. The think tank covers these areas

Now I just need to find the time to blog!

Marmalade SDK Tutorial – Handling key inputs and the on screen keyboard

This tutorial is part of the Marmalade SDK tutorials collection. To see the tutorials index click here

In today’s tutorial we are going to cover key input and on the on screen keyboard (OSK).

As usual if you just want the associated article source code then you can Download it from here. If you want the details on the updated CInput class then please feel free to read on.

Keys and Key States

Marmalade maps device keys to an enum called s3eKey. if you take a look at the Marmalade SDK header file s3eKeyboard.h you will see that the list of mapped keys is quite extensive.

Marmalade uses key states to let us know what is currently happening to all the available keys on the device, for example we make queries such as “is the back key pressed” or “is the menu key up or down”. The following states are supported:

  • S3E_KEY_STATE_DOWN – The user is holding down the key
  • S3E_KEY_STATE_UP – The key is up and not being held down by the user
  • S3E_KEY_STATE_PRESSED – The user has just pressed their finger on the key
  • S3E_KEY_STATE_RELEASED – The user has just released the key

To query the state of a particular key we need to call s3eKeyboardGetState(key), which returns the states of the specified key. Note that its possible that a key can have more than one state. For example, if the user has just pressed the key then it would have both the S3E_KEY_STATE_DOWN and the S3E_KEY_STATE_PRESSED states.

On Screen Keyboard

The on screen keyboard is a software based keyboard that is available to phones and tablets that support a touch sensitive screen (You can call s3eOSReadStringAvailable() to determine if it is supported). You can bring up the OS specific on screen keyboard quite easily using Marmalade’s s3eOSReadStringUTF8() and s3eOSReadStringUTF8WithDefault(). These blocking functions display the operating system specific keyboard and then return any entered text. Its possible to suggest to the system (by passing a flag to these functions) what kind of keyboard you want the user to be presented with to cater for different types of input. The following types are available:

  • No flags – Standard keyboard
  • S3E_OSREADSTRING_FLAG_PASSWORD – A password entry keyboard
  • S3E_OSREADSTRING_FLAG_EMAIL – An email address entry keyboard
  • S3E_OSREADSTRING_FLAG_URL – A URL entry keyboard
  • S3E_OSREADSTRING_FLAG_NUMBER – A number entry keyboard

CInput Changes

Ok, now that the basics are out the way lets take a look at the changes to the CInput class. If you haven’t read the previous article that introduced this class then you can check it out here

If you take a look at CInput.h, you will notice a few major additions. The first few additions include header files required by the key and on screen keyboard systems:

#include "s3eKeyboard.h" #include "s3eOSReadString.h"

Switching over to the CInput.cpp class source file you will notice that we have added a few extra checks into CInput::Init()

// Check to see if the device that we are running on supports the keyboard KeysAvailable = (s3eKeyboardGetInt(S3E_KEYBOARD_HAS_KEYPAD) || s3eKeyboardGetInt(S3E_KEYBOARD_HAS_ALPHA)); // Check to see if the device that we are running on supports the on screen keyboard OSKeyboardAvailable = s3eOSReadStringAvailable() == S3E_TRUE;

This code basically ensures that the modules we are wanting to use are available on the device that we are running on.

Next we add the following code to CInput::Update() to ensure that the system updates key states

// Update key system if it is available if (KeysAvailable) s3eKeyboardUpdate();

Lastly, we add code to query key states and show the on screen keyboard:

bool CInput::isKeyDown(s3eKey key) const { if (!KeysAvailable) return false; // Return down state of queried key return (s3eKeyboardGetState(key) & S3E_KEY_STATE_DOWN) == S3E_KEY_STATE_DOWN; } bool CInput::isKeyUp(s3eKey key) const { if (!KeysAvailable) return false; // Return up state of queried key return (s3eKeyboardGetState(key) & S3E_KEY_STATE_UP) == S3E_KEY_STATE_UP; } bool CInput::wasKeyPressed(s3eKey key) const { if (!KeysAvailable) return false; // Return pressed state of queried key return (s3eKeyboardGetState(key) & S3E_KEY_STATE_PRESSED) == S3E_KEY_STATE_PRESSED; } bool CInput::wasKeyReleased(s3eKey key) const { if (!KeysAvailable) return false; // Return released state of queried key return (s3eKeyboardGetState(key) & S3E_KEY_STATE_RELEASED) == S3E_KEY_STATE_RELEASED; } const char* CInput::showOnScreenKeyboard(const char* prompt, int flags, const char* default_text) { if (!OSKeyboardAvailable) return NULL; // Show on screen keyboard and return the input string if (default_text != NULL) return s3eOSReadStringUTF8WithDefault(prompt, default_text, flags); else return s3eOSReadStringUTF8(prompt, flags); }

Using the new CInput features

If we now turn our attention towards Main.cpp, we can take a quick look at what has changed from our previous Touch example.

Firstly note that we got rid of s3eKeyboardUpdate(); as this is now handled by g_Input.Update()

We have also replaced the following code:

if (s3eKeyboardGetState(s3eKeyAbsBSK) & S3E_KEY_STATE_DOWN) // Back key is used to exit on some platforms break;

With this code:

if (g_Input.isKeyDown(s3eKeyAbsBSK)) // Back key is used to exit on some platforms break;

Not a great deal but a little more readable.

Now, we add a check into our main loop to see if the user has tapped the top of the screen. If they have then we show the on screen keyboard

// if user taps at top of screen then activate on screen keyboard if (touch->y < 50) { // Show on screen keyboard then print out the returned text to the debug trace const char* text = g_Input.showOnScreenKeyboard("Enter Text"); if (text != NULL) s3eDebugOutputString(text); }

If the user enters some text then we display the entered text to the debug console using s3eDebugOutputString()

Handling Android Back and Menu Buttons

Its worth noting that we’ve come across a number of Android app stores that require special handling of home and menu buttons as part of their certification process. These buttons should be implemented as follows:

  • Back Button – Navigate backwards in your application to the previous screen / menu
  • Home Button – Bring up the in-app or in-game menu

Well that concludes this tutorial. I hope you all find it of some use. You can download the associated Keys project source code from here

Happy coding and don’t sit on two legged chairs!

Marmalade SDK Bitesize Tutorial – Running out of memory and how to fix it

This tutorial is part of the Marmalade SDK tutorials collection. To see the tutorials index click here

Available Application Memory

Ok, this is the first of my bite-sized tutorials that I have started running alongside my usual meaty tutorials. I see these types of problems cropping on the forums often so I thought that I would cover them in small bite sized tutorials. Another good reason for bite sized tutorials is that I get the chance to blog a little more often as I can put one of these together in 10 minutes.

I’m pretty sure that most if not all of you Marmaladians have seen this dialog box before. If you haven’t then you are truly blessed 🙂

Marmalade out of memory exception dialog
Marmalade out of memory exception dialog

Heap 0 out of memory. Allocating 2048 bytes but only 576 available (540 LFB).
Increase icf setting [s3e] MemSize (current value is 14584).

This error is basically the Marmalade system telling you that it wants to allocate 2048 bytes but doesn’t have enough memory to allocate it, in fact in this case we only have 567 bytes left.

To solve the problem you need to edit a file that Marmalade has generated for you and placed in your data folder called app.icf. This file is the main app configuration file and is where Marmalade stores certain runtime settings such as how much memory to allocate to your program or how big to make the data cache etc..

To change the amount of memory available to your app simply add the following section to this file:


This value is the number of bytes to allocate to your app, in this case we have reserved 10MB. Note that without specifying your own MemSize you will have a default heap size of 3MB

If you are dealing with multiple heaps then you can set the the available memory per heap using:

and so on…..

Debug Memory

When running an x86 Debug build the Marmalade system will usually require additional memory to build resources and such. Marmalade provides an additional S3E app.icf option that allows you to specify memory size during debug builds.


Data Cache Memory

The Marmalade SDK uses a data caching system to store certain data that it is going to use during rendering for example vertex streams and materials. Its not possible to allocate these kinds of data on the stack as they must persist until rendering has finished (when the app hits IwGxFlush()). If you are drawing a lot of stuff using a lot of different materials then there is a good chance that you are going to run of data cache and receive an error like that shown below:

Marmalade Data Cache Overflow Error Dialog
Marmalade Data Cache Overflow Error Dialog

IwAssert failure (GX, 761).
Message: Data cache overflow allocating 336. Increase [GX] DataCacheSize (currently 800)

To increase the amount of memory available to the data cache use the following app.icf setting (The default is 16384 bytes):



Vertex Cache Memory

When the Marmalade SDK transfoms your geometry it requires some work memory to place the transformed vertices prior to sending them to the GPU to be rendered. For example, if you are using IwGxFont to draw fonts then the vertices that make up the polygons of your glyphs will be transformed by the system into this vertex cache then rendered. You can change the amount of memory available for vertex transform using the following app.icf setting:


Keep an eye out for more bite sized tutorials coming very soon!