I want to put several dynamically drawn polygon in a UIView and make each of such polygon draggable. Should I put each dynamically drawn polygon in a subview and add that to a UIView (Which seems is not possible as one UIView can only display one subview) or should I draw each polygon in different CALayer and cascade the touch event to each layer?
I think your assumptions are wrong. A UIView can certainly contain and display multiple subviews. (That's why subviews is an NSArray -- because there can be many of them.) So yes, you should create a new UIView for each polygon and add them as subviews to your main view.
How do you draw multiple draggable polygons? If you're registered as an iOS developer, you can go to the Apple developer resources and look up the WWDC2011 session videos. In WWDC2001, Session 118, "Making the Most of Multi-Touch on IOS", Ken Kocienda demonstrates an app that does this using gesture recognizers to sense the touches. I don't think the code of the app is available, but he discusses it at length.
It depends on your number of polygons and how dynamic they are. If you have a high number of them, it will be costly to have hundreds of UIViews; in that case you'd be better off with CALayers and tracking the positions manually. If you only have a handful of polygons, then don't complicate your life and go for UIViews.
Related
I'm consider the following usage scenario:
The user adds a new shape to a page
He or she places the shape freely on the current view (e.g. using a pan gesture)
Also, the user can resize the shape (e.g. using a pinch gesture on it)
The shape snaps to already existing shapes on the drawing
Implementation details: A page is a custom UIView. The user can add as many shapes as he or she likes. Shapes are instances of different custom UIViews which needs to adapt their content to the new size (see step 3). Overlapping shapes are not possible. And the user must be able to select shapes for operations like "remove".
Question:
I could simply instantiate the shape UIViews and add them as subview to the page UIView. But then I would need to implement all the details like tracking touches to move UIViews to new positions, running the collision detection, handle resize and so on.
Are there controls/classes/... in UIKit, CoreGraphics or the like available which would make my life easier?
I found UIDynamicBehaviors in UIKit. Would this is be way to go or would you suggest a different approach?
Thanks a lot in advance!
Cheers,
Chris
I need to be able to interact with a representation of a cilinder that has many different parts in it. When the users taps over on of the small rectangles, I need to display a popover related to the specific piece (form).
The next image demonstrates a realistic 3d approach. But, I repeat, I need to solve the problem, the 3d is NOT required (would be really cool though). A representation that complies the functional needs will suffice.
The info about the parts to make the drawing comes from an API (size, position, etc)
I dont need it to be realistic really. The simplest aproximation would be to show a cilinder in a 2d representation, like a rectangle made out of interactable small rectangles.
So, as I mentioned, I think there are (as I see it) two opposite approaches: Realistic or Simplified
Is there a way to achieve a nice solution in the middle? What libraries, components, frameworks that I should look into?
My research has led me to SceneKit, but I still dont know if I will be able to interact with it. Interaction is a very important part as I need to display a popover when the user taps on any small rectangle over the cylinder.
Thanks
You don't need any special frameworks to achieve an interaction like this. This effect can be achieved with standard UIKit and UIView and a little trigonometry. You can actually draw exactly your example image using 2D math and drawing. My answer is not an exact formula but involves thinking about how the shapes are defined and break the problem down into manageable steps.
A cylinder can be defined by two offset circles representing the end pieces, connected at their radii. I will use an orthographic projection meaning the cylinder doesn't appear smaller as the depth extends into the background (but you could adapt to perspective if needed). You could draw this with CoreGraphics in a UIView drawRect.
A square slice represents an angle piece of the circle, offset by an amount smaller than the length of the cylinder, but in the same direction, as in the following diagram (sorry for imprecise drawing).
This square slice you are interested in is the area outlined in solid red, outside the radius of the first circle, and inside the radius of the imaginary second circle (which is just offset from the first circle by whatever length you want the slice).
To draw this area you simply need to draw a path of the outline of each arc and connect the endpoints.
To check if a touch is inside one of these square slices:
Check if the touch point is between angle a from the origin at a.
Check if the touch point is outside the radius of the inside circle.
Check if the touch point is inside the radius of the outside circle. (Note what this means if the circles are more than a radius apart.)
To find a point to display the popover you could average the end points on the slice or find the middle angle between the two edges and offset by half the distance.
Theoretically, doing this in Scene Kit with either SpriteKit or UIKit Popovers is ideal.
However Scene Kit (and Sprite Kit) seem to be in a state of flux wherein nobody from Apple is communicating with users about the raft of issues folks are currently having with both. From relatively stable and performant Sprite Kit in iOS 8.4 to a lot of lost performance in iOS 9 seems common. Scene Kit simply doesn't seem finished, and the documentation and community are both nearly non-existent as a result.
That being said... the theory is this:
Material IDs are what's used in traditional 3D apps to define areas of an object that have different materials. Somehow these Material IDs are called "elements" in SceneKit. I haven't been able to find much more about this.
It should be possible to detect the "element" that's underneath a touch on an object, and respond accordingly. You should even be able to change the state/nature of the material on that element to indicate it's the currently selected.
When wanting a smooth, well rounded cylinder as per your example, start with a cylinder that's made of only enough segments to describe/define the material IDs you need for your "rectangular" sections to be touched.
Later you can add a smoothing operation to the cylinder to make it round, and all the extra smoothing geometry in each quadrant of unique material ID should be responsive, regardless of how you add this extra detail to smooth the presentation of the cylinder.
Idea for the "Simplified" version:
if this representation is okey, you can use a UICollectionView.
Each cell can have a defined size thanks to
collectionView:layout:sizeForItemAtIndexPath:
Then each cell of the collection could be a small rectangle representing a
touchable part of the cylinder.
and using
collectionView:(UICollectionView *)collectionView
didSelectItemAtIndexPath:(NSIndexPath *)indexPath
To get the touch.
This will help you to display the popover at the right place:
CGRect rect = [collectionView layoutAttributesForItemAtIndexPath:indexPath].frame;
Finally, you can choose the appropriate popover (if the app has to work on iPhone) here:
https://www.cocoacontrols.com/search?q=popover
Not perfect, but i think this is efficient!
Yes, SceneKit.
When user perform a touch event, that mean you knew the 2D coordinate on screen, so your only decision is to popover a view or not, even a 3D model is not exist.
First, we can logically split the requirement into two pieces, determine the touching segment, showing right "color" in each segment.
I think the use of 3D model is to determine which piece of data to show in your case if I don't get you wrong. In that case, the SCNView's hit test method will do most of work for you. What you should do is to perform a hit test, take out the hit node and the hit's local 3D coordinate of this node, you can then calculate which segment is hit by this touch and do the decision.
Now how to draw the surface of the cylinder would be the only left question, right? There are various ways to do, for example simply paint each image you need and programmatically and attach it to the cylinder's material or have your image files on disk and use as material for the cylinder ...
I think the problem would be basically solved.
I'm working on building a custom control. Basically I want to allow the application to generate rectangles (positioned at x = 0 with a variable y value that increases as each rectangle is added).
I'd like them to respond to gestures where they have two positions (closed - which mostly hidden, open - expanded fully so that the entire rectangle is still visible but tethered to the side).
I've already designed an application with this in mind. Seeing as the rectangles will be generated by the users, I assume core graphics would be best for the job. Also, I want the rectangles to display different information based on their gesture-related position.
Is it possible to combine core graphics with these types of controls? I know this is asking a lot.
It's just that I'm having trouble determining how to combine each component in code.
Any advice would be greatly appreciated. Thanks!
Clearly, we're not here to write code for you, but a few thoughts:
You say that you assume Core Graphics would be best for the job. You definitely could, but you could also use CAShapeLayer, too.
So you might create a gesture recognizer whose handler:
Creates a CAShapeLayer when the gesture's state is UIGestureStateBegan and adds it as a sublayer of the view's layer.
Replace that shape layer's path property with the CGPath of a UIBezierPath which is created on the basis of updated location that the gesture recognizer handler captures when the gesture's state is UIGestureStateChanged.
I'd suggest you take a crack at that (googling "CAShapeLayer tutorial" or "UIPanGestureRecognizer example" or what have you, if any of these concepts are unfamiliar).
If you really want to use Core Graphics, you would have a custom UIView subclass whose drawRect draws all of the rectangles. Conceptually it's very similar to the above, but you have to also writing your own rectangle drawing code that you'll put in drawRect, rather than letting CAShapeLayer do that for you.
I am working on a prototype for building a DFD builder. This will have a palette of different objects for drawing DFD. (Rectangle boxes, arrows, Ellipses,circles).
I initially planned to use plain CAShapeLayer's to create objects and add it to the superview's layer (with help of CGPaths or UIBezierPath), so that I will reduce the memory footprint of the application.
Then I realized that using CAShapeLayer and adding them directly in super view's layer makes me to handle touches and use hit test to find the CAShapeLayer that was interacted by the user.
So I am planning to create a Custom UIView backed by CAShapeLayer so that I do not bother about handling the touches and spotting the specific object interacted by user.
Is this approach better than using plain CAShapeLayer? and if yes, please provide the reasons?
UPDATE:
#matt I did a memory testing and the results show that using CAShapeLayer will save memory
Neither approach is "better". A layer cannot exist without a view, and you can hit-test a layer just as well as you can hit-test a view. If you have multiple tappable drawn objects then it is going to be simplest if they are all separate layers so that you don't have to calculate which one was tapped; but that does not mean that they all need to be separate views.
As for "memory footprint", you are optimizing prematurely, a cardinal sin. Have you actual evidence that 100 layers (let's say) takes up less "memory footprint" than 100 views? Unless you do, you can't use that as a decision criterion.
So I'm looking into UIKit Dynamics and the one problem I have run into is if I want to create a UIView with a custom drawRect: (for instance let's say I want to draw a triangle), there seems to be no way to specify the path of the UIView (or rather the UIDynamicItem) to be used for a UICollisionBehavior.
My goal really is to have polygons on the screen that collide with one another exactly how one would expect.
I came up with a solution of stitching multiple views together but this seems like overkill for what I want.
Is there some easy way to do this, or do I really have to stitch views together?
Dan
Watch the WWDC 2013 videos on this topic. They are very clear: for the sake of efficiency and speed, only the (rectangular) bounds of the view matter during collisions.
EDIT In iOS 9, a dynamic item can have a customized collision boundary. You can have a rectangle dictated by the frame, an ellipse dictated by the frame, or a custom shape — a convex counterclockwise simple closed UIBezierPath. The relevant properties, collisionBoundsType and (for a custom shape) collisionBoundingPath, are read-only, so you will have to subclass in order to set them.
If you really want to collide polygons, you might consider SpriteKit and its physics engine (it seems to share a lot in common with UIDynamics). It can mix with UIKit, although maybe not as smoothly as you'd like.