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.
Related
Im planning to make a domino draw game but im not quite sure how to handle the tile placement so that each tile snaps to each value when a player sets a domino, could any one give me an idea on how to achive this?
Example image
This question is probably too broad. You really need to make an attempt at implementing a solution yourself and then come back if you run into a specific problem. However, if you really have no idea where to begin, you broadly need to do a few things:
Create a GameObjects for your dominoes and attach a scripts to the,
which define their numbers, set their corresponding texture etc.
Create an invisible play surface which is made up of a grid representing places where tiles can be put down.
Add code to handle picking up, moving and putting down your dominoes.
In the code that handles moving and/or putting down dominoes:
check whether the grid location where the domino is going to be placed is valid (e.g adjacent to another domino),
then check adjacent grid domino values
For adjacent dominoes, check their orientation
depending on the orientation relative to the domino you are placing, check the values at the nearest or both ends of the domino
if the adjacent domino values match a value on the domino being moved allow it to be placed, otherwise don't allow it to be placed
In the above example, "placing" a domino would simply mean moving it to a point on the play surface grid in either a vertical or horizontal orientation.
This is a very broad overview and there are plenty of gotchas that I haven't covered which may or may not give you trouble.
Edit: You could also do this without using a grid but it would be a little trickier when it comes to finding and inspecting adjacent dominoes.
I am working on a iOS 5 iPhone project where users can choose an image on their device, then trace an object inside of the picture (trace an apple out of a picture of a fruit basket), and then the picture needs to be uploaded with the "tagged" object so it can be pulled down later. Other people will then pull down the image and try to find where the tagged object is in the picture (Think "Where's Waldo?").
I have been trying to figure out the best way of tracing the object. Before, I had a user press the top left, top right, bottom left, and bottom right points around the object and create a square view around the object. The info for that view was uploaded and then pulled down for the user to find the object. The downside is that all objects are obviously not squares/rectangles so I need to do a free form shape.
I was thinking of allowing the user to draw over the object and then somehow I need to be able to tell what is inside of the trace (For example, inside of a circle that they traced), but a problem I forsee is making sure the trace they made is closed so I can fill in the shape (which is a whole not problem).
Any advice welcome on the best way of starting this.
Thanks!
UIBezierPath might be a very useful friend here. It allows you to create any shape you need, and it supports both drawing and hit-detection. I recently did an implementation for a storybook where I could trace out a shape with their finger, freeze it, and then use the shape for tap detection.
The basic idea is this:
When your finger touches the screen, start recording positions. Discard any positions that are too close to the previous position (eg, only record a point if it is >min-distance from the last recorded point). While doing this, you can draw the UIBezierPath so you can see what you are tracing out. Modify the UIBezierPath by adding points to it, instead of recreating it every time.* When you lift your finger, close the bezier path. Quite simple.
Now, this will result in a polygon (ie, straight edges). If your min-distance is low enough or if you are using it for hit-detection (as you say), it won't really matter. However, if you want to smooth the path, you have to use the curve-to methods, which slightly complicate it - but should you wish to follow up on this more, read up on splines and spline generation from a point series.
*note: otherwise you'll get lag while drawing large shapes because recreating a bezier path from an increasingly large series of points gets expensive. Modifying the existing path makes it much, much, much faster.
I am starting a new project in iPhone SDK in order to represent and manipulate graphs (in the sense of networks, not bar/pie/* charts).
I want to be able to interactively add/move/delete nodes and arcs between them, as well as to pan/zoom the whole representation.
As far as I can see, I have two major options:
First option: A single view handles it all.
Second option: Each element (node or arc) has its own associated view.
I think that pros/cons of each option are:
First option makes the drawing easy (you just populate the data structure and draw the Quartz 2D paths). However detection of touches is problematic, since you have to decide if a given touch point hits a node (this is easy, but you have to poll all nodes) or an edge (this is not so easy).
Second option makes it easy to implement the detection and handling of touches. However the drawing part could be problematic, since you have to rotate and resize all your views; even worse, if you drag a node you have to tell all the views (holding an edge incident to the given node) to resize/rotate themselves.
Which of the two options would you recommend me?
Thanks in advance,
Biel
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 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.