jQuery Touch Plugin

[manifesti...@gmail.com]

Greetings,

I have written a jQuery plugin that can use the built in Touch methods
including ontouchstart, ontouchend, ontouchmove, ongesturestart,
ongesturechange and ongestureend.

You may specify what options you want available for the specified
target(s), including: animate, dragx, dragy, rotate, resort and scale

LINK: http://plugins.jquery.com/project/touch

DEMO: http://www.manifestinteractive.com/iphone/touch/

- Peter Schmalfeldt

[Kyle Farris]

Dude, fantastic job. I love jQuery and I love iPhone development. I
will likely be using this on my next iPhone project (if necessary of
course...).

-Kyle

On Jul 27, 5:42 pm, "manifestinteract...@gmail.com"

[RobG]

On Jul 28, 7:42 am, "manifestinteract...@gmail.com"

Using jQuery as an underlying library is a poor choice. Rotate and
scale are particularly choppy, I much prefer the performance of the
demo at:

<URL: http://www.sitepen.com/blog/2008/07/10/touching-and-gesturing-on-the-iphone/
>

which unfortunately uses Dojo, I expect a set of functions optimised
for low-power CPUs and without the library baggage would perform much
better.

But the real challenge is to produce something that works with touch
and mouse events *without* browser or device sniffing.


--
Rob

[manifesti...@gmail.com]

jQuery is a popular library that is used by hundreds of thousands of
developers world wide. This free plugin was to allow the developers
who are using jQuery a method of using the built in features of the
iPod/iPhone touch gestures. Since it is clear that you do not use
jQuery, and that you have not actually looked at the plugins code, I
will let you know that there is, in fact, no "browser or device
sniffing".

Both this and the dojo plugin use the built in methods of the Apple
devices, there is no need to sniff/detect anything. It will work if
you have a device that supports the methods, and fail gracefully if it
does not.

There is nothing "unfortunate" about either plugin and both serve a
need that has been expressed by developers, like myself.

If you "expect a set of functions optimised for low-power CPUs and
without the library baggage would perform much better" then please
either offer an alternative, or work on providing a solution.
Otherwise...

- Peter

On Jul 28, 10:35 pm, RobG <rg...@iinet.net.au> wrote:
> On Jul 28, 7:42 am, "manifestinteract...@gmail.com"
>
> <manifestinteract...@gmail.com> wrote:
> > Greetings,
>
> > I have written a jQuery plugin that can use the built in Touch methods
> > including ontouchstart, ontouchend, ontouchmove, ongesturestart,
> > ongesturechange and ongestureend.
>
> > You may specify what options you want available for the specified
> > target(s), including: animate, dragx, dragy, rotate, resort and scale
>
> > LINK:http://plugins.jquery.com/project/touch
>
> > DEMO:http://www.manifestinteractive.com/iphone/touch/
>
> Using jQuery as an underlying library is a poor choice.  Rotate and
> scale are particularly choppy, I much prefer the performance of the
> demo at:
>

> <URL:http://www.sitepen.com/blog/2008/07/10/touching-and-gesturing-on-the-...

[RobG]

On Jul 30, 1:56 am, "manifestinteract...@gmail.com"

<manifestinteract...@gmail.com> wrote:
> On Jul 28, 10:35 pm, RobG <rg...@iinet.net.au> wrote:
>
> > On Jul 28, 7:42 am, "manifestinteract...@gmail.com"
>
> > <manifestinteract...@gmail.com> wrote:

If you are going to reply to specific points, it is preferable to do
so below trimmed quotes of what you are replying too. Posting order
restored.

[...]

> > > I have written a jQuery plugin that can use the built in Touch methods
> > > including ontouchstart, ontouchend, ontouchmove, ongesturestart,
> > > ongesturechange and ongestureend.

[...]

> > > LINK:http://plugins.jquery.com/project/touch
>
> > > DEMO:http://www.manifestinteractive.com/iphone/touch/
>
> > Using jQuery as an underlying library is a poor choice. Rotate and
> > scale are particularly choppy, I much prefer the performance of the
> > demo at:
>
> > <URL:http://www.sitepen.com/blog/2008/07/10/touching-and-gesturing-on-the-...
>
> > which unfortunately uses Dojo, I expect a set of functions optimised
> > for low-power CPUs and without the library baggage would perform much
> > better.
>
> > But the real challenge is to produce something that works with touch
> > and mouse events *without* browser or device sniffing.
>

> jQuery is a popular library that is used by hundreds of thousands of
> developers world wide. This free plugin was to allow the developers
> who are using jQuery a method of using the built in features of the
> iPod/iPhone touch gestures.

How do you estimate "hundreds of thousands"? Your inference, based on
a complete guess of use, is that because a large number use it, it
must be OK to use. By the same logic, if there are more "developers
world wide" not using jQuery, doesn't that make *not* using it a
better choice?

Agrument about the quality of a library should be objectively based on
the benefits of using it rather than generalisations and wild
estimates. The primary reason not to make code dependent on a library
is that it becomes tied to the fortunes of that library. It also
infers that a separate version of the code must be developed for each
supported library.

An alternative approach is to create independent code and supply
instructions on how to integrate it with some of the more commonly
used libraries.

> Since it is clear that you do not use
> jQuery,

That inference can't be drawn from what I posted, however it's
correct.

> and that you have not actually looked at the plugins code,

You can't draw that inference either, but I did.

> I
> will let you know that there is, in fact, no "browser or device
> sniffing".

I will let you know that jQuery uses quite a bit of browser sniffing -
for example, the string "jQuery.browser.msie" occurs 17 times in
version 1.2.6.

Regardless, the statement was a general comment that was not
specifically directed at the plugin, but at developing a gesture-based
interface. There is a disturbing trend toward browser detection and,
where development is targeted at mobile devices, device detection.
Both approaches are flawed, the sooner they are again relegated to
oblivion the better.

For the record, I am currently working on how to integrate touch
gestures with traditional pointing device gestures (noting that some
platforms already use touches to emulate a pointing device and that
some may use pointing devices to emulate touches). The goal is to
provide the ability to scale or rotate objects without regard for
which interface is being used.

> Both this and the dojo plugin use the built in methods of the Apple
> devices, there is no need to sniff/detect anything. It will work if
> you have a device that supports the methods, and fail gracefully if it
> does not.

The primary reason touted for using a general library is that it
allows cross-browser development. In that context, the aim is for
features to work in as wide a variety of situations as reasonable
(let's say in this case the most common 4 browsers and platforms).

The challenge is not to produce an effect based on a specific gesture,
but provide a feature that works appropriately for the interface being
used - e.g. scaling might use a pinch effect for a touch interface and
ctrl+mousedown followed by ctrl+mousemove where a pointing device is
being used. If a particular environment supports both, then both
should work.

> There is nothing "unfortunate" about either plugin and both serve a
> need that has been expressed by developers, like myself.

It is unfortunate that two bits of code that could have been
complimentary are mutually exclusive because the authors chose to tie
them to specific libraries.

> If you "expect a set of functions optimised for low-power CPUs and
> without the library baggage would perform much better" then please
> either offer an alternative, or work on providing a solution.

The validity of my criticim is independent of whether I personally
provide an alternative. The fact that Neil Roberts' code provides
much smoother scale and rotation actions proves the first part of the
statement. The tendency for libraries to be focused on generalised
functions and not performance provides a basis for the second.


--
Rob

[RobG]

On Jul 30, 1:56 am, "manifestinteract...@gmail.com"
<manifestinteract...@gmail.com> wrote:

[...]

> Since it is clear that you do not use
> jQuery, and that you have not actually looked at the plugins code, I
> will let you know that there is, in fact, no "browser or device
> sniffing".

I will let you know that jQuery uses quite a bit of browser sniffing

and that I did look at the plugin code.

My statement regarding sniffing was a general comment, it was not
specifically directed at the plugin.

> Both this and the dojo plugin use the built in methods of the Apple
> devices, there is no need to sniff/detect anything. It will work if
> you have a device that supports the methods, and fail gracefully if it
> does not.

And not at all on other devices. The goal should be to provide the
same functionality across platforms, not specifically for one
platform, i.e. the objects should drag, rotate and scale on whatever
browser I chose to use and that your plugin supports.

If someone choses to use the plugin, how do they know to use touch
events or not?

> There is nothing "unfortunate" about either plugin and both serve a
> need that has been expressed by developers, like myself.

The fact that they are based on different libraries means you need a
different plugin for each library and another if for no library.
Consider the case where you provide an independent "plugin" with
instructions for how to integrate it with different libraries.

> If you "expect a set of functions optimised for low-power CPUs and
> without the library baggage would perform much better" then please
> either offer an alternative, or work on providing a solution.

The value of criticism is not based on whether I can perform the task
better, but whether the task you perform does the job I want it to
do. You are free to take note of it or not.


--
Rob

[Fuzzy Orange]

What an absolute dick!

I think you'll find that nowhere did the OP claim that jquery was the
best javascript library in the world and everyone should be using it

He stated that a LOT of people do use jquery in their web development,
and therefore might want to take advantage of the ipod/iphone touch
interface

He's not saying "if you want to write an apple touch compatible site -
you MUST USE JQUERY",
He's saying "if you have a site written using jquery and want to make
it a bit friendlier to apple touch users, I've written a plugin for
you"

I sometimes wonder why people take the time to write excellent plugins
like this lad has done, just to receive 2 pages of well written but
pointless technical bullshit like you've just put up here

- Phil

[dhtml]

On Jul 29, 8:56 am, "manifestinteract...@gmail.com"
<manifestinteract...@gmail.com> wrote:

Hi Peter,

Inline style responses can make the discussion much easier to follow.
http://en.wikipedia.org/wiki/Posting_style#Inline_replying

> jQuery is a popular library that is used by hundreds of thousands of
> developers world wide.

Once upon a time, everyone thought the world was flat.

Millions of people believe in God; God must exist.

Most people eat meat; there aren't any ethical issues with it.

These concepts follows the thinking that since a lot of people ascribe
to it, it must be right. Politicians exploit this type of thinking. It
can be seen in the Jury system in America.

It's important to be able to look at the code critically.

> This free plugin was to allow the developers
> who are using jQuery a method of using the built in features of the
> iPod/iPhone touch gestures. Since it is clear that you do not use
> jQuery, and that you have not actually looked at the plugins code, I
> will let you know that there is, in fact, no "browser or device
> sniffing".
>

In jQuery there is a lot of device sniffing.

> Both this and the dojo plugin use the built in methods of the Apple
> devices, there is no need to sniff/detect anything. It will work if
> you have a device that supports the methods, and fail gracefully if it
> does not.

This plugin will also fail if jQuery is not included.

>
> There is nothing "unfortunate" about either plugin and both serve a
> need that has been expressed by developers, like myself.
>
> If you "expect a set of functions optimised for low-power CPUs and
> without the library baggage would perform much better" then please
> either offer an alternative, or work on providing a solution.
> Otherwise...

Adding jQuery to an iPhone webapp is very bad idea. It would add a lot
of overhead and irrelevance and I think this plugin shows that to be
true.

Alternatives:
* custom build the js
* dynamic script insertion

The touch code uses a few parts of jQuery. The css, text, and $
functions.

I can see some things about the code that are not very desirable. For
example:

| if(_dragging && !_sizing && _animate) {
| var _lastleft =
| (isNaN(parseInt($('#'+_target).css("left")))) ?
| 0:parseInt($('#'+_target).css("left"));
| var _lasttop =
| (isNaN(parseInt($('#'+_target).css("top")))) ?
| 0:parseInt($('#'+_target).css("top"));
| }

Using global variables.
Using the jQuery selector lookups each time the event fires.
Using the same jQuery selector lookups twice in the same expression.
Assuming page coordinates based on top/left values (though this could
arguably be considered a design decision, I don't think it's a great
one).

jQuery "will change the way you write JavaScript" and this can be seen
in the example above. jQuery dollar function isn't necessary here. I
don't see why jQuery is necessary at all.

How important is the jQuery here? I see: $, css(), and text() used.
The $ function could be replaced by saving an object reference or
designing an adapter with a collection of Touchables. That leaves the
css() and text() functions. Those can be replaced. It might be worth
considering using a different function to determine the coordinates of
the element and capture bubbled touch events. This is how Drag and
Drop APIs work.

The - opts - variable could instead be a property of an object:

function Touchable(el, opts) {
this.opts = opts;
this.el = el;
this.initEvents();
}

Garrett

>
> - Peter
>
[snip]

[dhtml]

On Jul 30, 11:19 pm, RobG <rg...@iinet.net.au> wrote:
> On Jul 30, 1:56 am, "manifestinteract...@gmail.com"<manifestinteract...@gmail.com> wrote:
>
>
> > Both this and the dojo plugin use the built in methods of the Apple
> > devices, there is no need to sniff/detect anything. It will work if
> > you have a device that supports the methods, and fail gracefully if it
> > does not.
>
> And not at all on other devices.  The goal should be to provide the
> same functionality across platforms, not specifically for one
> platform, i.e. the objects should drag, rotate and scale on whatever
> browser I chose to use and that your plugin supports.
>

But at the cost of what? How much code will that introduce? Will the
user experience (UX) be acceptable in different devices?

> If someone choses to use the plugin, how do they know to use touch
> events or not?
>

Who is someone? The end user, or the client of this API?

>
> --
> Rob

[Michael Kaye]

> Once upon a time, everyone thought the world was flat.

errmm... the world is flat...http://news.bbc.co.uk/1/hi/magazine/7540427.stm

[RobG]

On Aug 9, 7:32 am, dhtml <dhtmlkitc...@gmail.com> wrote:
> On Jul 30, 11:19 pm, RobG <rg...@iinet.net.au> wrote:
> > On Jul 30, 1:56 am, "manifestinteract...@gmail.com"<manifestinteract...@gmail.com> wrote:
>
> > > Both this and the dojo plugin use the built in methods of the Apple
> > > devices, there is no need to sniff/detect anything. It will work if
> > > you have a device that supports the methods, and fail gracefully if it
> > > does not.
>
> > And not at all on other devices.  The goal should be to provide the
> > same functionality across platforms, not specifically for one
> > platform, i.e. the objects should drag, rotate and scale on whatever
> > browser I chose to use and that your plugin supports.
>
> But at the cost of what?

At the cost of adding touch events to browsers that don't support
them. I doubt that will cause any issues.

> How much code will that introduce?

Not a lot, Apple chose to introduce touch events rather than abstract
them and issue traditional events so there's not much else you can
do. You could put a button on the page to say "Click here to use
touch events" but I don't like that.

> Will the
> user experience (UX) be acceptable in different devices?

I can't see how it affects the user experience - either the touch
events will fire or traditional ones. There will be a few of
listeners of one kind or the other that will never get fired, the only
cost is adding those listeners. That's no much of an overhead - there
are usually many listeners on a page that are never fired.

Unfortunately I've had very little time to work on this, the goal is
to make an element drag, scale or rotate without the developer having
to choose between touch or mouse events.

> > If someone choses to use the plugin, how do they know to use touch
> > events or not?
>
> Who is someone? The end user, or the client of this API?

The developer, the user of the plugin. There weren't any suggestions
as to how to use the plugin.


--
Rob