RunRev for iPhone and iPod Touch

[Richard Gaskin]

Björnke von Gierke wrote:
> You complain that my handler deletes the data, so it seems I wasn't  
> clear enough. Obviously there's a custom property, called "data". This  
> is what you use to show later parts of, or sorted stuff of, in the  
> field. That is why I said "less memory efficient", because there's an  
> additional property containing all the data. Sure, dividing the  
> presentation from the actual data is much more work then having both  
> in one, but it also gives you more control.

True, but if the object the data is stored in is part of the UI doesn't 
it obviate many of the benefits of such separation?  And if the data is 
already stored in a database or other file then that's just an extra copy.

But storage aside, if we delete the ID field from the record before we 
display it how do we know which record the user clicks on?

So in addition to adding the line of code about the itemdel, we need to 
add another which stores the sorted list back into the property before 
stripping out stuff for display, so we can later look it up in response 
to clicks.

Doable, yes, but requires a bit of forethought, strategy, and time.


> Again I'm not against having all the data in a field, and I never  
> claimed my way of doubling everything in a cprop is simpler. But no  
> matter if runrev agrees that your proposal is a nice thing to have or  
> not, it isn't available now.

As one who generally shares your interest here in focusing on immediate 
solutions, I appreciate your help with the scripting.

But stepping back to the original context of this thread, this was a 
conversation about relative ROI of proposed features, and this 
admittedly tiny feature of zero-width columns was presented in 
conjunction with independent column alignment.

The column alignment is absolutely critical for broad adoption in 
business environments. And fortunately the good folks at RunRev have 
previously acknowledged the importance of independent column alignment.

Extra bonus points that when they find themselves diving deep into the 
field object to make that happen, they'll be in a position to add 
zero-width columns for very little additional effort.

Like Linux support, this zero-width-column thang is a feature that, if 
well-timed, has an unusually high ROI because it has such an uncommonly 
low cost.

And to bring all this back to the iPhone, if the API presents a very low 
cost to port then of course it should be pursued at whatever point in 
the priority list where its ROI ranking would put it.  But the iPhone is 
not a Mac, and I suspect there will be many differences in how apps must 
be built for each.

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com