Optiscan has just been reviewed on CNET. They say, “Overall, Optiscan is a really nice QR Code reader. … It’s a full-featured app that should satisfy most users.”

Your app is on the App Store, and you’ve just sorted out the translations for all the metadata. So you go upload them on iTunes Connect, and then obviously you check that they look right in iTunes, changing country to make sure each language looks right. English is unchanged and obviously looks okay. France - tick. Deutschland- tick. Nederland - Whoah! That’s not right. My Dutch isn’t that hot but I know it isn’t identical to English. Check the rest, and it turns out Japanese has the same problem.

Let’s back up a step. Firstly, we’re changing our region using the My Store setting at the bottom of the homepage of iTunes Store.

That’s what we do for all the regions - and French works. Why doesn’t Dutch? Why doesn’t Japanese? I’ve been struggling to figure out what these two languages - or at least regional App Stores - have in common. And I have no ideas. Answers on a postcard to…

However, it is possible to check the localizations for Dutch and Japanese. The answer can be found in an Apple Support article, which I’ve summarised here.

On a Mac

• In iTunes, select any regional store other than Nederlands
• Quit iTunes
• Go to System Preferences->International->Language and drag Nederlands up above English
• Quit System Preferences
• Run iTunes and select the Nederlands regional store.
• Find your app. If you correctly uploaded Dutch metadata to iTunes connect, then your app’s App Store page will now display in Dutch

On a PC

• Forget the Windows language settings. They aren’t used.
• In iTunes, select any regional store other than Nederlands
• Go to Edit->Preferences->General and select Dutch (Netherlands)
• Quit iTunes
• Run iTunes and select the Nederlands regional store.
• Find your app. If you correctly uploaded Dutch metadata to iTunes connect, then your app’s App Store page will now display in Dutch

The same principle works for Japanese.

A common belief among programmers is that you should write code that says what you mean, because the compiler will probably do a better job at optimising than you can do off the top of your head.

On the other hand, Writing Efficient Android Code says “It is unwise to rely on a compiler to “save” you and make your code fast enough” and recommends that programmers do things like caching member variables (like array lengths) in local variables. This isn’t just premature optimisation; it’s trivial stuff we expect the most basic compilers to handle!

To understand why, it helps to know how your code ends up running on device:

(more…)

So you’ve acquired an Android Dev Phone 1 (the page goes to great lengths to avoid telling you that it’s just an unlocked G1). You’ve downloaded Eclipse, installed the Android plugin, and created a “MyProject” app that says “Hello World, MyProject”.

Now what?

Well, if you’ve been paying attention, you’ll have heard of two (or three) new paradigms:

• Tasks correspond vaguely to the user’s idea of accomplishing something, like “sending an e-mail”, and an associated “activity stack” which is hidden from the programmer.
• Activities correspond loosely to subtasks, like “picking a contact”.
• Intents are issued by activities (like SendEmailActivity) to launch other activities (like ContactPickerActivity).

But that’s about it. UI programming is traditionally a pain, which is why I like the iPhone SDK’s InterfaceBuilder — (more…)

Back in my original Save the Bits article, I noted that a foreign currency application on the iPhone, which I’ll refer to as AppX, uploaded 16K of data and downloaded 136K just to render a graph.

I said I’d get back when I’d run a packet sniffer. I’ve just done that, and the results aren’t pretty. (more…)

Your iPhone application is finished. The testers are happy. The graphics designers are sure that everything is pixel perfect. Your microsite is done. Your marketing material is ready. Your metadata is in order. All you need to do is to submit your application to the App Store and start raking in the dough.

Your heart sinks, though, because when you submit your application you receive a terrible error message - “failed codesign verification”. That’s all. No further details. No explanation as to what went wrong. Has all of your stress come to naught? (more…)

Just occasionally, I run into the kind of comment on a technical forum that leaves me speechless (or, more correctly, reaching for my keyboard). (more…)

Over here at Airsource, we’re not exactly retro, but we do care about computing resources, especially bandwidth. We like small sleek applications that perform well, not applications that use excess bandwidth, and run twenty times slower than necessary. With that in mind, I picked a relatively simple iPhone application that displays a currency exchange rate and a graph of recent historical movement, and measured its bandwidth usage. The results were amazing. (more…)

There’s clearly some confusion out there among iPhone developers about whether or not you need to release your IBOutlets. It’s actually pretty simple. (more…)

Google recently admitted to breaking the AppStore rules in their iPhone application, which fuelled a growing wave of resentment, prompted by the belief that Google were abusing their position as industry leaders to gain a competitive advantage in the market. The critics claim that a similar application submitted by anyone else would be rejected by Apple and never make it to the AppStore. Why should there be one law for Google, and another for the plebian masses? Shouldn’t the Google application be pulled from the AppStore until they abide by the rules, as others have been? (more…)