Hi all,
Some 8 months ago (3G release in Europe), I was programming the iPhone
optimized news portal (based on iui, off course), and I had to
implement gallery feature too. I was very surprised when I realized
that there is no usable javscript component. So, I had to create quick
and dirty workaround solution.
Few months later, I decided that I'll make that kind of component, and
now, here it is.
It is called JAIPHO (Javascript iPhone Photos), and by functionality
it attempts to be close to original iPhone Photos application as much
as web can offer. It is written in javascript so it is easy o
implement. Also to mention it is in beta release and published under
LGPL.
Ok, that's it. Hit me ;)
I would like to hear group opinion
This is great, nice work! Does this use any js framework or is it home
grown? Will this integrate into existing iPhone frameworks like jQTouch, iUI
or iWebKit? I haven't had a chance to play with it yet but I will.
On Wed, Mar 25, 2009 at 5:28 PM, Tole <tole....@gmail.com> wrote:
> Hi all,
> Some 8 months ago (3G release in Europe), I was programming the iPhone
> optimized news portal (based on iui, off course), and I had to
> implement gallery feature too. I was very surprised when I realized
> that there is no usable javscript component. So, I had to create quick
> and dirty workaround solution.
> Few months later, I decided that I'll make that kind of component, and
> now, here it is.
> It is called JAIPHO (Javascript iPhone Photos), and by functionality
> it attempts to be close to original iPhone Photos application as much
> as web can offer. It is written in javascript so it is easy o
> implement. Also to mention it is in beta release and published under
> LGPL.
> Ok, that's it. Hit me ;)
> I would like to hear group opinion
> Hi all,
> Some 8 months ago (3G release in Europe), I was programming the iPhone
> optimized news portal (based on iui, off course), and I had to
> implement gallery feature too. I was very surprised when I realized
> that there is no usable javscript component. So, I had to create quick
> and dirty workaround solution.
> Few months later, I decided that I'll make that kind of component, and
> now, here it is.
> It is called JAIPHO (Javascript iPhone Photos), and by functionality
> it attempts to be close to original iPhone Photos application as much
> as web can offer. It is written in javascript so it is easy o
> implement. Also to mention it is in beta release and published under
> LGPL.
> Ok, that's it. Hit me ;)
> I would like to hear group opinion
I think it could do with quite a bit of work to clean up the code.
I don't understand why eval is used, e.g.
var str = '';
str += 'var ret = master.' + method + '(e, argument);';
eval( str);
The first assignment to str is useless, the two lines are equivalent
to:
var str = 'var ret = master.' + method + '(e, argument);';
All 3 lines can be replaced by:
var ret = master[method](e.argument);
Don't do for..in iteration over Arrays, it is known to be problematic
if you ever intend to extend Array.prototype or use other people's
code in the same page as JAIPHO. At the very least you could include
a hasOwnProperty filter.
If you want an object, use an object. Don't use arrays where an
object should be used.
There are functions that should be primitive values, e.g.
On Sat, Mar 28, 2009 at 7:51 AM, RobG <rg...@iinet.net.au> wrote:
> On Mar 26, 7:28 am, Tole <tole....@gmail.com> wrote:
> > Hi all,
> > Some 8 months ago (3G release in Europe), I was programming the iPhone
> > optimized news portal (based on iui, off course), and I had to
> > implement gallery feature too. I was very surprised when I realized
> > that there is no usable javscript component. So, I had to create quick
> > and dirty workaround solution.
> > Few months later, I decided that I'll make that kind of component, and
> > now, here it is.
> > It is called JAIPHO (Javascript iPhone Photos), and by functionality
> > it attempts to be close to original iPhone Photos application as much
> > as web can offer. It is written in javascript so it is easy o
> > implement. Also to mention it is in beta release and published under
> > LGPL.
> > Ok, that's it. Hit me ;)
> > I would like to hear group opinion
> I think it could do with quite a bit of work to clean up the code.
> I don't understand why eval is used, e.g.
> var str = '';
> str += 'var ret = master.' + method + '(e, argument);';
> eval( str);
> The first assignment to str is useless, the two lines are equivalent
> to:
> var str = 'var ret = master.' + method + '(e, argument);';
> All 3 lines can be replaced by:
> var ret = master[method](e.argument);
> Don't do for..in iteration over Arrays, it is known to be problematic
> if you ever intend to extend Array.prototype or use other people's
> code in the same page as JAIPHO. At the very least you could include
> a hasOwnProperty filter.
> If you want an object, use an object. Don't use arrays where an
> object should be used.
> There are functions that should be primitive values, e.g.
Thanks Chris,
No there is no framework used in jaipho, and to be honest I didn't
seriously thought about that.
There is a simple reason for that: it has quite encapsulated
functionality. It takes separate html template (whole page) to be
shown, and it was meant to be used on both iPhone and standard web
sites.
So I thought, that the project usage and implementation should be as
easy as possible, with no dependencies of any kind.
Tole
On Mar 28, 1:35 am, Chris Collett <chris.j.coll...@gmail.com> wrote:
> This is great, nice work! Does this use any js framework or is it home
> grown? Will this integrate into existing iPhone frameworks like jQTouch, iUI
> or iWebKit? I haven't had a chance to play with it yet but I will.
First, thanks for realy great feedback. I realy apriciate it, and I
will implement most of the things you mentioned.
Second, I'll try to excuse myself just a bit.
Yes, there are more things that could be improoved and optimized.
Actualy that is my way of programming - something like getting real
philosphy. I'm trying to cover all project requirements in firts stage
at any cost. In this phase I'm also concentrated on interfaces but the
implementations are something I don't spend much time on. Anoher thing
I try to do is to copy/paste optimize which explains useles lines like
"var str = '';"
My last independent project took me 3 years of development and at the
end I didn't even published it. So with this one I didn't wanted to
make that mistake.
> I think it could do with quite a bit of work to clean up the code.
> I don't understand why eval is used, e.g.
> var str = '';
> str += 'var ret = master.' + method + '(e, argument);';
> eval( str);
> The first assignment to str is useless, the two lines are equivalent
> to:
> var str = 'var ret = master.' + method + '(e, argument);';
> All 3 lines can be replaced by:
> var ret = master[method](e.argument);
Tried, and works perfect!
> Don't do for..in iteration over Arrays, it is known to be problematic
> if you ever intend to extend Array.prototype or use other people's
> code in the same page as JAIPHO. At the very least you could include
> a hasOwnProperty filter.
Uh, I like for..in iteration so much. Right now for jaipho, there is
no rush to make it another way. It hardly can be mixed with someone's
code in same page because it takes whole page for itself.
But I'm considering another approach anyway. Few months ago I had that
kind of incident on my day job, when colleague of mine included
scriptaculous in project we were developing.
> If you want an object, use an object. Don't use arrays where an
> object should be used.
Yes I agree. This will be fixed soon. I'm fan of OOP and I had lot of
argues with my PHP colleagues which are using associative arrays for
almost all kind of data they are using in projects.
Personally, I'm sure there is something to be improved, there always
is, but I'd also like to say that your project is great! I've been
looking for something like this for a while, and whilst I would have
preferred it to use Prototype and Scriptaculous, you're right, as it's
encapsulated and independent from anything else I'm doing, it's not
that important.
Thanks for all your hard work, and allowing us to see it.
> First, thanks for realy great feedback. I realy apriciate it, and I
> will implement most of the things you mentioned.
> Second, I'll try to excuse myself just a bit.
> Yes, there are more things that could be improoved and optimized.
> Actualy that is my way of programming - something like getting real
> philosphy. I'm trying to cover all project requirements in firts stage
> at any cost. In this phase I'm also concentrated on interfaces but the
> implementations are something I don't spend much time on. Anoher thing
> I try to do is to copy/paste optimize which explains useles lines like
> "var str = '';"
> My last independent project took me 3 years of development and at the
> end I didn't even published it. So with this one I didn't wanted to
> make that mistake.
>> I think it could do with quite a bit of work to clean up the code.
>> I don't understand why eval is used, e.g.
>> var str = '';
>> str += 'var ret = master.' + method + '(e, argument);';
>> eval( str);
>> The first assignment to str is useless, the two lines are equivalent
>> to:
>> var str = 'var ret = master.' + method + '(e, argument);';
>> All 3 lines can be replaced by:
>> var ret = master[method](e.argument);
> Tried, and works perfect!
>> Don't do for..in iteration over Arrays, it is known to be problematic
>> if you ever intend to extend Array.prototype or use other people's
>> code in the same page as JAIPHO. At the very least you could include
>> a hasOwnProperty filter.
> Uh, I like for..in iteration so much. Right now for jaipho, there is
> no rush to make it another way. It hardly can be mixed with someone's
> code in same page because it takes whole page for itself.
> But I'm considering another approach anyway. Few months ago I had that
> kind of incident on my day job, when colleague of mine included
> scriptaculous in project we were developing.
>> If you want an object, use an object. Don't use arrays where an
>> object should be used.
> Yes I agree. This will be fixed soon. I'm fan of OOP and I had lot of
> argues with my PHP colleagues which are using associative arrays for
> almost all kind of data they are using in projects.
>> There are functions that should be primitive values, e.g.
>> That function re-creates the exact same string every time it is
>> called, it is a very inefficient way to go about providing a static
>> variable.
> Yes and no. "Every time" in this case is actually only once per page
> load.
>> Similarly, there are calls like:
>> var arr = this._GetArray( this.maListeners, name);
>> where _GetArray is:
>> obj._GetArray = function( arr, name) {
>> if (arr[name] == undefined)
>> arr[name] = new Array();
>> return arr[name];
>> }
>> consider:
>> var arr = this.maListeners[name] || [];
>> No function call, no simplistic _GetArray method.
> Yes, that is one of "dirty" implementations. But anyway working inline
> solution is:
> var arr = this.maListeners[name] || (this.maListeners[name] = []);
>> There is like quite a bit more that can be improved.
On Mar 29, 1:28 am, Henry Blackman <he...@inavize.com> wrote:
> I've been
> looking for something like this for a while, and whilst I would have
> preferred it to use Prototype and Scriptaculous,
I would strongly recommend against that. There is no need to create a
dependency on 300KB of scripts for no useful purpose. As written,
JAIPHO will not work if those scripts are included in the page.
[...]
> In terms of use, what license are you using?
The home page says "Published under LGPL".
[...]
> >> Don't do for..in iteration over Arrays, it is known to be problematic
> >> if you ever intend to extend Array.prototype or use other people's
> >> code in the same page as JAIPHO. At the very least you could include
> >> a hasOwnProperty filter.
> > Uh, I like for..in iteration so much.
There is no problem with for..in per se, only using it with an array.
Javascript is s simple language, everything is an object, even
primitives mutate into objects when necessary. That simplicity
shouldn't be abused.
> > Right now for jaipho, there is
> > no rush to make it another way. It hardly can be mixed with someone's
> > code in same page because it takes whole page for itself.
There are many developers who will include all scripts in every page
for simplicity on the basis that they are downloaded once and cached
after that. One of the first goals should be to ensure your code
works regardless of what other code is included in the page, so don't
modify built-in or host objects and write your code as if you expect
others might have.
> > But I'm considering another approach anyway. Few months ago I had that
> > kind of incident on my day job, when colleague of mine included
> > scriptaculous in project we were developing.
Scriptaculous is dependent on Prototype.js, which adds methods to
Array.prototype, which will break your code.
> >> If you want an object, use an object. Don't use arrays where an
> >> object should be used.
> > Yes I agree. This will be fixed soon. I'm fan of OOP and I had lot of
> > argues with my PHP colleagues which are using associative arrays for
> > almost all kind of data they are using in projects.
An issue that often occurs when developers come from a language they
know to one they don't is that they try to coerce the new language
into the same patterns as the other. That was a motivation for
Prototpye.js and has resulted in it being a good way to waste CPU
cycles and bandwidth.
> >> That function re-creates the exact same string every time it is
> >> called, it is a very inefficient way to go about providing a static
> >> variable.
> > Yes and no. "Every time" in this case is actually only once per page
> > load.
I was commenting mostly on the strategy of using a function to return
a string that should be held as a string variable. That particular
string should be in the HTML as a style element.
> Hi all,
> Some 8 months ago (3G release in Europe), I was programming the iPhone
> optimized news portal (based on iui, off course), and I had to
> implement gallery feature too. I was very surprised when I realized
> that there is no usable javscript component. So, I had to create quick
> and dirty workaround solution.
> Few months later, I decided that I'll make that kind of component, and
> now, here it is.
> It is called JAIPHO (Javascript iPhone Photos), and by functionality
> it attempts to be close to original iPhone Photos application as much
> as web can offer. It is written in javascript so it is easy o
> implement. Also to mention it is in beta release and published under
> LGPL.
> Ok, that's it. Hit me ;)
> I would like to hear group opinion
Well, I'm not sure that I understand you in complete.
In Slide mode the vertical scroll is available only if when you grab
tollbars.
In Thumbnails mode the control over gestures is not used at all.
In both cases you should capture the "ontouchmove" event and inside
the handling function/method you have to call "e.preventDefault()"
You can use JphUtil_Touches object for that, or if the preventing is
only feature you want to achieve, you should use regular anonymus
approach
elem.ontouchmove = function(e){e.preventDefault()}
Tole
ps, I'm glad you like my "strange" coding standard
On 1 tra, 14:11, domorethanyoucan <domorethanyou...@mac.com> wrote:
> So, I'd like to prevent vertical scrolls through photos.
> commening all the scrollY/pageY lines around line 2000 appears to have
> no effect.
> thoughts?
> ps, this thing is pretty neat.
> On Mar 25, 5:28 pm, Tole <tole....@gmail.com> wrote:
> > Hi all,
> > Some 8 months ago (3G release in Europe), I was programming the iPhone
> > optimized news portal (based on iui, off course), and I had to
> > implement gallery feature too. I was very surprised when I realized
> > that there is no usable javscript component. So, I had to create quick
> > and dirty workaround solution.
> > Few months later, I decided that I'll make that kind of component, and
> > now, here it is.
> > It is called JAIPHO (Javascript iPhone Photos), and by functionality
> > it attempts to be close to original iPhone Photos application as much
> > as web can offer. It is written in javascript so it is easy o
> > implement. Also to mention it is in beta release and published under
> > LGPL.
> > Ok, that's it. Hit me ;)
> > I would like to hear group opinion
