{"action":"closed","issue":{"url":"https://api.github.com/repos/jflinter/JRFMemoryNoodler/issues/1","labels_url":"https://api.github.com/repos/jflinter/JRFMemoryNoodler/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/jflinter/JRFMemoryNoodler/issues/1/comments","events_url":"https://api.github.com/repos/jflinter/JRFMemoryNoodler/issues/1/events","html_url":"https://github.com/jflinter/JRFMemoryNoodler/issues/1","id":116012600,"number":1,"title":"Recommended approach for playing nicely with existing crash frameworks","user":{"login":"derekleeapp","id":3169260,"avatar_url":"https://avatars.githubusercontent.com/u/3169260?v=3","gravatar_id":"","url":"https://api.github.com/users/derekleeapp","html_url":"https://github.com/derekleeapp","followers_url":"https://api.github.com/users/derekleeapp/followers","following_url":"https://api.github.com/users/derekleeapp/following{/other_user}","gists_url":"https://api.github.com/users/derekleeapp/gists{/gist_id}","starred_url":"https://api.github.com/users/derekleeapp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/derekleeapp/subscriptions","organizations_url":"https://api.github.com/users/derekleeapp/orgs","repos_url":"https://api.github.com/users/derekleeapp/repos","events_url":"https://api.github.com/users/derekleeapp/events{/privacy}","received_events_url":"https://api.github.com/users/derekleeapp/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-11-10T02:33:01Z","updated_at":"2015-11-10T07:23:43Z","closed_at":"2015-11-10T07:23:43Z","body":"Jack - First of all thank you for this contribution to the community! I had also read the FB article and wanted to take a crack at this but having seen that you already did that, I thought I would give yours a shot and send a PR should I find something else that I needed from it. \r\n\r\nI work across various teams and projects that utilize a variety of crash reporting tools but Fabric (Crashlytics) and HockeyApp are the two primary ones. You provided some general guidance for playing nicely with existing crash frameworks which is very helpful:\r\n\r\n*\"crashDetector is a little funnier. So, the way most crash reporting frameworks work is by using a method called NSSetUncaughtExceptionHandler, which takes a pointer to a function that iOS will call when your app has triggered an uncaught exception and is about to crash (most crash reporters will then try and figure out what has gone wrong and write it to disk so they can log it to a server or something later). Unfortunately, this can only point to a single function, so if JRFMemoryNoodler were to use it to figure out if the app is recovering from a crash, it would break any crash reporting frameworks. Since if you are interested in this memory profiling, you are almost certainly using a crash reporting framework, this would be a Bad Thing. So, the crashDetector param is a block that lets you ask your crash reporting framework if it has any crashes to report. You can leave it nil, in which case JRFMemoryNoodler will set up a very very simple crash reporter of its own, but you probably don't want this.\"*\r\n\r\nMy assumption is that by passing 'nil' into the initializer for the JRFMemoryNoodler that it won't be able to accurately detect that the app is being opened after having experienced a crash, which is why it is necessary to know this information.\r\n\r\nFor HockeyApp, at least on version 3.8.2, it looks like they have exposed this boolean value very easily and the following implementation should be sufficient:\r\n\r\n`[JRFMemoryNoodler beginMonitoringMemoryEventsWithHandler:^(BOOL wasInForeground) {`\r\n`    ...`\r\n`} crashDetector:^BOOL{`\r\n`    return [BITHockeyManager sharedHockeyManager].crashManager.didCrashInLastSession;`\r\n`}];`\r\n\r\nQuestion #1: Can you confirm the above approach matches your expectations?\r\n\r\nHowever for Fabric/Crashlytics I'm not finding any kind of similar API except for their delegate implementation which seems like it could be really sticky to try and implement with relation to your callback. Maybe something along the lines of:\r\n\r\n* Initialize Crashlytics framework; register delegate class\r\n* Initialize a class property (e.g. boolean didCrash) to NO. \r\n* In 'crashlyticsDidDetectReportForLastExecution:', update the didCrash class property to YES if a crash was detected.\r\n* Initialize the JRFMemoryNoodler and return the value of the didCrash class property for the crash detector block.\r\n\r\nMy only concern with this approach is ensuring the timing - can I confidently assume that the Crashlytics delegate will fire and update this property before getting to the JRFMemoryNoodler initialization call? \r\n\r\nIf you have integrated this with Crashlytics and have a recommended approach it would be great to hear some of your thoughts on this topic. \r\n\r\nThanks again for your contribution and taking the time to look this question over!\r\n\r\nBest,\r\n\r\nDerek"}}