Using Wax for easy access to Objective-C under IOS Gideros

bowerandy · September 2012

Folks,

Over the last day or so, I've put some effort into getting the Wax Lua-ObjectiveC bridge working under Gideros. Wax is a project by Corey Johnson that allows one to effectively write ObjC code in Lua and gain access to virtually all of the IOS libraries.

Here's an example in Lua of putting up a native multiline text field that can be edited with the IOS keyboard:

local font=UIFont:boldSystemFontOfSize(24)
local textField=UITextView:initWithFrame(CGRect(50, 50, 200, 40))
textField:setFont(font)
textField:setTextColor(UIColor:whiteColor())
textField:setBackgroundColor(UIColor:clearColor())
getRootViewController():view():addSubview(textField)

I've implemented Wax as a plugin, called BhWax, which just might be the last Gideros plugin you'll ever need to write (if you're on IOS). Sadly, Wax is tied to Objective-C for reasons that I discuss on my blog, so Gideros users developing for Android won't be able to make use of it, I'm afraid.

Here is a short video showing how you can set up the plugin in the GiderosIOSPlayer and a peek at the demo program I've included with the download:

More information is available on my blog page for those who are interested. I don't know whether it's just me but this seems really cool.

Best regards

phongtt · September 2012

Terrific job man! Looks very interesting. I think it will be very useful!

(But I don't have time to try it so soon, been hell busy)

TheOddLinguist · September 2012

Very exciting, indeed. I think this is a nice compromise alongside the plugin system. The plugins can provide a cleaner interface within your app, but Wax will give not only more power, but relatively effortless access to some powerful libraries. I see fantastic use cases for both, and this is exciting news. If only I had a better grasp of Obj-C. hehe Very well done.

ar2rsawseen · September 2012

I only wish something like that would be available to Android too

atilim · September 2012

Legendary! Now I can barely sit down...

alexzheng · September 2012

Is that can be adapted to gideros for android?

http://code.google.com/p/jnlua/

ar2rsawseen · September 2012

It would seem like so. At least it would allow to skip JNI step in plugin creation. Need to test it more. Which lua version does Gideros use?

evs · September 2012

WOW!!!

Cheers

evs

Mells · September 2012

Looks like another breakthrough step for Gideros. Nice work @bowerandy.

@ar2sawseen

June 23
We use Lua 5.1.4, and no plans for Lua 5.2 yet.

Source

techdojo · September 2012

=D> =D> =D> =D>

^:)^ ^:)^ ^:)^ ^:)^ ^:)^

Speed of Gideros, power of native iOS = WIN WIN WIN for indie developer!

ar2rsawseen · September 2012

Also finding same bridge for Javascript would be awesome, cause I could map Gideros classes to canvas object and allow running Gideros apps on websites through HTML5 canvas.

OR

It could work both ways and you could develop Gideros mobile apps using Javascript

GregBUG · September 2012

:O

^:)^ ^:)^ ^:)^

@bowerandy wow!

@all Gideros Rulez!

sprigame · September 2012

awesome ^:)^

jack0088 · September 2012

I've had a quick look at the video and must say it's stunning work you have done here!

The only thing to adapt, is the class system of wax. If this would match the class system of Gideros, it would look like native Gideros Plugin System.
(e.g. Classname = Core.class(Parentclass) )

great! ^:)^

OZApps · September 2012

@bowerandy, that video is amazing, this is (I am sure) only the start of a lot of things coming to Gideros. You have always pushed the limits of Gideros with amazing results.

OZApps · September 2012

...and

not 100% sure, but I recollect using things like

UIImage:imageWithContentsOfFile_pathForResource_ofType(nil, "image", "png")
or
UIImage:imageNamed("image.png"):CGImage()

with wax, but it spawns an error with your library, is there some change or is it something that I might be overlooking?

Images loaded via Gideros Bitmap have a lower z-order than those of the UIKit elements and rightly so because the native Gideros elements are drawn on the OpenGL Surface where as the others are all added above this layer/surface. So any ideas?

techdojo · September 2012

I got the demo working yesterday by following the instructions in the video and rebuilding the player (I have a separate player build just for Wax) however it was a bit fiddly and I can imagine it'll be a ball-ache to have to keep doing it every time you export a new project.

So...

Given that this is the mother of all plugin's to end all other plugin's I'd like to formally request @Atilim work with @Bowerandy to make this part of the official Gideros distribution so that the player and exported projects already have this functionality built it.

alexzheng · September 2012

The reason why I had never tried wax is writing so long API without code autocomplete
feature is a nightmare for me, who can remember the detail for every api.
Any handy editor available?

bowerandy · September 2012

UIAlertView:initWithTitle_message_delegate("title", "message", nil)
or
UIImage:imageWithContentsOfFile_pathForResource_ofType(nil, "image", "png")
or
UIImage:imageNamed("image.png"):CGImage()

with wax, but it spawns an error with your library, is there some change or is it something that I might be overlooking?

The alert view issue is caused by your use of an incorrect method selector. Looking at the Apple docs for UIAlertView, the correct one is: initWithTitle:message:delegate:cancelButtonTitle:otherButtonTitles:. So, if you create your alert with the following Lua, everything works okay:

local alert=UIAlertView:initWithTitle_message_delegate_cancelButtonTitle_otherButtonTitles("title", "message", nil, "ok", nil)
alert:show()

Actually, that method seems to have some sort of vararg ... at the end to add additional buttons. I'm not sure how (or if) Wax handles varargs so I just pass nil here. You could use addButtonWithTitle: to add more buttons if you wish.

The first UIImage call also seems to have an incorrect selector (at least I couldn't see it in the Apple docs). You can simply use imageWithContentOfFile: providing you pass a full path to the image. You need to remember that Gideros keeps its resource files in their specially named |R| folder. In order to get to the full path easily I've added a helper function, getPathForFile(), to BhWax.mm. So now you can call:

local image1=UIImage:imageWithContentsOfFile(getPathForFile("|R|Images/YouTube.png"))
print(image1)

This seems to work. You can pull a new version of BhWax from GitHub that includes this addition.

Unfortunately, doing the same with imageNamed: doesn't appear to work.

local image2=UIImage:imageNamed(getPathForFile("|R|Images/YouTube.png"))
print(image2)

This prints nil. I suspect this is because the docs say: "If this is the first time the image is being loaded, the method looks for an image with the specified name in the application’s main bundle.". Since our image isn't from the application bundle maybe this fails?

Images loaded via Gideros Bitmap have a lower z-order than those of the UIKit elements and rightly so because the native Gideros elements are drawn on the OpenGL Surface where as the others are all added above this layer/surface. So any ideas?

I don't think there's much we can do about this really.

best regards

bowerandy · September 2012

however it was a bit fiddly and I can imagine it'll be a ball-ache to have to keep doing it every time you export a new project.

I've done it several times now and it gets a lot easier every time. Obviously, you only have to do it once for every NEW project and then again every time Gideros release a new version. In between times you can just tick "assets only" when you export your project. But I'm sure you knew that

An alternative would be if someone could explain to me how to build all those source files into a static library in Xcode. That way only one file would need to be dragged across.

Given that this is the mother of all plugin's to end all other plugin's I'd like to formally request @Atilim work with @Bowerandy to make this part of the official Gideros distribution so that the player and exported projects already have this functionality built it.

I'd be perfectly happy with this. Doing this would also mean we could generate the autocomplete information for all common Cocoa classes and have the Gideros editor have these built in too. Shouldn't be too hard to write a bit of Lua reflect over all the apis and output the appropriate stuff.

best regards

moopf · September 2012

Clever as this is, if you're just developing for iOS and you're having to know the Objective-C calls anyway (understandably), why would you use Gideros at all? Leverage something like cocos2d if you want a higher level library (which offers a lot more functionality than Gideros) and develop natively. You're basically having to learn the Apple APIs anyway.

I must be missing something here!

phongtt · September 2012

For me:

"speed" of development, ease of use provided by Gideros (scripting, wifi deployment, lightweight emulator) that someone like me can hardly run away.
(And I'm happy that my game designer and artist can easily build, experiment, and change game parameters, art themselves to check the result instantly on their Windows machine)

Only when you have some need that isn't available yet, then this will come into help.

I think that's the point (okay, at least just for me)

moopf · September 2012

@phongtt Certainly speed of development in Gideros *can* be quicker but it can also be slower and more frustrating if things aren't covered (you know masks, clipping etc. etc.). But speed really isn't everything - making things too quick develop can lead to shoddy development. I just look at the quality of some of what's been released with these 3rd party systems and it makes me shudder. Apple isn't tough enough on quality control.

In terms of wifi deployment, it's really not much quicker than having your device connected and pushing to the device in XCode (and you get much better debugging).

I see so much here that's really centered on iOS and it's always puzzled me. And this bridge just exacerbates that, because you're basically having to learn the APIs anyway and the more things like this gets used the more users of Gideros tie themselves to iOS only. I guess that's my point.

Not to take away from what's been done here by @bowerandy at all, which I think is a great example of pushing the system, I just think I have a different mindset after having previously developed just for iOS - I want to target all the platforms I can without having to port and maintain multiple code-bases. Not doing that seems like a wasted time investment these days. Unfortunately to do that you need to find a system that provides most of what you want, which I think I have now.

phongtt · September 2012

Okay, it will be forever to discuss/argue about Gideros being better or so for different tastes or different needs, etc.

But I agree with your point regarding equal support for both iOS and Android (which you used to push and shout for in other threads)

bowerandy · September 2012

@moopf, but surely a system that provides "most" of what you want is worse than useless! You need to be able to get around any roadblocks that you come across and have the confidence from the outset that you can do this. Gideros gives this confidence with plugins but, frankly, they are a pain to write and you have to muck around with XCode (on iOS of course) etc. The Wax stuff just makes it much simpler to do this on iOS and to debug it when you need to.

True, if your main focus is portability then Wax gives you nothing. I can see that, for you, this is all meaningless. For me, and maybe some others, I have little interest in Android at the moment and just want to produce the best possible app I can for the iOS market. To do this I sometimes need access to native features which aren't supported directly in Gideros out of the box (turn based game kit for example). Wax gives this without the pain of writing a plugin.

The point isn't really to code everything in Wax. You could do that and it might be interesting but, in the end, you'd probably just create something that was slower and harder to maintain than using raw Cocoa (although being able to ignore all that XCode malarky might be very compelling). No, I think the real point is to write 2D graphics apps in Gideros but drop down to Cocoa when something gets in the way.

By way of an example, I'm writing a simple game app (my first) which isn't that complex really but even with this I have so far I've needed to drop into plugins on several occasions:

1) To access the Photo Library
2) To take a snapshot of the screen and save to PNG so it can be reloaded in Gideros
3) To create a native Keyboard with editable text field
4) To use the Turn Based game kit
5) To create an AI module because Lua wasn't fast enough

All but 5) I could have done in Gideros using Wax and it would be (much) faster and more maintainable.

best regards

bowerandy · September 2012

@phongtt, interestingly I think that Wax *will* help Gideros to provide better cross platform capability.

Imagine the time that @atilim has spent creating the GameKit plugin or the StoreKIt plugin and the iAd plugin. All of these things, and more, can now be done easily by us users rather than Gideros. This leaves the crew more time to concentrate on other enhancements like portability (and async texture loading; hint, hint)

best regards

moopf · September 2012

@bowerandy Thanks for explaining your rationale for this, I can see where you're coming from (and others) and that's cool.

phongtt · September 2012

Aha, that makes sense

)

OZApps · September 2012

@Andy, Maybe you might also want to add that if anyone wanted to use additional frameworks like the new Twitter Interface in iOS they could use that by instantiating a new TWTweetComposeViewController. However I also believe that the plugins might need to have the includes or is there an easier way to integrate this functionality without recompiling everything into the player?

And I do agree and wanted to add that Gideros like other frameworks is an OpenGL based framework it offers features for Game Making, the whole purpose of Plug-Ins was to have features that were not yet included. The majority of these were to have functionality like the native widgets. Wax is not a silver bullet, but it does for a lot of developers that want to focus on iOS only provide complete access to the latest features of iOS that no other Lua based framework could offer. So in that regards, this is a welcome feature and yes, if cross-platform is the focus, then this is not much helpful.

However if one wants to make business apps with iOS functionality, this is THE plug-in to have, it is as stable or unstable as the wrapper itself (Wax).

OZApps · September 2012

I used Wax around late 2009 but who could have thought of using Wax for integrating with a Lua based framework. It is almost like having a translator for an native English speaking person. Sometimes it is important and very useful. Thanks Andy.

Dale · September 2012

This just blows me away. Possibly the plugin to end all plugins.

If you were finding a need for a plugin, more than likely this Wax plugin would let you do what you want, from Lua, more easily, and quite efficiently.

It also makes Gideros, oddly, a great platform for developing LUA native-GUI iOS apps... It's awesome having wax abilities from within the rapid development cycle the on-device player, and none (well, fewer) of the setup hassle of raw Wax.

Very excited to see this, I expect to use it a lot.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Using Wax for easy access to Objective-C under IOS Gideros

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Using Wax for easy access to Objective-C under IOS Gideros

Comments