I'm pretty new to iphone development, so this is more of a high-level question. The simplest description of what I am looking to do is create a zoomable/panable field on which I can place a bunch of circle objects. The number of these circles is likely to be in the hundreds, and ideally when the user zooms in close enough, more information can be displayed. From stuff I've read, it seems like UIScrollView provides the simplest way of making a zoomable/panable view but I'm not sure it's the best way to handle a view that includes a hundred graphic objects. I'm trying to figure out if I should progress further down that path or look into things like CALayers, Core Graphics, etc. Any guidance or advice would be greatly appreciated. Thanks in advance,
Roman
I suggest you to use UIScrollView, because it will save a lot of time for handling proper zooming/scrolling. So the workflow is next:
1. Zoom you scroll view
2. In delegate's callback scrollViewDidEndZooming:withView:atScale: you can obtain the scale and determine the level of detail that you need.
3. redraw the visible region (using Core Graphics) with appropriate level of detail (number of circles etc.)
So you should use the mix of Core Graphics and UIKit.
Related
I'd like to allow a user to add a shape (which would just be a UIImage) onto some sort of canvas, then move and resize it on the screen but I'm not sure how to go about this. Ideally I'd like the basics of a drawing app which can use images from a user's device. Each shape would have an associated position, size and z-index.
The only thing I'm unsure of is how I'd create a bounding box (the one with four blue dots to allow resizing/moving). I have experience with UIKit, and would prefer to keep the majority of the app in this for the time being, but I get the feeling this type of thing might be better suited to Cocos2D or a similar framework.
If anyone has any pointers/open source code I can dig through it would be hugely appreciated.
I think you should look into CALayer, or even CAShapeLayer. I'm just starting to play with them, but I'm pretty sure you can easily get the functionality you want with either. Draw the border in the layer's drawLayer:inContext:. Check out the Quartz2d Guide path drawing section for the functions you need.
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!
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 want to create a bar chart diagram. I already have a diagram component, I just need to adapt it to a bar chart. When touching one of the bars, the value shold pop up in small view.
As I can see there are several different strategies that can be applied here. What I want to know is which strategy should I use? Any of these or perhaps there are other better ideas?:
Bar is a UIButton.
Bar is a touch enabled UIImage.
Bar is a UIView.
Bar is just painted graphics and I have to transcode the touched coordinates and make some calculations in order to know what bar was touched. I don't don't believe in this strategy but perhaps there are reasons to rethink this that you can provide for me...
I assume that a UILable is the way to present the data associated with the bar?
Thanks in advance for your advice!
In my humble opinion, and having written many bar charts (and other charts)... #4 is actually the correct choice for performance and my personal preference. Creating the virtual graph in memory to map touches to bars is not difficult at all, as you are simply storing rectangles in arrays and checking to see if points are inside that rect.
CGRectContainsPoint(CGRect, CGPoint);
Now, having said that, if you want to introduce animations in to your chart, which is pretty cool stuff... then I could create a UIView composed of several UIViews (one for each bar, or bar segment), this way you can animate each bar individually without writing your own animation loop.
just my two cents.
my thoughts are that #2 and #3 are kind of the same since you'd display an image using a UIImageView. UIButton is a pretty thin layer on UIView that makes the event handling easy, but it might do things visually you don't want (or maybe you do?). Either way, it's so easy to try these variations I'd just play with it. I can't see a specific reason for #4 unless your overall strategy drives you in this direction, like maybe you start doing some drawing that is rich/complex enough that you have too many views being created.
AFA the popup display, it really depends what you mean by "pop up". Like once it pops up, do you need a way to dismiss that popup?
Have you checked out Core Plot? It is an active and powerful library that is pretty flexible and should meet all your needs.
Here's what I need to do:
I will have a toolbar with multiple objects on it (for this we'll call them A,B,C,D) and I want to be able to have the user click and drag them around and be able to snap them to a grid and connect to each other.
Sounds easy, right? Well here's my problem: some objects are different sizes, so A could be a 1x1, B be 1x3, C be 3x4, etc.
So how should I do this? I was thinking about just having each element as a separate UIImageView (or UIView, haven't decided yet) that can be dragged around, then take it's location and see what images are next to it.
Another thing is I have to be able to export these locations to either xml or json (not sure yet, probably xml)
It sounds like you would need a subclass of UIView with tessellation or some sort of underlying grid coordinate system with the units being 1x1. The 'tiles' could be subclassed from UIView, having a UIImage and grid position information. If adjacent tiles are by definition connected, then you wouldn't need additional state information about connectedness. And writing this out would be as easy as writing out origins.
I am working on something similar, but with single-sized tiles. It has been fun - especially the insertion logic: positioning a tile between two other tiles and figuring out what gets moved to make room.