I want to use interstitial ads in my app, so I implemented all necessary delegate methods.
The problem is, if I use [self requestInterstitialAdPresentation] to show the ad, only the interstitialAdDidLoad: method gets called.
The interstitialAdActionDidFinish: methods doesn't get called...
But if I use the deprecated [self.interstitial presentFromViewController:self] to show the ad, everything works.
Is there anything new to implement to get things work ?
Thanks in advance
Ok, I resolved the problem.
Since IOS7 with its iAd Additions there's no need for an adInterstitialDelegate. The only thing to do, is preparing the ads or set the interstitialPresentationPolicy to something other than none (as you can read in the documentation) and as a last step requesting the ad using the requestInterstitialAdPresentation: method.
iOS 9.2.1, Xcode 7.2.1, ARC enabled
#Jellyjoey I confirmed, viewDidAppear is called when the ad is closed. And as you might expect, when you tap the ad, viewDidDisappear gets called.
It has to do with how you are presenting the interstitial ad:
Completing an Advertising Action
If the full-screen ad displayed the rich media ad inside your app, it
calls your delegate’s interstitialAdActionDidFinish: method after the
ad finishes. Your implementation of this method should restore any
services paused by your app when the action started.
Important: If your app was moved into the background because the
willLeave parameter was YES, then the app’s user interface is never
covered by the banner view and your app does not receive a call to
interstitialAdActionDidFinish:. However, if your interface was covered
by the banner view, your app could still be moved into the background
later, either because the advertisement launched another app or
because the user chose to do so. In all cases, if your user interface
was covered by the banner view, it is uncovered and your delegate’s
interstitialAdActionDidFinish: is invoked before your app moves to the
background. Because the app may be moving into the background, your
delegate should return quickly from its interstitialAdActionDidFinish:
method.
To view the excerpt above and the rest of the guidelines for interstitial ads:
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/iAd_Guide/Full-ScreenAdvertisements/Full-ScreenAdvertisements.html#//apple_ref/doc/uid/TP40009881-CH5-SW24
Here are two examples provided by Apple of how to use full page ads:
https://developer.apple.com/library/ios/samplecode/iAdInterstitialSuite/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010627-Intro-DontLinkElementID_2
Related
In my iOS 7+ app I'm using the latest version of Harpy, which perform an app version check and present an alert if there's a new version of my app available in the App Store.
Due to the structure of my app, I'm facing this issue in the debugger:
Attempt to present <UIAlertController: 0x144538530> on <DCLoginViewController: 0x14460c1a0> whose view is not in the window hierarchy!
this is because harpy is configured in the AppDelegate and has a parameter that define the presentingViewController:
[[Harpy sharedInstance] setPresentingViewController:_window.rootViewController];
I believe the issues arise because my app check if the user is already logged in, if so, instead of presenting the DCLoginViewController, it jumps to the next view which is "LoadingViewController".
How can I set the presentingViewController to be this LoadingViewController or even the ViewController currently on screen at execution time?
Thanks for your help.
You don't have to launch Harpy in the AppDelegate. You can launch it after LoadingViewController has loaded. It's only recommended to launch it in the AppDelegate as the idea is to show the alert as soon as the app is loaded. It's more of a UX thing than anything else.
I used to disable current view while a method is running in the background(may be an API Call) asynchrnolsly.But as per the Human Interface Guidline I understood that disabling the View while a method runs in the BG, is not a right way.So If I need to avoid user accessing different IBActions while some thing performs in the back ground what is the best method?
Does anyone have any insights into when/under what conditions applicationWillTerminate is called in iOS 5/6?
I've got some logic i'd like to execute whenever the application terminates (not moves to the background), for example if the user navigates to the application bar at the bottom of the screen by double tapping the home button and force quits the app.
when i try to do this on a test device, applicationWillTerminate does not seem to get called. Is there a reason for this?
My plan B is to tie that logic to some persistent object like a singleton or a static that is automatically destroyed when the app quits.
Any suggestions?
thanks
Have you read the documentation for applicationWillTerminate:,
It says,
For applications that do not support background execution or are linked against iOS 3.x or earlier, this method is always called when the user quits the application. For applications that support background execution, this method is generally not called when the user quits the application because the application simply moves to the background in that case. However, this method may be called in situations where the application is running in the background (not suspended) and the system needs to terminate it for some reason.
There is a "maybe" mentioned there. Probably that answers your question. So it is not necessary that this will get called when you quit the app. Probably you might have to use UIApplicationExitsOnSuspend to disable multitasking and then it might get called while putting in background. But that again depends on your app requirement. If you cannot disable multitasking, you might have consider doing that in applicationDidEnterBackground method or so. I am not sure if there are any other delegate methods which will help in identifying the force quit.
In iOS one can purportedly use the CLLocationManager's startMonitoringForRegion: method to register a delegate to respond to the device moving into a specific geographic region, even when the app isn't launched. From the CLLocationManager Class Reference:
In iOS, the regions you register with the location manager persist between launches of your application. If a region crossing occurs while your iOS app is not running, the system automatically wakes it up (or relaunches it) in the background so that it can process the event. When relaunched, all of the regions you configured previously are made available in the monitoredRegions property of any location manager objects you create.
I assume if the app is relaunched, iOS doesn't actually bring it to the foreground. I couldn't find any good samples illustrating where startMonitoringForRegion fits into an overall application, so my questions are:
Does one have to register the delegate for startMonitoringForRegion from somewhere specific? I'm guessing it can't be plonked in a view controller if we're launching the app without bringing it into the foreground. Can someone give an example with some context around it?
If we decide we do want to bring the app into the foreground as a result of entering the region, how would we do so?
When is startMonitoringForRegion registered with the OS and when is it unregistered? Does the user have to have launched the app at least once (even if it's since been killed) for the initial registration to take place? What about if the user powers off the device? Will our handler be registered the next time the device is powered on, or will the user have to launch the app at least once again?
Does one have to register the delegate for startMonitoringForRegion from somewhere specific? I'm guessing it can't be plonked in a view controller if we're launching the app without bringing it into the foreground.
False. A view controller object still does exists if it's allocated-initialized, even if its contents are not presented.
If we decide we do want to bring the app into the foreground as a result of entering the region, how would we do so?
Not possible using public APIs (I'm not sure whether an app in the background can use - [UIApplication openURL:] with its own URL scheme to bring itself into the background, but I doubt it); however you may be able to use the SpringBoardServices framework to launch your app:
SBSLaunchApplicationWithIdentifier(CFSTR("com.mycompany.theBestiPhoneAppEver"), false);
When is startMonitoringForRegion registered with the OS and when is it unregistered? Does the user have to have launched the app at least once (even if it's since been killed) for the initial registration to take place?
If the user never runs your application, code inside will never be run, so it won't get registered.
What about if the user powers off the device? Will our handler be registered the next time the device is powered on, or will the user have to launch the app at least once again?
Now that's a good question. I don't know it off the top of my head, nor did I find an answer in the documentation (probably you haven't found that either), so I'd say you just better try it yourself to be sure.
My question is specific to iPAD, and I also aware of the basic memory management of iOS, but I am having a different problem.
As I have build an application where I have several UIViewControllers and UIViews,
I have a loginController thats gets called when I launch the App.
My MainView is a single screen with all the ViewController loaded and placed at their respective places and the app runs fine and smoothly.
Problem:
Problem comes when I logout, most of the time my App crashes by saying EXC_BAD on the
[super dealloc] line of my mainView controller.
As for now on I have added a custom function cleanUP in all my viewControllers that gets called when user logout from the app.
Is this the right approach ?
As I know that we can clean up in our didload etc. function and the dealloc gets called too.
but here i have an iPAD when my all viewControllers are just open in front of me, They will be closed or not visible when I logout from the App.
So how to approach on my crash issue and How to manage memory here in my iPAD?
The best way I know to resolve bad-access problems is to use Instruments with the Zombie tool. As you probably know, when you get a bad access issue, is because you try to access to an object that is deallocated.
Try go to Product -> Profile and choose Zombie. Hit record and reproduce your crash. then inspect the pointer to the object that produced that crash and look for the retain count.