My iPhone development is stepping up a notch and I'm looking at the UI. We're thinking of having a few nice interface-y features - things like dragging and dropping images onto one another from a gallery list, or similar.
How far does the basic iPhone interface stretch? Do most people create their own interfaces and code, and if so what's the base there? CoreGraphics? OpenGL?
I don't want to reinvent the wheel, but neither do I want to take an overcomplicated option if someone's done the work already.
There are several tiers to Cocoa-based interfaces. Generally, I recommend working at the highest level of abstraction that meets your needs for presentation and performance.
The base UIKit elements that you can place using Interface Builder or code are designed to handle the most common cases within an application's interface. These provide some degree of customization, depending on their type, but what you see is generally all you get. On the iPhone, Apple even tries to maintain a certain look and feel for these stock elements by rejecting applications during review that use them in ways that contradict the Human Interface Guidelines.
The next level down are custom UIViews. These can be made to look like anything through the use of Quartz drawing within the -drawRect: method. You can do your own touch handling by overriding methods like –touchesBegan:withEvent: or by using the new UIGestureRecognizers. Given the level of customization you can do here, this is where most people stop when tweaking their interfaces.
You can go a little lower than this by working with Core Animation layers and animations. You don't gain a lot, performance-wise, by using CALayers instead of UIViews on the iPhone, but they can be useful if you want to craft visual items that use the same code on Mac and iPhone. Custom animations may be required if you want to do something more than animate a view between two states linearly. You can even do some limited 3-D work using Core Animation.
Finally, there is OpenGL ES for display of full 3-D scenes and for really high performance graphic display. This is about as close to the metal as you're going to get when dealing with the iPhone display system, and it shows in terms of the amount and complexity of code you have to write. For complex 3-D work, this is what you will need to use, but for 2-D and even rudimentary 3-D I recommend looking first to Core Animation because of the code it can save you. If performance is unacceptable, then should you go to OpenGL ES.
Now, just because you need to use one of these technologies to work with part of your interface does not mean that it can't coexist with the others. UIViews are backed by Core Animation layers, and even OpenGL ES renders into a CALayer which can be placed in a view. Again, use the highest level of abstraction that is appropriate for that part of your interface.
Related
In our current app, some consultants wrote code in OpenGL to make things look nice. Basically mimicing a UITableView, goes horizontal instead of vertical, and of course prettier. I was reading through a Core Animation book and they said that with Core Animation, you could mimic Apple's Cover Flow navigation. To me, that looks nice enough.
Does anyone know if any of that is done in OpenGL or just Quartz and CoreGraphics?
Secondly, (here's the open-ended question), but if we were to redesign something to mimic Apple's cover flow, assuming it was not in OpenGL ES, would that be less memory intensive and perform better? It seems like our app runs out of memory rather quickly in its current state since it's pushing a lot of data through the horizontal table.
The content of a Core Animation layer (text, shapes, images, ...) is rendered with Quartz, but the rendering of the layer itself is done by OpenGL, so rendering performance shouldn't be a problem.
Core Animation might use less memory, because it can release the content of invisible layers (or table cells in your case).
All you ios architects out there, please help me choose architecture/technology for the following iphone/ipad app.
The app itself is a financial app, but we want more of a game look-and-feel of the app, so we probably don't want to use the builtin looks of the cocoa widgets. The elements on the screen will probably be some kind of blob-shaped images.
The app will essentially have five "blob"-shaped areas, spread out evenly across the screen. One of the blobs will be centered and larger than the other ones. Within each blob there will be clickable areas which will pop up "details" and menu-action blobs. These blobs are also graphics objects and must not take over the whole screen. The blobs should animate nicely when popping up. The graphics elements will have a couple of lines of text, which are generated, so the overlaying text itself cannot be part of the static background-image.
The main user interaction will be swiping within the center blob, displaying summaries of the items that are conceptually contained within the blobs underlying data store. Now and then, the user will drag and drop the item to one of the other blobs. While dragging, the item should be traced by a line and when dropping on the other blob, the item should be animated to look like it's being "sucked into" the blob.
Now, what kind of technique would you suggest for this app? Is Cocoa suitable in this scenario? Should I use a game framework like Cocos2D? All kinds of suggestions including example code snippets are most welcome.
I realize that this question might not be as straightforward and to the point as questions generally are on SO, but I hope your answers will come to use by more people than me. Thanks!
EDIT (MY SOLUTION):
I eventually ended up doing everything in UIKit, which was a lot easier than I expected.
Briefly described I used UIButtons with Custom style and an image background, which gave me full control over the visual appearance of the "items". I also found it very useful to manipulate the underlying CALayer of many of my other UIViews. It is often easier than drawing things from scratch using Core Graphics programming.
Another thing that was useful were the UIGestureRecognizer:s. I found them useful for both handling "real" gestures like swiping, longpress etc, but also for handling normal "tap" for UIView classes that aren't subclasses of UIControl. Two examples are UIImage, UILabel and UIView itself. That way I could handle taps for these simple classes. I could for example use a normal UIView, modify it's CALayer to change the look of it completely and still handle taps. Using this technique, I didn't have to subclass any views at all in my app.
The animations were pretty easy too, even though I had to use a non-public method to use "suck" animation, so my app will never pass App Store moderation. It was just a prototype anyway so I don't care.
When this app will be for real, I will probably implement it in HTML5/JavaScript wrapped by Phonegap. The reason for this is mainly reuse of existing mobile web services and also for code reuse across platforms. It will probably also be easier to hook into the existing security solution when using a webapp.
Cocos2d is great if you need to move elements around really fast as it is a layer on top of OpenGLES. I think from what you have said the UIKit will be fine, you get nice animation support, you can do some nice things with UIScrollViews to handle moving elements around etc.
If you need more detailed graphics support and lots of moving elements, particle effects etc then by all means go for Cocos2D but be aware that in Cocos2d the application works more on a scheduled update method, i.e. you get notified every 1/60th of a second to move stuff draw stuff etc, whereas with normal UIKit approach it is more event drive, i.e. I click a button and show a view etc.
I'm creating an interactive e-book for the iPad. This book will contain multiple pages that will consist of a lot of animations (frame and motion animations), transitions,... I was wondering what my development options are, should I use OpenGL, Quartz,...?
I've use UIImageView.animationImages before and found that it had really bad performance. What's the best way to draw frame based animations?
Does anybody have some good pointers to resources on this?
thanks in advance,
Thomas
I guess that depends a bit on what you'll be drawing. If you have a need for 3D, then OpenGL is the way to go, but it doesn't sound like it. I have a feeling Quartz2D is going to be just fine for your 2D drawing needs. I've done drawing with both and they have a very similar API. I think the downside of using all the raw power of OpenGL is that you have then signed up for doing most of the work yourself. I don't recommend attempting to using Core Animation high level APIs to manipulate OpenGL views.
If you do use Quartz2D and "normal" UIViews instead of OpenGL/EAGLView, then you can take advantage the many pre-canned animations Apple already build with Core Animation. This include the card flip left/right, resizing, moving (x/y translation), rotation and the ever popular e-book page curl.
The best example of iBook like custom page curl functionality I could find is this example code from High Caffeine Content. However, you don't have to bring that much math to the table if you just want to use the out of the box Core Animation stuff. The bad performance you may have encountered could have been due to anything, including older/slower hardware. They have revved the graphics chips on the new devices.
I have to develop an application "Behavior like an Tetris game".
I have never used "OpenGL" for the iPhone application developement.
Application is something like this
Red / green / blue square boxes drop from top
Red + Red + Red = Points & boxes disappears
same way user has to make combination & get points
Different levels are there.
There are three buttons Left, Right for movement & bottom for speedy fall
For this kind of application should I use open GL or NOT?
i.e. Is it possible to develop entire application with view & it's animation?
If yes then, will it be more complex as compare to open gl?
What is the advantage of using open GL?
(I know that it gives good 2d, 3d look )
(But here my question means - easy coding?)
(Or open gl is more complicated as compare to objective-c?)
(I am just asking because I am not aware of it)
Basically your options are:
Using OpenGL
Using Quartz
Using UIKit
OpenGL is a fairly complicated beast, but is by far the best way to squeeze performance out of the iPhone. Do you need it for a Tetris game, though? Almost certainly not.
Quartz is the toolkit used in Mac OS X and the iPhone to draw images and do image effects. Because I come from an OpenGL background in other languages, I find Quartz strange and frustrating. However, it is probably easier for someone who is new to both.
You can do everything here using UIKit, and it will definitely be much much easier than other options. The main disadvantage is that it's rather slow in comparison, but once again doing a Tetris-like game shouldn't matter at all.
Before you go with UIKit, though, I recommend just checking out something like Cocos 2D, which will give you the advantages of OpenGL without the headache of dealing with all of its inner workings.
From the tone of your question it looks like you're confusing what OpenGL is and isn't with regard to Objective-C.
OpenGL is a library written in the C programming language (to put it simplistically) that excels at rendering shapes (especially 3D shapes) for display on a screen. It doesn't replace Objective-C inside your program, it merely assists you in drawing the shapes. If you don't use OpenGL, you'll need to write some sort of drawing/rendering code in your NSView (or subclass) to render the blocks. By using OpenGL, you will be provided a lot of helpful C methods for drawing shapes, which otherwise you'll have to implement yourself. On top of that OpenGL has thousands of man hours worth of drawing optimizations that you can take advantage of if you use it rather than trying to implement shape rendering yourself.
Having said that, OpenGL isn't all sunshine and roses. It works like a state machine and has its own assumptions about the way it will be used (like any API). Just because you know C and Objective-C doesn't mean that using OpenGL will be trivial. If you've never written any OpenGL code, I suggest you look into a reference like the venerable Red Book.
The thing to keep in mind is that OpenGL is not a language until itself (ignoring the OpenGL shading language). Its merely a set of C functions to aid you in rendering graphics.
You may well want to ask as well on http://iphonegamedev.stackexchange.com/, the new Stack Overflow variant just for iPhone gaming.
To learn & understand what you need.
Please go through following link.
it includes all necessary links for all kind of resources that you needed.
http://maniacdev.com/2009/04/8-great-resources-for-learning-iphone-opengl-es/
Edit :
After reading your question properly ( actually my question - By r & d I found solution).
I think - you need to develop a 2d application.
Go for the following link. Best option for 2d animation.
http://code.google.com/p/cocos2d-iphone/
Don't forget to visit following link, if you needed sample codes.
http://monoclestudios.com/cocos2d_whitepaper.html
I am wondering what makes Layers different from Views, when every View comes along with it's own Layer. Maybe I am wrong with that. But then: What are these Layers good for?
Like I understand it, I would use an UIView to group elements in my GUI. I could also use that UIView to position things over other things. So where come Layers into place here?
Should I think of them just as the z-index like in HTML / CSS? Are they just interesting for Core Animation stuff?
Compared to UIVIews, CALayers are
lightweight
filled with timing information for animation
Some things are harder to draw, like text (esp. unicode).
If you have less than 20 or so of them, it probably doesn't matter. If you have complicated animation needs, or just a ton of layers to draw, you may benefit from using CALayers instead.
On the iPhone, there's not a significant performance difference between using UIViews and CALayers, in my experience. The Mac is a different story, with NSViews being significantly more heavyweight.
Dealing with CALayers (or at least a view's layer backing) is sometimes necessary for complex animations, particularly keyframe animations or movement along paths.
Additionally, CALayers can be used to create platform-independent (Mac and iPhone) custom user interfaces. UIViews are very different from NSViews, but CALayers are identical between the iPhone and Mac OS X Leopard (aside from a few properties that are missing on the iPhone). I've used CALayers to share UI code between an iPhone application and its Mac counterpart.