First of all, I am not claiming what I say bellow is the one truth, my game was not a huge success but one thing I never got was complaints about the joystick implementation (other than early ones about jumping by going up)
This may be a bit short, I figured this was a bit known by now but I keep seeing it happening even in games done by extremely smart people in these forums, so here it is: my study on touch screen and virtual controls. Most what I write here can be observed on my Misu Misu Kaboon (android) or Bomber Cat (ios, same game different name.)
Bellow is a typical touch screen game layout:
One typical action many developers take, is to make these things pixel perfect controls. This means, you touch a pixel in the area, and you are giving input. If you move your finger out of the area, it cancels out. This is a bad idea. Many things can make players constantly leave the control area, from getting too into the game (and start dismissing the visual overaly) to plain sweaty fingers, sometimes big fingers can easily get out of the area too.
A solution often done is to give the player an option for bigger controls. Although a nice feature to have (visually increasing the size of controls) it is not a good fix because players can end up looking at more GUI than the game they want to play, and this is true even if the controls are translucent.
So, my first rule, when I implement a touch control, is to follow the next layout:
As you can see, I am adding a color coded “aura” box around each control. What this means is that the player can touch anywhere within that color box (that will actually be invisible to the player) to give input to the game. The only “real” functions of the visual controls are to give the player a general idea of where to tap/touch, and also to define a center area. If the player taps at the right of that DPad, as long as its within the red box, he will get left movement. If he hits all the way to the right, then he moves right. Although you can do analog (multi-speed) movement with this, you should cap it so that you reach max speed way before you get to these margins (this is hard to master and I admit I was never happy with my own implementation, in fact my iOS and Android versions have different settings as I kept monkeying with this long after release.)
For the plain on/off buttons, the idea is simple: tap on the box, you get that input.
Now, lets go into some more advanced stuff!
What should happen if a player has his finger in the DPad, and he slides his finger outside the area? This is not as simple as you may think. Although the player may had been very conscious about tapping within the margin, it’s very likely him leaving the box was not intentional. I have defined this rule for myself: When the player taps within the hot-spot, I store the touch-ID. Every time any event occurs I am looking for this Anchored Finger ID. If the player has not let go of the screen, I assume he is not interested in disabling input. His input should continue, and based of this screen, if he is to the right he just keeps going right. As soon as I get a Touch Event Ended event that matches the anchored finger ID, at that point I set the touch input anchor variable to -1 and all movement should stop (until a new touch event id is captured within that box.)
But what about the binary buttons?
Binary buttons can be very similar. Misu Misu Kaboom had a charge mechanic similar to the one in Mega Man X. It is very likely the player may want to hold onto the fire button for a while, even if his finger slips. If the game was too strict and the player finger slips a few pixels, he may release a nasty bomb that may destroy the burgers he was trying to collect. Not good, so, the shoot button gets the same treatment: every finger that taps it becomes anchored, no matter how far on the screen it moves. Heck, it may go to the upper left corner and it should remain anchored until the player intentionally lets that finger go. This makes 100% certain the player wont accidentally stop charging unless he does a solid physical decision to just let go.
In other games you may want the player to keep shooting no matter what, or it may be a turbo button that is required to dash over small pits like old Super Mario Bros. So, depending on the importance of the input, you want to make sure the player cant let go accidentally by sliding too far. Anchor that touch if it’s that important for the game.
But what about…
There is a limitation with touch controls. With old NES, you were able to hold on to a jump button and with the tip of your thumb you were able to shoot. Since it’s the same finger, all you get out of a touch screen is that the thumb gets centralized. You can add overlapping boxes, but in my experience, this didn’t feel “right.” Instead I came up with a dragging mechanic.
What I do here is that should you drag your finger over an input area, it activates, but does not anchor. This allows me to anchor on to my shoot button, and from there drag into my jump button. Now I may find myself airborne and now I can actually let go of that charged shot mid air, all with just one finger. Since my touch did not start inside the jump area, I can leave the jump button and I stop jumping but keep charging. I never set my own jump button to anchor because I didn’t dim it important to jump like a frog all the time in my game, but I could have just as easily set my jump button to anchor and shoot to also dub as an activate-on-hover button, allowing for the reverse mechanic. I think it would not be too intuitive for a player if the finger sometimes anchors to the jump and other times to the shooting button. I would suggest if binary button binding was dimmed necessary, to pick one anchoring button, not two.
Finally:
This last figure just shows how a finger can anchor to the fire button, drag over the jump button, and then drag up to stop jumping.
BTW, in my game, the jump button is not to the right, but on top of the shooting button. The neat bit about this is that it dubs as a pseudo-gesture. Dragging your finger up from the shoot button, well, jumps! 
I don’t have the game at hand to take a fresh screenshot so sorry for the recycling of promotional shot used in the Google Play store.
There are many things I did wrong. I never gave the player a way to re-organize controls, nor resize the visual queues, this mainly because I did my own GUI and it was horribly hard to tweak (in the future I hope to use nGUI.) I never tested the default acceleration scheme either with other people, nor did I offer ways to adjust it. And I’m sure there are many other mistakes that I can think off, but I think the points I outlined above are very important.
All this goes down to two basic rules:
Make it VERY easy for the player to start doing what he wants to do.
Make it hard for the player to accidentally stop doing that thing.
If a player accidentally stopped moving, they ARE going to complain, and they may do so in the form of 1 star ratings.
Remember: the only reason you are adding visual DPads on a game is so the player can guess the gestures and motions he must execute to play the game, not to actually emulate the restrictive nature of a real world gamepad. If you think you are supposed to emulate those restrictions, then you are wrong. In a real world dpad the user will know he let to of a button because he will feel the bumpy surface move under his finger. There is no such tactual feedback in touch screens.