Codea Team,
I had a Flic bluetooth wireless button from Shortcut Labs,
I’m interacting and testing it with CODEA without Success.
I run an Innovation and Design Labs and I’d like to develop taylor made use cases, demonstrations and taylor made solutions using CODEA and FLIC in iPad.
I’d love use FLIC in conjuction with CODEA. How CODEA can help me to do that ?
Regards, Fernando Lemos.
Codea doesn’t support Bluetooth. If you want to code for Bluetooth on iPad I’d suggest either
If you really have your heart set on using Codea, you could always get your hands on an arduino or a raspberry pi with both Bluetooth and Wifi modules and use either one to translate the Bluetooth signals through a socket connected to Codea, but that’s a lot of effort and @yojimbo2000’s solution is much better.
Just add
showBlueToothKey(key, value) -- Value can be a string, number or encoded table or class
readBlueToothKey(key) -- Gets BlooTooth receive key
FLIC have an iOS Native Library to interact and threat bluetooth communication, that you get access to it when install Flic App.
CODEA could interact with FLIC if someone can provide a LUA wrapping arounf fliclib, to enable it services to CODEA Program.
Do you know if it’s possible to us get CODEA to access an iOS library or do we need Simeon or Two Lives Left to do this wraping and give us through an CODEA application upgrade ?
@yojimbo2000’s solution is good, but requires native coding. To engage childreen to game programing or to quick MVP / MVS or demos, could be pretty intersting to do it in CODEA.
@TheSolderKing your suggestion would works pretty well but also requires much more additional HW and efforts to do it. Maybe Swift Playgrounds could be an alternative in the future, but will be CODEA or Swift, right ?
@yojimbo2000 and @TheSolderKing, did you see my post about FLIC and FlicLib in iOS ?
Hi @fmlemos
It would need to be added to Codea in an update - which requires bindings, a simplified and user friendly API, documentation and bug testing.
Support for the FlicLib would be significantly easier than generic Bluetooth support. Right now there isn’t a way for us to make adding niche features like this cost effective unless there is significant demand.
If we did add it I imagine (from a cursory look of the API) that the bindings would work like this:
function setup()
# if no buttons are registered to Codea then
if #flic.buttons == 0 then
-- Open the FLIC app and grab a button, then return
flic.grab()
else
setupButton()
end
end
function setupButton()
-- Check if there are any buttons registered
button = #flic.buttons > 0 and flic.buttons[1] or nil
if button then
-- Add an event handler for button clicks, make a sound and change the button color to be random
button.onclick = function(b)
print("Someone pressed button: "..b.identifier)
b.color = color(random(0,255), random(0,255), random(0,255))
sound(EXPLOSION)
end
end
end
function flic.returned()
setupButton()
end
If you were to write a Codea addon for the runtime we could potentially integrate it if the addon was stable and high quality.
Hi @John … sorry for my delay to answer, I was traveling and arrived today.
I considers this integration Flic and Codea pretty appealing from both sides and specially for customers of both like myself.
I’m interested to see this integration and I’d like to know How can I help to make it happen ?
Can you give more instructions and directions on How to build this Codea Arron and have it included in the product ?
Regards, Fernando Lemos.
Arron → Addon
The GitHub repo for Codea add-ons is here. It has a base template and 2 examples: GitHub - twolivesleft/Codea-Addons: A collection of basic Codea addons for getting started extending the runtime
You’d have to write the Objective-C bridge between the FLIC API and Codea. This would only work in Codea projects once they’ve been exported to Xcode, you wouldn’t be able to access them from the Codea app itself. For them to be be accessible from Codea, you’re dependent on the TwoLivesLeft team creating
bindings, a simplified and user friendly API, documentation and bug testing.
which sounds like a lot of dev effort to me 
It looks like the FLIC App can be configured to open a URL. In that case, you just need a code-executing program that has a URL scheme. As far as I know, Pythonista is the only one, see here: The Pythonista URL Scheme — Python 3.6.1 documentation
So the students would use Pythonista to write the script they want to be executed when the FLIC button is pressed, then you’d enter into the FLIC App the URL that runs the Pythonista script, eg pythonista://MyFLICButtonScript?action=run&args=long%20press, and the script should run on press (I don’t have the FLIC button or App, but from reading the API tutorial, it seems to work via url schemes. You’d need to check whether the app does allow custom urls to be registered. It looks like it does).
I think Lua is a slightly friendlier language for complete beginners than Python, but lots of students are taught Python as their first language (it’s certainly a much more widely used language than Lua).
Incidentally, it is possible to open Codea with a URL. The URL isn’t codea:// though, it’s db-cj1xdlcmftgsyg1:// B) However, it’s not possible to make Codea do anything like run a program from this url call. I think that asking for ?action=run support in Codea’s url-scheme would be a much better feature-request than asking for FLIC support, as url-schemes are an open and widely used standard that have multiple applications, whereas FLIC button support only targets FLIC buttons.
Finally, if you’re interested in programming robots from an iPad, have a look at this post on controlling a Sphero using Swift Playgrounds: Use iPad to Program Robots with Swift Playgrounds - Swift Blog - Apple Developer
@yojimbo2000 Pythonista does sound like it’s more suited for this kind of use-case (running a ‘script’ via url schemes) but I’m open to looking at this kind of functionality for Codea. The trick is making sure Codea can transition from whatever it’s currently doing to running a particular project. It also needs to pass in the parameters somehow, which may or may not require restarting the current project.