It looks like you're new here. If you want to get involved, click one of these buttons!
I’m lost. I learned Lua using Codea on an iPad and only code on the iPad. I don’t have a Mac so I never used Xcode. I’m assuming that objc is a way to access more lower level functions that Codea doesn’t give access to. Looking thru the Apple Developers information, there’s a lot of stuff there, but how much of it is actually useful or is very little of it useful using Codea. Just wondering.
Comments
I'm with you. There is a lot of stuff that Xcode can do on the iPad, but it's a big bite to swallow. I'm hoping for pointers as well.
@RonJeffries Just looking at some of those examples in the other discussion Codea (316) doesn’t make me want to use it. That code looks like someone just closed their eyes and started hitting keys. And then what would they get out of all that code. I guess that would be for someone who wants to do some serious coding and get down in the works. I’m just a pass the time, something to do, write some code, type of coder, nothing serious.
i think we should all test different classes to see what is available and compile a list, it would help all of us
the thing to keep in mind is the list of tech covers all aspects of apple dev, watchOS, iOS, macOS, so some things are not available like Automator, but from the things that are available we basically have access to a lot more powerful things like accessing internal device info
@skar I looked through the Development kit at the different classes and didn’t see a lot of things that might be useable (at least for me) . I’m sure as more examples are posted by those who know the objc stuff, maybe there will be useable info. I just code on the iPad and that’s just for kicks. So yes, a list of useable objc code might be useful.
I understand your concerns about the new feature. This is definitely an advanced one, opening too many doors to list and explain all of them. If you've never touched Objective-C, then this new feature will likely not make a lot of sense even with lots of documentation and examples.
The best used of the new objc feature I've done so far for my personal projects was to add Game Controller support to some of them. I can now connect my PS4 controller and play my prototypes with just a few lines of objc code that is very close to what I would have had to write in a Codea Objective-C addon.
The big advantage here is that I can write the code and test it directly in Codea, without having to export the project and writing/adding the Objective-C addon.
That being said, for this example, Game Controller support should probably be added to Codea with a simple API. But in the meantime, you can use objc if you cannot wait for it, and this applies to any other existing or future iOS features you'd like to use which has not yet been added to Codea.
It took us some time to step up to Craft so C is a step in the opposite direction and complexity..
Thanks again, now back to the docs.
@Bri_G I could definitely write a quick example using Game Controller. Maybe one scene could show virtual buttons on screen that light up as you press the different buttons or move the thumbsticks, and another scene would show how you can use this to move a sprite on the screen. What I would do is create a Game Controller tab containing all the objc code, but exposing it through an easier API.
Do you have a PlayStation or Xbox controller you can connect to your iOS device so you could play around with the example?
Would it be specific for that controller or a little more generic?
@jfperusse I agree with you and @Bri_G, this is advanced code. Instead of a good Codea example, we need a bunch of small examples that are easier to follow and understand. Also as mentioned by @skar, maybe a list of one or two lines of code that shows things. Maybe along the lines of the code below that shows how to get and set the screen brightness.
What's great about the Game Controller framework is that it is pretty generic, so the sample would work for both PS and XB controllers, yet I could include the device specific features such as the touchpad on the PS controller, etc.
My interest here is getting access to native iOS features.
I envision a text entry field that can use all the native iOS text-editing features (copy, paste, selecting, moving the cursors, etc) without any extra coding.
I can’t wait for an image-picker that can access the camera roll.
Conceivably we could invoke the standard sharing action sheet to send things to each other over text, email, or AirDrop.
And of course I’ve been working to get real-time matches working over Game Center, and this will be great for that.
That said, this is plainly a very advanced feature. Learning objective-C and the iOS APIs is outside the intended scope of Codea, I think. After all Apple has an entire website with thousands and thousands of articles devoted to that.
I see this as a niche feature mainly useful for people who already have, or are interested in acquiring, experience with the broader Apple Developer toolkits.
That said on top of that said, any features created using those tools should be of great benefit to the entire Codea community, without other folks needing to learn anything outside of Codea’s brand of lua.
Yes. I suspect we will wind up with some useful bits of code to be patched in, and of course some folks will do big amazing things. It's very cool.
@dave1707 @RonJeffries this is definitely something you can choose to ignore when using Codea
We will likely use it ourselves instead of writing libraries directly in C. It allows anyone here to prototype a new module, over which we can write a much more "Codea like" API. The game controller thing is a good example — often requested and something I haven't got around to doing. Now it can be done by anyone and they can design an abstraction over it for others to use
It has a lot potential to grow the Codea APIs by making the ability to write native modules more accessible
personally the modules i would be most interested in seeing made for use would be of course controller but that’s already pretty much been covered, but also
machine learning
bluetooth/multi peer connection
game center
javascript vm
and Dispatch
@skar good ones!
Dispatch is a tough one (likely not feasible) as the Lua VM is not thread safe, so you could not run Lua code on multiple threads.
Good stuff @Simeon, I can see how that can advance Codea rapidly. It's an exciting capability and thanks to @jfperusse for making it happen.
@John @Simeon I hate to say it but I just got the data-loss bug again.
I am using Working Copy on the project so I know for sure it was not resetting to the last committed state. The data loss appeared in Working Copy as a loss. So luckily I could just discard changes.
I think it was resetting to the previously-most-recent opened state, but I can’t be sure.
So maybe Codea detected some conflict between it and Working Copy and the project reset itself while I was actively coding?
@UberGoober @Simeon Probably this isn't related, but I've had issues with losing entire tabs in the most recent AppStore version (and prior to this). Sometimes, lines of code that are automatically wrapped because they are too long, are not shown. When pressing 'enter' at the end of the line, they sometimes reappear. However, Codea often seems to crash when trying that. Last time this happened to me. Multiple tabs were wiped entirely. Also, Codea seems to crash when using the search function and tapping on a result that's not in the current tab. This all could be due to the fact that some of the tabs I got are extremely large.
Also, thanks @jfperusse! Can't wait to try this out, this is absolutely huge!
The new objc module provides considerable Codea scalability, but requires us to learn more and more about the iOS native library.
There used to be some functionality that had to be written on the Xcode, but now it seems like we can code and debug it directly on the Codea.
Maybe the add-ons(iAds, IAP etc.) now can be written in iPad directly? It is very useful.
I've been wanting the ability to create folders directly for some time now and within a couple of hours I've got it working and WebRepo is making use of it already.
I think with the arrival of Swift Playgrounds 4, Codea now has some serious competition so this is a big step in the right direction for Codea in my opinion.
Speaking of WorkingCopy, it has been losing connections to Codea projects and sometimes cannot recover. Anders has reproduced the bug. However, it would be Very Useful if Codea projects were more like folders and less like documents, if that's a description of why WorkingCopy has to jump through its own orifice to deal with Codea ... and might also let us use other simpler approaches for Codea project version backup.
@UberGoober I'll probably drop you a private note inquiring how you have WorkingCopy hooked up and whether you ever lose connection.
@RonJeffries it seems to me it might be a useful conversation at least to some degree for John and Simeon to be able to see. Yes I lose connection often. I have Working Copy synced to Codea projects and (usually) their GitHub repos too.
Mouse & Keyboard examples using the ObjC bindings (Also available as ‘MKInput’ on WebRepo):
@Simeon It would be much appreciated if you could make preferspointerlocked available in some form so we can properly hide the cursor to avoid activating system gestures with the mouse.
Edit: Updated with preferspointerlocked & to correct for changes during beta.
@Steppers You should already be able to change the value of preferspointerlocked, but I'm not sure on which UIViewController it must be changed. Maybe try this one?
@Steppers In version 3.5 (322), it is now possible to set the value of preferspointerlocked on our view controller. I used MKInput to test and was able to toggle visibility of the cursor. Let us know if it works for you!
@jfperusse Already beat you to it
MKInput 1.1.0 (on WebRepo) already has the
hidecursor()
function.Haha nice
Hey everyone, @Steppers! Just wanted to let you know that the latest beta version includes a breaking change which will require minor modifications to your projects using objc.
In previous versions, some property getters had to be accessed through a method. The most common example was objc.cls.UIApplication:sharedApplication(), where sharedApplication is actually a property. This was because of a limitation in Objective-C reflection which does not always allow us to differentiate between a property and a method.
Thanks to @Simeon, we found a better way to support this by considering non-void, parameterless methods as properties, with the exception of new, alloc and init methods.
TL;DR, in your samples, you will need to change some code to access those properties using the dot syntax instead of the colon syntax. For example, this line from MKInput:
objc.cls.GCMouse.current.mouseInput
Note also that we've added objc.app (objc.cls.UIApplication.sharedApplication), and objc.viewer (objc.cls.UIApplication.sharedApplication.keyWindow.rootViewController
local controller = root.presentedViewController.presentedViewController).
@jfperusse Thanks, I’ll update the example I have here on the forum but WebRepo & MKInput (from WebRepo) should already be updated to work.
I had wondered why that was so took a look at NSLua but just accepted it eventually as it wasn’t too bothersome.
@jfperusse Is there any chance we can check for the presence of a property or method without displaying the warning in the output when it doesn’t exist?
For example
if mouseInput.middleButton then
displays a warning when I’m using a trackpad with no middle mouse button.I’d rather it just return nil and not mention it tbh.
That's an odd one, as the property should exist regardless of whether the middle button is supported on the device. It's declared as an optional GCControllerButtonInput in the SDK
@Steppers Do you still have the warning with 326? That's an issue I fixed last minute this morning, and I wasn't getting the warning anymore with MKInput.
@Simeon, if my Codea program is running and then i drag right from the left edge to see the code but i do not complete the action i.e. i drag the left edge back- it causes Codea to exit to the desktop.
@piinthesky Does it exit to the desktop without crashing Codea. When I do the above test on my iPad, I go back to the iPad home screen with a Codea crash popup.
Delete the WebRepo project & the folder 'webrepocache_vfs' in Codea's documents folder (using the files app) and try a fresh install again. If it's a VFS issue I suspect the cache folder has got corrupted somehow. If that doesn't help let me know.
@Simeon With version 326, it takes a long time for dependencies to open. Once it opens, scrolling thru them is very slow.
The other things under Do open immediately.
Checked different iPads.
On the iPad Air 4 it opens immediately.
On the iPad Pro 1 it takes 5 seconds.
@dave1707 thanks for the report, I made this change to fix a different but, but I was aware it could make things slow. I'll have to look into an alternate fix
@dave1707 please let me know if the dependencies behave better for you in the latest beta
@Simeon
The search/replace seems to work OK.
The yellow leftover from a search doesn’t hang around anymore.
The dependency list and scrolling looks like it’s back to normal.
Dragging a running project from the left side to the right and then back again doesn’t crash Codea.
Not sure what the Codea reference problem was, didn’t test that.
Closing WebRepo down with the top left corner X and rerunning worked OK. Thanks.
The project does usually seem to go a bit dodgy after the update so that's nothing out of the ordinary. I should probably just close the project instead.
Edit: My post is incomplete, even though I typed a lot of stuff that I won't type again.
Edit2: I realized I can't use emojis here. Everything I typed after an emoji, didn't get posted.
I'm a noob, so Obj-C is stuff I won't learn in the near future. Just wanted to let you know about the crash on launch for us, "rogue" users of the iOS ecosystem.
Thanks for this tool! I'll stick to 3.4.7 for now and see what I can learn and might as well start posting here as I make some progress, if any.
@sebgo that's odd! We didn't really do anything to change the way Codea starts up. I don't suppose you had access to a crash log or anything we could trace with
But, Codea/iPad didn't issue a crash report. Do you expect that from excessive memory demands?
@Bri_G iOS doesn’t consider an ‘Out-Of Memory’ crash a crash per-se.
As far as iOS is aware, the App just uses too much memory so it kills the process. No crash report is created for that.
The only thing Codea could really do about that is to identify at launch if the app was closed in an unexpected way during the previous session. I’ve spent a lot of time in the past working on something like this for some resource heavy iOS games and it’s not the most reliable.
iOS issues ‘Low Memory’ events to an application when they near the limit but often with games it’s difficult to process and react to those in time when the memory usage spikes during resource loading. By the time the app processes the event it can already be too late and the OS has killed the process.