›

Ouya Bindings library for "Mono for Android"

liortalliortal Posts: 1Member
in ODK (OUYA Developer Kit)
I have created a bindings library for all Xamarin "Monodroid" users.

The source is available here: https://bitbucket.org/liortal/ouya.bindings

Test and tell me if it works, it builds fine.

Note that 2 types are currently missing:

CancelIgnoringJsonResponseListener
CancelIgnoringOuyaResponseListener

Not sure you'd need access to these in your C# code.

Comments

  • arcticdogarcticdog Posts: 235Member
    I believe those are required to implement the pattern they've provided to access the IAP functions. I don't think the Monodroid tranlsator creates equivalent events.

    I did actually get it working with those two listeners about a week ago. I don't have access to my code at work, but I recall it was just a modification to the metadata file to accommodate the java Object class. (You were probably getting an error that said the proxy interface wasn't being properly implemented)

    If you want to be the official keeper of the bindings, I'll post what I did in a few hours and you can update your code (or I can send you a copy of my solution and you can merge).
  • TheUndisputedTheUndisputed Posts: 19Member
    i wood allso like this ,, can you make it public

    Michael
    Michael Hansen
  • KonajuGamesKonajuGames Posts: 560Member
    Those two classes are simply convenience classes so developers don't have to implement the OnCancel for each one. They are not required for using the ODK. The way those classes have been implemented in the ODK does confuse the binding generator in MfA though, so the easiest way is to exclude them.

    I have been working on bindings as well, and am currently renaming parameters and making enums from static ints. How far did you get, arcticdog? I'm interested to see how you transformed those classes to get them to work.

    I'm going to add my bindings to GitHub so the MonoGame project (of which I am a member) can easily reference as a submodule.
  • arcticdogarcticdog Posts: 235Member
    My version of the bindings here.  Feel free to use it where-ever.

    *Disclaimer... these bindings are a derived work of the odk0.0.4 in C# for Mono For Android, and are not related to OUYA's non-existent effort on this front, and therefore is not endorsed, sanctioned nor does it adhere to any other term that may imply that this is an "official" work of OUYA*  :P :)  

    I haven't modified any of the static ints and personally, I don't think I'd bother. There's not a lot of them.  The ODK is a moving target until an official release, and the type safety gain is pretty minimal at this point. Plus it's one less thing to maintain if the ints happen to change subtly for some reason and they're not caught.


  • KonajuGamesKonajuGames Posts: 560Member
    Many thanks for that.  I found the transform for the Invoker class produced a warning that the node couldn't be found, so I removed it.  I have borrowed the other two transforms. :)
  • KonajuGamesKonajuGames Posts: 560Member
    edited January 2013
    https://github.com/slygamer/ouya-csharp

    All parameter names have been mapped to their correct names.
    Enums for axes and buttons.
    Removed deprecated methods.

    Post edited by KonajuGames on
  • arcticdogarcticdog Posts: 235Member
    Great! :)  

    Hopefully the API doesn't change too radically going forward so you don't have to go through all of that mapping pain again.  At some point when everything stabilizes, it might not be a horrible idea to get rid of the listener pattern and implement callbacks into the interface with an event dispatcher instead.  You've done all the hard work of re-mapping enums and naming methods.  But as long as it uses the listener pattern rather than hiding that behind the event system, it still sort of sits half way in the Java world and half way in .Net/Mono.

    You're right about the Invoker class. Good catch there.  I know at one point when I was fiddling with the transforms for the interface, adding that node got me further.  I guess after that other transform was added, it wasn't required anymore (and probably just added an empty method)

    Have you had any luck getting it into MonoGame?
  • KonajuGamesKonajuGames Posts: 560Member
    I have now created a Visual Studio project template for an OUYA game, so it is now a one step process to get a runnable game integrated with the OUYA Launcher.  All available in MonoGame's GitHub repo https://github.com/mono/MonoGame

    I agree with changing the listener pattern to events.  That is my next step.  It is a much more complex transformation than the simple renaming of elements.  I have also committed the api.xml created by MfA, which will allow an easy diff of the next ODK update to catch all changes.
  • KonajuGamesKonajuGames Posts: 560Member
    An async/await version would be very cool (when Xamarin release that support for MfA).
  • arcticdogarcticdog Posts: 235Member
    KonajuGames said:
    An async/await version would be very cool (when Xamarin release that support for MfA).
    You thinking for the IAP calls?  I believe the Task Parallel library is available in MfA.  async/await is basically syntactical sugar wrapped around that.
  • KonajuGamesKonajuGames Posts: 560Member
    True, it is syntactic sugar, but it does make quite a difference to how you use it.
  • totallyeviltotallyevil Posts: 10Member

    Thanks Sly! Using your API and including it in our build solution,

     

    Ouya.Console.Api.

    OuyaFacade.Instance.Init(this, MY_DEV_UUID);

    and the category intent, we were able to deploy Santa Shooter to Ouya. Now we just need to implement controller support in cocoso2d-xna and we'll have a fully functional MonoGame/MonoDroid game!

    Thanks for your work and sharing it!

     

Sign In or Register to comment.