At work an interesting tempest in a teapot arose.
And in my personal hacking life, another tempest in a teapot.
The former I cannot discuss. The latter, however, I can: my little protest in code has come to bite me on the ass. Or rather, more specifically, it has come to bite another poor fellow on the ass: I just found out his application has been rejected because Apple believes FlowCover is CoverFlow, despite the differing graphical appearances. (Specifically my tiles don’t “pop” the way iPhone CoverFlow tiles do as they pass through the center. It was a style choice.)
I’ll wait if he wants to raise hell publicly; it’s not my story. But I do know there are at least two other applications currently on the Apple Store which successfully shipped using FlowCover, so it just illustrates the lack of standards on Apple’s editorial review process.
And it should be evidence that the App Store is succeeding because of the success of the iPhone, and not the other way around–as Verizon, T-Mobile, Google and others seem to believe as they shove their own mobile device application stores down people’s throats.
Development Chaos Theory 
Thanks for putting together FlowCover! It makes it really easy to add a nice Cover Flow view to an iPhone app. I was wondering how hard it would be to make the animation “snap” to the selected cover as the view is scrolled (like Apple’s implementation). I like the fluidity of the FlowCover animation, but I find the snapping quite helpful when actually trying to select a cover.
LikeLike
The actual position of a tile is determined by the code in FlowCoverView.m at – drawTile:atOffset: (around line 409). If you want more “snap” you will need to alter the code in that routine which sets up the current transformation matrix for the current tile depending on the linear offset of the tile.
Just play with the code there (fiddle with the constants, adjust things there) to see how tiles are affected.
LikeLike