Basic LocalNotifications functionality

[zaddok]

This code allows creating on device local notifications (Notifications that do not need a remote server of any type). I have completed basic testing and it works for my personal use case. Callbacks are made using call_deferred which I suspect might help avoid multi threading issues, but I am not sure.

Please feel free to merge it into your main branch. This code is released to the public domain on the condition that people who use or share the code maintain a license that makes it clear this code is not guaranteed/warranted to work. (MIT or comparable)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

[rktprof]

Thank you for this!

I added some comments, feel free to argue against me. And if you don't have the time to fix it it's not a problem as I can take a look later

[rktprof]

I don't think we should use underscores for the parameters in @callable functions, it makes no difference for godot and if called from within swift it's better to have either proper names or just use the variable name, I generally try to replicate what the API calls them if available

[rktprof]

Minor but it's always better to use // or /// comments. Because if you are searching through a project you immediately see that a line starts with // whereas that is not the case with /** */ as that comment can start and end anywhere around the line you search for

Most editors have a shortcut to comment/uncomment blocks of code, in VSCodium it's cmd/ctrl + k + c and cmd/ctrl + k + u to comment and uncomment respectively

[zaddok]

I was just copying the style of a page explaining how to create swift documentation style comments. I found another page from apple on this, so I'll update to to follow https://www.swift.org/documentation/docc/writing-symbol-documentation-in-your-source-files

[rktprof]

I would probably use GD.pushError() to handle errors, unless the error is sometimes expected, in which case I would use GD.pushWarning() instead. Even though it doesn't matter as much if you can't test it in the editor

[zaddok]

I was using GD.print() to cause information to display in the Xcode console, to allow debugging/testing inside Xcode. I'll remove most of the print statements, except for true errors that we would would want to see in the Xcode console.

[rktprof]

GD.pushError also show up in the Xcode console with a big "USER ERROR" in front, I'm not sure about GD.pushWarning but I assume it's similar so I would keep those around for when needed

[rktprof]

Using callDeferred is nice and simplifies things on the Godot side, but it might be better to return an error value if something fails so the user can react to the problem. The standard Godot way is to return 0 as an ok and >0 for errors.

You should be able to use onComplete.bind() / bindv() to add parameters even though callDeferred doesn't take any.

I fell back to using callv() because I didn't get the .bind() functions to work, it might be a bug in SwiftGodot or I did something wrong, will investigate on my end as using callDeferred is probably preferred

[rktprof]

Could this be made more general to schedule X days into the future instead of always just tomorrow?

[zaddok]

oops, i didn’t mean to submit this. that was meant to just be a helper for me. but maybe it’s a good idea to keep it and generalize it.

[rktprof]

Since it looks like the scheduling takes seconds in order to schedule, it would be nice to remove the use of the Date class so the extension doesn't depend on Foundation anymore

[zaddok]

All good comments, i’ll have a look at this tomorrow. My main reason for wanting to use call deferred and force fetching of results (instead of returning a value directly), is to avoid “Mysterious thread issues.” In the past I had some cases of occasional iOS crashes in my apps that only occurred while running on the phone. It was super difficult to debug because it only occurred on phone, so i never got to the bottom of it. Using deferred solved this and i don’t know why. (this was using godot rust though, not godot swift)

This call deferred solution forces the main tread to read a value from the already completed node, whereas a normal call results in your thread trying to call a node that could be being used by the main thread.

[rktprof]

Yeah, ideally we should use callDeferred() with .bind() or bindv() which is supposed to work but currently doesn't, so I'm using an intermediate file in GDScript that takes the information returned from the swift classes, convert it into typed GDScript and then goes through call_deferred in order to bring it to the main thread.

[rktprof]

Good news about callDeferred, we can now use it with parameters migueldeicaza/SwiftGodot#491 he even gave us a variable amount of arguments directly on the call so onComplete.callDeferred(Variant(OK), Variant(result)) now works.

One gotcha that remains though is that to receive the callback you always need to have the same amount of arguments, so you might have to send onComplete.callDeferred(Variant(ERROR), Variant()) in order for it to go to the same place in godot

Currently in the process of cleaning up the callbacks in the other scripts