By paddloPayday loans

Home > Mobile, Speed Tweaks > ActionScript 3.0 TouchEvent: Guaranteed Mobile Speedup

ActionScript 3.0 TouchEvent: Guaranteed Mobile Speedup

Tap screen

MouseEvent Works but TouchEvent Works better

The TouchEvent Object

I suppose old habits die hard, especially when those habits still work. (Some programmers are fond of saying, If it ain’t broke, don’t fix it! and the similarly dull-witted proverb, Don’t re-invent the wheel!) Well, with mobile devices, you’d better think about breaking old habits, and I put myself at the top of the dullard list for taking so long to make some adoptions. One of the first changes to make when creating mobile apps is to use the TouchEvent instead of the MouseEvent. In working on a game, I merrily kept using MouseEvent until I noticed that my apps kept getting stuck in the mud when I put them on a mobile device. So, I decided to give TouchEvent a try. Naturally, I couldn’t test in Flash Pro CS5.5; so I had to wait until I launched it in my iPhone. When I did, the difference was night and day. The sluggishness disappeared.

The good news is that MouseEvent and TouchEvent classes work pretty much the same as far as programming them into an app. I have no idea what’s going on with either under the hood, and I shouldn’t have to concern myself with those issues other than to know that one works better with mobile devices than the other. To get started, we’ll take a look at the sequence for setting up for TouchEvents, and while almost identical to MouseEvent, there are programming differences. First, though, click the Play button to see the little testing app on your computer. You can also download the Flash 5.5 Fla file and Client class by clicking on the Download button.
play button

As you can see it’s a simple little app to move a “Samurai” character left and right; up and down. The buttons are in Japanese, and if you read Japanese, you’ll realize that the characters look like a first-grader’s attempts to learn how to write in Japanese. (Feel free to make some better simple buttons using Japanese characters and send them along with any comments you may have.)

Possible Controversy: After I had finished this post, I ran across the following:

http://help.adobe.com/en_US/as3/dev/WSb2ba3b1aad8a27b0-6ffb37601221e58cc29-8000.html

In it is a note of caution:

Note: Listening for touch and gesture events can consume a significant amount of processing resources (equivalent to rendering several frames per second), depending on the computing device and operating system. It is often better to use mouse events when you do not actually need the extra functionality provided by touch or gestures. When you do use touch or gesture events, consider reducing the amount of graphical changes that can occur, especially when such events can be dispatched rapidly, as during a pan, rotate, or zoom operation. For example, you could stop animation within a component while the user resizes it using a zoom gesture.

That certainly makes sense, but I found that even using TOUCH_TAP, it was a quicker and far more responsive than listening for a CLICK event. There’s only one way to resolve this issue; try it yourself with a mobile app on a mobile device–any one you want. Use the Comment section to report what you’ve found. The sample app is as good as any for a trial, but feel free to create one of your own choosing.

As Chico Marx remarked in Duck Soup, Well, who you gonna believe, me or your own eyes? Believe your eyes and give it a whirl!

Just the Right Touch

Setting up the TouchEvent includes three imports:

  • import flash.events.TouchEvent;
  • import flash.ui.Multitouch;
  • import flash.ui.MultitouchInputMode;

That contrasts with the single MouseEvent import required when using the mouse event. However, prior to using the TouchEvent class you have to set up your mobile context with the following line:

Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;

That statement focuses the input mode to touch instead of a mouse event. I was unable to get the TouchEvent to work without the statement; so, don’t forget to include it in your program.

Finally, you need an event listener, and it has the same format as a mouse event except you use TouchEvent. Also, instead of using CLICK, use TOUCH_TAP, as the following illustrates:

upBtn.addEventListener(TouchEvent.TOUCH_TAP,moveNow);

With that knowledge, you’re all set to set up an app using TouchEvent.

Many Ears; One Handler

One of the big memory hogs in programming, especially noticeable in mobile devices, is event listening. Each event listener sets up a series of operations that have to keep listening for an event. Having a single event won’t help, but it’s a step in the direction of having a single listener (which will help). The following Client sets up an example of using the TouchEvent. All of the buttons are SimpleButton objects and the background is a big Sprite. Likewise, Sam3 is a Sprite that you can move around using tap on your mobile device.

?View Code ACTIONSCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
package 
{
	import flash.display.Sprite;
	import flash.display.SimpleButton;
	import flash.events.TouchEvent;
	import flash.ui.Multitouch;
	import flash.ui.MultitouchInputMode;
 
	public final class Client extends Sprite
	{
 
		private static var leftBtn:SimpleButton=new Left();
		private static var rightBtn:SimpleButton=new Right();
		private static var upBtn:SimpleButton=new Up();
		private static var downBtn:SimpleButton=new Down();
		private static var bkground:Sprite=new Background();
		private var sam3:Sprite=new Sam3();
 
		public function Client()
		{
			addChildAt(bkground,0);
			setControls();
			setSamurai();
		}
 
		private final function setControls():void
		{
			Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;
			upBtn.x = 825,upBtn.y = 19;
			upBtn.addEventListener(TouchEvent.TOUCH_TAP,moveNow);
			addChild(upBtn);
 
			leftBtn.x = 740,leftBtn.y = 106;
			leftBtn.addEventListener(TouchEvent.TOUCH_TAP,moveNow);
			addChild(leftBtn);
 
			rightBtn.x = 873,rightBtn.y = 105;
			rightBtn.addEventListener(TouchEvent.TOUCH_TAP,moveNow);
			addChild(rightBtn);
 
			downBtn.x = 825,downBtn.y = 202;
			downBtn.addEventListener(TouchEvent.TOUCH_TAP,moveNow);
			addChild(downBtn);
		}
 
		private final function setSamurai():void
		{
			sam3.x=(960/2); sam3.y=(640/2)+100;
			addChild(sam3);
		}
 
		private final function moveNow(e:TouchEvent):void
		{
			switch(e.target.name)
			{
				case "instance11":
				sam3.y -=5;
				break;
 
				case "instance1":
				sam3.x -=5;
				break;
 
				case "instance6":
				sam3.x +=5;
				break;
 
				case "instance16":
				sam3.y +=5;
				break;
 
			}
		}
	}
}

I set it up to be viewed from a landscape perspective because of a larger project I’m developing. Also, as you can see in the moveNow method, there are no “brakes” on the movement, and so the character can move anywhere, including right off the stage. Currently, I have a nicely working global movement system set up using a State Pattern, and I’d like to integrate both local and global movement into a single movement. Not only would this cut down on the number of listeners, but it would also provide a more interesting game. Figure 1 shows how it looks on an iPhone, and I’d like any feedback if tried on Android or other non-iOS devices.

The 960 x 640 size is compressed to fit in an iPhone environment

You also might want to swap out the TouchEvent for a MouseEvent and try it again in a mobile device. You’ll find that it gets “stuck” after a few clicks. As always, we’re interested in your comments and feedback.

Share
Categories: Mobile, Speed Tweaks
  1. January 16, 2012 at 7:17 am | #1

    Its nice to finally see a clarification on the subject. Most developers that blog about mobile development tend to suggest that people should use MouseEvent for the sake of an easier transition to mobile development in general. Great post.

    • William B. Sanders
      January 16, 2012 at 1:00 pm | #2

      Hi Nick,

      That pretty well described me until I actually tried it out. Also, I think that developers found that testing apps during development is easier using MouseEvent because they can test it without having to put it on a mobile device. I’m going to see if I can find why TouchEvent works so much better than MouseEvent on mobile apps and add a little post about the reasons behind it.

      In any event, I appreciate your kind comments, and I hope developers try it out where they are finding sluggish event handling where some kind of touch is required.

      Kindest regards,
      Bill

      • January 16, 2012 at 3:20 pm | #3

        I can definitely see your point and it might be true that testing becomes easier using MouseEvent. The problem starts when someone stays there and does not use techniques optimized for mobile (whether it is the TouchEvent or something else).

        After all, the end user will use the app in a device and not in an emulator so its ok to start testing without a device but if you do it for long then problems arise (you described these better in your post).

        At the end of the day, releasing a non-optimized app does more harm than good since Flash (as a platform) has already got some pretty big hits lately. Its up to us to prove that it can get the job done and it can do it well!

        • William B. Sanders
          January 16, 2012 at 8:22 pm | #4

          Hi Nick,

          You may have noticed that I did a follow-up about the Adobe docs warning off developers from using TouchEvent unless multiple gestures are involved. It might not be a bad idea to set up a series of test-apps to see. However, from my experience, those docs may not have been written using MouseEvents as comparisons when actual mobile apps were used in comparison with TouchEvent. I am hoping that the blog readers will do some tests on their own and find out how different mobile OS work. All I’ve been testing on is iOS, but I’d really like to see Android. (I’ve been slow in getting my Android tests going!)

          Kindest regards,
          Bill

  2. HB
    January 20, 2012 at 8:57 am | #5

    I guess the differences between the mouse and touch events lies in that touchs cover a bigger hit area than what a mouse or stylus would.

    My main concern is another, what if you want to have both simple touch events and gestures? If you enable gestures you have to resort back to the mouse, don’t you?

  3. William B. Sanders
    January 20, 2012 at 11:41 am | #6

    Hi HB,

    In working up the app, I used SimpleButton, and the hit area is determined by the Hit frame. The hitTestState of the SimpleButton class is the object used to determine what is the area counts as ‘hit.’ There’s nothing to indicate what event that state object encounters; so I do not believe that it matters whether you use a MouseEvent or TouchEvent. The hit area remains the same.

    Your point about using both gestures and touch is an interesting one. I imagine you’re talking about setting up code using,

    Multitouch.inputMode = MultitouchInputMode.GESTURE;

    but you also need to include,

    Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;

    I had not thought about that! We need a “workbench” post where we can examine a number of event handling situations where some of these issues can be tested. Thanks for bringing them up–better to work on them before you absolutely have to have them.

    You’ve probably already seen Adobe’s take on it at:

    http://www.adobe.com/devnet/flash/articles/multitouch_gestures.html

    and while helpful, it’s a tad general.

    Kindest regards,
    Bill

  4. HB
    January 20, 2012 at 11:56 am | #7

    You talk about the hit area of the button, I talk about the area Flash gets as being “clicked”, when you use a mouse the “click area” is rather small, just the hotspot defined for the cursor (which is a point). I guess when using touchevents instead of a hotspot you get some rectangle like a 3×3 area, or something like that.

    This is just a guess/theory, as using a finger is harder and less precise than a mouse cursor and you somehow need to make an app easier to use in such an interface, aside from just making bigger buttons.

    • William B. Sanders
      January 20, 2012 at 12:56 pm | #8

      HB,

      This is especially true if you have ‘fat fingers’ like I do!

      Cheers,
      Bill

    • HB
      January 20, 2012 at 1:35 pm | #9

      Looking at the documentation, TouchEvent indeed has a sizeX and sizeY properties that indicate the contact area, so my theory may be indeed right.

      Also, there is a thing I didn’t mention, but already assumed on my first reply, if my thought is indeed true, it would also explain why even using raw touch events needs more resources than plain mouse events. Having a single hot spot means there is no denying in which object on the screen you clicked, however, having an area means you must process that area, check all the objects it intersects with, and choose which one should receive the events (if not all of them do).

      • William B. Sanders
        January 21, 2012 at 9:17 am | #10

        Hi HB,

        I had noticed the Size properties. It is clear that Adobe considers MouseEvent to be faster for the reasons noted in the snippet from their docs (above.) However, in testing the responses using SimpleButton objects using the little app in this article, it was clear that TouchEvent worked better–it was more responsive and didn’t get stuck. What did you find in testing it on a mobile device?

        Thanks,
        Bill

  5. May 27, 2012 at 2:55 am | #11

    I’ve also been noticing that using MouseEvent on my Flex app is just awful compared with running a native IOS app. Even the “optimized for mobile” List objects are not too hot. Scrolling is ok, but selecting is not so great.

    So I will try out some TOUCH events and let you know how I get on.

    Hope Adobe can improve the performance of these things one day as its one of the most basic things which influence a users’ impression of speed.

    In other areas the performance of Flex mobile is great, such as 3D transforms and drawing.

  6. William B. Sanders
    May 27, 2012 at 9:05 am | #12

    Hi Sean,

    Flex, Flash Pro and Flash Builder all seem to have the same advantages and disadvantages when it comes to iOS working with compiled code. In one sense that’s good because no matter what flavor IDE you like using, it comes down to the same issues. I still favor Flash Pro because I can use its tools for creating graphics. However, I wish I could edit code like you can in Flex!

    Kindest regards,
    Bill

  7. August 27, 2012 at 11:53 am | #13

    How can I use with “Multitouch.inputMode = MultitouchInputMode.GESTURE” and “Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT”

    I use the touch gesture does not work. How do I fix this problem ??? Please help me :(

  8. sayk
    August 30, 2012 at 2:12 am | #15

    Hi guys.. Somebody pls hlp.. I’m getting trouble with the gesture zoom and pan.. It works fine but the movie gets stucked up like if it is having 1 0r 2 fps.. How to overcome this?? Is there any special actionscript class that can increase memory for the application. I want the 3 cores of the processor, the entire memory space, and also the graphics memory to be dedicated to this single flash application. The graphics in it is that much important. Must be smooth and flawless..

  9. sayk
    August 30, 2012 at 2:50 pm | #16

    hey i’ve found this gestureWorks so awesome. Is ther any way to author this without spending money??

  1. January 17, 2012 at 10:08 am | #1

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>