35


POOR MAN'S BLOG

08.08.2010 12:31 - So this confused me

I'm working to add iPad support to a current iPhone app, and this confused me for a bit.

I've loaded up the app, as-is. I know I've not built in support for different
resolutions, so that everything is crammed in the corner is no surprise. But,
it seems like only part of the interface will accept touch events. Stranger,
when I add a bright background colour to my main view, and rotate the iPad
simulation, I see this constilation of four black rectangles spinning over
my interface. I only see them during the interface rotation animation.

Turns out, the only part of my UI to accept thouch events is the area enclosed
by these four black rectangles. Weird, no? I NSLog my way through the
view/subview tree, nothing to be seen. Everything looks great, what area these things?

I added a background colour to the window object. Result, I see little bits
of the colour during the rotation animation.

I hit on the solution after giving my window object 50% opacity. Now I can
see that this block of window colour moves without animation, always ending
up surrounded by the black rectangles, just before they dissapear at the end
of the animation. It's the window area which can recieve touch events, even
though my views render outside of it. Then I spot a checkbox: 
              
               Window: Full Screen at Launch.

I check it, and tada, the window colour goes full screen, everything is working again.

So, those four black rectangles? Well, you know if you don't set your main
view's background colour to match up with the rest of the UI (lets say black)
and then perform an interface rotation? You'd expect black + black, right?
Well, you get this seam of view background colour. Really, the view extends
everywhere, and these four black rectangles are the mask that makes the corners
of the screen black while everything rotates. So your black main UI makes  up
one side of the seam, the black rectangles make up the other side of the seam.

Cool, result. (But largley incoherent blog post...)


30.05.2010 12:35 - Shuffling arrays with ActionScript

Excellent article on shuffling arrays with ActionScript.

It includes a code sample for shuffling an array, which you should use:

    // In-place array shuffle. See Fisher-Yates.
    Array.prototype.shuffle = function()
    {
        var i = this.length, j, temp;
        if ( i == 0 ) return;
        while ( --i ) {
            j = Math.floor( Math.random() * ( i + 1 ) );
            temp = this[i];
            this[i] = this[j];
            this[j] = temp;
        }
    };

It uses the Fisher-Yates shuffle, which in rough terms, means that it works.


24.05.2010 23:43

It is currently Monday. (It says BLOG, not GOOD BLOG.)

(It doesn't even say BLOG WITH AN RSS FEED.)


21.05.2010 10:28 - PATENTS - [[draft]]

Re:
http://digitaldaily.allthingsd.com/20100520/googles-royalty-free-webm-video-may-not-be-royalty-free-for-long/

The only way to know that you are free of patents is if everyone with a patent
sues you for infringement, and they all loose.

21.05.2010 09:36 - SVN AND THE CLEAN COMMIT - [[draft]]

While plotting on the virtues of Git's guarantee that if you commit something,
you will be able to check it out again in the future, this example came to mind:

  Alice : Commits class A
  Bob   : Checks out A
  Alice : Renames A to C, commits
  Bob   : Without touching A, uses class A in B, commits

Now, Alice and Bob have checked out code which compiles, however the SVN HEAD
will not compile. Oops.

Now, most of the time, Bob doesn't use class A, he really uses class X and there
is no conflict and HEAD still builds. Everyone gets on with life.

But Git is different. When Bob tries to commit, regardless of whether it might/might
not work if he were to just automatically merge on the server, he'll get you-must-update
warnings. And then he has to learn about rebase, or merging if he has local commits.
And then Git gets a bad rap for being hard to use.