Archive

Monthly Archives: October 2014

Design Decision

2014-10-08
Programming

In the midst of working on CageFace, two design questions arose.

The program requires that facial images of Nicholas Cage be embedded so that they can later be superimposed. This could be performed manually, with each asset being loaded and processed at startup to determine it’s attributes, or they could be precalculated. The former offers an advantage in two forms: it cancels out API differences between platforms, and it is easier when developing because all that’s needed is to dump images of Nicholas Cage into the start folder. The second offers an advantage in startup time. Perhaps a first-time popup is in order.

The second question is what to do after the users click the ‘take picture’ button, labelled, ‘NOT THE BEES’. If the original image is stored, that increases the memory overhead of the application significantly, and means the image has to get copied every time the ‘NICHOLAS CAGE’ button is pressed to superimpose faces (thus adding to processing time). It is possible to condense the two buttons into one which will take the picture AND do the processing for NICHOLAS CAGE, at a cost of not allowing faces to be re-CAGE’d.

No clear solutions yet.

Android Permission Gotcha’

2014-10-06
Programming, Rant

Android development has improved by a few leaps and bounds since the last time I touched it, but it’s still fraught with numerous tiny inconsistencies and gotchas. One I ran into recently came in the form of writing to an SD card. In my AndroidManifest.xml, I added the WRITE_EXTERNAL_STORAGE permission. Three times I failed, not sure why despite the permission I was still getting access denied.

Attempt 1:
“<uses-feature android:name=”android.permission.WRITE_EXTERNAL_STORAGE” />”
If you don’t see the issue, that’s okay. The problem was I used ‘uses-feature’ instead of ‘uses-permission’.

Attempt 2:
“<uses-permission android:name=”android.permission.WRITE_EXTERNAL_STORAGE” />”
This time I used the correct tag, but had the uses-permission _inside_ the application tag.
This compiled and ran without problems, but led to the permission error I mentioned above.

Attempt 3:
Okay, move the tag outside of the application. Should be okay? Compiled alright (still). Run. Crash — permission denied. The problem? The tag came after . I’m no expert, but I’m fairly certain that the order of tags inside a manifest should be pretty irrelevant. {“a”:10, “b”:20} is the same as {“b”:20, “a”:10} in my mind. Sibling nodes have no ordering guarantee. (In my world at least.) But you can’t always get what you want. After moving the permissions above the application tag, everything went well.

It’s not hard to imagine that this sort of hiccup would be baffling and upsetting to a newcomer. Make note of this as one more edge to file off the SDK.