I integrated Playhaven Full Screen ad in my App. there are two action performing while full screen ad Load. One is Dismiss the view and Second Go to the App Store. I have to check Which Functions are called when both actions are Performed.
I already Tried below Function
-(void)request:(PHPublisherContentRequest *)request contentDidDismissWithType:(PHPublisherContentDismissType *)type{
NSLog(#"Type %#",type);
}
but it Return me the String PHPublisherContentUnitTriggeredDismiss in both case.
How to add Diffrent action on Both Button Clicked ?
Currently the Playhaven SDK doesn't differentiate between the type of dismissal in triggering the the contentDidDismissWithType delegate. I know that this is something we are looking into adding in the future, however.
Related
I'm transitioning from Google Analytics to Firebase Analytics. Unlike Google Analytics, Firebase automatically tracks screen views, which is great! But, instead of tracking the screen, it continuously attempts to track the UINavigationController. I get the following error log twice every time I navigate to a different view controller.
[Firebase/Analytics][I-ACS031006] View controller already
tracked. Class, ID: UINavigationController, -1770652405567491888
Is there some configuration required when you have a navigation controller? How do I get automatic screen tracking working in this scenario?
UPDATE: I haven't found a solution to this yet, but I at least found the cause of the problem. It looks like Firebase doesn't understand your view controller hierarchy if your initial view controller is a Tab Bar Controller. My initial view controller in my main story board is a Tab Bar Controller. If I take this out, I get good screen tracking reporting from my app.
UPDATE: It looks like I've found an OK solution to this, but I'm still wondering if someone has a better idea. Since Firebase sees all of the view controllers under my Tab Bar Controller as the same UINavigationController, I can call setScreenName manually in viewDidAppear for all of them.
Analytics.setScreenName(screenName, screenClass: screenClass)
This is OK because it's not any worse than Google Analyics, but it's not ideal because the system still tries to track the UINavigationController twice for every view controller and I'm also not getting the benefit of automatic screen tracking. I looked into trying to remove the Tab Bar Controller from Firebase as some folks seem to have done, but it looks like those methods have been removed from the current (v4.0.0) version of the Firebase SDK.
Screen is automatically tracked in Google Analytics for Firebase. You can see it in the user engagement card in the Main dashboard. This has been introduced in Firebase Version 3.8.0 for iOS. More in track screen doc. Quoting from the doc:
Events that occur on these screens are automatically tagged with the parameter firebase_screen_class (for example, menuViewController or MenuActivity) and a generated firebase_screen_id. If your app uses a distinct UIViewController or Activity for each screen, Analytics can automatically track every screen transition and generate a report of user engagement broken down by screen.
However, you can also track screens manually using the setCurrentScreen() method. The details on this screen should be available in the user engagement card when you select the ScreenName from the dropdown, all the screens manually tracked in the code should be displayed there with the breakdown of duration on average.
Please note that the setScreenName is not an event, it is rather an event parameter that goes with the event that is tracked in the logEvent() method call.
I am using Parse Server deployed on Heroku and MongoDB for my Swift 3 IOS app. When i open my home view controller I want to check if there is a user alredy logged in and if there is not I want it to perform a segue to go back to the login page. The function correctly states that there is no user logged in and also hides the log out button. The segue does not work though. Here is the image of what is happening:enter image description here
You are trying to perform the segue before the view has appeared. Move your call to an overload of viewDidAppear.
For example, I have a Notification that occurs when there is an "unauthorized" error returned from the api server that should bring the user back to the login screen. This event could appear anywhere in the program.
Do I create a new viewless controller to manage states and have it monitor for this notification and then present the login view controller?
I'm thinking about push notifications too, received by the app delegate. Some of these may cause the data model to get updated and then the screen to change. Who should make the screen change? In the past I put all this in the AppDelegate. But there must be a more elegant way!
I also found out about FlowControllers. But they don't play nicely with Interface Builder, at least according to this solution.
Please let me know if you need more specific information about my project.
An iOS app I'm creating shows a setup screen upon first launch which requires data to be written to the database.
Upon launch, I need to access this value form the database.
If it is set, launch main view controller
Else show setup view controller.
As far as I'm aware theres two ways I can do this, programmatically setting it from the AppDelegate or using an initial View Controller as a splash screen and performing the look up and segue there.
What would be the best way to approach this? Is it wrong to do a database lookup in didFinishLaunchingWithOptions?
Using a splash screen is probably the better option as it provides better scope for modification in the future and allows you to update the user on progress. It is fine for the app delegate to run logic to determine how the app starts but you should endeavour to keep the app delegate minimal and focussed.
I very much doubt that you would get this approved (if your goal is the App Store). Your app delegate needs to create a window, and set a rootViewController to that window before it returns YES in appFinishLaunching:
You simply do not have enough time to check with a server before creating the first viewController and you'll be creating poor interface if you try. I suggest the first ViewController will need to be informing the user that it is checking with the server with an activityIndicator or something. The best :)
I have a simple question, but I’ve looked through Apple’s documentation and done some searching and I can’t find the answer to it.
Is it possible to programmatically pull up Game Center’s sign-in view? I have a UIButton that requires Game Center, and if the client does not sign in when the app is opened (iOS pulls up the sign-in view at launch), I want to provide a second chance for the user to sign in.
I'm assuming you're calling this GKLocalPlayer method on launch: -setAuthenticateHandler: (>= iOS7) or -authenticateWithCompletionHandler: (<= iOS6)
If the user cancels the presented login screen, calling these methods again does nothing, or rather, the completion handler is called with an error. The user will then need to login to GameCenter through the GameCenter app or through the Settings app. (While testing, you can login through the GameCenter app, then logout. After that the screen can be presented in your own app again.) You can show an UIAlertView telling the user to login through the GameCenter app.
Alternatively, and I don't know if this is allowed/approvable, but in iOS7 the authenticateHandler has a viewController parameter holding the login screen. If you store this login view controller in an instance variable and the user cancels login, you can present the login screen again later using a UINavigationController.
If you try to present the saved login view controller with -presentViewController:animated:completion: the view controller's Cancel button no longer works, but using a UINavigationController hides the Cancel button and allows navigation back to your own view controller.
You'll also need to hide the login screen manually after the user logs in by responding to GKPlayerAuthenticationDidChangeNotificationName. It doesn't seem like developers were intended to be able to do this, so it may not pass approval, but it works!