Developing a game intended for multiple end platforms can present some unique challenges to consider. For one, the differing pixel resolutions on apple devices over the years necessitate at least some different background images and layouts to accommodate the different aspect ratios. My initial technique to deal with this problem was to include a copy of each background for each device present in its scene, with its rendering switched off.
On Thursday, October 31st Google announced their new flagship phone, the Nexus 5. Along with their newest device they announced it would ship with Android 4.4, codenamed “KitKat” (much to the surprise of the entire Android community that was expecting “Key Lime Pie”.)
I received my Nexus 5 on November 7th, and have had some time to get used to KitKat as well as the device itself. Originally this post was going to review the device and the new Android version, but instead I want to discuss several of the key changes that have been introduced with 4.4 and my thoughts on them.
As one would expect with a fine product, it would work best right out of the box. In the case of Android Studio, some assembly is required. The issue I found was that a newly created project with default settings wouldn’t compile. I thought that this bug might have been specific to my setup, but after reproducing it on 3 different computers and finding several outstanding questions as well as a few open bugs with Google concerning the issue, I decided that a fix would be a fine thing to write up, hoping it enables other people to develop as painlessly as possible.
Apple and Steve Jobs started the smart phone revolution. Just 7 short years ago we had the first iPhone, a technical marvel in its day. The craftsmanship of not only the device but also the iOS operating system was a thing to behold. Apple continued with its excellence in both hardware and software design for years. Unfortunately, the wild ride has ended, at least for the moment. While the hardware has kept up relatively well (although there is not a heck of a lot of innovation), the iOS operating system has, sadly, regressed.
With the release of iOS 7, there are several changes in how you lay out and customize the appearance of your UI. In particular, the status bar is now transparent, and your views will show through it. Now this is a great opportunity to redesign your app and take advantage of this new look and feel, but what if you aren’t ready and you want to the old iOS 6 status bar back? Well, I’m excited to tell you that there is a way to do this!
Recently I started a project which required an iOS app to be locked in landscape orientation. The method mentioned below was always the standard for locking/setting the orientation, but iOS 6 deprecated this method. This post will show and explain some other options that I came across when investigating alternative options for locking the screen.
[code language=”javascript”]
[[UIDevice currentDevice] setOrientation:UIInterfaceOrientationLandscapeRight];
[/code]
The Android library is constantly growing. New widgets are built, and existing ones get deprecated. We’ll see how we can make XML layouts versioning more maintainable and more OO using the <include/> element. For that we’ll take as an example the ActionBarSherlock SearchView.
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:
eclipse.preferences.version=1
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>
overridepresentation=true
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.