Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat
Using Wax for easy access to Objective-C under IOS Gideros - Gideros Forum

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

bowerandybowerandy Guru
edited September 2012 in Plugins
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
+1 -1 (+14 / -1 ) Share on Facebook
«13

Comments

  • 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)
  • 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.

    Likes: atilim

    +1 -1 (+1 / -0 ) Share on Facebook
  • ar2rsawseenar2rsawseen Maintainer
    edited September 2012
    I only wish something like that would be available to Android too
  • atilimatilim Maintainer
    edited September 2012
    Legendary! Now I can barely sit down... :)

  • 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?
  • MellsMells Guru
    edited 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
    twitter@TheWindApps Artful applications : The Wind Forest. #art #japan #apps
  • =D> =D> =D> =D>


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

    Speed of Gideros, power of native iOS = WIN WIN WIN for indie developer! :) :) :)
    WhiteTree Games - Home, home on the web, where the bits and bytes they do play!
    #MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
  • ar2rsawseenar2rsawseen Maintainer
    edited 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 :)
  • :O

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

    @bowerandy wow!

    @all Gideros Rulez!
    TNT ENGiNE for Gideors Studio - Particle Engine, Virtual Pad, Animator Studio, Collision Engine - DOWNLOAD NOW !!! IT'S FREE!!! -
    www.tntengine.com
  • 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! ^:)^
    Owltwins. Smart design and creative code.
    »Gideros Illustrator« - [svg|xml] scene designer using Adobe Illustrator®™ Within one line of code!
  • @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.
    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • OZAppsOZApps Guru
    edited 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?

    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • 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.

    WhiteTree Games - Home, home on the web, where the bits and bytes they do play!
    #MakeABetterGame! "Never give up, Never NEVER give up!" - Winston Churchill
    +1 -1 (+4 / -0 ) Share on Facebook
  • alexzhengalexzheng Guru
    edited 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?
  • bowerandybowerandy Guru
    edited 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

    Likes: OZApps

    +1 -1 (+1 / -0 ) Share on Facebook
  • 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

    Likes: techdojo

    +1 -1 (+1 / -0 ) Share on Facebook
  • moopfmoopf Guru
    edited 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!
  • phongttphongtt Guru
    edited 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) :)
  • @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.
  • 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)
  • bowerandybowerandy Guru
    edited 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
  • bowerandybowerandy Guru
    edited 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
    +1 -1 (+3 / -0 ) Share on Facebook
  • @bowerandy Thanks for explaining your rationale for this, I can see where you're coming from (and others) and that's cool.
  • @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).
    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • 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.
    twitter: @ozapps | http://www.oz-apps.com | http://howto.oz-apps.com | http://reviewme.oz-apps.com
    Author of Learn Lua for iOS Game Development from Apress ( http://www.apress.com/9781430246626 )
    Cool Vizify Profile at https://www.vizify.com/oz-apps
  • 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.

    Likes: SatheeshJM

    +1 -1 (+1 / -0 ) Share on Facebook
Sign In or Register to comment.