The binding-test folder you added to the cocos2d bindings puzzled me up to now. I now know what it is about. But still, the project is incomplete there. Where do I find ApiBaseTest.cs, ApiCtorInitText.cs, ... should I get them from https://github.com/mono/maccore/tree/master/tests/bindings or is this part of an assembly somewhere ?
@StephaneDelcroix for the cocos2d tests you need to clone the maccore as a sibling to the monotouch-bindings directory. That should make the test project build as-is, otherwise (e.g. a new project) you need to copy the files into your solution.
The files are not part of an assembly - mostly because the same binary would not be usable for both Xamarin.Mac (which we use nunit for testing) and Xamarin.iOS (which uses Touch.Unit/NUnitLite).
@StephaneDelcroixApiCtorInitTest tests are executed on instances created from the default constructor. Mostly because it's not possible to guess the required parameters for other .ctor. The next blog post will be about constructors.
OTOH other tests exists for every exported selectors to ensure that they exists (respond) and that their managed/native signature match. More details coming in future blog posts (but you have all the sources until then :-).
You better email components@xamarin.com for question specific to the component store that are not covered in the submitter terms.
My best guess would be: (a) depend on the original component license and (b) binding projects includes the static library (so it does not matter to the store itself). Of course your component review rating might go down if you don't keep updating your bindings.
[TestFixture]
public class BindingCtorTest : ApiCtorInitTest {
public BindingCtorTest ()
{
// fictional example where binding won't work without
// some specific initialization code
MyLibrary.SharedConfiguration.Server = "127.0.0.1";
}
}
@StephaneDelcroix that would execute before each test while the constructor will be called once.
Now there's a [TestFixtureSetUp] but I never found it very useful - but it's symmetric with using [TestFixtureTearDown] (and a finalizer would not be reliable, timing-wise to replace the later).
Yes, that's the point. Re-initializing your configuration for every test. Anyway, in this case, that's nitpicking as there's one [Test] per [TestFixture] :)
My example might not be a very good one :-) but I wanted to show it's possible to initialize a library once (not per test) since it's not uncommon for native library (like the mono runtime itself) not to allow re-initialization.
Nougat is .Net, granted it's Pascal but that doesn't bother me. But the ability to import a library and use it is very enticing, versus creating an error prone binding, having to wait for someone else to create a binding for me or porting the code myself.
To quote marc hoffman, whom I have a great deal of respect for. I've been using his RemObject SDK and DataAbstract products for years in both Delphi and in .Net:
Here’s the amount of legwork i had to do before i could work with the GameKit APIs, just like every other Cocoa developer would: i added a reference to GameKit to my project. Done.
That’s it. No begging someone to translate header files, or waiting for someone to create a crappy abstraction wrapper class. Add a reference, and use the APIs as Apple intended them — that’s the way development should be.
Just curious why the same couldn't be down with MonoTouch.
@JeremyBrown There's not much details about Nougat and I don't like to speculate. There's just too many ways to achieve any goal - some easier than others, all with (at least some) drawbacks.
and use the APIs as Apple intended them
Honestly I'd rather not. I much prefer to have complexity (bindings) and ugliness (how an ObjC API looks in .NET) restricted to few than exposed to all. So it boils down to the time spend creating bindings versus the time using them - across every users.
Since the later is generally much larger than the former I think it's worth the time to curate the API bindings, to bring them to match the language and test them to ensure the later group experience is the best.
@StephaneDelcroix That's awesome! There are some ObjC runtime API to query methods (e.g. class_copyMethodList) so maybe it could be done without an outside step.
I have not really looked into this one - mostly because it would (for iOS and OSX bindings) list Apple private selectors. We (Xamarin) do not want to bind any of them since it would be too easy to get application refused in the appstores. OTOH for library bindings that's a great addition!
Also about fields... the blog series was written a while ago. Since then we made some changes to bindings wrt fields so it might be possible (I need to review that fixture) to be more precise if some (non-NSString) fields cannot be found in the native library. Feel free to beat me into reviewing this :-) I'm not likely yo have time to look into this before Evolve.
Can you please tell me how to get MD5 key/sha1 key for Google Map API1 in Windows XP Operating system.
I got some steps on this link but can any one tell me this same steps for windows xp.
Posts
protected override Assembly Assembly { get { return typeof (CCAccelAmplitude).Assembly; } }where to put this code?
- Abuse
0 • LikeThe binding-test folder you added to the cocos2d bindings puzzled me up to now. I now know what it is about. But still, the project is incomplete there. Where do I find ApiBaseTest.cs, ApiCtorInitText.cs, ... should I get them from https://github.com/mono/maccore/tree/master/tests/bindings or is this part of an assembly somewhere ?
- Abuse
0 • Like@simon: in all of your test classes... https://github.com/mono/monotouch-bindings/blob/master/cocos2d/binding-test/BindingCtorTest.cs
- Abuse
0 • Like@StephaneDelcroix for the
cocos2dtests you need to clone themaccoreas a sibling to themonotouch-bindingsdirectory. That should make the test project build as-is, otherwise (e.g. a new project) you need to copy the files into your solution.The files are not part of an assembly - mostly because the same binary would not be usable for both Xamarin.Mac (which we use
nunitfor testing) and Xamarin.iOS (which uses Touch.Unit/NUnitLite).- Abuse
0 • Likethanks @poupou, at this time of the day, I had that figured. Your stuff is awesome and able to catch 100's of issues
There's one or two that'll have to ask you about, but lemme send a pull request first
- Abuse
0 • Likeyou're not testing the constructors' selector but the default one, right ?
- Abuse
0 • Like@StephaneDelcroix
ApiCtorInitTesttests are executed on instances created from the default constructor. Mostly because it's not possible to guess the required parameters for other .ctor. The next blog post will be about constructors.OTOH other tests exists for every exported selectors to ensure that they exists (respond) and that their managed/native signature match. More details coming in future blog posts (but you have all the sources until then :-).
- Abuse
0 • Likepretty cool guide! Exactly what I was looking for.
Question :
thanks in advance.
- Abuse
0 • Like@vbellet, Thanks :)
You better email components@xamarin.com for question specific to the component store that are not covered in the submitter terms.
My best guess would be: (a) depend on the original component license and (b) binding projects includes the static library (so it does not matter to the store itself). Of course your component review rating might go down if you don't keep updating your bindings.
- Abuse
1 • 1Like@poupou: this https://github.com/mono/maccore/pull/47 detect some signature mismatches for constructors
- Abuse
2 • 2LikeJust to give back the support answer (nat lol :)) about who can submit a binding :
Everybody can submit a binding as long as the license to the original objective-c library allows you to.
As far as I know almost all objc component are under the MIT license, so let's get some binding done!
- Abuse
2 • 2LikeThis is an awesome blog post series, thanks for writing down these details!
- Abuse
2 • 2Likeand unless there's another constructor with parameter
- Abuse
0 • LikeAren't you supposed to do that in [SetUp] ?
- Abuse
0 • Likewell, actually: https://github.com/StephaneDelcroix/monotouch-bindings/blob/cocos2d/cocos2d/binding-test/BindingCtorTest.cs
(and I'm now done with the comments for the second post)
- Abuse
0 • Like@StephaneDelcroix that would execute before each test while the constructor will be called once.
Now there's a
[TestFixtureSetUp]but I never found it very useful - but it's symmetric with using[TestFixtureTearDown](and a finalizer would not be reliable, timing-wise to replace the later).- Abuse
0 • LikeYes, that's the point. Re-initializing your configuration for every test. Anyway, in this case, that's nitpicking as there's one [Test] per [TestFixture] :)
- Abuse
0 • LikeMy example might not be a very good one :-) but I wanted to show it's possible to initialize a library once (not per test) since it's not uncommon for native library (like the mono runtime itself) not to allow re-initialization.
- Abuse
0 • LikePardon my ignorance but why do we have to bother with having to create a "binding"/wrapper when products like RemObject's Oxygene “Nougat” can simply add a reference to the library and start using it?
Nougat is .Net, granted it's Pascal but that doesn't bother me. But the ability to import a library and use it is very enticing, versus creating an error prone binding, having to wait for someone else to create a binding for me or porting the code myself.
To quote marc hoffman, whom I have a great deal of respect for. I've been using his RemObject SDK and DataAbstract products for years in both Delphi and in .Net:
Just curious why the same couldn't be down with MonoTouch.
- Abuse
0 • Like@JeremyBrown There's not much details about Nougat and I don't like to speculate. There's just too many ways to achieve any goal - some easier than others, all with (at least some) drawbacks.
Honestly I'd rather not. I much prefer to have complexity (bindings) and ugliness (how an ObjC API looks in .NET) restricted to few than exposed to all. So it boils down to the time spend creating bindings versus the time using them - across every users.
Since the later is generally much larger than the former I think it's worth the time to curate the API bindings, to bring them to match the language and test them to ensure the later group experience is the best.
- Abuse
0 • LikeIf you want a test for completeness : http://blog.reblochon.org/2013/03/producing-better-bindings-completeness.html
- Abuse
0 • Like@StephaneDelcroix That's awesome! There are some ObjC runtime API to query methods (e.g.
class_copyMethodList) so maybe it could be done without an outside step.I have not really looked into this one - mostly because it would (for iOS and OSX bindings) list Apple private selectors. We (Xamarin) do not want to bind any of them since it would be too easy to get application refused in the appstores. OTOH for library bindings that's a great addition!
Also about fields... the blog series was written a while ago. Since then we made some changes to bindings wrt fields so it might be possible (I need to review that fixture) to be more precise if some (non-
NSString) fields cannot be found in the native library. Feel free to beat me into reviewing this :-) I'm not likely yo have time to look into this before Evolve.- Abuse
0 • LikeCan you please tell me how to get MD5 key/sha1 key for Google Map API1 in Windows XP Operating system. I got some steps on this link but can any one tell me this same steps for windows xp.
http://docs.xamarin.com/guides/android/platform_features/maps_and_location/obtaining_a_google_maps_api_key
- Abuse
0 • Like