In trying to implement the Google Analytics SDK for iOS, I've run into two brick walls.
The first one is that after executing this code in application:DidFinishLaunchingWithOptions:
[[GANTracker sharedTracker] startTrackerWithAccountID:#"UA-XXXXXXX-YY"
dispatchPeriod:10
delegate:self];
[[GANTracker sharedTracker] setDebug:YES];
.. and then trying to track anything or call dispatch, no debug messages are logged whatsoever. I've added NSLog lines before and after tracking calls and the code is definitely being reached.
Secondly, when I do try and do a manual dispatch, it returns NO. All the other issues I've seen online are where dispatch returns YES but it's somehow not going through properly. What does one do if dispatch actually returns NO?
I've tried adding an NSError * reference to the track methods and those actually succeed (no error, function returns YES). But the events are definitely not being periodically dispatched, since we're seeing nothing on the GA account more than 24 hours later.
EDIT: I've also got NSLog calls in both of the delegate methods (hitDispatched: and trackerDispatchDidComplete:eventsDispatched:eventsFailedDispatch:), and neither of those are being called either.
i think you should check this to delegate method of GANTracker
- (void)trackerDispatchDidComplete:(GANTracker *)tracker
eventsDispatched:(NSUInteger)hitsDispatched
eventsFailedDispatch:(NSUInteger)hitsFailedDispatch{
//print or check number of events failed or success
}
//Delegate is set to 'nil' instead of class instance which implements the delegate methods.
[[GANTracker sharedTracker] startTrackerWithAccountID:#"UA-XXXXXXX-YY"
dispatchPeriod:10
delegate:nil];
In your case, assuming that UIApplicationDelegate may be implementing GANTrackerDelegate, the message call should set delegate as ' self '.
Cheers!! Amar.
Possibly the dispatch is relying on the calling thread's run loop - Is it possible you are running this from a secondary thread, one which might not exist by the time the dispatch is suppose to call you back?
You've not enabled dryRun have you? Double check with:
[[GANTracker sharedTracker] setDryRun:NO];
Also try dispatchSynchronous, it'll block as it's sending but might help with if things aren't on the same threads:
[[GANTracker sharedTracker] dispatchSynchronous];
Just've checked it from scratch, dispatch perfectly worked meaning
a) your device is somehow different (i still have unsolved crashes on the particular iPad's 3 from Apple tester's unresolved, so it wouldn't be a huge surprise)
b) your code is somehow different - and that's much easier for you to fix.
For the a) there's no advice but to test it against all the devices you might get, for the b) i could only say what worked for me:
downloaded 1.4 SDK here
got Google sample projects with git clone https://code.google.com/p/google-mobile-dev.analytics-end-to-end/
configured final/AnalyticsSample to launch, changed the source slightly
(trackEvent::::: were called from sample, app was restarted manually as there's zero time period requiring dispatch call)
- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[[GANTracker sharedTracker] startTrackerWithAccountID:kGANAccountId
dispatchPeriod:0
delegate:self];
NSLog(#"Dispatch%#", [[GANTracker sharedTracker] dispatch] ? #"ed Successfully": #" Failed");
[self.window addSubview:tabBarController.view];
[self.window makeKeyAndVisible];
return YES;
}
That's it, log says Dispatched Successfully, worth trying i guess.
cough
I'd misspelled the #define to start the tracker object in my app delegate. Other files were spelled correctly, hence the logging statements showing up, but when I tried to log just before the tracker was started it didn't show.
Oops. Well, at least there's a decent troubleshooting post for Google Analytics on SO now!
Related
I have two code paths that needs to execute on app launch:
1. When Crashlytics detects a report from the last run
2. When it is a clean launch, ie, no crash report was detected.
Crashlytics provides (and recommends) that this method be used to detect crashes:
- (void) crashlyticsDidDetectReportForLastExecution:(CLSReport *)report
but the documentation specifically says that the method is not called synchronously during initialization. So while I can use this for detecting case #1, I don't think it is possible to use the same method to detect case #2 without possibly introducing a race condition.
As far as I can tell, the current framework does not expose any method to check for the existence of a report, either in Crashlytics.h or CLSReport.h. If it did, I could check for the existence of a crash report before the framework initializes.
Suggestions?
Solution proposed by Mike (from Fabric)
Mike -- I'm used to assuming that delegate methods and callbacks cannot be assumed to happen synchronously, or on the same thread. You seem to be saying that I can/should make that assumption here, so that this (psdeudocode) would work:
(in AppDelegate)
- (void)crashlyticsDidDetectReportForLastExecution:(CLSReport *)report completionHandler:(void (^)(BOOL))completionHandler {
self.HadCrash = YES;
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
completionHandler(YES);
}];
}
(In AppDelegate didFinishLaunching)
crashlytics.delegate = self;
[crashlytics init]; // presumably if the delegate method IS going to be called, it will be called here.
if (!HadCrash)
{ // do "no crash" stuff here }
Mike from Fabric here, there are two methods that can be used to know about a crash that happened.
1) - (void)crashlyticsDidDetectReportForLastExecution:(CLSReport *)report;
This method has the following restrictions:
It is not called synchronously during initialization
It does not give you the ability to prevent the report from being submitted
The report object itself is immutable
The most important benefits are that the ability to report crashes is not affected in any way.
2) - (void)crashlyticsDidDetectReportForLastExecution:(CLSReport *)report completionHandler:(void (^)(BOOL submit))completionHandler;
This is called synchronously when the last execution of the app ended in a crash.
You can then take whatever action you want to take, but the report will not be sent unless the completionHandler is called with YES passed in. If NO is passed in then the call will be finished, but no report would be sent.
Here's a sample implementation from the docs:
- (void)crashlyticsDidDetectReportForLastExecution:(CLSReport *)report completionHandler:(void (^)(BOOL))completionHandler {
// Use this opportunity to take synchronous action on a crash. See Crashlytics.h for
// details and implications.
// Maybe consult NSUserDefaults or show a UI prompt.
// But, make ABSOLUTELY SURE you invoke completionHandler, as the SDK
// will not submit the report until you do. You can do this from any
// thread, but that's optional. If you want, you can just call the
// completionHandler and return.
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
completionHandler(YES);
}];
}
I think that addresses the question, but let me know if I missed something.
Our project uses WebRTC for VOIP calls and it works fine before accessing the CallKit framework. But when I tried to access the CallKit framework, there was a situation where neither side could hear each other's speech. When I removed CallKit, everything returned to normal.
CallKit's answer button is the same function as the original answer button in the project.
And what amazed me was that it was not necessary to hear no sound. Sometimes everything is normal, but sometimes there will be problems. Well, the probability of a problem is greater.
I found the following flowchart, I suspect the problem lies in the order of function calls. But I do not know how WebRTC corresponds to the functions in the diagram.
In addition, I am curious whether socket instability will cause the CallKit framework to work abnormally
Please forgive me English is not good, but this problem has been haunted me for several days, I do not know where exactly a problem, is not where the conflict with the CallKit framework?
Hope you can help me, thank you very much!
Few steps need to be done to connect webrtc and callkit in proper way:
First of all, you have to use the RTCAudioTrack and add the RTCAudioSession for handling the audio. Old legacy RTCAudioSession added directly into RTCPeerConnection works but it's not prefered a way to do that.
Second thing is to use manualAudio. When app is booted you should change useManualAudio flag on RTCAudioSession:
RTCAudioSession.sharedSession().useManualAudio = true
which gives you possibility to postpone the audio until CallKit informs that audio session was activated, so inside the ProviderDelegate you should implement following method:
(void)provider:(CXProvider *)provider didActivateAudioSession:(AVAudioSession *)audioSession
RTCAudioSession.sharedSession().didActivecated(audioSession)
RTCAudioSession.sharedSession().isAudioEnabled = true
and for second audio delegate method don't forget to add:
(void)provider:(CXProvider *)provider didDeactivateAudioSession:(AVAudioSession *)audioSession
RTCAudioSession.sharedSession().didDeactivecated(audioSession)
RTCAudioSession.sharedSession().isAudioEnabled = false
Apple suggests us to wait till the Connection gets established and then fulfill the performAnswerAction. Below is the source
Apple Suggestion for Call Kit Documentation
If the recipient of a call answers before the app establishes a connection to your server, don't fulfill the CXAnswerCallAction object sent to the provider:performAnswerCallAction: method of your delegate immediately. Instead, wait until you establish a connection and then fulfill the object. While it waits for your app to fulfill the request, the incoming call interface lets the user know that the call is connecting, but not yet ready.
So we need to wait for a second or two before we fulfill the action in performAnswerCallAction
In the end, I solved the problem, but I still do not understand why it can be solved.Below is my solution:
First of all, I delay the call of "fulfill" by 1 second (note that this time can not be less than 1 second)
- (void)provider:(CXProvider *)provider performAnswerCallAction:(CXAnswerCallAction *)action {
if (self.delegate && [self.delegate respondsToSelector:#selector(callKitManager:refreshCurrentCallStatus:)]) {
[self.delegate callKitManager:self refreshCurrentCallStatus:EUCCallKitStatusAnswerAccept];
}
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[action fulfill];
});}
Second, I also delayed my network request call by one second (here longer than the previous one)
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1.0 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[self.peerConnection offerForConstraints:[self offerConstraintsRestartIce:NO] completionHandler:^(RTCSessionDescription * _Nullable sdp, NSError * _Nullable error) {
[self peerConnection:self.peerConnection didCreateSessionDescription:sdp error:error];
}];
});
In this way, my problem is solved.
If you know why this can solve this problem, please comment on me, thank you!
For people wanting to reply quickly without reading the post: I am not hitting any memory limits. Read the whole post for details.
My WatchKit extension cannot properly function without the user first being "onboarded" through the phone app. Onboarding is where the user must accept the permissions that we require, so it's very crucial.
On my WatchKit extension, I wanted to display a simple warning for users who had not finished onboarding within our phone app yet.
As such, I thought I'd get the status of onboarding from the phone in two ways:
When the user opens the app/the app is activated (I use the willActivate method to detect this)
When the app finishes onboarding it sends a message to the watch of its completion (if the extension is reachable, of course)
Both of these combined would ensure that the status of onboarding is always kept in sync with the watch.
I wrote the first possibility in, utilizing reply handlers to exchange the information. It worked just fine, without any troubles. The warning telling the user to complete disappears, the extension does not crash, and all is well.
I then wrote in the second possibility, of the extension being reachable when the user finishes onboarding (with the phone then directly sending the companion the new status of onboarding). My extension crashes when it receives this message, and I am stuck with this odd error.
Program ended with exit code: 0
My extension does not even get a chance to handle the new onboarding status, the extension just quits and the above error is given to me.
I am not hitting any sort of memory limit. I have read the technical Q&A which describes what a memory usage limit error looks like, and I don't receive any sort of output like that whatsoever. As well, before the extension should receive the message, this is what my memory consumption looks like.
I have monitored the memory consumption of the extension right after finishing onboarding, and I see not a single spike indicating that I've gone over any kind of threshold.
I have tried going line by line over the code which manages the onboarding error, and I cannot find a single reason that it would crash with this error. Especially since the reply handler method of fetching the onboarding status works so reliably.
Here is the code of how I'm sending the message to the watch.
- (void)sendOnboardingStatusToWatch {
if(self.connected){
[self.session sendMessage:#{
LMAppleWatchCommunicationKey: LMAppleWatchCommunicationKeyOnboardingComplete,
LMAppleWatchCommunicationKeyOnboardingComplete: #(LMMusicPlayer.onboardingComplete)
}
replyHandler:nil
errorHandler:^(NSError * _Nonnull error) {
NSLog(#"Error sending onboarding status: %#", error);
}];
}
}
(All LMAppleWatchCommunicationKeys are simply #define'd keys with exactly their key as the string value. ie. #define LMAppleWatchCommunicationKey #"LMAppleWatchCommunicationKey")
Even though it's never called by the extension, here is the exact receiving code of the extension which handles the incoming data, if it helps.
- (void)session:(WCSession *)session didReceiveMessage:(NSDictionary<NSString *, id> *)message {
NSString *key = [message objectForKey:LMAppleWatchCommunicationKey];
if([key isEqualToString:LMAppleWatchCommunicationKeyOnboardingComplete]){
BOOL newOnboardingStatus = [message objectForKey:LMAppleWatchCommunicationKeyOnboardingComplete];
[[NSUserDefaults standardUserDefaults] setBool:newOnboardingStatus
forKey:LMAppleWatchCommunicationKeyOnboardingComplete];
dispatch_async(dispatch_get_main_queue(), ^{
for(id<LMWCompanionBridgeDelegate> delegate in self.delegates){
if([delegate respondsToSelector:#selector(onboardingCompleteStatusChanged:)]){
[delegate onboardingCompleteStatusChanged:newOnboardingStatus];
}
}
});
}
}
Before including this onboarding-related code, my WatchKit extension was tested by over 100 people, without any troubles. I am using the exact same custom error dialogue that I was using before, just with a different string. I cannot for the life of me figure out what is causing this crash, and the ambiguity of it has given me very little to work with.
Any help would be greatly appreciated. Thank you very much for taking your time to read my post.
Edit: I just tried creating a symbolic breakpoint for exit(), which is never hit. If I call exit() myself, it calls the breakpoint, so I know the breakpoint itself is working.
One question and one issue:
I have the following code:
- (void) registerForLocalCalendarChanges
{
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(localCalendarStoreChanged) name:EKEventStoreChangedNotification object:store ];
}
- (void) localCalendarStoreChanged
{
// This gets call when an event in store changes
// you have to go through the calendar to look for changes
[self getCalendarEvents];
}
These methods are in a class/object called CalendarEventReporter which contains the method getCalendarEvents (in the callback).
Two things:
1) If the app is in the background the callback does not run. Is there a way to make it do that?
2) When I bring the app back into the foreground (after having changed the calendar on the device) the app crashes without any error message in the debug window or on the device. My guess is that the CalendarEventReporter object that contains the callback is being garbage-collected. Is that possible? Any other thoughts on what might be causing the crash? Or how to see any error messages?
1) In order for the app to run in the background you should be using one of the modes mentioned in the "Background Execution and Multitasking section here:
uses location services
records or plays audio
provides VOIP
services
background refresh
connection to external devices
like through BLE
If you are not using any of the above, it is not possible to get asynchronous events in the background.
2) In order to see the crash logs/call stack place an exception breakpoint or look into the "Device Logs" section here: Window->Organizer->Devices->"Device Name" on left->Device Logs on Xcode.
To answer your first question, take a look at https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
What I did to get code running in the background is to do something like
In the .h file
UIBackgroundTaskIdentifier backgroundUploadTask;
In the .m file
-(void) functionYouWantToRunInTheBackground
{
self.backgroundUploadTask = [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:^{
[self endBackgroundUpdateTask];
}];
//code to do something
}
-(void) endBackgroundUpdateTask
{
[[UIApplication sharedApplication] endBackgroundTask: self.backgroundUploadTask];
self.backgroundUploadTask = UIBackgroundTaskInvalid;
}
The code above I pretty much learned from objective c - Proper use of beginBackgroundTaskWithExpirationHandler
As for your second question, you should set a breakpoint where code is supposed to run when you bring the app back to the foreground. No one can figure out why an app crashes if not given enough code or information.
The solution to the second part of the question was to raise the scope of the object containing the callback code. I raised it to the level of the containing ViewController. This seems to work. I still can't figure out how to raise the Notification (i.e. execute the call back) if the notification comes while the app is in the background/suspended. This prevented the object containing the callback from being cleaned up.
I'm using the latest SDK version, and the basic code to register and send a page view:
[[GANTracker sharedTracker] startTrackerWithAccountID:#"UA-MY_ACCOUNT_ID-1"
dispatchPeriod:10
delegate:self];
NSError *error;
if (![[GANTracker sharedTracker] trackPageview:#"/firstpage"
withError:&error]) {
NSLog(#"tracker failed: %#",error);
}
However the events are not dispatched from the device or simulator. There are no errors as well. When i turn on the debug flag, i can see the following:
dispatch called
dispatching 4 events
[after 10 seconds]
dispatch called
...dispatcher was busy
[after 10 seconds]
dispatch called
...dispatcher was busy
My delegate method never gets called:
- (void)trackerDispatchDidComplete:(GANTracker *)tracker
eventsDispatched:(NSUInteger)eventsDispatched
eventsFailedDispatch:(NSUInteger)eventsFailedDispatch{
NSLog(#"success: %d failures: %d",eventsDispatched,eventsFailedDispatch);
}
I tried to create a new publisher ID but it did not help as well.
I do have internet connection from the device and simulator
I deleted the app before trying.
I played with the dispatch period - setting it to -1 and call the dispatch manually
Nothing helped.... :(
I'm struggling with this for a day now... how can i make it work?
I had the same problem with the dispatcher ("...dispatcher was busy"). In my case, it was because I had run my app normally in the background, and it was using the dispatcher. When I tried to connect the device to Xcode to run and debug the app, the console showed me that message. So the solution was easy:
Stop the app in Xcode
Close the app in background
That's it.
you can put after calling the GANTracker a manual dispatch like that:
[[GANTracker sharedTracker] dispatch];
and it work perfectly