Question - animation

[nferruzzi]

Hi,
I'd like to have my pins moving from cluster position to their own position and viceversa (like the photo application). Unfortunately I don't see how I could implement this with the map animator protocol, for instance how can I get the "parent" location when an annotation is moved in/out from a cluster ?
thanks

[choefele]

You are right - this type of animation is not currently supported with the existing interfaces. I definitely want to have this in future, though.

Pull request? ;-)

[nferruzzi]

Ok :)
I got it working but can't really say without your review if this is more too hacky or can be a good starting point.
https://github.com/nferruzzi/CCHMapClusterController

[choefele]

Thanks a lot for your work — I'll have a look in the next few days

[choefele]

I haven't finished reviewing the code yet, but have you had a look at this library? It seems to get by without using associated objects.

Also, is there a way to unit test the code?

Thanks

[choefele]

Unit tests: while I don't think we can test the animation itself, we can create tests to ensure that annotations are at the right place afterwards. So I need two tests, one for CCHFadeInOutAnimator and one for CCHMoveInOutMapAnimator. The tests should be pretty similar.

Let's work on the unit tests and take it from there (I would try to implement this without using associated objects).

[nferruzzi]

Yes I totally agree with you about writing tests first :) as I supposed my first attempt was an hack, I assumed that "other kind of MKAnnotations" could lie around sets and arrays but now I see that only cluster annotations are in there and (like the lib you pointed out) cluster to cluster relations could be saved there. Meanwhile I hope to get a move in/out test soon :)

[mikrobi]

Actually there are "MKAnnotations of other kind" in CCHMapClusterAnnotation.annotations. If we want to store the cluster relationship as a property we'd have to wrap every annotation in CCHMapClusterAnnotation.annotations with a custom wrapper class. Another solution could be a protocol having properties for storing the required relationship data. The library user would have to implement that protocol for all annotations passed to the cluster controller. On the other hand, I don't think associated objects are a bad design by default. @nferruzzi's solution sketch doesn't look that bad for me. It kinda make sense and reduces complexity for both, the library and its usage. @choefele what do you think?

[choefele]

I think the animations are based on the MKAnnotations added to the map and these are all of type CCHMapClusterAnnotation. I'm not against associated objects per se, but if a property on CCHMapClusterAnnotation is enough then that would simplify the implementation.