I am exploring the idea of drawing some custom primitives (using CGContext) on a view that is scrollable and larger than the phone screen width.
The idea would be to use the "power" of a UIScrollView by programmatically scrolling the content of the view as the content is added and decouple in this way the scrolling handling (and general UI interaction with the view) from the content drawing.
Is this a feasible approach in iOS?
Yes it is. The easiest approach AFAIK would be to add a UIView onto the UIScrollView. You would then draw on that UIView instance - after drawing another part of your graph/image you would need to inform the containing scroll view, via a delegate for example, that it needs to update its contentSize. This would of course be the size of the UIView upon which you drew. The update is needed, beacuse it seems that you may need to increase your drawing area size as you do it.
Related
I have a simple metal setup which draw image in the middle of MTKView. I wish I could add pinch zoom and other functionality as we have in scroll views, so i can zoom image and move it around with some thresholds.
I also don't want to implement it myself since my app will live in both Mac OS and iOS and this is twice more code to support and write.
Is there a way I could use default scroll view controlls to manipulate my projection? I mean set scroll view somehow on top of my view and get some data in delegate manner or whatever.
Any help would be appreciated!
You may want to try Metal2DScrollable sample code. The idea is that:
place MTKView behind (not a subview) UIScrollView,
Place dummy content view as a subview of UIScrollView
Make the dummy content view to be the target of zooming
Set up UIScrollView properly such as contentSize, contentInset etc.
Make both UIScrollView and dummy content view to be transparent
Calculate transform from dummy content view's bounds -> MTKView's coordinate -> device coordinate
Apply that transform when rendering with Metal
So, MTKView is not in the UIScrollView, but this tricks fools user's eyes.
https://github.com/codelynx/Metal2DScrollable
The same technique may work with macOS with some tweaks, but I haven't tried.
Is it possible to increase the clickable area of a UIView subclass?
I would rather do it without subclassing it's superview. Is that possible?
I've seen how to do it by overriding hitTest:withevent: and pointInside:withEvent: on the superview, but as I said, I would rather avoid that.
Why not create a container view that has a larger area, with a transparent background, that contains a subview that has your visible part? This is a quick and easy way to increase the tap area of a button, for instance.
In my iOS app I want my users to be able to zoom in on the screen. My main uiview contains several subviews which contain images. I want my uipinchgesturerecognizer to either change the scale, or ideally use some "zoom" rather than scaling each subview.
Please and thank you.
This can be accomplished with UIScrollView. First create a scroll view as the base of your view hierarchy, putting your previous container view as a subview of the scroll view. Set the delegate of the scroll view to self and implement the delegate method viewForZoomingInScrollView, in which you should return the view that will be zoomed in (your original container view). This will allow the user to pinch and zoom your original UIView.
It's hard to provide advice on this without having a clearer view of what exactly you want to achieve.
Can you include a link to a sketch? For example, do you want the individual subviews to remain the same size but the layout to change ? Do you want the individual subviews to resize but their contents to be upscaled?
If you simple want to treat the subview as (basically) a single image which just happens to have other images in it, then maybe it would be better to render it as one and then scale that?
I have a CALayer for which I provide content for only the visible area (somewhat similar to CATiledLayer). The problem is there does not seem to be a way to receive notification when the visible area of the CALayer changes so that displayLayer is called. I currently subclass and hook setPosition, setBounds, and setTransform, but this doesn't catch the cases where a superview/layer changes (for example, UIScrollView scrolls by changing the scroll views origin ). I'm left hooking parent views and sprinkling setNeedsDisplay all over the code.
Is there a better way?
The currently visible rect is [CALayer visibleRect]. This is set by the scroll view (layer) and is what you're expected to base drawing on in scroll views.
You probably want to override -needsDisplayOnBoundsChange to return YES. That's typically how you handle most of what you're describing.
If you want things like position to force a redraw (that's unusual, but possible), then you can override +needsDisplayForKey: to return YES for any key changes that you want to force a redraw.
If you want to make sure you're only drawing what you need to draw, then you should be checking your clipping box using CGContextGetClipBoundingBox() during your drawing code.
Seems like a very simple problem! But I'm having great difficulty.
My ideas and attempts so far:
scrollView.backgroundColor = [UIColor colorWithPatternImage:myImage]]
Doesn't scroll with contents
Create UIView the size of contentSize (actually, larger due to elastic bounces on scroll view), and use pattern as above on this sub view of UIScrollView.
Causes massive memory hit (and crash) when UIView gets too large. See also: Large UIScrollView with background pattern fails
Similar to (2), exept I only create a UIView the size of the maximum number of repetitions of the background image that will be seen, and cleverly move the view to wherever is needed to show the correct background repetitions.
Causes this background view to shift left and right unexpectedly when animating the scroll.
Create UIView subclass and override drawRect. Use various Core Graphics techniques to draw content by hand.
Not animatable. Implementing my own contentOffset property isn't a standard Core Animation property.
Overriding drawRect on UIScrollView doesn't respect the content offset, and doesn't get called multiple times as it scrolls/animates. The rect parameter is always simply the bounds of the UIScrollView.
As with (4), except I set the bounds.origin of my UIView subclass in my setContentOffset implementation, since it's an animatable property.
drawRect doesn't seem to get called every frame.
Use CATiledLayer, as suggested in this answer: Large UIScrollView with background pattern fails. Implementation details here: http://www.cimgf.com/2011/03/01/subduing-catiledlayer/.
I really don't want the ugliness of seeing tiles asynchronously being drawn as user scrolls. It's just a simple background pattern!
This seems like the simplest thing! Why is it so hard!?
Maybe the sample code:ScollViewSuit->3_Tiling can help you. You can search it in the official docset.
This works like CATiledLayer but only use UIKit, the tile was loaded on the main thread.
And I really don't think this is a good solution.