UIKit Issue?

ljp1203

Hi All!

I need help with UIKit by @MikeHart .

I am also using SceneManager by @ar2rsawseen .

Now the issue I am getting is that every time I click on the button it doesn't change scenes at all, and I can't seem to figure out why. There are no errors whenever I run it on my iPhone.

Here is my code:

mainmenu = gideros.class(Sprite) function mainmenu:init()     --Create Event Button local createBtn = Button.new()   createBtn:setPosition(40, 200) createBtn:setSize(250,100)   --Create Event Mask createBtn:setBGImage("Images/btn1.png") createBtn:setImage("Images/btn1_over.png")   --The Actual Button and Listener createBtn:addEventListener("click", function() sceneManager:changeScene("createEvent", .25, SceneManager.overFromLeftWithFade) end)   addToRootView(createBtn)     end

Hopefully someone can help!

Thanks!
-Landon

techdojo

Have you done the basic checks - like putting a print statement inside the eventListener.
That way at least you know the function is being called correctly.

ar2rsawseen

BTW SceneManager is by @atilim

SimpleLoop

UIKit doesn't work with scenemanager as UIKit makes a new view on top of the GLView that Gideros uses to show things on the screen. Scenemanager is only programmed to move the things on the GLView not on the UIView on top.

To work around this you can in the change scene function manually remove the UIKit elements from the screen.

bowerandy

@ljp1203, did you see this?

http://www.giderosmobile.com/forum/discussion/comment/13793#Comment_13793

If you use Hot Wax rather than UIKit, then the UIKit views can interact with SceneManager quite nicely. The demo used in the video is part of the BhWax download.

best regards

ljp1203

Hi everyone!

Thanks for all the responses. I was caught in Hurricane Sandy for this past week, because I live in New Jersey on the East Coast of the United States. I was without power for 6 days, I've never seen something like that before. But luckily we were all safe, and got our power back today. So thats why I haven't been on.

Anyways, back to what were all here for :

@techdojo I have added print() statements and now its a lot easier to see if something is working or not. Thanks

@ar2rsawseen Woops, I thought it was made by you because of your website www.appcodingeasy.com . Sorry @atilim

@SimpleLoop That makes sense. I will probably be going back to BhWax because of how easy it looks and also how simple the documentation is.

@bowerandy Thanks for telling me that and I will probably go use the BhWax method rather then UIKIT method. Also, where would I find documentation for BhWax to see how to add things such as datePicker, imagePicker, textFields, etc?

Again, thanks everyone for the responses, and sorry I was a little late to answer.

Thanks!
-Landon

OZApps

@ljp1203, glad to hear that you are fine. I have experienced Yasi last year (dunno if you heard of it) and know what it is specially with a cyclone/hurricane of those magnitudes and wind speeds.

Caroline

@bowerandy, @MikeHart - I haven't had a chance to use Hot Wax yet. Would it be a better solution all round to use Hot Wax rather than UIKit? Or is UIKit still better for a quick solution?
If UIKit is completely superceded by Hot Wax, then I would like to update the ReadMe for the UIKit plugin.
Also, is it "Hot Wax" or "BhWax"?

OZApps

@Caroline,
Using Wax opens up the entire iOS API to Lua. BhWax is the modified version of Wax by Andy from BowerHaus, so he has called the project BhWax, but the code name is HotWax.

With BhWax, you might have seen a couple of posts on my site howto.oz-apps.com on how you can access some advanced features in the iOS API without doing much, including using TV Out, Facebook, Twitter, all of UIKit, Camera, etc.

Most importantly, there is practically no code to maintain, the only thing is updating every new version of the Gideros Player with the plug-in.

bowerandy

@Caroline, the module name is "BhWax", which is the name I initially chose for the project since all my libraries begin with "Bh" (for Bowerhaus). However, I later thought of the name "Hot Wax" but didn't think it was worth changing all the existing code and videos so the two names remain.

As @OZApps says, the wax stuff opens up all of the iOS API so, in a sense, it does supercede the UIKIt plugin. However, there are a couple of reasons why I think the plugin should probably continue:

1) In writing any code it is important to understand what one is doing, even if it is only a couple of lines. To use Hot Wax you do have to know something about Cocoa and ObjectiveC. For many this might be a little overwhelming (even though wax disguises the unpleasantness of things like memory management). The plugin is targetted to specific features and exposes them in a Gideros friendly way, so some people may feel more comfortable using this.

2) The UIKit plugin is a direct binding over the iOS API so is unlikely to break with future versions and, even if it did, would be relatively easy to fix. Hot Wax, on the other hand, is quite a complex interface layer based on Corey Johnson's original Wax code. As far as I can tell, Corey is not really maintaining this code anymore. There could arise a situation in future where iOS 7 (or 8 or 9) breaks the Wax layer and, even with the full source, it might be difficult to fix it.

I'm not saying this will happen, but it could. The library has been about since iOS 4 and has not broken so far. I managed to add some code to pass Lua functions as Objective C blocks (which was something introduced in iOS 5, I think) but it was quite tricky to do.

So for me, will continue to use Hot Wax rather than UIKit plugin. I found I was constantly adding little enhancements to the plugin to do extra stuff and Wax avoids this but I'm used to ObjC anyway. However, from your perspective, I don't think I'd phase out the plugin unless you really want to.

best regards

Caroline

Right - thanks. I've updated the github ReadMe for UIKit to point to your blog, @bowerandy, and also your post.

OZApps

@Andy, actually though Corey is not maintaining this code, he is now working for GitHub, so there could be a possibility that he might fix it (if the need arises). Another point is that he has some code that is already pre-compiled in byte format (reminds be of the days when most source code contained DATA statements followed by numbers for graphics, level, data, etc.

and for all we know, we might be able to use other tools like tolua, swig etc to expose the Objective-C classes to Lua.

I believe the incompatibility might not come from the newer version of iOS but from the newer version of Mac OS, specially if Apple discontinue Intel processors and start with ARM processors.

However till then, I recomend HotWax to every one that wants to use Gideros and iOS.

ljp1203

@OZApps @bowerandy

I am going to be using Parse as my Backend Service for my app. I wanted to know if I should use Hot Wax or UIKit to accomplish this as I will need some native widgets to make a login screen, etc?

Also, would I use the iOS API shown here: https://parse.com/docs/ios/api/

Or

Would I use the REST API shown here: https://parse.com/docs/rest

Thanks
-Landon

OZApps

@Landon,
If it has a REST API, then that would be the option for you. Wax is a good wrapper on UIKit however it is not a gateway to objective-C to Lua. Many structures and functions are not available or exposed.

ljp1203

@OZApps

How would I add, for say, a date and time stored on the Parse server with the REST API and Wax?

Thanks
-Landon