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?
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.).
Maybe try the bindings from ayoung and follow his readme.
https://github.com/ayoung/monotouch-testflight
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.
Related
I have read a question/answer which states Flutter Web is a fork of Flutter and so one Android Studio (or VScode) project can't be built to handle both.
I'm not an expert on either (obviously) but I don't understand why the fact the libraries are forked implicitly precludes one from using the same source code for the different destinations.
Has anyone done so? And, if so, is there a skeletal project anyone would care to share?
Windows SDK 7.1 was the last version that included the baseclasses direct show sample. But later Windows SDK have strmbase.lib with the compiled library. What use is the library without the headers?
It might be included without good reason waiting for its cleanup time, or there is unobvious reason such as reference to this static library when linking other legacy libraries.
Either way you are correct in the part that DirectShow bases classes are no longer in Windows SDK. Those interested in DirectShow development would typically get DirectShow BaseClasses and samples from Windows-classic-samples/Win7Samples and build the code including strmbase.lib themselves.
I've downloaded Crashlytics app that integrates Crashlytics.framework into XCode project, and it works great for XCode. But as far as I know, to build Xamarin.iOS binding I need static library, and I can't find it neither in framework nor in Crashlytics.app contents. There is only "run" executable and header. I don't know how to use it under Xamarin.iOS. Btw, AndrewReed on Xamarin forum managed to build dll somehow, so it's possible.
So, how to create crashlytics binding for Xamarin?
AndrewReed answered this question on Xamarin forum:
As with quite a few sdk's, sometimes they bundle a folder instead of the static lib,which essentially is the static library. There will be a sizeable file that maybe doesnt have an extension(this is your .a file) so you can rename that to be .a and then include that in a xamarin bindings project. Run the sharpie marker on the header file in the folder which will generate your necessary files. Watch out for one gotcha, delegate is a reserved word in c#, so you may need to go around and change this by adding an # symbol(to the name) to allow you to use the reserved word.
So what I actually did was, created a project in xcode and ran the crashlytics programme, this then added the crashlytics framework to the project. In finder locate that and you will have a structure like so: - run - /Versions --/A ---Crashlytics ---/Headers ----Crashlytics.h
So the /A folder is essentially your static lib, use this and create your binding from that, or in this particular case, just download it from the mono bindings || my repo.
If you're looking for an officially supported crash reporting plugin, Crittercism just released one (Full disclosure: I'm one of the co-founders). You can download the bindings from the Xamarin store here: http://components.xamarin.com/view/crittercism
The latest version of Xamarin seems to have it build in.
Here are the steps that I followed
1.) In the Xamarin Studio , go to the main app, and add the Crashlytics API key in the Build -> Crash reporting section. Build and run that app. The evidence suggests that is enough to get data sent to Crashlytics. I saw that it knew about older versions of the app I had built and ran weeks ago with the API key already in.
2.) Go to Xcode and create a new project with the same name as the Xamarin project, com.{company}.{appname}. (You probably need to have that profile downloaded.) I did it in Swift by the way with no issues.
3.) Go to crashlytics.com com and go to settings -> Apps (or https://www.crashlytics.com/onboard)
4.) You will get an app to download and run. The app walks through the steps of adding
A.) A build phase run script
B.) Code to the application main Crashlytics.startWithAPIKey(“nnnn”)
5.) Run your Xcode version of the app
The Crashlytics web page popped up immediately.
How do I get the source for a specifik stable release of servicestack from Github?
I'm trying to download and build the source for version 3.9.0.0 but I am having two sorts of problems.
1) There are no labels for the main service stack project so I can't figure out at what commit the 3.9.0.0 was built from.
2) Since Service Stack main project depends on ServiceStack.Text I also need to know against what version of ServiceStack.Text the ServiceStack 3.9.0.0 was built against.
If anyone wonders. The reason I ask this is because the later ServiceStack releases are not all backward compatible and a project I recently took over is throwing exceptions down in the ServiceStack.Text. And the version of ServiceStack.Text seems important since the version of ServiceStack and ServiceStack.Text I downloade, collided on build on extension.
The state I am at is that I got souce for what seems to be 3.9.4 and I managed to get hold of a nuget packet of ServiceStack.Text with version 3.9.0.0 that I could compile against (no source) and this actuallt killed of the trubbeling exception in ServiceStack.Text so that problem seems at least temporarely solved. At the next issue I'll probably be stuck again so I'd really like the source. (It is the point with open source after all right?)
Best regards, Nick
Although older versions are not supported by ServiceStack, you could to go back through the ServiceStack commit logs until you see a message that says INCR to v3.9.x.
One way to quickly browse releases is to look at changes to the Properties/Assembly.cs file which changes when the version is incremented.
As ServiceStack is uses components from different sub projects, you will need to do the same for ServiceStack.Text, ServiceStack.OrmLite and ServiceStack.Redis as well.
ServiceStack keeps the same version in-sync with the other components, so the v3.9.4 of ServiceStack uses a v3.9.4 of ServiceStack.Text, etc.
Monotouch compiles the app into the native code. How can Apple know that the app was built using MonoTouch? Does Monotouch leaves a signature in the application?
Does Monotouch has its own libraries which could be a trace of the origin or it compiles all the code and all its .NET libraries into native code?
The resulting .app package contains the application binary, your resources as well as the required additional libraries, such as:
montouch.dll;
System.dll;
System.Xml.dll and so on.
As such, it would be trivial for them to check if the application was built with monotouch or not - it is as simple as right clicking the package and then select "Show package contents" in Finder.
However, you need not worry about that, as Apple has just relaxed their License Agreement: http://daringfireball.net/2010/09/app_store_guidelines
And even if the assemblies containing metadata were not included in the app bundle (directory), I am quite sure it is relatively trivial to learn how to recognize from the patterns in the actual code in the app executable that it was produced by MonoTouch, if one would want to. So there is not reason for MonoTouch to try to "hide" that fact.