The show is the brain child of Jeremy Saenz (aka ‘the Flex Gang$ta’) and is intended to be a fun discussion about all things technical but primarily focusses on Flash and Flex.

Jeremy is an extremely talented developer who also raps about the Flex framework. (Video evidence provided below)

The cast is made up of Nate Beck and Aaron Boushley of ZaaLabs, Dan Florio of PolyGeek.com, Jeremy Saenz and myself.

It’s a pretty scrappy group. Dangerous sure, but I don’t know if I’d go so far as to describe us as ‘gangsta’. I guess you can be the judge.

Here’s the show details:

We introduce the GangstaCast crew and cool our episode 1 nerves to bring you 2 full hours of talking. Multitouch Matt gives us a rundown on multitouch and gestures in society, Dan talks about Runpee and the Nexus One, Aaron shares his woes on Alchemy and Javascript/HTML5, Jeremy talks 360|Flex…. And Nate likes stalking celebrities.

Here’s the Flex Gangsta blog and you can download the mp3 here.

Thanks for letting me be a part of the show!

And just for good measure here is one of my favorite Flex Gangsta music videos. I couldn’t resist:

Sorry for any slow down in tutorials and blog posts but we are scrambling to learn this new parenting business.

Ethan hasn’t yet fully grasped the finer details of Object Oriented Programming but I have no doubt that he’ll be teaching me ‘best practices’ in multiple programming languages before he can walk.

He’ll likely be my multitouch alpha tester once he gains some control over his arms.

I’ll report back on how that’s going in a few months.

I just pulled down VMWare Fusion 3 and noticed I was able to receive raw touch data from my HP Compaq L2105tm monitor.  I’m sure there was a way to do this with Fusion 2 but I didn’t find it.

In Fustion 3 I opened up the settings for the Windows VM and specified the connected monitor USB device.  In my case, it was named ‘Quantra Optical Touch Screen’.  A name that just rolls off the tongue.

You can go grab VMWare Fusion 3 here.

I prefer working in OSX and I’ve been using Bootcamp to bounce around between operating systems in order to test different multitouch applications.  You might have noticed the bumpy transitions in my screencasts.

I like to think I’ll be more productive with this setup but the truth is I’m even more likely to loose countless hours exploring some sort of multitouch mapping application.

I’m speaking on ‘The Benefits of using Zip Disks for Computer Storage’. My entire presentation fits on 5 Zip Disks!!!

OK, I’m actually speaking on Multitouch on the Flash Platform. I’ll be showing new code, new multitouch applications and showing how stupid simple developing for multitouch interfaces can be.

Admission to this event is free, all costs are covered by donations and sponsorships so if you are interested in hearing me speak (and I know you are) zip on over to register and be sure to stop me and say hello.

I don’t think gestures should be patentable.  A gesture is a common movement that expresses an idea or meaning.  Gestures by their very definition are commonly used.  If Apple is the only company allowed to use certain gestures in their program then they aren’t really commonly used and therefor aren’t really gestures.

Imagine if only one club or organization was allowed to use a certain handshake.  Would it be a gesture?  Nope.  I’d be a secret f**king handshake not a gesture.  And you can’t patent a secert handshake.  (lord knows I’ve tried)

Today multitouch is on a variety of different platforms, devices and operating systems.  Microsoft has Windows 7, the Android OS is multitouch capable and there are even some Linux distros getting into the game.  We should be focussing our efforts on coming up with an agreeable set of gestures that users can understand and can expect will perform certain actions across all of these operating systems.   Patenting gestures doesn’t help this cause.

Apple hasn’t really been challenged on these patents, as far as I can tell.  However, Apple recently has begun rejectingapplications from their own app store based on the application’s use of gestures deemed ‘associated solely with Apple applications’.  This is bad news for anyone who wants the use of gestures to survice across multiple platforms and devices.  This is bad for the general public’s understanding of multitouch

What makes me worried is that Apple may not stop at regulating their own devices.  Apple may believe that their patented gestures are enforceable across a variety of different platforms and devices.  And while I’m super rich and world famous, I don’t have enough greenbacks to fend off the Cupertino lawyer mob squad just because I’ve used gestures in one of my amazing flash multitouch applications.

Here’s an image (via Patently Apple) of there latest multitouch patents:

Why we shouldn’t fear Apple

Turns out that a number of developers have been using Apple’s multitouch gestures for their own research, applications and profits for a pretty long time.  These ‘Apple tribute artists’ are particularly nasty because they were developed long before Apple started dabbling in multitouch.  In particular, the pinch and zoom gesture has a bit of history.

• Jeff Han copied the Apple iPhone pinch and zoom gesture in his presentation at the Ted conference in 2006 or about a year before the iPhone was launched.
• Bill Buxton pirated Apple’s multitouch technology and did gesture research at the University of Toronto in 1984, the same year the Macontosh computer came out from Apple .
• Myron Krueger was stealing Apple’s pinch and zoom gestures as early as 1983.  This video from 1988 is pretty amazing.

And it turns out that multitouch technology predates all of these guys.

So, what’s it called when someone copies your work but has the nerve to do it long before you’ve created that work?  I think they call it ‘prior art‘ and it means most of Apple’s gesture patents are a complete sham.

Patents bad, Copywriting good

Apple should instead focus it’s efforts on copywriting the way that it implements each gesture.  We’re all geeky programmers here and we respect the fact that Apple Inc. has written proprietary code to for tracking individual touch points.  That code is yours.  You can defend that.

What you can’t claim is the ownership of common meaningful movements.  Jeff Han, Bill Buxton, Myron Kruger all knew gestures were not patentable.  When will Apple figure it out?

Question for Apple:

• Shouldn’t we try to get developers to standardize on gesture meanings for ease of use across varied platforms and applications?
• If a gesture is a common movement that expresses meaning, then shouldn’t we be looking to make these ‘gestures’ more common?
• Couldn’t we do that by encouraging all developers to use them in their applications regardless of platform or device?
• Doesn’t Apple want to save the lives of countless baby unicorns?

The book is completely free and you can download a pdf copy here.  The book is a short read.  It’s about 60 pages and most of it is more reference material for people building their own systems.

The content is also almost one year old and this content seems to be changing rapidly.

Here are some chapter details:

1. Hardware Technologies

• Introduction to Hardware
• Introduction to Optical Multi-Touch Technologies
• Frustrated Total Internal Reflection (FTIR)
• Diffused Illumination (DI)
• Laser Light Plane (LLP)
• Diffused Surface Illumination (DSI)
• LED Light Plane (LED-LP)
• Technique Comparison
• Display Techniques

2. Software & Applications

• Introduction to Software Programming
• Tracking
• Gesture Recognition
• Python
• ActionScript 3 & Flash
• .NET/C#
• Frameworks and Libraries

In the last section ‘Frameworks and Libraries’ you will find a section on multitouch simulators.  My open-source SimTouch application is mentioned which is pretty cool.

Now how do I get them to plug my website?

I came across this fantastic video with Bill Buxton of Microsoft on Natural User Interfaces (NUI). Bill Buxton has been playing around with multitouch and alternative user interfaces since the 80s.

What I thought was most interesting about this video was the thought process that went into it. It’s clear that Bill is really trying to understand what will be the most natural way to interact with these new digital devices. It’s cool to see creative thinking folks turn problems inside out in order to find a solution.

What to see a different aspect of some digital content? Don’t move the pixels on the phone, simply move the phone.

This group has worked on a ton of multitouch research, projection based multitouch white boards, and were instrumental in the development of Seadragon.

Bill, you are radical. Call me and we’ll catch a drink sometime.

Yesterday, I noticed that CS5’s Device Central has a multitouch simulator that is pretty robust.  While this simulator is focused on mobil devices it may still be very useful for developers who don’t have access to a multitouch device or in my case are too lazy to switch to Windows 7.

Device Central also works great while debugging.

Check out the video:

Device Central CS5 – Flash Professional Integration from Mark Doherty on Vimeo.

And read more here.  Thanks for posting this Mark Doherty!

The team at HPI took a multitouch table top concept, Frustrated Total Internal Reflection (FTIR), and turned it into an interactive floorboard. The design isn’t exactly an economically viable option but it does show a creative use of multitouch technology.

Ironically, it isn’t the FTIR that pricey but the cameras,  displays, or projectors that adds price to the project.  Seems like this would get pricey after about 10 feet or the size of a normal throw projector.

The video shows one FTIR panel which is able to track and identify a user by the sole of their shoe.  The team at HPI went one step further (pun intended) by invoking menus, keyboard and tracking body movement by looking a foot balance.

Typing on this might be even worse than my PS3.

To learn more about HCI check their website: http://www.hpi.uni-potsdam.de/

And the specific multi-toe project here.

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

was changed to:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

The general interpretation of this change is that Adobe’s new ‘Compile for iPhone’ feature would violate the TOS (terms of service) agreement.  This is all going down 3 days before Adobe is expecting to announce their new CS5 suite.

Now I’m not saying that Apple is intentionally sending a big f-you towards Adobe . . . actually . . .  ok, yeah,  that’s what I’m saying.

The timing of the TOS change couldn’t be worse for Adobe.  On Monday, Adobe is launching CS5 and one of the biggest expected announcements was the ‘Compile for iPhone’ (highlighted at the Max keynote)  Peter Elst of Adobe even goes so far as to call the timing ’a malicious move‘ by Apple.

Adobe employees have spent countless hours developing, writing example code, and documenting the process of building flash applications for the iPhone.  This is an astronomical amount of work and while it might not be a financial burden for Adobe, it is in fact dispiriting for all of the individuals who worked hard to make this feature possible.

Adobe’s official twitter response is:

We are looking into the new SDK language. We continue to develop Packager for iPhone OS which will debut in Flash

The CS5 code is and has been in lock down for sometime.  One would expect for Flash CS5 to ship with the ‘Compile for iPhone’ feature still included.  The good news is developers should be able to get Flash applications on to their own personal provisioned phones but it doesn’t look good for submission to the Apple App Store.

Why Apple, why?

(I previously wrote about this here)

Apple has always enjoyed controlling every aspect of their product line.  Allowing Adobe to partake in development tooling means that Apple has less control over one aspect small aspect of iPhone universe.  If Apple is truly the cell phone ‘Soup Nazi’ then any loss of control is a bad thing in their mind.

A large influx of Adobe generated applications means that Apple would suffer more App Store distress and an extreme slow down to the application approval process.  Add increased traffic from iPad application submissions and you have a recipe for disaster.

I’m also suspicious that Apple may have wanted to discourage their developers from being able to cross compiling all of these applications to other mobile operating systems.  (Check out ‘One Application, Five Screens’)  Apple’s unique and increasing library is one of it’s largest selling points when courting users.
How Apple, how?

Apple isn’t looking to turn away applications made in JavaScript.  Solutions like PhoneGap should continue to work correctly however Unity, OpenPlug ELIPS, MonoTouch, and XMLVM are all question marks. I’ll go out on a limb and guess that Apple won’t be too restrictive with these other cross compilers.

Apple will most likely be enforcing this new rule by take a strong look at the additional and mandatory binary signature that is required to make Flash on the iPhone work.  Do these other cross compilers have a similar binary signature that identifies them as being cross compiled?  (I’m asking because I have no idea.  Comments anyone?)

Adobe Could Respond

Adobe originally didn’t seem worried about the possibility of this:

Adobe’s Jeremy Clark has said:

iPhone applications built with Flash Platform tools are compiled into standard, native iPhone executable packages and no runtime interpreter is necessary to run the application. Over 30 Applications built using the Flash Packager for iPhone have already been accepted in the iPhone app store so we’re confident that our method fits within the rules of the iPhone App Store.

I hope that Adobe’s confidence in the ‘old rules of the iPhone App Store’ didn’t blind them into not having an alternative plan.

What kind of alternative plan?

I hope that Adobe is considering letting Flash for the jailbroken iPhone quietly slip out the backdoor. I have theorized that Adobe could do it. I just hope that this prediction comes true.

Or maybe Adobe has a far better alternative that they will wow us with on Monday.  I just hope that Adobe isn’t (as John Gruber puts it) royally fucked.

Other suggested responses?  Quit developing software for the Mac maybe?

Be sure to comment with ideas and opinions.  Thanks!