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

scurvyrat · September 2012

@bowerandy Thanks for your work on this. Very exciting.

It looks like Wax from Corey Johnson hasn't been worked in a few years. Is there an issue of it needing to be updated, for example for iOS6?

How do you think the speed difference (in app responsiveness) of using the Wax framework vs MHUikit.mm?

bowerandy · September 2012

@scurvyrat, yes you're right but he does still seem to answer questions in the Google group for Wax.

There may be issues with future versions of IOS, we'll have to see. I already came across one such problem with blocks, which obviously weren't around when Wax was first developed. I think I have a solution for this in the pipeline though.

Since the UIKit is really just wrapping UI objects and not doing much processing in between, I doubt there's much difference between using Wax and UIKit, speed-wise. I'd prefer to use Wax, I guess, because if anything is missing it can be added straight off in Lua.

I would guess that as soon as you start looping through thousands of objects, things will probably go a lot slower, though.

Best regards

ar2rsawseen · September 2012

Sorry did not want to hijack thread, but don't want to create a new one for such a small issue, but if anyone is interested, then it might be possible to use Scripting Layer for Android, which would work as generic plugin for Android in Gideros.

http://code.google.com/p/android-scripting/

Basically it creates a server and then provides android API through lua socket.

https://groups.google.com/forum/?fromgroups=#!topic/android-scripting/sJuM2NgT2iw

I don't really have time to experiment with it more right now, but I just thought to post it if someone can't wait and want to experiment on their own before I get the time to do it.

Dale · September 2012

@bowerandy - a few comments

Again, I love this wav plugin, and think it could mean huge things for Gideros.

Right now, with this plugin, Gideros may have the most rapid development environment for iOS native GUI apps. If I add a new native button, click Run, and my new native button appears instantly.

Compare that to Appcelerator, for example, where you have to rebuild (which for me, takes the better part of a minute).

Even with bare XCode, you're looking several seconds before the build is finished and the app is relaunched on the simulator. (Similarly, with bare wax, you have to rebuild/relaunch your app with every change, a bit slower than XCode alone.)

With Gideros/wax and the player, UI elements can be added and changes viewed instantly. Does anyone else offer this speed of development/test?

A few suggestions, to keep the momentum going:

The demo app fails in the simulator; I changed the iPad detection (IosImagePicker.lua, line 43) to:

	return 1 == string.find(model, "iPad")

and things now work properly in the simulator. (It was trying the iPhone picker by mistake, when using the iPad emulator.)

Also, I might suggest perhaps doing up two example apps with this:

- UIKit demo - Do a version of the test project that does the same thing (buttons, webview, etc.) to show how the common UI elements are used, but from wax rather than UIKit. (Maybe their tableview example, too.)

- One of the getting started tutorials, http://mobile.tutsplus.com/tutorials/iphone/iphone-wax-part-2/ would be interesting if tweaked to work with Gideros/wax.

I assume for the latter, we ignore the AppDelegate.lua stuff and use getRootViewController() instead.

Finally, I don't suppose there's a way to have errors passed back to Gideros Studio, rather than crashing the player?

Again, great work!

-d

OZApps · September 2012

@Dale, I have an article that kind of attempts to address the exact issue that you have mentioned, you can read up on http://howto.oz-apps.com/2012/09/get-developing-for-free-enterprise.html There will be a couple of follow up articles that will discuss how to use the other common UI elements. However this should still be a good starting point to try and base other elements off.

OZApps · September 2012

@ar2rsawseen, have you seen this? https://github.com/mkottman/AndroLua
This is perhaps the Android version of Wax, so all Android users can rejoice and perhaps use this.

atilim · September 2012

@OZApps From the description, AndroLua uses LuaJava:
http://www.keplerproject.org/luajava/
https://github.com/jasonsantos/luajava

Also @alexzheng posted this link: http://code.google.com/p/jnlua/

Both seem good solutions.

gorkem · September 2012

With Gideros/wax and the player, UI elements can be added and changes viewed instantly. Does anyone else offer this speed of development/test?

I'm seriously wondering this - anyone has a clue about how other potential fast mobile application developers do it? Are there any other (faster) solutions in this world for instant app development?

techdojo · September 2012

Not sure how relevant it is but I've been looking at Interface HD (http://appshopper.com/productivity/interface-hd) which is an iPad (and iPhone) app mockup tool where you literally create your app by dragging and dropping the widget components onto a screen and changing the options visually.

Once done you can export your app as an xCode project and "apparently" it just compiles and will run - obviously you have to wire up the logic and the back end but it seems right up there with the RAD tools you get with Visual Studio

OZApps · September 2012

@techdojo, Interface is the latest offering, there were earlier offerings from several other developers (funnily from the Australasia region or more specifically from the Australia-New Zealand region) that did generate code.

I am attempting to write one that would do something similar and (maybe being over ambitious) also generate code for several frameworks including Gideros. The real killer is that I have to either write it thrice for Windows, Mac OS X and *nix or use something that compiles multi-platform. I was hoping to get a Desktop compiler from one of the Lua frameworks (Löve is desktop but not usable as yet in regards to protecting the source code and using native widgets) I guess I am getting a bit off topic, so... yeah, hope that we can have something like that for Gideros soon. While I am working on it, any body else wants to help, compete? welcome...

bowerandy · September 2012

@bowerandy - a few comments

The demo app fails in the simulator; I changed the iPad detection (IosImagePicker.lua, line 43) to:
	return 1 == string.find(model, "iPad")
and things now work properly in the simulator. (It was trying the iPhone picker by mistake, when using the iPad emulator.)

Also, I might suggest perhaps doing up two example apps with this:

- UIKit demo - Do a version of the test project that does the same thing (buttons, webview, etc.) to show how the common UI elements are used, but from wax rather than UIKit. (Maybe their tableview example, too.)

- One of the getting started tutorials, http://mobile.tutsplus.com/tutorials/iphone/iphone-wax-part-2/ would be interesting if tweaked to work with Gideros/wax.

I assume for the latter, we ignore the AppDelegate.lua stuff and use getRootViewController() instead.

Finally, I don't suppose there's a way to have errors passed back to Gideros Studio, rather than crashing the player?

Ok, thanks for that fix. I pushed it to GitHub.

Re: the demos. I'm currently writing a turn-based gaming demo using GameKit because I need this for the game I'm really meant to be working on (yes, I have to get down to some "real" work sometimes). I will hopefully have this ready in the next day or so. There'll be plenty in there to act as a further BhWax tutorial and I'll publish it on my blog.

I agree that someone could redo the UIKit demo but I haven't got time to do it myself, I'm afraid. Also, I am aware that several people here, most notably Mike Hart and Carnite, have put a lot of work into that plugin (I still don't understand how it all works inside) and I didn't want to suggest, or assume, that BhWax would necessarily usurp it.

The "iphone-wax-part-2" tutorial is also an interesting candidate and I did consider porting it for a time. I didn't do it for the following reason. It seems to me that there are two distinct uses for Wax. The first is as a generic plug-in replacement for typical Gideros applications. By this I mean, you write a normal Gideros 2D graphics app/game and, when you find a native iOS feature that you need, you implement this with some Wax calls. I'm completely convinced that this is a valid way to go, since I can't really seen any disadvantages to it.

The other use has also been hinted at; to use this as a means to a rapid application development environment for iOS, where nearly all the coding is done as Cocoa calls from Lua. Now, I think this idea, needs more investigation because there may be speed issues which we haven't seen yet (just calling out to UIKit elements isn't going to cause any speed bumps, whereas writing Cocoa loops in Lua may do).

Anyway, for those who want to try this latter RAD approach, yes, ignore the AppDelegate.lua stuff and hang off the getRootViewController().

With regard to errors, what I've seen is that not all of them will actually crash the player. Most of the time I've seen the Gideros app exit back to the player as it does with normal Lua. However, I think there is certainly a problem with crashing if you get any error at all inside a Wax callbac into Gideros. I think it may need somebody with a bit more knowledge of (and access to) the internals of the Gideros player (@atilim?) to be able to trap these successfully.

best regards

bowerandy · September 2012

BTW, has no one noticed the cocoa_annot.txt file inside the BhWax distribution?

Best regards

atilim · September 2012

cocoa_annot.txt whoa! @-)
(I'll give more information about internals)

bowerandy · September 2012

@atilim, yes I guessed at the api file structure and it so it only does a partial job (it is better than nothing) but it's not quite right. To recreate, load the other project in the BhWax folder.

Best regards

atilim · September 2012

I've looked at Autocomplete.lua and it's impressive!

Once, I wanted to directly bind Objective-C runtime functions https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html to Lua as a plugin. But I haven't got a chance to implement it.

Anyway, wax is much more easy to use.

bowerandy · September 2012

@atilim, if you can provide more details about the .api file and how the autocomplete in the IDE works, I might be able to improve on the cocoa_annot.txt file contents. Alternatively, the method AutocompleteGenerator:formatAutocompleteSelector() can be rewritten any way you like to alter the file contents.

I'm currently running with the (huge) .api file right now and it works well enough. Because there are so many match possibilities it makes finding shorter sequences a bit harder but it really helps with those long Cocoa names.

One idea that occurs to me is that, if the IDE were to display the shorter matches first, then one would be able to choose a partial match (by hitting enter), then type some more to narrow down the search even further.

best regards

ar2rsawseen · September 2012

@ar2rsawseen, have you seen this? https://github.com/mkottman/AndroLua
This is perhaps the Android version of Wax, so all Android users can rejoice and perhaps use this.

@OZApps From the description, AndroLua uses LuaJava:
http://www.keplerproject.org/luajava/
https://github.com/jasonsantos/luajava

Also @alexzheng posted this link: http://code.google.com/p/jnlua/

Both seem good solutions.

Problem with them seems to be that they are interpreting lua on the Java side, basically allowing to load and run lua file or code in Java, whereas in Gideros we need something that can be called from lua.
But maybe I'm misinterpreting something, because I didn't have enough time to dive deeply into it.

alexzheng · September 2012

It's amazing for the autocomplete!
I can not wait to try it, however,I can not see clearly what you did in the video,Is the final xcode project for giderplayer or a simple step to step tutorial to setup the project available?

bowerandy · September 2012

Hi @alexzheng, what is it in the video that you can't understand? I tried to make it quite clear what to do. Have you tried watching it full screen?

best regards

alexzheng · September 2012

which files have you dragged into the xcode project?

alexzheng · September 2012

OK,I setup it up according the orignal wax project, now the player can run the imagepicker demo.

alexzheng · September 2012

Perfect for both the two demos.
But a little pity, hardcoded postion of the views will not scale for different screen as other sprites, these views are out of control of the scale mode of gideros.

OZApps · September 2012

@Andy, any ideas on how the selectors are used? In the sense selectors are strings and how do we get Lua functions to be used as selectors?

bowerandy · September 2012

Hi @OZApps. I'm not quite sure what you mean. Can you give an example of what you want to do?

best regards

OZApps · September 2012

@selector(myFunction)

or

addTarget_action_forControlEvents(self, HERE, UIControlEventType)

basically the callback functions or the selector functions.

bowerandy · September 2012

@ozapps, I see what you mean. Well, normally you don't need to use @selector() if you are passing a selector as a parameter. It isn't a real function anyway, just a compiler directive that has no equivalent in Wax. You can just pass a Lua string and Wax will convert it automatically to a selector. It can do this because, internally, Wax knows the expected types of all parameters.

If you want to call a selector dynamically you can also do:

myObject:performSelector("selector")

Or

myObject:performSelector_withObject("selector:", param)

Best regards

OZApps · September 2012

Uhhh! I have spend too much time with Lua, I forgot that... Thanks Andy..

fixed...

OZApps · September 2012

the reason this came up was I tried the function name as string for the switch and slider first and the callbacks did not work, where as it works for most of the controls, it does not work with a switch control

function theFunc(sender) 
	print("called")
end 
 
switch = UISwitch:initWithFrame(CGRect(100,10,0,0))
switch:addTarget_action_forControlEvents(self, "theFunc", UIControlEventValueChanged)
getRootViewController():view():addSubview(switch)

OZApps · September 2012

@Andy, did you try the AddressBook, I tried the ABAddressBookCreate() only to give me an error that it was not found. Any ideas??

bowerandy · September 2012

HI @ozapps, I'm in the middle of something right now that is making my head hurt so I can't test this out for you but..

One thing that occurs to me is that the target object you pass to that addTarget method must be an ObjectiveC class not just a normal Lua class. To create such a class using Wax you need to use the waxClass() function. Also, if function takes one argument then it's selector should be "theFunc:" and not "theFunc".

best regards

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