I am working on iPhone application. I am having a MemoryViewController page on which I have to display questions to the user for a particular time period. I have to reload same view with new question again and again. Here I have to apply view animation in the form of right to left move. and the new view will contain new question.
Have I to take 2 different views on the same parent view? or it can be implemented with same view.
Any code help, please.
Thanks.
I would make them in two different views, so you would end up with something like:
newQuestionView.frame=CGRectMake(360.0,0.0,newQuestionView.frame.size.width,newQuestionView.frame.size.height);
[UIView animateWithDuration:1
animations:^{
oldQuestion.frame=CGRectMake(-360.0, 0.0, oldQuestion.frame.size.width, oldQuestion.frame.size.height);
newQuestionView.frame=CGRectMake(0.0, 0.0, newQuestionView.frame.size.width, newQuestionView.frame.size.height);
}];
What will happen is:
You first position the new question in the right side of the screen, so you can see it coming from the right. Then, inside the animation, you will put the old question in x=-360 and the new on in x=0, this way you will have the effect you want. In the animateWithDuration:1, you can change the 1 to whatever time you want the animation to last.
Related
I have a ContentView with a StackLayout with multiple children sized to the full width of the screen. In other words, if the screen width is 320 and I have five children, the inner StackLayout is resized to 1600.
In this ContentView, I have Next and Previous buttons that when clicked, animate the inner StackLayout's TranslateX property. Basically, I'm creating a carousel by translating the StackLayout within the ContentView. I chose this route because I was having layout issues using a ScrollView and a custom renderer when I would modify that layout of the view (by hiding labels, etc.)
However, I've hit a snag. Content that appears after I set the TranslateX property doesn't receive any tap events. I believe I might have to reset some tappable area, but I'm not even sure where to begin with that. Does anyone have any suggestions?
I posted this same question in Xamarin's Forums, and someone there answered. For anyone looking, the answer is here: https://forums.xamarin.com/discussion/comment/142914/#Comment_142914
If that link stops working at some point in the future for some reason, the relevant answer is:
Hit testing is done based on the actual frame of the control determined by layout, but translation happens after layout. Therefore hit testing does not take translation into account. If you want a view to be touchable then you should update its layout directly rather than using translation.
Storyboard Screenshot
I wonder if anyone can shed any light on this for me.
I have a UIPageViewController as part of a SWRevealViewController structure as seen in the storyboard in the linked picture.
The UIPageViewController contains a series of UIViewControllers which have a vertical scroll views in them. The first page shows fine but when I swipe left to display a new page the view loads about 30 pixels to high and after 0.5 a second it drops down to the right place. After that when you scroll left and right it displays normally.
I have tried everything in this post so far and nothing has worked.
self.automaticallyAdjustsScrollViewInsets = false;
pageViewController.automaticallyAdjustsScrollViewInsets = false;
I am pretty sure it is something to do with UIPageViewController scroll inset but not sure what to do about it as I have tried everything I can think of in the last 3 days to try and fix this.
Thank you in advance
Not sure if this will help you, but I had a smaller 5px bounce issue scrolling images in a UIPageViewController. Nothing in the post you look through helped me either. But using a separate UIView as a container view between the individual page view controller's view and my UIImageView miraculously solved the issue for me.
So the hierarchy you want in your page's view controller's view is:
Main View
Container View
Your Actual view content
How could I move a subview to the front of the stack when the LevelMeter detects a certain amount of decibels? I want LevelMetering to be active in real time without a record play function.
Ultimately, I'm trying to animate a mouth to open and close based on sound.
To make a view topmost in the view order, you just have to send a -bringSubviewToFront: to the view that contains it. From a view controller, you might do something like:
[self.view bringSubviewToFront:levelMeterView];
If that doesn't answer your question, perhaps you can expand a bit on what you're asking?
I am trying to create a resize toggle animation on this simple custom TUIScrollView class (from TwUI open source project and very similar to UIScrollView) that I have built. It is called TUILayout and supports horizontal layout as well as vertical, animated insertions and removals and has a more declarative way of supplying data to it's cells that I prefer over delegation. It recycles views similar to TUITableView or UITableView. Anyway if you want to follow along, it's just one class and is here.
https://github.com/mrjjwright/TUILayout.
In the example code, the user clicks the blue button in the lower left and all the rows shrink smoothly to a size where the user can reorder and delete some rows (right click on a row in the example to see this in action), etc... and then the user toggle the rows back out to their original size by clicking the blue button again.
While doing this resize in setObjectHeight:animated I first resize my model objects that represent the rows, recalculate and set the contentSize on the TUIScrollView, cycle in all the new views (say 10 more views will fit in the shrunk view so dequeueReusableView and addSubview gets called 10 times) and finally I animate the frames of all the views to their size and location in layoutSubviews.
The result is that the scrollview correctly shrinks to a size where the scrollbar no longer displays, the views that are on screen animate smoothly down to their reduced size, but the newly added subviews that can now fit in the visibleRect animate in much later as one block of subviews.
So all the newly added subviews lag behind the views that were on the screen and I can't figure out why the animation isn't all happening together. I have tried lots of different combos of things with no luck including CATransactions. I am wondering if it has to with how a CAScrollLayer works or if somebody can help me think through this.
The more general issue is how to smoothly handle resizing animations on scrollviews that recycles their views and I have looked at several other grids out there in the iOS world and have got some inspiration but am looking for more.
Thanks!
I think I might have solved my own issue here (as I was making my bed this morning it hit me). I forced the current runloop to run after cycling in all the necessary subviews and very importantly not setting the contentSize of the scrollview until after the run loop completes and adds the needed subviews for the animation. In order to get the run loop to fire I used the trick from this SO question:
skipLayout = YES;
[[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode beforeDate: [NSDate date]];
skipLayout = NO;
If skipLayout is set TUILayout just returns from layoutSubviews so that the views just added are not immediately removed by the recycling layout code. Forcing the run loop to run made sure that all subviews were on the screen for the animation. After this I performed the resize animated layout. I updated the code on github if anybody is interested. I will leave this question open for a while to gain some further insight.
I have a view that is being shown within a larger view and will always remain in the same place. When some user input is provided, a second view will appear below the first one. want this to be a somewhat smooth transition so what I've done is place the second view directly behind the first one, then started a timer that check if the views overlap using their intersection, if they do, the second view is slightly lowered, and overlapping is checked again, until the views no longer overlap, and the timer stops.
I want the transition to seem like the second view was behind the first one and is now being slid out from underneath. For that reason I created an "imaginaryRect" that represents exactly where the second view (called progressBarView) would be, if it was being displayed entirely, and use that to check the intersection as I move imaginaryRect down. But I then make the rectangle below the intersection (which would be imaginaryRect minus the intersection height) the one that actually displays the second view, and that one's called newFrame.
This all works perfectly, except for how the second view is being animated. I want it to appear to slide out from under the top one, which would mean that as the view begins to appear below the top one, the user would first see the bottom part of the second view appear, as it slid further down he'd see the middle part, and finally the top finishes coming down and they are all visible. What is actually happening is that when the view starts appearing, it appears from the top down. First the top part appears, then middle, then bottom. It doesn't give the impression that it's being slid out from under the top one. In fact, it looks like isn't moving, and instead gives the impression that something that was on top of it covering it is being slid down.
I've been at this since the day before yesterday and I think the problem has to do with the origin of the frame. But that's it.
This is the code I'm using:
CGRect imaginaryRect = NSMakeRect(progressBarView.frame.origin.x,progressBarView.frame.origin.y, view.frame.size.width, view.frame.size.height);
CGRect rectIntersection = CGRectIntersection (view.frame,
imaginaryRect);
//if view and imaginary progress bar view frame intersect, the view is lowered
//the second condition prevents one drop too many at the end
if (!CGRectIsNull(rectIntersection) && (rectIntersection.size.height!=0)) {
CGRect offsetFrame = CGRectOffset (imaginaryRect, 0, -1);
imaginaryRect = offsetFrame;
//rectIntersection is recalculated after the offset, so it's height is subtracted for newFrame
rectIntersection = CGRectIntersection(view.frame, imaginaryRect);
//the rect below the area of intersection
CGRect newFrame = CGRectMake(imaginaryRect.origin.x, imaginaryRect.origin.y, view.frame.size.width, view.frame.size.height-rectIntersection.size.height);
//move the PBview to the new, slightly lowered frame (this is the frame that's located below the front view, but subtracts the intersection)
[progressBarView setFrame:newFrame];
Thanks for the help!