i am quit new at iphone development and trying to make a photo collage software while learning it. Right now i have a lil problem and hope you can help me out.
I have an UiviewController with a view in it, in this view i have 7 scrollviews with uiimagevies in them for zooming and scollign images within these scrollviews.
All that works well but now i want to make these 7 scrollviews dragable and maybe if possible zoomable (so that the image within the given scroolview zoom together with the scrollview).
It should be possible to drag them all around the screen and if possible even overlap them
and by the way rotating would be great ;-) hope that is not to much asked for.
Would be great if someone can help me out with this..
Well you've got to decide on some other choice here because the functionality you are asking for overlaps, and you can't ask the app to magically know which the user wants to do. What I mean by this is that when you touch and drag within a scroll view, it's going to try to scroll itself, rather than drag the entire scroll view around.
As for rotation and zooming - that gets more complicated, because you start dealing with vector math and the like. You can check out my question on rotation here. The link I gave you has the code to get both rotation and zooming to work.
Related
i'm new to game developing so i might be a little confusing on defining what i need.
Assume i have a wide background picture, much bigger than the screen(e.g.4000*3000px), how should i approach if i want to navigate it with the input from the gyroscopes?
i mean handling the device up, down, left, right and so on.
If you remember the old Mosquitoes game on Symbian i would like to do something similar but without the camera.
However any suggestion is appreciated.
Thanks in advance.
Use UIScrollView - put your pic inside the scroll view and try to navigate with fingers.
When scroll will be working nice, use this or this or any other tutorial to find out how to use accelerometer.
Finally, when you will be able to collect data from accelerometer, give it to UIScrollView using [myScrollView scrollRectToVisible:myRect animated:YES];
All needed math and physics must be done by you.
Ok so i have a good chunk of my game finished now and Im working on my level select view. I want to implement a horizontal scroll view with multiple buttons on each view, in something that looks like Angry Birds or Cut The Rope, or something like that. I know I use a scroll view and set anchor points from my reading on here and other sites but im not sure exactly how i can implement that. Im a bit of a noob and my game didnt need to implement any real graphics so im not familiar with open gl or quartz, although im not afraid to try to learn it.
Anyone know how i can implement anchor points in a horizontal scroll view for my level select view?
Thanks!
As already answered, you have to use UIScrollView. We use scroll view when our contents are too large to be shown on the screen.
Refer the class reference here and Some links that could hep you.
Apple's scrolling demo
Understanding Scrollview
I hardly know how to explain my case other than to point to the excellent Absolute vodka app, Drink Spiration.
I am trying to make a carousel like image browsing with a little spice. I would really like to find a simple core animation explanation on how to accomplish something like the above app.
I hope someone can help with this. The solution doesn't have to be exactly the same, but just explain what is happening and it would be best if it was simple and no opengl. Just something to point me in the right direction. I don't think using just a scrollview with uiimageviews is enough.
I wrote something similar and its quite easy once you figure it out in your mind. All done justing using regular old views and animating transforms on them.
Say its 3 images on screen, and you can rotate new ones on and off ... then you will need 5 views set up (most simply just a UIImageView with a relevant image set). They are the currently selected image, the two either side of it and the ones that are, or will be animating on or off when the user flicks left or right.
Each of these 5 images has a position, an angle and an image. When the user flicks left or right each gets animated to the next position and angle, views that are about to come onscreen have their image updated to the next image in the set. If the user keeps on flicking in the same direction you simply reposition views on one side as they come off the other.
With this setup you can do lots of cool carousel like things very simply.
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.
I have horizontal list for which I'm implementing my own scrolling logic. I have the "touch and drag" scrolling working great, but I'm having trouble with the "flick" gesture. All the built in scrollable views have the feature that if you "flick" the view it scrolls faster or slower based on the intensity of the flick.
Does anyone has any suggestion how do that for my view?
What I'm doing right now is changing the UIView.center.x coordinate of my custom UIView to scroll it across the screen
I would strongly suggest you figure out how to make use of the built in UIScrollView class. Apple has invested a LOT of effort to make scrolling feel 'right'. You may be able to recreate some, or even all, of that feel, but it'll take a lot of work. Better to piggy back off of what's already been done.
If you want to implement your own scroll view, you'll have to make the view scroll based on the length of the sweeping distance and the speed at witch it went across the screen. Taking these parameters as input and using simple geometry math you could calculate how much further the view should scroll after the sweep has ended(touchesEnded event).
Ofcourse this is not as simple as it sounds, making the flick gesture just feel right and natural is much harder.
If you really are set on doing this yourself, Drew McCormack has a great article on MacResearch where he explains some of the physics behind momentum-based scrolling. His implementation uses HTML, CSS, and JavaScript, but the core principles could be brought across to your custom UIView subclass.