Hi there,
It would be super amazing if someone who is familiar with ANEs could encapsulate the ODK into an ANE for us AIR developers. I could do it but I'm strapped for time at the moment.
A big thumbs up to whoever does it first.
Thanks!
I'm seriously considering tackling this, but I really have no experience with native extensions, so I can't guarantee that I'll know what I'm doing. :-)
I'd love to tackle this, it'd be brilliant for AIR to support Ouya. Only issue I have is I don't have a development kit, if I did I'd be up all night to create an extension for it. I mean, only essential thing is really controller mapping and support. Otherwise Ouya can just run a normal APK.
Okay. I put a little time into this just now and immediately came upon some roadblocks.
The way that native extensions are designed, it's not a matter of simply passing arguments or variables from an ActionScript class into an existing Java class and listening for returns. Each java class in the ODK needs to be augmented with some extra code to work as part of the native extension. And since the ODK doesn't seem to include source (yet?), so I can't really do much with it.
I was hoping to simply use external libraries, so each time the ODK is updated, it would be a simple matter of swapping out the ODK source files and recompiling the extension, but from what I can tell, there's more to it than that, unfortunately, and so outside of the difficulty of creating the extension in the first place, I don't know how practical it will be to maintain as the ODK rapidly evolves over the next few months.
But this is coming from my limited (perhaps faulty?) investigations. Until I can get my hands on the ODK source code, there's not much I can do at the moment. And of course, I also don't have a dev console, so there's that, too. :-)
I looked at this a little bit. And admittedly, I'm not an AIR developer. But it sounds like one method for accomplishing this is to set up a proxy service between AIR and Java then communicate back and forth via a socket. I'd be a little concerned about performance here since the controller class would utilize this frequently, but you never know.
You could also try wrapping the ODK classes and methods with a java class you create that implements the required interface that AIR is expecting. Then just pass through calls to your class to the equivalent/underlying calls to the ODK.
This would get you in implementation compliance for the native extension without having to modify the ODK source itself.
You could also try wrapping the ODK classes and methods with a java class you create that implements the required interface that AIR is expecting. Then just pass through calls to your class to the equivalent/underlying calls to the ODK.
That's more or less the prescribed way to do it, which has little performance overhead, compared to a service anyway. But the problem with wrapping is that none of the tutorials on Native Extensions seem to involve leveraging existing Java classes. All the examples are really simple, involving passing a few ActionScript variables into a custom-written Java method and sending the return back to the AIR runtime.
The way it should work is just as you describe: I'd write an ActionScript interface class for each of the classes in the ODK, as well as Java wrapper classes for each of them in order to make them visible to the interfaces. Then I would compile the extension (which packages up the whole mess into one schizophrenic library), and after invoking the extension in my manifest, I would be able to call the methods/variables/classes of the interface in my AIR app.
But frankly, I don't yet know how to do that (like all AIR/Flash developers, I'm an self-taught amateur). The other option would simply be to copy/paste each of the ODK classes into new Java classes and add the extra code required to let them be called by the interface. It's hard to tell which is the least efficient way to do it.
Having just learned the structure of Native Extensions today (and without much Java experience), I could probably easily whip up an extension to handle android hardware features like a gyroscope or vibration, or software features like notifications, but those all involve simple ins and outs, so getting any of the ODK to work properly, even something as simple as duplicating the static constants for the OUYA controller buttons, totally confounds me.
Perhaps once we have source (and I have time to learn more about what native extensions are capable of), I could get closer to a implementation.
But in truth, for the moment this is all over my head. Perhaps it will be less of a challenge to a more experienced developer.
This would be a great time for someone from Team OUYA to chime in and say that they are working on it already. :) Ideally, something from Team OUYA would be better than a 3rd party approach but if they aren't working on it, one of us will have to take it on. I can't remember who but I believe someone has already done it but I don't think they have released anything for public use.
Team OUYA, if you are reading this, it is absolutely worth it to support AIR as much as Unity. If you combine AIR 3.5+Flare3D+Starling, you can do most 3D titles in Flash. And there are a lot of us out there. I also develop in Unity but I'd rather just stick to one code base to rule them all.
I hadn't considered that, but ideally, yes, it would be easiest (and probably best for all involved) if OUYA created and maintained an Native Extension themselves. I figured that it would be outside thier wheelhouse, but you reminded me that there are a bazillion AIR/Flash developers out there, and it would be in OUYA's interest to bring them (and their kajillions of games) into the fold.
I mean, surely some of that extra Kickstarter money can be used to hire a ActionSctipt wiz. ;-)
By the way, this is what I asked Julie in August via email:
Will Ouya support "AIR for Android" development? My thinking is that I would use AIR's Captive Runtime feature to package the AIR runtime within the app (like how it's implemented in iOS without needing Apple's involvement), and use AIR's native extensions feature to implement any Ouya-specific APIs (which I would develop in Java). Is this an accurate assessment?
And this was her reply:
// We plan on supporting AIR; looking into it now.
I don't see that as much of a confirmation, since I mentioned creating the extension myself, but it's the only word on the subject I've heard from Team OUYA so far, and it does seem somewhat promising, so I thought I'd repost it here.
I received an email reply from Julie saying the same. I also saw a Tweet from Ouya saying they're working on support for AIR. There's no point in making an ANE for it on my own if somebody on the Ouya team is already working on it, so I'm just going to sit back and wait until they officially release whatever AIR support they have planned.
Since I'm working on a huge performance update for my game right now, there's plenty to keep me busy in the meantime. Though it's a bit unfortunate for those who are ready to jump into Ouya right now and would like to have their AIR game done in time for launch.
Keep in mind that OUYA technically already has support for AIR apps, in that it can run them just like it can run any other Android app. And because some of the controller's face buttons and its d-pad default to native Android hardware keyboard inputs, you could even implement limited support for the controller.
Julie hasn't confirmed anything beyond that up to now. Of course, it could be that they are indeed working on a native extension for the ODK, but we don't really know, and I'm inclined to think that they would be more specific about it if that were the case.
Either way, it would be good to get a clarification from someone on the team.
Yeah, something from Boxer8 in the form of a yes or no rather than a maybe would be good. I could give it a go in about a week's time but I have more important things to work on if Boxer8 has already got someone working on it. If Milkman Games had a dev console, I'm sure they would have had it completed with docs by now but I doubt they have one.
Seeing as how, at least to me, the gap between where we are now and full AIR support seems quite small, it wouldn't at all surprise me if the reason we don't already have it is because Adobe would rather save it as a feature for Flash CS7.
My gut feeling is this will be a Boxer8 thing more than an officially supported Adobe thing.
For most of us to make the March/April launch date, we can't wait around for months for the ANE. Some sort of support will need to be available within the next month. TBH, I'm hoping someone is already working on it and makes it known. If not, I will have to tackle it in the next few days. I have no problem releasing it if I get it done first.
This is my first priority when our dev kit arrives. It's gone from Hong Kong to Cincinnati to Ontario. It left the facility in Ontario at noon so hopefully it'll arrive tomorrow or Monday. I'll gladly share with the community once I have something working.
Game_Radiator, if you can have a go at it once you get your console, that will be awesome. Just let us all know how you are going with it. I won't have time to try and tackle it for about a week.
I have experience with AIR Native Extentions and unfortunately Air for mobile doesn't support Native Extensions :(
That doesn't make any sense. While it's possible to create extensions for desktop OSes, Native Extentions for AIR was designed by Adobe *specifically* for mobile OSes like iOS and Android.
Hmph, sorry. That is odd, I've looked into it several times and the official Adobe response was always that it was not available. I suppose I stand corrected. I'll look into it again and see what I can do to add Gamepad and other ODK functionality.
rocketbunny
Posts: 46Member
Comments
The way that native extensions are designed, it's not a matter of simply passing arguments or variables from an ActionScript class into an existing Java class and listening for returns. Each java class in the ODK needs to be augmented with some extra code to work as part of the native extension. And since the ODK doesn't seem to include source (yet?), so I can't really do much with it.
I was hoping to simply use external libraries, so each time the ODK is updated, it would be a simple matter of swapping out the ODK source files and recompiling the extension, but from what I can tell, there's more to it than that, unfortunately, and so outside of the difficulty of creating the extension in the first place, I don't know how practical it will be to maintain as the ODK rapidly evolves over the next few months.
But this is coming from my limited (perhaps faulty?) investigations. Until I can get my hands on the ODK source code, there's not much I can do at the moment. And of course, I also don't have a dev console, so there's that, too. :-)
You could also try wrapping the ODK classes and methods with a java class you create that implements the required interface that AIR is expecting. Then just pass through calls to your class to the equivalent/underlying calls to the ODK.
This would get you in implementation compliance for the native extension without having to modify the ODK source itself.
The way it should work is just as you describe: I'd write an ActionScript interface class for each of the classes in the ODK, as well as Java wrapper classes for each of them in order to make them visible to the interfaces. Then I would compile the extension (which packages up the whole mess into one schizophrenic library), and after invoking the extension in my manifest, I would be able to call the methods/variables/classes of the interface in my AIR app.
But frankly, I don't yet know how to do that (like all AIR/Flash developers, I'm an self-taught amateur). The other option would simply be to copy/paste each of the ODK classes into new Java classes and add the extra code required to let them be called by the interface. It's hard to tell which is the least efficient way to do it.
Having just learned the structure of Native Extensions today (and without much Java experience), I could probably easily whip up an extension to handle android hardware features like a gyroscope or vibration, or software features like notifications, but those all involve simple ins and outs, so getting any of the ODK to work properly, even something as simple as duplicating the static constants for the OUYA controller buttons, totally confounds me.
Perhaps once we have source (and I have time to learn more about what native extensions are capable of), I could get closer to a implementation.
But in truth, for the moment this is all over my head. Perhaps it will be less of a challenge to a more experienced developer.
Team OUYA, if you are reading this, it is absolutely worth it to support AIR as much as Unity. If you combine AIR 3.5+Flare3D+Starling, you can do most 3D titles in Flash. And there are a lot of us out there. I also develop in Unity but I'd rather just stick to one code base to rule them all.
Thanks,
CEO, Rocket Bunny Games
I mean, surely some of that extra Kickstarter money can be used to hire a ActionSctipt wiz. ;-)
Since I'm working on a huge performance update for my game right now, there's plenty to keep me busy in the meantime. Though it's a bit unfortunate for those who are ready to jump into Ouya right now and would like to have their AIR game done in time for launch.
Julie hasn't confirmed anything beyond that up to now. Of course, it could be that they are indeed working on a native extension for the ODK, but we don't really know, and I'm inclined to think that they would be more specific about it if that were the case.
Either way, it would be good to get a clarification from someone on the team.
CEO, Rocket Bunny Games
Seeing as how, at least to me, the gap between where we are now and full AIR support seems quite small, it wouldn't at all surprise me if the reason we don't already have it is because Adobe would rather save it as a feature for Flash CS7.
For most of us to make the March/April launch date, we can't wait around for months for the ANE. Some sort of support will need to be available within the next month. TBH, I'm hoping someone is already working on it and makes it known. If not, I will have to tackle it in the next few days. I have no problem releasing it if I get it done first.
CEO, Rocket Bunny Games
Android Specialist
OUYA
Game_Radiator, if you can have a go at it once you get your console, that will be awesome. Just let us all know how you are going with it. I won't have time to try and tackle it for about a week.
I'm sure we can get this done.
Cheers,
CEO, Rocket Bunny Games
However the game pad works in AIR out-of-the-box using keyboard bindings http://forums.ouya.tv/discussion/158/flashdevelop-adobe-air-i-can-breathe