How can I integrate a Scrollwheel into my application?
I'm currently using Sliders but have found them to be sometimes difficult to control exactly (for example with a linear scale from 0% to 100%). I guess they weren't designed for that purpose and are meant to be used for cases where not pitch perfect control is ok (Volume Control and the likes). However, I really need an exact way of inputting data (other than TextFields, they won't work in my case).
I figured that a Scrollwheel kind of UI Element would be perfect for me. Are there any opensourced Scrollwheels available that would fit my needs?
Horizontal, just like Sliders
Variable Start and End Values
Variable Scale
Small in height
Pretty :)
I tried using the Picker but that didn't work for me since it shows it's values inside of it, which makes it both big and not pretty to look at when used multiple times inside of one View.
If there's nothing available that fulfills my needs (described above) could someone please give me a hint on how to start effectively with creating such a UI element? Thanks!
I've finally found something which fits my needs :)
OBSlider, a subclass of UISlider which allows variable scrubbing speeds – it imitates the behavior seen while scrubbing in iPod.app.
Fulfills all my needs:
Horizontal
Variable Start and End Values
Variable Scale
Small in height
Pretty :)
Related
I'm new to cocoa development and wondering what the right approach would be to the following:
I have a window with controls who's size is dynamic. In other words, I don't know the width of the window in advance. I also want to give the window a padding of 15px. In the CSS world I would simply pad a div and make it inline to accomplish this. I can't seem to figure out how to do this with NSWindow/NSView.
Question is too vague to be sure, but IFF I'm understanding you, you want a subview of the window to resize itself to always be 15pixels from the left and right sides of the enclosing window (for example).
here are the two constraints (as set up in Interface Builder, but you can do the same thing from code):
That's one view whose width is set to adjust while keeping the left and right padding to the window frame at 15 pixels (points actually, but don't worry about that).
As your view hierarchy gets more complicated you'll use different techniques for different pieces of the layout. Which is why matt was suggesting that you haven't been specific enough to actually answer a question. (What specific part of what you are you trying to do isn't working and what did you try that didn't work?). I've shown you the first step of the simplest outer layer above and it reflects a principle that carries down through your view hierarchy, but there are other cases - two items with the same width, three items with the same horizontal space between them, and so on - that require different techniques.
It sounds reading the auto layout documentation all the way through would be helpful for you. It talks about different types of relations (Equal is what I used below) and some on techniques. Unfortunately Apple's documentation situation is a bit of a mess at the moment which makes this more difficult than it should be (sigh).
What used to be the definitive auto layout guide is "unmaintained" and the place that documentation seems to be heading is incomplete and certainly less accessible. The most useful part for this context is the NSLayoutContraint documentation, though that links to the "Unmaintained" document noted above (sigh).
I've been Googling like crazy for a while now, and I simply can't find any answers to the question: is it possible to implement the Android List scrolling, without using an actual list UI?
I'm trying to make a grid of rectangles such as the kind you would find in a typical game app respond to finger movement in the same way that it does using Android lists (bounce on the bounds, the 'flick' effect, etc), but all of the approaches I've found involve over-complicated solutions involving extending the list, defining XML layouts, etc.
Would it not be possible to simply give an object variables for 'document' height, 'viewable' height and y-offset? I'm happy to give the delta (MS since last update) to the object on every update. It would also be good if the actual interactive region was also definable.
Additionally; are there strong advantages to using the ListView instead that I'm missing? I assume responsiveness comes into play, but I'm quite happily managing that manually at the moment.
Just use ScrollView directly, assuming you only need vertical scrolling.
I have an infinite scrollview in which I add images as the user scrolls. Those images have varying heights and I've been trying to come up with the best way of finding a clear space inside the current bounds of the view that would allow me to add the image view.
Is there anything built-in that would make my search more efficient?
The problem is I want the images to be sort of glued to one another with no blank space between them. Making the search through 320x480 pixels tends to be quite a CPU hog. Does anyone know an efficient method to do it?
Thanks!
It seems that you're scrolling this thing vertically (you mentioned varying image heights).
There's nothing built in to UIScrollView that will do this for you. You'll have to track your UIImageView subviews manually. You could simply maintain the max y coordinate occupied by you images as you add them.
You might consider using UITableView instead, and implementing a very customized tableView:heightForRowAtIndexPath: in your delegate. You would probably need to do something special with the actual cells as well, but it would seem to make your job a little easier.
Also, for what it's worth, you might find a way to avoid making your solution infinite. Be careful about your memory footprint! iOS will shut your app off if things get out of hand.
UPDATE
Ok, now I understand what you're going for. I had imagined that you were presenting photographs or something rectangular like that. If I were trying to cover a scroll view with UILeafs (wah wah) I would take a statistical approach. I would 'paint' leaves randomly along horizontal/vertical strips as the user scrolls. Perhaps that's what you're doing already? Whatever you're doing I think it looks good.
Now I guess that the reason you're asking is to prevent the little random white spots that show through - is that right? If I may suggest a different solution: try to color the background of your scroll view to something earthy that looks good if it shows through here and there.
Also, it occurred to me that you could use a larger template image -- something that already has a nice distribution of leaves -- with transparency all along the outside outline of the leaves but nowhere else. Then you could tile these, but with overlap, so that the alpha just shows through to the leaves below. You could have a number of these images so that it doesn't look obvious. This would take away all of the uncertainty and make your retiling very efficient.
Also, consider learning about CoreAnimation (CALayer in particular) and CoreGraphics/Quartz 2D ). Proper use of these libraries will probably yield great improvements in rendering speed.
UPDATE 2:
If your images are all 150px wide, then split your scrollview into columns and add/remove based on those (as discussed in chat).
Good luck!
I would like to reproduce UIScrollView's flick-to-scroll behavior, but I don't want to use (or can't use) that class. What can I do?
Okay, I've answered this by implementing my own library that captures the dynamics of UIScrollView.
What’s useful about my code is that it is independent of coordinate system, animation rate, and particular UI classes that you're using. It can easily be nested in a custom view class of your choosing.
The iPhone’s default flick-to-scroll behavior is interesting. If you hold your finger down for a long time and move it in a variety of directions, you’ll see that only the very last direction is used to compute the scrolling motion.
If you try to build this code yourself, however, you’ll quickly discover that simply using the last two points to compute the direction of motion isn’t going to cut it. Instead, my code keeps a short history of touches and uses linear interpolation to determine where the touch “would have been” some small amount of time ago. This interpolated point is used as the basis for computing the motion vector. This leads to a very pleasing interaction.
The code is available on github, here: http://gist.github.com/100855. It is released under the BSD license.
So what about UIScrollView did not work for you? That class is pretty flexible...
Dave, I see you've answerd your own question with some code but, doesn't setting the following give you what you need:
myScrollView.bounces = YES;
myScrollView.pagingEnabled = YES;
myScrollView.directionalLockEnabled = YES;
Specifically, it sounds like you have reimplemented directionLockEnabled. Maybe understanding why you can't use UIScrollView is the more interesting problem :-)
This is cool! I've used it in an app where my scrollable view is one day's worth of graphical data in a range from 1902-2037, so a UIScrollView would not be efficient.
Please pardon my lack of Photoshop skills, but I'm curious what type of strategy Apps like Facebook and AP Mobile News are using for the 'label slider' in their applications. Here's a quick snippet outlining what I'm talking about as I'm sure the name I'm labeling the utility as is being butchered: http://dl-client.getdropbox.com/u/57676/slider.jpg
Essentially the user can touch the label and glide it along the X axis. It has a smooth bounce effect also once it hits the edges. This gives quite a bit more real estate if you need to present more on the screen than what your portrait mode allows for and is thus very valuable.
Is it a matter of just creating a UILabel that's wider than the screen with a bit of Touch API + Core Animation? Would love insight on how to start tackling this thing.
You'll most likely want to use a UIScrollView, with a UILabel as its content view. Size the label appropriately to your content, and then set the contentSize property of the scrollview to that size.
I created a similar control, and it's much easier than you think. It's just a UIScrollView with a series of UIButtons added to it. You could use labels instead of buttons - just depends on the feel you want. I think Facebook is probably using labels for theirs.
In any case, you'll probably want to use a series of components rather than one component (which is what Ben suggested) in the event that you want to, say, style the "selected" label differently from the others. It also makes hit detection a little easier.
You get the bounce effect for free by default - you may have noticed that most scroll views in iPhone apps do the same thing. It can be turned off as well.