Has anyone written a transform for View or added CoreData Support? about icarousel

[nicklockwood]

Hi George,

The solution you suggest is basically how I've done this previously. Not sure I get what you mean about the alpha, buy creating a new vew and zooming it is basically the right appoach.

Kind Regards,

Nick

(Sent from my iPhone)

On 20 Sep 2011, at 13:57, George [email protected] wrote:

While I'm asking....

I was just curious if anyone has written a transform that once a thumbnail in a carousel is taped which takes that selected item and simulates a zoom out to a larger picture to be inspected and then dismissed by a tap? The tap part I can do.

I assume that I could create a alpha 0 view over the top of the current selected thumbnail and then animated the transform to create a zoom effect while progressing the alpha from 0 to 1 or maybe .9ish. Then just reverse it when you tap on it to cause it to shrink back into the thumbnail shown in the carousel.

Just wanted to ask before I commit a few days to mess with it!

Thanks in advance.

Reply to this email directly or view it on GitHub:
#42

[Bookworm370]

I've used a alpha factor while zooming in the past so that it seems that it comes out of nowhere and gets deeper as it gets to full size. Sometimes I play with leaving it partially transparent so that the person knows that that there is something behind the zoomed item. I'm thinking of adding a couple of touch-points and icons on the view that zooms out like the standard X to dismiss the zoom, a trash can with the tear off effect to delete the picture from the carousel. That way I can then enable the picture itself for taps for future use (like a pop-over if they want to print it, email it, etc).

I just have to work on a way to tie iCarousel datasource to my CoreData model. All the pictures for an entity I want to show are thumbnails and full resolution in Coredata as a relationship to the entity. E.G. If I'm showing a person then all the persons pictures have a relationship that has person.pictures where Pictures is also a CoreData entity that contains the dates, thumbnail and unique pointer to the full sized picture in the sandbox.

What I'd like to do is (maybe I'll fork iCarousel) add something that I can point the datasource method to that says, here is the NSSET from CoreData (eg. person.picture) and take the picture.thumbnail transformable UIImage and add it to the carousel for all pictures in the NSSET relationship. But when I tap on it, return to me not just the index but the pointer to the object in the managedObjectContext so I can have Coredata delete it, etc and then just call [carousel reloaddata] to traverse the CD model again to get the result.

CoreData can weak link each of the objects so I can use that power to manage all the pictures.

Ideas as to where in the class it would make sense to add this? Or should it be an iCarousel wrapper class? Humm

I hate to mess with someone else's baby without their opinions or blessing... Just good ethics.

[nicklockwood]

It's up to you of course, but I wouldn't put that in the iCarousel.

iCarousel is a view, CoreData is a model. MVC design dictates that views
should not talk directly to the model because limits their reusability (the
iCarousel fork you created would only be useful for projects that also used
your data model, and every time I updated iCarousel you'd have to merge the
changes back in). Model and view should be linked via a controller.

So What you should be doing is creating an iCarousel controller object of
some kind. You could build this as a UIViewController subclass, but that's
also a bit limiting - what if you wanted two carousels on screen, each with
their own datasource?

So in conclusion, I think you should make an NSObject subclass called
something like iCarouselDataController that is designed to act as the
datasource for an iCarousel and mediates between the carousel and Core Data.
That would then be re-usable for any project that used that data model
design.

Nick

On 22/09/2011 16:07, "George"
[email protected]
wrote:

I've used a alpha factor while zooming in the past so that it seems that it
comes out of nowhere and gets deeper as it gets to full size. Sometimes I
play with leaving it partially transparent so that the person knows that that
there is something behind the zoomed item. I'm thinking of adding a couple of
touch-points and icons on the view that zooms out like the standard X to
dismiss the zoom, a trash can with the tear off effect to delete the picture
from the carousel. That way I can then enable the picture itself for taps for
future use (like a pop-over if they want to print it, email it, etc).

I just have to work on a way to tie iCarousel datasource to my CoreData model.
All the pictures for an entity I want to show are thumbnails and full
resolution in Coredata as a relationship to the entity. E.G. If I'm showing
a person then all the persons pictures have a relationship that has
person.pictures where Pictures is also a CoreData entity that contains the
dates, thumbnail and unique pointer to the full sized picture in the sandbox.

What I'd like to do is (maybe I'll fork iCarousel) add something that I can
point the datasource method to that says, here is the NSSET from CoreData (eg.
person.picture) and take the picture.thumbnail transformable UIImage and add
it to the carousel for all pictures in the NSSET relationship. But when I
tap on it, return to me not just the index but the pointer to the object in
the managedObjectContext so I can have Coredata delete it, etc and then just
call [carousel reloaddata] to traverse the CD model again to get the result.

CoreData can weak link each of the objects so I can use that power to manage
all the pictures.

Ideas as to where in the class it would make sense to add this? Or should it
be an iCarousel wrapper class? Humm

[Bookworm370]

Yup, you're right, I wasn't totally thinking it out. I'll cobble something up and maybe submit it to you for inclusion. At the same time, as I'm creating a subclass I'll add the convenience accessor of something like userInfo that a lot of classes implement and even third party frameworks like ASI so that other than setting just a simple tag you can attach a userInfo NSDictionary to the currentView object so when you pull the currentView you can also get to the userInfo dictionary. You can then store whatever you want to define what to do when a person clicks on a currentItem. You can store the MOC, the NSManagedObject pointer in the MOC as the carousel isn't guaranteed to match up the indexes with the NSSET (actually Coredata doesn't guarantee the order of NSSet's unless you pull them using a sort predicate.

It would be nice if once the iCarouselDataController adds a carousel subview it can also store all the references that are needed to get back to the proper entity that the thumbnail was pulled from so that another view controller that is pushed down the line to handle the tap can then pickup the real 'data source' (ie the MOC and the entity that was used to create the carousel item) and then do what you want to do like delete, modify, replace, resize, etc.

I think the iCarouselDataController could be a great addition that could link iCarousel straight to CoreData and have it dynamically populate by only manipulating the ManagedObjectContext!

Thanks for the great work! You gonna be at VTM Boston? I'll buy you a beer!

George

[nicklockwood]

Boston's kind of a trek from London ;-) maybe I'll see you at next year's WWDC.

Nick

[gmoledina]

I use CoreData too as a data source for iCarousel, and I have a controller (like iCarouselDataController) that uses NSFetchedResultsController to query the CoreData context and feed the carousel.

I suggest you look into NSFetchedResultsController, it's a great controller that was written to feed UITableViews but as iCarousel works the same way, it's very easy to plug it in with iCarousel as well.

http://developer.apple.com/library/ios/#DOCUMENTATION/CoreData/Reference/NSFetchedResultsController_Class/Reference/Reference.html