I'm developing Piano App for iPhone.
I'd like to develop smooth-scrollable keyboard (like Music Sampler).
I put a custom view(1440px x 120px) in UIScrollView.
I wanted to use OpenGL because Quartz is too slow.
But I couldn't make OpenGL view in 1440px.
Any idea to make a faster & large-sized custom view?
Thank you.
Any instance of UIView has a maximum size of 1024x1024. Doesn't matter if it is OpenGL or not. You can have a scrollable area larger than that, but you will have to build it from multiple tiled views.
Using OpenGL for this would be overkill and a bad idea. You'll waste a lot of time setting up things that are already provided for you in UIViews, such as touch handling.
There are two ways for laying out nonstandard keyboards on the iPhone that I've seen. The first is to create a static UIImageView that contains a representation of your entire keyboard, capture touch events within this view, and match the location of those touch events to where your prerendered keys are on the keyboard. If the user hit one of your virtual keys, you overlay some sort of image that shows the key popping out at you and you process the keypress. I believe this is the approach that many of the calculator applications take.
An alternative way is to set up each of your keys as separate UIViews, lay them out within a larger superview, and have each do processing of their touch events. This is what I do in the interface shown here. The lower menu consists of two submenus, and within the submenus each of the menu buttons are separate UIViews. Their content (the border, gloss, and text) is rendered via Quartz, but that rendering only happens once. Because these views are layer-backed, they cache their drawn content and animate and scroll very smoothly. Touch events trigger each menu item's action. Note that the top half of the menu is contained within a UIScrollView so that you can scroll for more options.
My personal recommendation is to use the latter approach, because dynamically drawing your piano keys at startup lets you experiment with different key sizes and shapes without having to redo your art every time.
Related
If you go to Apple Photos and do pinch zoom you can zoom in/out to change the number of columns in the grid. I assume it uses UICollectionView, however, I have no idea how it obtains this animation.
It's not difficult to change the number of columns in UICollectionView programmatically, I don't quite get the animation.
Any ideas?
It looks like the gesture triggers a new layout. There's a whole class dedicated to switching between layouts gracefully: UICollectionViewTransitionLayout. The docs say in part:
You can use UICollectionViewTransitionLayout as-is or subclass it to
provide specialized behavior for your app. A common use for transition
layouts is to create interactive transitions, such as those that are
driven by gesture recognizers or touch events.
Unlike a regular time-based animation, the transition between layouts is driven by a transitionProgress property that you update, so the transition can easily track a gesture. You can see exactly that kind of thing happening in Photos: if you alternate between pinching and zooming, the transition tracks that by going back and forth.
It's possible, perhaps likely, that Photos uses a subclass of UICollectionViewTransitionLayout in order to provide a more polished user experience, but if you're looking to emulate what Photos does, I think this class is the right way to start.
I got an app that allows users to add content to a canvas. I would like to be able to offer the user an ability to move, rotate, resize, reflect this content. Currently I'm doing this with gestures, but would like to know if there is some sort of open-source widget that draws a box around the view and adds 4 buttons to do these functions:
rotate 90 degrees
rotate freely
resize
delete
Can anyone think of an open source framework that I can add to my project to create controls like the ones displayed?
I can probably build this by hand, but debugging gesture recognizers and view rotation is not the most fun thing, so I'm looking for something more polished.
Thank you!
Here's a link to an open source control on cocoa controls that looks like something you could use: TDResizerView.
"TDResizerView is used to resize and rotate an imageview with single finger"
Sounds like a good place to start from, even if you need to modify it.
I've never used this particular control though, so take my word for what it's worth.
edit: Also keep in mind that on iOS, users generally expect gestures. Forcing them to use the handles instead of pinching or rotating may be bad for your user experience, depending on why you want the handles instead.
I want to make an endless vertical scrolling layer that gives the impression that the main character is moving upwards. I have been brainstorming on how to achieve this.
My issue is that I want objects to appear as if they are coming from above and below the screen at the same time. Secondly, I want to be able to move the main character to create and destroy box2d joints between it and some of the objects appearing on the screen. What is the best way to achieve this with consuming too much memory? I would appreciate any help on this.
Apple did a wonderful tutorial of this in a WWDC 2011 video session. It was "UITableView Changes, Tips & Tricks" and it's about 35m40sec into the video.
Since the use of the UITableView is really just a UIScrollView for the purposes of the background, you could just use a UIScrollView and you can either have it move on timer or events as needed.
Think of your player as moving within a stationary bounding box. The background can scroll using the aforementioned pooling method (as the background tile scrolls off the screen it is placed into a pool, and before a new tile is instantiated the pool is checked for available reusable tiles). Thirdly, your enemy objects will simply approach from either the bottom of the screen or the top.
Imagine your idea without the scrolling background (flying effect) and you should find that the problem is relatively straightforward.
I also needed and endless scrolling background layer. This can do exactly that, and it is super simple to set up and use. Just copy the four files in to the cocos2d folder in your project, then follow the quick tutorial seen on the github. Make sure the image you use is seamless (when you line them up vertically you can't tell where one ends.
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 trying to make a level-of-detail line chart, where the user can zoom in/out horizontally by using two fingers, and grow the contentSize attribute of the the UIScrollView field. They can also scroll horizontally to shift left or right and see more of the chart (check any stock on Google Finance charts to get an idea of what I'm talking about). Potentially, the scroll view could grow to up to 100x its original size, as the user is zooming in.
My questions are:
- Has anyone had any experience with UIScrollViews that have such large contentSize restrictions? Will it work?
- The view for the scroll view could potentially be really huge, since the user is zooming in. How is this handled in memory?
- Just a thought, but would it be possible to use UITableViewCells, oriented to scroll horizontally, to page in/out the data?
This is kind of an open ended question right now - I'm still brainstorming myself. If anyone has any ideas or has implemented such a thing before, please respond with your experience. Thanks!
This is quite an old topic, but still I want to share some my experiences.
Using such a large UIView (100x than its origin size) in UIScrollView could cause Memory Warning. You should avoid render the entire UIView at once.
A better way to implement this is to render the only area which you can see and the area just around it. So, UIViewScroll can scroll within this area smoothly. But what if user scrolled out of the area that has been rendered? Use delegate to get notified when user scroll out of the pre-rendered area and try to render the new area which is going to be showed.
The basic idea under this implementation is to use 9 UIViews (or more) to tile a bigger area, when user scrolled (or moved) from old position to new position. Just move some UIViews to new place to make sure that one of UIView is the main view which you can see mostly, and other 8 UIViews are just around it.
Hope it is useful.
I have something similar, although probably not to the size your talking about. The UIScrollView isn't a problem. The problem is that if you're drawing UIViews on it (rather than drawing lines yourself) UIViews that are well, well off the screen continue to exist in memory. If you're actually drawing the lines by creating your own UIView and responding to drawRect, it's fine.
Assuming that you're a reasonably experienced programmer, getting a big scroll view working that draws pars of the chart is only a days work, so my recommendation would be to create a prototype for it, and run the prototype under the object allocations tool and see if that indicates any problems.
Sorry for the vagueness of my answer; it's a brainstorming question
But still, this approach (in the example above) is not good enough in some cases. Cause we only rendered a limited area in the UIScrollView.
User can use different gestures in UIScrollView: drag or fling. With drag, the pre-rendered 8 small UIViews is enough for covering the scrolling area in most of the case. But with flinging, UIScrollView could scroll over a very large area when user made a quick movement, and this area is totally blank (cause we didn't render it) while scrolling. Even we can display the right content after the UIScrollView stops scrolling, the blank during scrolling isn't very UI friendly to user.
For some apps, this is Ok, for example Google map. Since the data couldn't be downloaded immediately. Waiting before downloading is reasonable.
But if the data is local, we should eliminate this blank area as possible as we can. So, pre-render the area that is going to be scrolled is crucial. Unlike UITableView, UIScrollView doesn't have the ability to tell us which cell is going to be displayed and which cell is going to be recycled. So, we have to do it ourselves. Method [UIScrollViewDelegate scrollViewWillEndDragging:withVelocity:targetContentOffset:] will be called when UIScrollView starts to decelerating (actually, scrollViewWillBeginDecelerating is the method been called before decelerating, but in this method we don't know the information about what content will be displayed or scrolled). So based on the UIScrollView.contentOffset.x and parameter targetContentOffset, we can know exactly where the UIScrollView starts and where the UIScrollView will stop, then pre-render this area to makes the scrolling more smoothly.