Well just like a Thursday morning, I’m over the hump. Getting into the android slump is always discouraging, but once through the middle of it (you’re never always out), things start to look up. I had a rough few hours last block, and I waited until I was done until I posted to keep my mood light. So, where are we now? We have all the core gameplay working, the tile selection works, the word lookup and matching works, and it’s blazingly fast.

So as I mentioned before we had some issues with Android, the question always comes up ‘You don’t care for android, but why do you develop for it?’. It’s true, I don’t care for it, for a few reasons, mainly the JAVA bit (which I don’t need to touch much thanks to cocos2dx), the fact that I have to write for 2.3 devices which make up 60% of the market today (shocking as 4.0.3 is out). [Devices can’t update, and most manufacturers still ship 2.3 for low-end phones as it has much cheaper licensing costs, and less restrictions from google]. So that’s never fun. So the reason why I do develop for it… I simply like a challenge, and I like keeping my coding skills up to par. I can write OBJ-C in my sleep, it’s my day job, and I do rather well at it. That’s work for a client, I always tell clients to avoid Android when they can, as the work / cost is 10 times that of iOS and the return is about 1/10th. This is pretty well known now in the market, unless you’re doing a utility app (banking, finance, fart app), for games it’s not viable yet.

But I like c++, but I really love cross platform development. I always write my objc projects in a a custom environment which runs on Mac, iPhone, iPad all within the same code. It is a bit of setup work, but in the end I have one code base for 3 platforms. With cocos2d-x I can get 5 platforms potentially (more, but only 5 I’m currently interested in), all on the same code. That’s a really cool concept, and Android does have a market. I may not like the software, but the hardware is kind of cool, and I really like users, as well as my games. My games do well on iOS ratings wise, so that encourages me to port them to other platforms. They don’t move many units on Android, but the feedback is great, so that’s encouraging. So yes, in short I bury the hatchet with the platform to deliver to the customer.

Ok so some technical things! Wow reading a huge plist / processing it on Android was unbearable, something that took 1 second on a iPod takes 11 minutes on my android tablet (same chip as an iPad), I blame the os. So that led me to some cool programming which I carried over to all the platforms. Basically I already was generating this huge dictionary from the plist on Mac, so I then just added a call to save it as a binary file to disk. I then take that binary file and load that into memory, and parse it into an array. Basically doing the same thing, but pulling out the middle man of reading in a plist / parsing it into a primitive array. That said, I got the loading time down to 200 milliseconds on android. That warrants a smiley… 🙂

Next thing I hit was errors on Android which I didn’t see on iOS. These were memory issues. I created a custom class that will determine your resolution and pull up the right assets. If you’ve done android from iOS in cocos, you’ll know you really want your ‘-hd’, ‘-ipad’ files to work instantly. Well they don’t, so I created a simple class that does similar logic and appends the file suffix depending on your resolution. Anyway, the issue I hit was that the memory sometimes go bad after making the call. I was passing const char* pointers out of the methods, which ‘is’ correct, but when setting multiple labels, etc to the same variable it would get lost.

I didn’t set up the overly complex way of debugging c++ code in eclipse on android, so I had to do some logging to catch the issue. It was pretty apparent after a while it was memory gone missing, as it would work on a relaunch, and fail somewhere else. (It always worked on iOS). So I then looked at ways to keep that memory around, using strdup worked great, but it caused leaks, as I was returning the value with a strdup, so no way I could release it. But then instead of fighting c solutions, I put on my cocos2d-x hat, and then simply returned a const char* as before, but fed that into a CCString, that then worked until the end of the method and cleaned itself up properly, no leaking! I had that issue a couple places, as it’s a word game, very character centric!

Anyway, not much insight here, this is more of a log than a development lesson, if I had the time and there was interest I could cover some of these topics in more depth. For now I’m just fighting the clock to get the app done. But we’re getting close the core gameplay is working, now I just need to start adding some of the other displays, (timers, lists, etc), which should prove challenging as they’re custom drawn views, but challenges are fun. (Usually after the fact)