I added the ADBannerView to a view and when I load the app I get the following message:
ADBannerView: WARNING A banner view (0x7a023c0) has an ad but may be obscured. This message is only printed once per banner view.
As far as I can see the entire banner is visible on the screen. Is this really a problem? Or is it only a warning that I can ignore?
As Stephen Darlington says, it's a good idea to figure out what the issue is. An easy way to double-check this in code (from a view controller) would be:
// bring your bannerView to the front
[self.view bringSubviewToFront:bannerView];
// and make sure it's positioned onscreen.
bannerView.frame = CGRectMake(0.0, 0.0, bannerView.frame.size.width, bannerView.frame.size.height);
Assuming you had an iVar / IBOutlet to your AdBannerView called bannerView, this would take care of any interface builder positioning issues, and make sure bannerView wasn't covered by anything.
From my experience, nothing bad happens if the ad is offscreen, however, the iAd will not load new ads until it knows it is fully onscreen. So, as you start up your app,
Your AdBannerView will attempt to load an advertisement, whether it is onscreen or not.
Depending on whether or not it is successful, your AdBannerViewDelegate will receive either
a) bannerViewDidLoadAd: (proceed to step 3) or
b) bannerView: didFailToReceiveAdWithError: (the AdBannerView will try again on its own)
At that point, the ball is in your court as to what to do with said bannerView, if in fact it did load an ad. An easy way to check for this in code is yourBannerView.bannerLoaded, which will return YES if it has an ad, or NO if it doesn't. And so...
How you handle the AdBannerView after it successfully loads its initial ad determines how it will behave in the future. You do not have to place it onscreen immediately -- choose a time that makes sense within your application. However, a banner view that has successfully loaded an ad will NOT try to load another one until it is onscreen. (Makes sense, right?) The tricky part is....
4b) you also won't get any new delegate messages from that bannerView, so if you're not moving the bannerView onscreen immediately upon getting the bannerViewDidLoadAd delegate message, you'll have to implement some kind of control structure on your own to handle when, if at all, you DO move it onscreen, at which point it will begin asking the ad server for more ads, and you'll get more delegate messages, and the cycle begins anew.
So, to sum up: It's only a problem if your iAd is obscured if you'd like to serve more iAds and get paid. However, eCPM has been very, very low lately, so maybe that's not such an issue after all ;)
To add to this discussion, I received this message when I modified the center property to move the ad just outside the screen. I use UIView animations to slide the ad onto the screen.
After some experimenting I figured out how to do this without causing the message to appear. The trick was to hide to set the adBannerView.hidden property to YES while waiting for the ad to load. Once it was loaded, I just had to make sure to set the hidden property to NO only after committing the animation:
-(void) fadeAdIn:(UIView*)view
{
float offsetY = view.frame.size.height * (bannerOnBottom ? 1 : -1);
CGPoint pos = [self getBannerPosition];
view.center = CGPointMake(pos.x, pos.y + offsetY);
[UIView beginAnimations:#"AdIn" context:nil];
[UIView setAnimationDuration:1.0];
view.center = pos;
[UIView commitAnimations];
// must unhide AFTER animation has been committed to prevent "ad obstructed"
view.hidden = NO;
}
Like compiler warnings, I think this is something that you should probably try to get to the bottom of even if it's not immediately causing problems. If I were Apple, I'd send my ads to apps that actually show them (I'm not saying they do do this), so there could be a financial aspect too.
A couple of problems that I've seen:
The iAd frame is slightly off, maybe off the screen by just a pixel or two
You've accidentally created two iAds and one is on-screen and the other is hidden behind the first
I got the same problem but the reason is I have OpenFeint notification bars on top of that, e.g. high scores, achievement unlocked, etc. It slides in and then slides out, does not stay for long, so I don't think it is a problem.
I you put ADS on the top, then user would not see OpenFeint notifications, that will be another problem, I do not know if this happens if you have ADS and OpenFeint on different locations of screen, I did not try it as my app's bottom screen is full of buttons, so only top of screen is available.
Another option is to listen for status bar resize events and move the iAd when that happens so that it isn't respositioned offscreen (resulting in that warning and no served Ads).
In your app delegate, tap into this function:
(void)application:(UIApplication *)application willChangeStatusBarFrame:(CGRect)newStatusBarFrame
// Check newStatusBarFrame.size.height and animate your iAd frame up or down accordingly.
I am obtaining this message when I add a ADBannerView to a UIScrollView. In this case the ad may be obscured.
The answer from LearnCocos2D was the solution for me. Not sure if this is a specific issue with Cocos2D (which I am using). My problem was I was using the "new" style animations using blocks which Apple recommends using, animateWithDuration:delay:options:animations:completion: When I use these, I get the obscured warning. I guess the problem is the view is partially obscured while it's animating in, hence the warning, but you can't make it completely visible before it's done animating, obviously, unless you just want to pop it on screen, which is ugly.
That's OK, because switching back to the "old" style animation using beginAnimations: and commitAnimations: did eliminate the warnings for me. I'm curious if this warning means you are actually missing out on ad revenue or if it's just annoying but not actually a problem.
I had code like this:
if (animate)
{
[UIView animateWithDuration:0.5 animations:^{
self.adBannerView.frame = adBannerFrame;
self.otherViewFrame.frame = otherViewFrame;
}
];
}
else
{
self.adBannerView.frame = adBannerFrame;
self.otherViewFrame.frame = otherViewFrame;
}
and after some experimenting, I found that the order of the initializations should be reversed in both if and else legs.
self.otherViewFrame.frame = otherViewFrame;
self.adBannerView.frame = adBannerFrame;
So the idea was not to let another view cover the AdBannerView, even for a few microseconds.
Related
I've got a view controller whose view contains a UIImageView that does animation:
//AnimationViewController::ViewDidLoad event:
var ctlAnimations = new UIImageView();
ctlAnimations.AnimationImages = list.ToArray(); //<--list contains the UIImages
ctlAnimations.AnimationDuration = 1.0 * list.Count;
ctlAnimations.StartAnimating();
this.Add(ctlAnimations);
This works perfectly: when I push AnimationViewController onto the navigation stack, it displays and animates the UIImage.
But now I need to show AnimationViewController with a custom animated transition:
var transition = CATransition.CreateAnimation ();
transition.Duration = 0.3f;
transition.TimingFunction = CAMediaTimingFunction.FromName(CAMediaTimingFunction.EaseInEaseOut);
transition.Type = CATransition.TransitionFade;
this.View.Layer.AddAnimation (transition, "fade");
//viewController is being pushed with animated=false, because we have a custom animation
base.PushViewController (viewController, false);
this.View.Layer.RemoveAnimation("fade");
This also works perfectly, in that the new View transitions into place using the specified custom animation.
But when I push AnimationViewController onto the stack using an animated transition, it displays but the animation doesn't run. Instead, it shows the first frame of the animation (the first image in the list), and doesn't run it.
So, something about the transition is breaking the ability to animate a UIImage in the new view controller, but I simply can't figure out what to do about it.
Update: I've noticed that if I tap the NavigationController's back button, but then move off of the back button and let go (so I don't actually go back), the animation starts playing!
PushViewController works like this: Over the current view controller the next view controller is placed you can say pushed onto the stack. From Apple docs its clear that either you need to push view controllers either with animation or without.
Work around:
Set the frame of the next view controller's view's x position beyond
the screen's right
Suppose width of the screen is 320, then set the x position of next
view as 320.
Add the next view as subview to the existing one.
Now do your custom animation.
Another work around:(a bit more overhead though)
Take a snapshot programmatically of current view.
Add the snapshot image as the initial view of next view controller.
Now push view controller without animation. (User will still see the old view)
In viewDidAppear of new view controller start your custom animation.
[I have to warn you that this method of taking snapshot might give you a small delay in older devices. Newer devices are pretty fast enough you wont see any lag]
Let me know if any issues in case you are implementing any of these solutions.
Try putting the animating bit in ViewDidAppear rather than ViewDidLoad. Also, try using breakpoints and NSLogs to follow what happens after the animation, starting with the ViewDidLoad and ViewDidAppear. Try having the animation repeat forever so you can see if it has ever been animating or not.
I'm very curious what the culprit is here as well. Why is the animation not displaying correctly in some cases?
My theory is that you have placed animation code in viewWillAppear rather than viewDidAppear. Animation code does not run properly when placed in WILL or SHOULD methods.
Can you please post back what caused the issue?
Suspicion #1
I am betting that your code is not being called because it is in ViewDidLoad. I believe you are creating a customized view stack, that means you need to be using the ChildViewController methods from Cocoa.
I am unfamiliar with MonoTouch (I only write pure CocoaTouch), so this might not be 100% correct
I would be consoling out your viewDidLoad and viewDidAppear methods and absolutely make sure they are being called. It is my suspicion that viewDidLoad IS NOT. And this is causing viewDidLoad to not be called on the UIImageView.
In your code you probably need the equivalent of (from objective-c):
[self addChildViewController:viewController];
// OR?
[base addChildViewController:viewController];
This tells the 'parent' viewController that the Child has been made visible, so call the viewDidLoad/Appear and Unload/Disappear methods when appropriate. This might not exist in MonoTouch, or the Push methods might not be fully implemented, so you might need to do some hacky (bad) stuff like manually calling the viewDidLoad method manually.
Suspicion #2
It could also be that your 'list' variable (the one holding the images) is nil. If that happened the animation would not run. OR maybe it has something to do with the duration of your animation, try to set it to whatever would make it repeat forever. Be sure it isn't running REAL FAST somehow and you are just missing it.
begin philosophical musing
Either that or start learning actual Cocoa development :) Not meant as a flame, but definitely meant seriously, you are going to run into problems trying to develop applications through translation layers (custom language-bridges meant to get around writing the base language of a framework/application/platform).
Titanium/MonoTouch/PhoneGap will never produce as robust or high-quality applications as real Objective-C. And besides that, once you learn Cocoa it will change how you write everything else, and I doubt you will want to go back. As the wonderful website of the same name says, 'Cocoa is my girlfriend'
Let me tell the something about UI in IOS. In IOS access to the UI Elements is limited to a single thread.
The single thread would always be the mainThread except in the case when you are running an animation.
Hence when u are performing number of animation at the same instance you have to use
beginAnimation.
setFrame (or) some methods that changes state of UI element.
Repeat step2 for all those objects u are scheduling to animate.
comitAnimations to perform all animations at once. (using comit animations ensure all the animations are performed on same thread)
So, I guess here is what happening in ur case.
Viewcontroller started an animation to push the view controller into stack.
Image view started another animation before finishing first animation.
Look at the links to get a clear idea link1 and link2.
Well Let's get into the solution
Add an ivar and retained property named ctlAnimations to your class
In ViewDidLoad (or) ViewDidAppear
self.ctlAnimations = new UIImageView();
ctlAnimations.image=(UIImage*)[list.toArray() objectAtIndex:0];
this.Add(ctlAnimations);
[self performSelector:#selector(startAnimatingImage) afterDelay:0.1];
Create a private method named startAnimatingImage with below code
self.ctlAnimations.AnimationImages = list.ToArray();
ctlAnimations.AnimationDuration = 1.0 * list.Count;
ctlAnimations.StartAnimating();
On a brief we just shown first image for a moment when the firstanimation is taken place and then we delayed animation start for 1 second so that it performs after first animation and then starts animating the image.
Go ahead and give it a try
There is the concept for the Main thread. So UIAnimation are actually works on Main Thread and at the same time may be this was happen that another task is performing on the same Main Thread.So that was a case like IOS will give preference according to processes id of each process at a time and for the solution you need to make background thread for the same operations.
Well, I never figured out what the problem was here, but it also turned out that there was some sort of memory leak in UIImage such that on some phones my code was crashing.
So I rewrote it to do the animation manually. Now I set a timer and keep a frame index variable, and every time the timer rings I change the image myself. This amounts to the same thing, and it turns out it fixes this problem.
Foreword, this isn't me losing a view off screen because I did the transform wrong, it's weirder.
Problem is, if I use an .m34 transform to achieve the perspective I need, the view hierarchy breaks, but remove the transform and it draws everything correctly.
Here's an example.
I have a background image (subviewOne), a menu(subviewTwo), and an object on top of all of that which I apply the CATransform3D to (subviewThree).
Simple code:
CALayer *layer = subviewThree.layer;
CATransform3D perspectiveTransform = CATransform3DIdentity;
perspectiveTransform.m34 = -1.0 / 500;
layer.transform = perspectiveTransform;
Prior to applying this code, the view hierarchy was, and still is on iOS 5:
(bottom to top)
subviewOne->subviewTwo->subviewThree
After applying it, I end up with:
(bottom to top still)
subviewTwo->subviewOne->subviewThree
Now, subviewThree still has the perspective transform applied to it, and is in the correct spot, on top of everything else, same as on iOS5. However, the Menu/subviewTwo, is now hidden by the background image/subviewOne, and nothing I do will get it to be drawn on top of the subviewOne. No amount of insertSubviewAtIndex:, bringSubviewToFront, sendSubviewToBack, etc, will make the view draw correctly.
This is incredibly peculiar particularly because the views that are drawn out of order are NOT having any kind of CATransform3D applied to them.
I have verified this independently in two different apps and multiple devices 6 devices. iOS5 draws everything correctly, and if I remove those four lines, everything draws correctly, but nothing I've tried on iOS 6 stops the .m34 from breaking the view ordering. It's not always as simplistic as the example I've provided, but this is the most demonstrable case I have witnessed.
Has anyone else experienced this, solved this?
Edit: More info for comment.
Yeah, typo with the extra *.
Figure there's an Imageview, QuadCurve Menu, and Textview.
I was calling the method with the .m34 in the viewDidLoad, but swapped it to the viewDidAppear real quick to check for you.
Doesn't matter. Don't get me wrong, the subviews are listed in the correct order when you call
NSLog(#"%#", [self.view.subviews description]);
They just aren't drawn on screen correctly.
In desperation, I wrote some crazy weird code, and I discovered the following.
I can call the method that draws the menu on a 10 second delay,
[self performSelector:#selector(createQuadCurveMenu) withObject:nil afterDelay:10];
which ends in
[self.view addSubview:menu]
As well as a totally superfluous
[self.view bringSubviewToFront:menu]
and it's still drawn behind an imageView that is set as the lowest subview in the .xib.
I have verified this two ways. I can go into the .xib and set the imageView to hidden, and running again I can see the menu, now that the imageView isn't covering it. I can also just comment out the code that applies the .m34 transform to the textView, and the menu then again correctly appears on top of the imageView. Again, none of this happens on iOS5 and iOS4.
At this point, I'm starting to think that it's a bug inside iOS6 itself, and have been waiting for the NDA to expire so I can ask here if anyone else has experienced it.
Pretty sure this is an iOS 6 bug: I've blogged about it here: iOS 6 Rendering Bug: 3D-Rotation Causes Layers to Render Without Respect for View Hierarchy.
Good news: You can work around the bug by setting zPositions on the affected layers: set the zPositions in increasing order of the view hierarchy. So if I've understood correctly, you want:
subviewOne.layer.zPosition = 0;
subviewTwo.layer.zPosition = 1000;
subviewThree.layer.zPosition = 2000;
Check out the blog for more info, including a link to the Open Radar version of the bug I've logged with Apple.
Also, this might be considered a duplicate of this post: iOS 6 view hierarchy nightmare. It has the same bug source and solution, although the symptoms you both describe are different.
I have a nice little app on the app store that does pretty well for itself. Life was great until iOS 5 came to town. Now, I have a number of issues with my app that I have no way of fixing because I have no clue what is going on, because I feel that they are iOS 5 issues, not mine.
Was there an iOS 5 conversion manual I missed? Or did they just change everything for fun, and want us to figure out where all the easter eggs were?
Here is another issue I am experiencing (that I have wasted so much time trying to fix), that DON'T EXIST AT ALL when I simply say that I want to run the app in good ol' 4.2:
Modal view
My app is a simple reader app. I have a book reading view that displays text with a UIWebView. One of the features I have been working on involves the ability to take notes as you read. This is achieved by hitting a button, and presenting a modal view. Yes, a modal view. The most simple pre- iOS 5 thing you could possibly do. Now, when I dismiss my modal view, just by hitting cancel, and simply dismiss the view, when I get back to my reader view, the navigation bar at the top is pushed up half way off the screen! This doesn't happen in 4.2, but there it is in iOS 5!
What can I do to get this issue resolved?
Thanks for your help.
Ok, I was just able to figure out what in the blazes was going on. I had the shouldAutorotateToInterfaceOrientation value set to a BOOL variable, so that when the modalView was coming back, it didn't know the state/size of the status bar. Fixed that, and the problem disappeared.
I have the feeling it has something to do with the way you present and dismissing the modalview. Apple introduced a new method to present views. May you try using theses instead of the old ones and see if it fixes your problem.
So here is what you do:
change this method:
presentModalViewController:animated:
into the new preferred method introduced with iOS 5:
presentViewController:animated:completion:
Depending if you are using dismissModalViewControllerAnimated:to dismiss your view, change it into dismissViewControllerAnimated:completion.
This methods also have completion handler which is very useful to do some extra work after the view has been presented/dismissed. Maybe that also helps with your other issue. Let me know if that might helped.
A major change in iOS 5 is that the navigationController property of UIViewController is no longer set for modal views. Instead, there is a new (not present in iOS 4) parentViewController property. So where you're using navigationController in a modal view you need to change the logic to something like:
UIViewController* parent;
if ([self respondsToSelector:#selector(parentViewController)]) {
parent = self.parentViewController;
}
else {
parent = self.navigationController;
}
(That's from memory, so I can't guarantee that every t is dotted and every i crossed.)
I was seeing this same clipping problem.
I found out that the reason for my issue was that I set the content size within the modal dialog (something I did for my iPad layout), so removing these two lines seemed to fix the issue:
CGSize size = CGSizeMake(320, 480);
self.contentSizeForViewInPopover = size;
I thought the problem was fixed but it wasn't. After reviewing the code some more, cleaning the build, and retesting it turned out to be a shouldAutorotateToInterfaceOrientation which would return NO for all orientations, for a brief amount of time (flag == NO) while the app is loading (root controller). You want to at least return YES to one orientation like so:
- (BOOL) shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation
{
return !self.flag ? UIInterfaceOrientationPortrait == toInterfaceOrientation : YES;
}
I want to fade-out a view as it is scrolling inside a parent UIScrollview. When the fade-out animation begins, the scroll view stops scrolling. It jumps to the correct position when the fade is complete.
My fade-out is achieved with animateWithDuration and block objects, triggered upon a page-change I detect in scrollViewWillBeginDragging.
Does anyone know how to make them both happen simultaneously? Just to be clear, I am not 'animating' the UIScrollView scrolling - rather it is happening via user interaction of swiping.
EDIT:
Here is the code I'm using to fade the UIView. This code is in a UIViewController derived class, which is the delegate for a UIScrollView. When the user starts dragging his finger, I want to fade out the subView. But when the user starts draggin a finger, the subview fades and the scrolling stops. After the subView has completely faded out, the the scroll view will then snap to the location where the user's finger is.
-(void)scrollViewWillBeginDragging:(UIScrollView*)scrollView
{
[UIView animateWithDuration:0.5
animations:^
{
self.subView.alpha = 0.0f;
}
completion:^(BOOL finished) { }];
}
A little late, but if you want to keep using blocks, you can use:
animateWithDuration:delay:options:animation:complete:
add "UIViewAnimationOptionAllowUserInteraction" to options to allow interaction while scrolling.
I'm sure that you will still have the lag problem. Here's the best way I can explain it. Please forgive me in advance since I'm probably using the wrong terms. All animations must run on the main thread. When you call an animation, iOS first *P*rocesses then it *R*enders before it generates *F*rames. It looks like this.
PPPPRRRRFFFFFFFFFFFFFFFFFF
But since ScrollViews don't know how long your animation is going to be or when it will end, it has to perform the animation like this.
PRFPRFPRFPRFPRFPRFPRFPRF
My theory is that the lag you are experiencing has to do with these two calls colliding on the main thread at the same time. I'm not sure how you would solve this problem other than with a faster chip. I've that you could push one animation to the CPU and one to the GPU, but I'm not that advanced at programming yet.
very interesting ... I've checked this out, and yes, i have the same effect ... Well, it seems that the animateWithDuration somehow blocks the main thread ... which is not logical, and the documentation doesn't say anything about it either ..
However there is an easy workaround, something similar to this: (i've set the animation duration to 3 so i can see that it's working while i'm moving my scroll view :) ...)
[UIView beginAnimations:#"FadeAnimations" context:nil];
[UIView setAnimationDuration:3];
self.subview.alpha = 0.0f;
[UIView commitAnimations];
I would suggest, since the opacity is based on the user's finger's movements in the UIScrollView, using the delegate method scrollViewDidScroll:. The scrollView passed as a parameter can be used to check the contentOffset which is simply a CGPoint indicating how far into the content view of the UIScrollView the user has scrolled. Something like this can be used to relate the scroll position to the opacity of a given view in a paginated UIScrollView:
- (void)scrollViewDidScroll:(UIScrollView *)scrollView {
// The case where I used this, the x-coordinate was relevant. You may be concerned with the y-coordinate--I'm not sure
CGFloat percent = ((int)(scrollView.contentOffset.x) % (int)(scrollView.frame.size.width)) / scrollView.frame.size.width;
if (percent > 0.0 && percent < 1.0) { // Of course, you can specify your own range of alpha values
relevantView.alpha = percent; // You could also create a mathematical function that maps contentOffset to opacity in a different way than this
}
}
According to information that is still not supposed to be widely released, all iOS 4.x versions completely block user interaction while the animation is in progress.
Isn't it interesting, though, that you're UITouches are obviously still registered during the animation? Hmm... maybe that HINTS that something NEW is coming in a yet-to-be-released version!
I.e., If you can, read the iOS 5 Beta documentation on UIView class methods.
Developing an iPhone app.
I've got a really strange problem where, every once in a while, the status bar at the top of my app screen will turn solid black. Not like the black version of the status bar, but like a solid black rectangle with NO text/icons. It's very rare, but usually seems to occur after returning to the app via multi-tasking or from a locked device (the app has been running in the background). I've seen it occur on both 3GS and iPhone4. Here's a screenshot:
I can never reproduce it when trying, it just seems to eventually happen at some point (sometimes it will go for days without happening).
Once it does occur, the app seems to continue functioning fine, even with the status bar gone, except for when I do one specific action in the app which will cause everything to freeze up all the sudden (the app doesn't crash, but everything on screen is frozen and non-interactive). Without explaining the design in detail, the specific action that causes it to freeze up (after the bug appears) is performing a simple upload in the background to a SQL database. Resetting the app is the only way to fix the problem once the black status bar appears.
Anyone else ever experienced this? I can't find a single thread anywhere explaining similar behavior, and it's driving me nuts.
It happened once in my app when I called a drawing method in my custom subclass of UIView instance right before I added it as a subview to parent view.
The solution was apparently easy: add it as a subview first before sending/calling any custom drawing methods.
Examples:
CustomView *aView = [[CustomView alloc] init];
[aView drawSomething];
[self.view addSubview:aView]; //wrong approach
[aView release];
Should be:
CustomView *aView = [[CustomView alloc] init];
[self.view addSubview:aView];
[aView release];
[aView drawSomething];
The screenshot is missing, but what you describe sounds as though you've incorrectly implemented the use of Apple's built-in view controllers.
Both UINavigationController and UITabBarController will automagically shift all the content inside them down by 20-pixels, if they detect there is "supposed" to be a statusbar on screen at the moment.
My guess is that you have some code that is removing the statusbar, but which is kicking-in after the Apple code has already detected it and shifted everything down to accomodate.
The "fix" is to re-read the docs on Apple's classes very carefully and use them as Apple dictates (usually, people use them in ways that seem sensible - e.g. embedding them inside other views - but which Apple has expressly declared are unsupported. Sadly those classes from Apple are very fragile)
Are you holding a reference to a QLPreviewController instance? I was able to solve this problem in my app by creating a new autoreleased QLPreviewController whenever I need to display a file modally, as opposed to reusing the same instance over and over again.
I had a similar problem, which I described in this question here
If you have any, try removing any CGRect frame created by reference to:
[UIScreen mainScreen].applicationFrame]
and instead create the frame using a more manual definition. If that works, you can decide how to proceed from that point.