I'm implementing UI from dribble to practice my ability. Below images are original and my implementation.
I implemented almost, but I can't implement below side's shadow effect, how can do that?
My implementation is just stack two Card and move to left a bit. But I think it is not optimal solution, isn't it?
So my little solution for this one is just you need to build a stack witha container behind and a card in the front with some shadows to obtain this 3d Animation
Related
I'm picturing a graph paper like interface, as you click on any given box within the graph it gets colored in. I'm doing this to draw rough shape outlines.
My question is what is the best approach to do this? Draw the lines for the graph and track where the touches occur and color accordingly? Make some array of buttons? Maybe using spritekit?
I'm not too worried about efficiency as I'm not doing anything too complicated but I'm just trying to find some common design ideas behind it.
Something visually similar to this.
You can accomplish some pretty complex behaviours with a UICollectionView and a custom layout. UICollectionView is nice because it manages taps and drawing each cell individually, which should vastly simplify things for you.
I'm trying to recreate the barrel effect that can be seen on the camera mode picker below:
(source: androidnova.org)
Do I have to use OpenGL in order to achieve this effect? What is the best approach?
I found a great library on GitHub that can be used to achieve this effect (https://github.com/Ciechan/BCMeshTransformView), but unfortunately it doesn't support animation and is therefore not usable.
I bet Apple used CGMeshTransform. It's just like BCMeshTransform, except it is a private API and fully integrates with Core Graphics. BCMeshTransformView was born when a developer discovered this.
The only easy option I see is:
Use CALayer.transform, which is a CATransform3D. You can use this to simulate the barrel effect you want by adjusting the z position and y rotation of each item on the barrel. Also add a semitransparent dark gradient (CAGradientLayer) to the wheel to simulate the effect of choices getting darker towards the edges. This will be simple to do, but won't look as smooth and realistic as an actual 3D barrel. Maybe it will look good enough to create a convincing illusion though? (To enable 3D transforms, you need to enable depth by using view.layer.transform.m34 = 1/500.f or similar)
http://www.thinkandbuild.it/introduction-to-3d-drawing-in-core-animation-part-1/
The hardest option is using a custom OpenGL view that makes a barrel shape and applies your contents on top of it as a texture. I would expect that you run into most of the complexities behind creating BCMeshTransformView, and have difficulty supporting animations just like BCMeshTransformView did.
You may still be able to use BCMeshTransformView though. BCMeshTransformView is slow at processing content animations such as color changes, but is very fast at processing geometry changes. So you could use it to do a barrel effect, as long as you define the barrel effect entirely in terms of mesh geometry changes (instead of as content changes like using a scroll view or adjusting subview positions). You would need to do gesture handling + scrolling yourself instead of using UIScrollView though, which is tricky and tedious to get right.
Considering the options, I would want to fudge it by using 3D transforms, then move to other options only if I can't create a convincing illusion using 3D transforms.
I'm really interested in this effect introduced in iOS 7 Camera app:
http://i41.tinypic.com/2a0hwk8.jpg
Notice, how "Pano" option is transformed - as if it is goes on a circular path to the right and dissappears. What kind of transformation can achieve this effect? Any help would be appreciated.
Thanks
It is probably a transform that is applied and adjusted when the view in question (the label) reaches a certain position (which would normally be done with KVO or similar).
However, a good place to start would be the iOS 7 picker view, which has a similar 3D effect, but in the vertical rather than the horizontal. They are probably achieved the same way, and the advantage with the picker is you can inspect its view hierarchy in your own apps.
I'm struggling with conceptualizing animations with a CALayer as opposed to UIView's own animation methods. Throw "Core Animation" into this and, well, maybe someone can articulate these concepts from a high level so I can better visualize what's happening and why I'd want to migrate UIView animations (which I'm quite familiar with now) to CALayer animations on the iPhone. Every view in Cocoa-Touch automatically gets a layer. And, it seems, you can animate one and/or the other?!? Even mix them together?!? But why? Where's the line? What's the pro/con to each?
The Core Animation Programming Guide immediately jumps into Layer & Timing Classes and I think need to take a step back and understand why these varied pieces exist and how relate to each other.
Use views for control and layers for eye candy. Layers don't receive events so it's easier to use a view for those cases, but when you want to animate a sprite or backgrounds, etc., layers make sense. Events pass right through layers to the backing view so you can have a pretty visual representation without messing up your events. Try to overlay a view that you're just using for visual representation and you'll have to pass tap events through to the underlying view yourself.
An UIView is always rendered to a CALayer. When you use UIView methods to animate a view, you are effectively manipulating the underlying CALayer.
If you need to do simple things, use the UIView methods. For more complex situatins, or if you want layers not associated with any view in particular, use CALayers.
I've done a bunch of apps in the past year. Here's my rule of thumb:
Use UIView until it doesn't do what you want.
Then move to CoreAnimation. But before you get into it too much...
If you write more than a few animations, use Cocos2D.
UIView transforms are only 2D and are restricted to that, LAyer transforms however can be 3D and you should use those if you want to do 3D stuff, UIView animation will work if you change either the UIView transform or the CALayer transform. So at a basic level, you can do a lot more manipulation when you are working with a Layer rather than the View.
I am not sure if I am misunderstanding Chris' response to "What's Cocos2D doing better? Don't you have other problems then, regarding the touch event handling and many other stuff that misses in openGL ES?"
It sounds like the answer suggests Cocos2D is not based on the OpenGL ES framework when in fact it actual is. While it is a great 2D game engine it does implement OpenGL for much of it's rendering - attached to a physics library it allows for a lot of very interesting possibilities for animation - and Chris is correct - it is a lot less coding indeed.
I'm looking for ideas on how to draw a skinnable "button" in a game application. If I use a fixed sprite non-vector image for the button background, then I can't size the button easily. If I write code to draw a resizable button (like Windows buttons are drawn), then the programmer has to get involved -- and it makes skinning difficult. Another option is to break the button into 9 smaller images (3x3) and stretch them all -- kindof like rounded corners are done in HTML.
Is there another "easier" way? What's the best approach?
If you really want to accomplish this, the way to do it is with texture coordinates. Much like you would make a stretchable button/panel design in HTML with a table, you simply define the UV coordinates for the corners, the top stretchable area, the bottom stretchable area, the side stretchable areas, and then the middle.
For an example of this being implemented in an XNA engine (though it's a closed source engine), see this:
http://www.flatredball.com/frb/docs/index.php?title=SpriteFrame_Tutorial
Yes. I am working on an Editor. It's a XAML-like language (or OpenLaszlo-like, if you prefer) for XNA. So the buttons can be resized by the editor. The buttons might also be resized by a style sheet.
I guess you're right that it's likely that the buttons will all be the same size in a real design. But even in a window's app, you sometimes need to make a button wider to accomodate text.
It should be possible with shaders. You would probably have to do texel lookups, but it would cut down on the number of triangles in a complex UI.