I've been searching around and can't seem to find a definitive reference on how to use the TestFlight SDK with MonoTouch... has anyone gotten it to work successfully with 0.8.3 and mind sharing their secret?
Asked
Active
Viewed 2,834 times
4
-
This question has an answer that seems to do the trick: http://stackoverflow.com/questions/14499334/how-to-prevent-ios-crash-reporters-from-crashing-monotouch-apps – Dermot May 07 '13 at 15:11
3 Answers
10
Testflight documentation can be found here: http://docs.xamarin.com/ios/tutorials/TestFlight_Support#
The Testflight bindings can be found here: https://github.com/mono/monotouch-bindings/tree/master/TestFlight
Instructions about building are also on Github following the link above. Basically you just have to run "make" from the TestFlight folder (but copy the appropriate TestFlightSDK_xxx.zip file into that folder first).
The Make file included in the github repo utilizes the TestFlight SDK (a zip file) which must be independently downloaded from TestFlightApp.com and manually copied (in compressed form) into the folder containing the binding project from github.
Then use Testflight SDK as explained on the Testflight website (call TakeOff(), set checkpoints, etc.).
-
I've tried to do this, but get the following error: /var/folders/wv/.../T/tmp483c5d2d.tmp/reczookaScorer -framework CFNetwork -framework Foundation -framework UIKit -framework AudioToolbox -lz -u _mono_pmip -u _CreateZStream -u _CloseZStream -u _Flush -u _ReadZStream -u _WriteZStream -liconv -lmono-2.0 -lmonotouch -L/Developer/MonoTouch/.../usr/lib -force_load /var/folders/wv/.../T/tmp483c5d2d.tmp/libTestFlight.a ld: in /var/folders/.../libTestFlight.a, file too small for architecture armv6 collect2: ld returned 1 exit status mtouch exited with code 1 – Ryan Moore Feb 23 '12 at 00:48
-
-1
From my own research and trials trying to get the TestFlight SDK to work with MonoTouch, it seems that the error reporting won't really work. Here's why:
Essentially, the TestFlight SDK inserts an obj-c global exception handler and then sends the exceptions, stack traces, etc. to TestFlight. Since the SDK is a NATIVE library, it will only wind up receiving native obj-c exceptions. This means that none of your Mono exceptions will ever reach this global obj-c handler because the handler is running at a lower level than the Mono runtime.
So, you CAN bind to the native TestFlight SDK library, you CAN call the TakeOff() method, etc. But at the end of the day, it's all kind of pointless because your Mono-level exceptions will never be caught. You could certainly receive obj-c exceptions when they occur, but this doesn't really help you with your Mono exceptions. Since all your code is presumably in C# running in the Mono runtime, don't expect your exceptions to hit the TestFlight SDK handler.
If I'm wrong, someone please correct me, but I don't believe the TestFlight SDK will be useful until a MonoTouch library is written that intercepts Mono exceptions and sends those to TestFlight.
NovaJoe
- 4,595
- 6
- 29
- 43
-
Agreed that some stack information can get lost in the crash report, but most of the details are caught & reported (including some custom C# object types and their method signatures). Your definition of usefulness is subjective, TestFlight API session reports include all crossed Checkpoints and the **complete Console log** for every session... that alone is priceless for my use cases. (tested by throwing an exception in my mono(cross) app code :-) – benhorgen Sep 17 '12 at 21:03
-
Hmmm...the console log bit is useful. Having a bunch of checkpoints that you know execution is crossing could be useful too, but it seems rather cumbersome. I'd really like to see a collaboration between Xamarin and TestFlight to come up with a Mono DLL for this. – NovaJoe Sep 17 '12 at 21:07