I am new to sprite kit. Does anyone know how to divide the view controller into two parts. One is fixed and the second one is movable (I mean like two screens)?
You could create a UIView as a container for your whole screen and within that UIView add two SKViews which would be your "two screens" that you could do with as you needed.
You could give them the sizes you require by getting the first views height and width and set the SKViews proportionally based on that size. Such as an SKViews frame would be the parent UIViews height divided by two.
What are you trying to do? You may not need two controllers. You can use an SKNode as a "screen" in many circumstances. I believe it's also possible to put two SKScene into one view.
So, what does the motionless screen do, and what does the movable screen do?
If it's something like a minimap / menu (like Nintendo DS) then you can easily do that with an SKNode.
You don't need two screens to "ignore" the motionless part of the screen... you get the touch inputs every frame--it's up to you what to do with them. In other words, if the user touches the non-moving part of the screen, you can just ignore those inputs.
Related
I'm trying to do a custom layout like the Chanel app you can find the app in the Appstore.
https://itunes.apple.com/us/app/chanel-fashion/id409934435?mt=8
I know they are using an UICollectionView, but no clue how to start.
The interaction feels like a tableview mixed with a paginated scroll. When you scroll the elements grow, and the first element position itself at the top.
Start with dragging & positioning just one UIView. See UIGestureRecognizer docs and look for existing examples of movable views. You'll need an UIPanGestureRecognizer to move the view.
Resize the view depending on its Y position.
Create & position an image inside that view depending on the view size using a couple autolayout constraints.
Note that Chanel app has different constants for these constraints. With a minimum view height, one image's top is 80% height, for another image it's 90% height. Make sure you can manipulate constraints from code (I think it's a good idea to create everything from code there, XIBs are not very flexible).
Make the view "anchoring" to certain points (e.g. top = -75%, 0%, 75%, 90% from what I see in the Chanel app) when you stop moving it. Just find the nearest one and animate the view to it.
Once you did it with 1 view, move all your work to an NSView subclass (if it's not yet there) and create a collection of these views.
You can create UICollectionView, but I'd rather do it with a simple NSArray: I actually don't see a reason to use UICollectionView here; it's a very simple structure. Anyway, you write your own gesture recognizer (don't you? I can't see another way) - so what's the point to use UICollectionView? If you want to expand the app functionality some day, UICollectionView will unlikely help you with that. Well, it's my hypothetical approach, you can find another one while working on that.
Position other views while you're moving an "active" view. Do it by hand, without any UIScrollViews.
Write a function that reflects the Y position of the "neighbor" views while you moving one. It should "slow down" to the bottom of screen.
I have a UIView, defined in a nib, and I need to be able to show/hide a middle button in that view. When I show the button, I need to reposition the two bottom buttons below it, as well as make the view taller to make room for everything. When I hide the middle button, I need to move the two bottom buttons up and vertically resize the view to make it less tall. I do NOT need to animate any of this since it the changes will never occur while the view is visible to the user.
I'm new to iOS and I'm used to using Autolayout, but I can't use Autolayout in this case to handle this automatically, so my current approach is to hardcode the frame position and dimensions for the two bottom buttons for each of the two different situations. I'm also hardcoding the two different frame sizes for the view itself. In viewDidLoad, I determine if I need to show/hide the middle button and set the frames for the view and bottom buttons appropriately. This works, but if feels hacky. Is there a better way I should be doing this?
Thanks in advance for your wisdom!
You don't need to hardcode your frame sizes in viewDidLoad. The only thing you should take care of is determining that whether you need to show you middle button or not. Within the implementation file where you are allocating your UIButtons, check if the middle button has to be shown, if Yes allocate it, if not then don't. The frames of two buttons and the view should contain a factor which can set/size them accordingly.
You'd basically be managing the Auto-layout programmatically. And if you're not even allowed to that then whatever else you'd end up doing would pretty much be a hack.
I'm in the market for a nice thorough example/tutorial link or demo on programmatically creating and redrawing/resizing on rotation a view with nested tiled views. This means that the root view will need to rotate on rotation, and trigger all nested views to also rotate and resize.
For example, lets say you have a view with forty rectangle views tiled within, Id like to rotate an iphone/ipad and have the forty nested views also rotate (not hard) but more importantly resize and move. A four by ten grid might change to be five by eight.
I'm able to effect this programmatically but I'm finding that the x/y bounds etc are all off kilter.
Please no comments about "But just use storyboards"...
Thanks!
I've found that it can often be a bit of effort to get it working as you'd like/expect. Things to take into consideration are the callback you are using to pick up rotation, there are 3 and they serve a slightly different purpose
- (void)willAnimateRotationToInterfaceOrientation:(UIInterfaceOrientation)orientation duration:(NSTimeInterval)duration
This is probably the one you want to use, at this point when you query self.view.frame (or whatever you use to get the super frame) it will return the value that the frame will be once the rotation has complete. It also takes into account auto-resizing, and it gives you this before the rotation has taken place (ie no visible effect yet). Use this to calculate all the new positions and sizes of the views and set them.
- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)orientation duration:(NSTimeInterval)duration
This tells you the rotation is about to happen, but still returns the frame for the current orientation, useful for hiding/showing views, but not for calculating new positions!
- (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation
This is called once rotation is complete, it returns the new sizes and frames, but if you attempt to reposition views here they will look as though they are jumping around after the rotation is complete.
I'd also recommend playing about with auto-resizing, as this can be a real bitch. I sometimes set the auto-resizing in code as well as in a xib juts to be sure there is no funny business!
If the rectangles are nested in a view controller they should rotate automatically (you probably knew that just thought I add it in case)
I am trying to create an iOS UI where I have a set of subviews arranged as a grid on the UI and on clicking any of them I would like to expand this subview to a larger size. I am able to do the animation to expand this subview but I would also like this functionality such that other subviews nearby are pushed away.
On dimissing, this expanded view it should contract to the original size and bring back the other views to its original location.
I am thinking of a variety of ways to implement this but there are many use cases, and hence I would like some pointers in the right direction?
Does iOS itself provide a functionality by which expanding a sibling view contracts/moves the neighboring one? If not, what other ways are there to implement this?
Toms
What would be the best way to have a vertical scrolling screen? My game will consume two screens high, the user should be able to move between the two screens by a simple drag or swipe action. The background is not tiled and sprites will be placed on it. What would be the best way to go about such screen management?
You have asked two questions here. The fist of which is how to respond to touch gestures (like a swipe). This blog post and associated sample is a good starting point.
The second of which is how to have two screens. This is also simple. Pass a translation matrix (Matrix.CreateTranslate) into SpriteBatch.Begin. How you want to do this is up to you. If you want both screens to have (0,0) be the top left of the screen, give each of them a translation matrix and translate one downwards by the display's height below the other. (While a screen is out of view, you could skip drawing it entirely.)
When the user swipes, simply animate the translation such that one screen moves out of view, and the other moves into view.
It depends on whether you want users to be able to see half of the top and half of the bottom screen, or only ever the top or the bottom.
You could try placing the two screens worth of content into a ScrollViewer, and setting the ScrollViewer.VerticalScrollbarVisibility to False; this would allow users to drag/swipe easily between the "screens".
Something like:
<ScrollViewer VerticalScrollBarVisibility="Hidden">
<my:FirstScreen/>
<my:SecondtScreen/>
</ScrollViewer>
One thing to consider would be whether you want to handle the user changing the phone orientation, or whether you'll lock the phone into Portrait/Horizontal orientations. I also believe that phones with different resolutions will eventually be released and any applications in the Windows Marketplace will need to be able to handle both full and half resolutions.