Occasionally it’s convenient to have an Android
RelativeLayout that references another layout element that hasn’t been defined at that point in the XML file. E.g.:
I am very pleased to announce a major update to Grio’s memory matching game: Flipout!
Flipout! is a game of luck and skill where you need to match pairs of cards… similar to the game of Concentration. We throw a few twists at you, however, to add to the challenge. What if suddenly the cards decided to up and swap themselves? Can you keep track of entire rows moving as one? And just when you thought you had a handle on things, one of the cards explodes, scrambling all of the cards around it!
Over the years, I’ve used a variety of editions of Eclipse with a variety of plugins. These days I try and minimize all of that and ask Eclipse to do as little as possible as infrequently as plausible. The below is a diary of sorts of the events that led to that choice.
A selection of ways Eclipse has failed me:
- It lies about custom key bindings being set, doesn’t actually set them despite indicating it has, and stores the bindings in the robust and never problematic Java-properties+XML standard format resulting in configuration files that look like this:
org.eclipse.ui.commands=<?xml version\="1.0" encoding\="UTF-8"?>\n<org.eclipse.ui.commands>\n<activeKeyConfiguration keyConfigurationId\="org.eclipse.ui.emacsAcceleratorConfiguration"/>\n<keyBinding commandId\="org.eclipse.jdt.ui.edit.text.java.search.references.in.project" contextId\="org.eclipse.ui.contexts.window" keyConfigurationId\="org.eclipse.ui.emacsAcceleratorConfiguration" keySequence\="COMMAND+SHIFT+V"/>\n<keyBinding commandId\="org.eclipse.ui.window.previousPerspective" contextId\="org.eclipse.ui.contexts.window" keyConfigurationId\="org.eclipse.ui.emacsAcceleratorConfiguration" keySequence\="ALT+COMMAND+CTRL+ARROW_LEFT"/>\n</org.eclipse.ui.commands>
Normally I could care less what format software stores its config files in, but despite the braindead format I’ve still had better luck editing this file by hand than trying to get Eclipse to handle it correctly. If your config file format is too error-prone for your software to handle, maybe it’s time for a change.
Recently I started work on an iOS game. I decided not to use the Core Animations framework provided by Apple and instead experiment with some third party game engines. I chose Cocos2D as it is an all in one package. It gives you the ability to add and control sprites, add cool graphics and animations, access to a sound engine and also 2 physics libraries.
If you have used XCode’s built in unit testing frame work , then you’ve likely hit one of the frustrating points of trying to test your application when making api calls over a network. (I’ll save you some time, and let you know the test dies before the call can finish). That’s not great, but it does not mean you can’t test your application and it’s ability to hit your api.
If you had read thru Apple’s iOS Human Interface Guidelines, I’m sure you’d notice that it mentioned about how your app should provide a responsive user experience. If the app is processing a lengthy operation, it ought to provide a feedback as suggested by Apple, “Subtle animation can give people meaningful feedback..” Consider this lengthy operation: loading image from a URL. This is a very common task. The problem is, UIImageView doesn’t have a built-in method that lets you load an image and at the same time give you a chance to provide a meaningful UI feedback such as a “subtle animation”.
On my most recent project I was building the client-side of a mobile app. I was a few days ahead of the backend in terms of functionality, but what was really giving me issue was the absence of any kind of test data. Rather than kill my momentum and allow the backend to block my development, I decided to build a quick API “emulator” that would allow the client to perform actions and feed it randomized test data.
Our most recent in house project was a fun children’s game called Whack Attack, and was built with Unity 3D and released for iPhones and android devices. Unity is a great tool, but it is definitely (and obviously) more geared for game crafting in the third dimension. Our game deals mostly with two dimensional sprites, although they are set in a pseudo 3d environment to attain some basic perspective.
On a recent project, we needed a widget that would allow users to select a photo from their Facebook albums. “Surely the new Facebook Android SDK must support this.” I thought. Alas, my hopes were unfulfilled. “Well, I bet there is a third-party solution for this!”, I surmised, but again, my search was for naught. At this point I decided to roll up my sleeves and do it myself.