I have a myriad of UIImageViews that act as 'tiles' on a map. They align up next to one another to form a grid of images.
Ordinarily, the grid images are flush against each other, but whenever the iPhone or iPad device is rotated, or if a UIView is applied to the view that contains these tiles, the spaces between the UIImageViews become momentarily visible, showing off the grid pattern that I'd like to be invisible.
Any ideas what might be causing this?
Thanks
Consider using CATiledLayer to draw all the images in a single view instead of using multiple subviews. There's a nice writeup on using it at Cocoa Is My Girlfriend. CATiledLayer makes it easy to build an image out of smaller tiles, display higher resolution images as the user zooms in, and avoid memory problems that come from keeping too much of a large image loaded.
this is happening because you are using different views (here uiimageview). Since they are not part of the same fabric during any animation or change in view hierarchy there is a chance that the gap between them would be visible.
This is a very common problem in graphics programming. The way to fix this problem is to have one single view and add these uiimageviews as sub-layers to this view. That way all the imageviews are part of the same fabric and the gap would not be visible.
I did not post any code but then so did you ;)
Related
I want to implement an horizontal collection view displaying images that increases the size of the images with a smooth animation as they approach the center and reduces their size as they move away.
I have been studying the UICollectionView potentials but so far I have not been able to understand if such behaviour is possible to be implemented using UICollectionView or what would be the best alternative. For instance using UIScrollView instead (with a lot more work probably).
Some guidance or sample code would be most welcome. Thank you.
In terms of creating an infinite scrolling capability using a UIScrollView (no looping back to the start), for a calendar in fact, will one very large UIView for long scrolling in UIScrollView cause resource issues?
Assumptions:
That is assuming one programmatically adds/removing subviews onto this main backplane view as it is about to need being shown/visible, then removing afterwards.
Don't want to use UICollectionView (to focus question on use of UIScrollView please)
Requirements:
Would want to put UI View onto this background plane as well as drawing to it directly, e.g. adding lines.
So therefore would need to be adding/removing things like Lines drawn as well UILabels. (well haven't delved into Lines and whether they would need to be drawn in their own subview, upon which you're then adding removing these "line" subviews, as opposed to drawing directly onto the main backplane view in drawrect)
Background:
I see some suggestions of having 3 "pages" (views) and you keep moving these as scrolling occurs, however this just seems more complicated.
There should not be any resource issue as far as you use views.
I developed kinda map application with the next view structure.
MapScrollView (UIScrollView)
- TileContainerView (UIView)
- TileContainerSubViews[10..] (UIView)
- TileLayer [] (CALayer)
- UIButton[]
- IconLayer[] (CALayer)
- TrackLineLayer (CALayer)
- .....
All of the Tile**Views in hierarchy and MapScrollView share the same size, which is aligned to the size of the TileContainerSubViews[n], which further holds many TileLayer(s) with size of 256x256. The largest TileContainerSubView[] can hold as many as 10000x10000 TileLayer(s)
which is 2560000x2560000 in view size. (Of course, we can't actually add that many layers due to resource issue.) All of views/layers are added/removed on the way.
Note you can create large UIView but not CALayer.
When I tryed to create huge CALayer, the program terminated with some error message. CATiledLayer doesn't seem to have this constraint but I haven't tested.
I have a myriad of UIImageViews that act as 'tiles' on a map. They align up next to one another to form a grid of images. The layer of each UIImageView is added as a sublayer of a UIView.
Ordinarily, the grid images are flush against each other, but whenever the UIScrollView that contains the UIView is zoomed in or out, the spaces between the tile images become visible, showing off the grid pattern that I'd like to be invisible.
Any ideas what might be causing this?
Sounds like you're trying to create a CATiledLayer from scratch...?
Why not just use CATiledLayer?
I'm making a music app that displays musical notation. Currently the notation is in a very large view that extends horizontally until the music ends. Obviously this isn't a good solution because I quickly run out of memory when display large scores of music.
My question is how I can implement my view such that the view where I do my drawing is only the size of the screen, but the content gets scrolled across it (The view is contained in a scrollview)? I imagine I could just only draw stuff on the screen and redraw the view as it gets scrolled with different x coordinates, but this seems ugly and would be pretty slow.
Thanks for any suggestions. : )
There are a number of solutions around. Usually these involve drawing one-or-two screen widths past the edges, then scrolling as needed, and drawing again into the area that was previously visible. In essence, using the scroll-view as a circular buffer.
Try a Google search for UIScrollView infinite scroll.
Also, see Infinite horizontal scrolling UIScrollView.
I've finally finished my first large application, the only problem is that I've focued a lot on design, and I'm using custom nibs as cells with transparent backgrounds. When I tried testing the application on my iPhone, the performance was terrible.
Is there any way to get better scrolling performance while using transparent cells with a ImageView behind the UITableView?
I've read two articles mostly:
blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/
cocoawithlove.com/2009/04/easy-custom-uitableview-drawing.html
Looks good, but what if I want to use transparent cells?
a) Uses solid color.
b) Uses imageview as background.
Any help will be greatly appreciated. I want to get this baby released as soon as possible, but the performance as it is now is terrible!
First off, stop using nibs. Every time a cell is created, you're now hitting the disk in order to unarchive the nib. 3.1 will actually make this better, but until then, please create your cell in code.
Secondly, remove transparency wherever you can. Anything that doesn't need to be transparent, shouldn't be. And anything that isn't transparent should have the opaque property set to YES.
A third suggestion is if you're using a lot of subviews, you will see a performance benefit by using a custom view to draw everything instead of a bunch of subviews. If you choose to go this route, you should consider how it behaves when rotating to landscape mode (e.g. how the stretch action occurs), or if you have any controls that need to handle touches separately from the cell itself.