For an App that is not going to be released on the AppStore I'm looking to embed an interpreter for easy scripting needs. Since I don't really like to get down with pure C, the interpreter should be an Objective C library.
While searching the web I've come across a couple of script interpreters for Objective C but whether those guys work on iPhone is not quite so clear. The one I found that apparently works well on iPhone is LuaCore which brings Lua scripting to iOS Apps.
Which Objective C scripting interpreters have you successfully embedded in iOS Apps?
Some Javascript options:
Using a headless WebKit instance
Instantiate a custom build of JavaScriptCore
CouchBase's attempt at getting SpiderMonkey running (more modern Javascript than V8)
Notice that the JS option will provide with a quite raw runtime environment, you'll probably need to write at least some of it yourself for it to be a convenient development environment.
Other languages:
An attempt with Python.
Clojure by way of a static build of JavaScriptCore (see point 2 above).
The Nu language is also supposed to integrate well, and have a good Objective-C bridge.
I have only tried the first headless WebKit variant for Javascript, but plan to try as many of those listed as possible for a project during the coming months.
Update:
I've used the Javascript method 1 (headless WebKit) a bit longer. I got it running quite effortlessly, and will stick with that for a while. But it has a huge drawback: you can't call back to native in an easy manner. I solved this by writing a PhoneGap inspired bridge that empties a command queue after the script has run.
I've also tried Python using the link I gave. I made it compile and execute some sample code, but it suffers from the same problem as using Js via headless WebKit, and since it consumes quite a bit of memory I skipped it for now. A callback command queue in the same spirit as the one I created with Js would be possible though. Another Python method would be to attempt to call into the Objective C runtime using ctypes. That approach is described in this answer.
Update 2: Here are several new(ish) links for running Scheme, with both interpreter and compilation options.
I just stumbled upon a really decent description by Twitter user #mysterycoconut of how to get Lua support up and running.
Just discovered a post regarding scripting on iOS at answerspice.com.
Based on the post I evaluated Nu and had it up and running pretty quickly based on the Xcode project referenced in this discussion (thanks Tim!). I tested in the simulator and on an iPhone 4. So Nu is definitely among the scripting languages that can be embedded in an iOS App.
Related
I have integrated Lua with my ObjC code (iphone game). The setup was pretty easy, but now, I have a little problem with the bridging. I have googled for results, etc... and it seems there isn't anything that could work without modifications. I mean, I have checked luaobjc bridge (it seems pretty old and dicontinued), I heard about LuaCocoa but it seems not to work on iphone, and wax is too thick.
My needs are pretty spare, I just need to be able to call objc methods from lua and don't mind having to do extra work to make it work (I don't need a totally authomatic bridging system).
So, I have decided to build a little bridge myself based on this page http://anti-alias.me/?p=36. It has key information about how to accomplish what I need, but the tutorial is not completed and I have some doubts about how to deal with method overloading when called from lua, etc...
Do anybody know if there exist any working bridge between objc and lua on the iphone or if it could be so hard to complete the bridge the above site offers?
Any information will be welcomed.
Don't reinvent the wheel!
First, you are correct that luaobjc and some other variants are outdated. A good overview can be found on the LuaCocoa page. LuaCocoa is fine but apparently doesn't support iPhone development, so the only other choice is Wax. Both LuaCocoa and Wax are runtime bridges, which means that you can (in theory) access every Objective-C class and method in Lua at the expense of runtime performance.
For games and from my experience the runtime performance overhead is so significant that it doesn't warrant the use of any runtime binding library. From a perspective of why one would use a scripting language, both libraries defy the purpose of favoring a scripting language over a lower-level language: they don't provide a DSL solution - which means you're still going to write what is essentially Objective-C code but with a slightly different syntax, no runtime debugging support, and no code editing support in Xcode. In other words: runtime Lua binding is a questionable solution at best, and has lots of cons going against it. Runtime Lua bindings are particularly unsuited for fast-paced action games aiming at a constantly high framerate.
What you want is a static binding. Static bindings at a minimum require you to declare what kind of methods will be available in Lua code. Some binding libraries scan your header files, others require you to provide a special declaration file similar to a header file. Most binding libraries can use both approaches. The benefit is optimal runtime performance, and being able to actually design what classes, methods and variables Lua scripts have access to.
There are but 3 candidates to bind Lua code to an iPhone app. To be fair, there are a lot more but most have one or more crucial flaws or are simply not stable or for special purposes only, or simply don't work for iPhone apps. The candidates are:
tolua and tolua++
luabind
SWIG
Big disadvantage shared by all Lua static binding libraries: none of them can bind directly to Objective-C code. All require to have an additional C or C++ layer available that ultimately interfaces with your Objective-C code. This has to do with how Objective-C works as a language and how small a role it has played (so far) when it comes to embedding Lua in Objective-C apps.
I recently evaluated all three binding libraries and came to enjoy SWIG. It is very well documented but has a bit of a learning curve. But I believe that learning curve is warranted because SWIG can be used to combine nearly any programming and scripting language, it can be advantageous to know how to use SWIG for future projects. Plus, once you understand their definition file implementation it turns out to be very easy (especially when compared to luabind) and considerably more flexible than tolua.
OK, bit late to the party but in case others come late also to this post here's another approach to add to the choices available: hand-code your LUA APIs.
I did a lecture on this topic where I live coded some basic LUA bindings in an hour. Its not hard. From the lecture I made a set of video tutorials that shows how to get started.
The approach of using a bindings generation tool like SWIG is a good one if you already have exactly the APIs that you need to call written in Objective-C and it makes sense to bring all those same API's over into LUA.
The pros of the hand-coding approach:
your project just compiles with one standard Xcode target
your project is all C & Obj-C
the LUA is just data shipped along with your images
no fiddling with "do I check in generated code" to Git
you create LUA functions for just the things you want
you can easily have hosted scripts that live inside an object
the API is under your control and is well known
dont expose engine APIs to level building team/tools
The last point is just that if you have detail functions that only make sense at the engine level and you don't want to see those when coding the game play you'll need to tell SWIG not to bind those.
Steffens answer is perfect and this approach is just another option, that may suit some folks better depending on the project.
I currently have the need to execute prolog code in an application I am making. I am aware that Apple probably never would allow something like this in the App Store, but that is not the intention either. This is more a private project that will never reach the App Store.
Purpose
In this case prolog is used to describe an object (like for example a telephone) and its properties. The object will be drawn with OpenGL using coordinates specified in the prolog script. The reason for using prolog is that I need the ability to query the program about some of the features this object has, and prolog eases this a lot. Bottom line: I "need" to query a prolog script from my app.
Possible solutions
Embed an already existing implementation written in C. I am unsure if this will even work.
Execute the prolog code on another machine and use the network to query prolog.
It seems that it is possible to run some sort Ruby VM inside the app (shinycocos uses this as far as I understand), could this be used to run one of the Ruby Prolog implementations?
Find some alternative to Prolog. This needs to give me some of the same possibilities I get with prolog.
Sadly, google gives me close to no results at all, so I have a feeling that I might be quite alone on this project. If anyone have any experience or clue at all, I would be very thankful.
Having faced similar difficulties calling prolog code, albeit in a different situation, I'd recommend checking out the castor c++ library. This allows you to write logic paradigm code in native c++ without needing to extend the language at all. As castor is a header only library it is easy to compile wherever c++ is available.
Castor website: http://www.mpprogramming.com/cpp/default.aspx
Half a year later, I would just like to provide some insight on this. I ended up writing a server with an interface to prolog in Java, accepting prolog calls through TCP. It works almost exactly like the live prolog interpreter SWI-prolog (among others) provides, and mostly works quite well. However, it is far from an optimal solution, as you can't call functions from inside prolog. You lose the possibility of having two-way communication.
If I were to start all over again, I would certainly have tried harder to compile one of the pure C implementations for iOS. I gave it a quick go, but my lack of experience stopped me from even removing all of the errors I got. Judging by the fact that you cannot have prolog running as a background process on a unmodified version of iOS as well, some major rewriting would have to be done. Because of this, one might just have to write a new implementation (perhaps inspired by some of the more lightweight ones out there) from scratch to get the perfect solution.
You can download SWI-Prolog's source code and compile it with XCODE for iOS platform. I've never done that, but it's certainly technically possible.
Once you do that, there are a lot of examples on how to run prolog code from C/C++, hence, you will be able to run prolog from Objective-C.
FYI, you can quite easily bi-directionally make calls between Java and SWI-Prolog if you use JPL:
http://www.swi-prolog.org/packages/jpl/
It is also fully re-entrant, so you can instantiate prolog code from java, which in turn instantiates java code etc...
I did this for a number of commercial projects a few years ago when I was required to connect a Prolog based Reasoning Engine to a lot of Java code.
It does use JNI (the Java Native Interface), so you need to be careful about how you compile and link to the native api. Though if you compile it appropriately for each platform you can make it work cross platform. I had it working on OS-X, Windows, Linux & Solaris.
I do not know if this has been tried but there is the possibility to use the combination of NodeJS for Mobile Apps & TauProlog:
https://code.janeasystems.com/nodejs-mobile
https://github.com/JaneaSystems/nodejs-mobile
and
http://tau-prolog.org/
I'm moving away from strict Android development and wanting to create iPhone applications. My understanding is that I can code the backend of iOS applications in C/C++ and also that I can use the NDK to include C/C++ code in Android apps. My question however is how? I've googled quite a bit and I can't find any clear and concise answers.
When looking at sample code for the NDK, it seems that all the function names etc. are Android (or at least Java) specific and so I would not be able to use this C/C++ backend to develop an iPhone frontend?
I'd appreciate some clarification on this issue and if at all available some code to help me out? (even just a simple Hello World that reads a string from a C/C++ file and displays it in an iOS and Android app).
Thanks guys
Chris
Note that I almost exclusively work on "business/utility/productivity" applications; things that rely heavily on fairly standard UI elements and expect to integrate well with their platform. This answer reflects that. See Mitch Lindgren's comment to Shaggy Frog's answer for good comments for game developers, who have a completely different situation.
I believe #Shaggy Frog is incorrect here. If you have effective, tested code in C++, there is no reason not to share it between Android and iPhone, and I've worked on projects that do just that and it can be very successful. There are dangers that should be avoided, however.
Most critically, be careful of "lowest common denominator." Self-contained, algorithmic code, shares very well. Complex frameworks that manage threads, talk on the network, or otherwise interact with the OS are more challenging to do in a way that doesn't force you to break the paradigms of the platform and shoot for the LCD that works equally badly on all platforms. In particular, I recommend writing your networking code using the platform's frameworks. This often requires a "sandwich" approach where the top layer is platform-specific and the very bottom layer is platform-specific, and the middle is portable. This is a very good thing if designed carefully.
Thread management and timers should also be done using the platform's frameworks. In particular, Java uses threads heavily, while iOS typically relies on its runloop to avoid threads. When iOS does use threads, GCD is strongly preferred. Again, the solution here is to isolate the truly portable algorithms, and let platform-specific code manage how it gets called.
If you have a complex, existing framework that is heavily threaded and has a lot of network or UI code spread throughout it, then sharing it may be difficult, but my recommendation still would be to look for ways to refactor it rather than rewrite it.
As an iOS and Mac developer who works extensively with cross-platform code shared on Linux, Windows and Android, I can say that Android is by far the most annoying of the platforms to share with (Windows used to hold this distinction, but Android blew it away). Android has had the most cases where it is not wise to share code. But there are still many opportunities for code reuse and they should be pursued.
While the sentiment is sound (you are following the policy of Don't Repeat Yourself), it's only pragmatic if what you can share that code in an efficient manner. In this case, it's not really possible to have a "write once" approach to cross-platform development where the code for two platforms needs to be written in different languages (C/C++/Obj-C on iPhone, Java for Android).
You'll be better off writing two different codebases in this case (in two different languages). Word of advice: don't write your Java code like it's C++, or your C++ code like it's Java. I worked at a company a number of years ago who had a product they "ported" from Java to C++, and they didn't write the C++ code like it was C++, and it caused all sorts of problems, not to mention being hard to read.
Writing a shared code base is really practical in this situation. There is some overhead to setting up and keeping it organized, but the major benefits are these 1) reduce the amount of code by sharing common functionality 2) Sharing bug fixes to the common code base. I'm currently aware of two routes that I'm considering for a project - use the native c/c++ (gains in speed at the expense of losing garbage collection and setting targets per processor) or use monodroid/monotouch which provide c# bindings for each os's platform functionality (I'm uncertain of how mature this is.)
If I was writing a game using 3d I'd definitely use approach #1.
I posted this same answer to a similar question but I think it's relevant so...
I use BatteryTech for my platform-abstraction stuff and my project structure looks like this:
On my PC:
gamename - contains just the common code
gamename-android - holds mostly BatteryTech's android-specific code and Android config, builders point to gamename project for common code
gamename-win32 - Just for building out to Windows, uses code from gamename project
On my Mac:
gamename - contains just the common code
gamename-ios - The iPhone/iPad build, imports common code
gamename-osx - The OSX native build. imports common code.
And I use SVN to share between my PC and Mac. My only real problems are when I add classes to the common codebase in Windows and then update on the mac to pull them down from SVN. XCode doesn't have a way to automatically add them to the project without scripts, so I have to pull them in manually each time, which is a pain but isn't the end of the world.
All of this stuff comes with BatteryTech so it's easy to figure out once you get it.
Besides using C/C++ share so lib.
If to develop cross-platform apps like game, suggest use mono-based framework like Unity3D.
Else if to develop business apps which require native UI and want to share business logic code cross mobile platforms, I suggest use Lua embedded engine as client business logic center.
The client UI is still native and get best UI performance. i.e Java on Android and ObjectC on iOS etc.
The logic is shared with same Lua scripts for all platform.
So the Lua layer is similar as client services (compare to server side services).
-- Anderson Mao, 2013-03-28
Though I don't use these myself as most of the stuff I write won't port well, I would recommend using something like Appcelerator or Red Foundry to build basic applications that can then be created natively on either platform. In these cases, you're not writing objective-c or java, you use some kind of intermediary. Note that if you move outside the box they've confined you to, you'll need to write your own code closer to the metal.
Is there anyway to load an objective c script at runtime, and run it against the classes/methods/objects/functions in the current iPhone app?
MAJOR NOTE: The major reason I'd like to do this is to allow me to rapidly prototype an application, and then, after I'm done a major prototyping phase, take the scripts I was writing and compile them at build time instead. I don't ever plan on shipping an app with an objective c interpreter in it.
The reason i ask is that I've been playing around with iPhone wax, a lua interpreter that can be embedded in an iPhone app, and it works very nicely, in the sense that any object/method/function that's publically available in your Objective C code is automatically bridged, and available in lua.
This allows you to rapidly prototype applications by simply making the core of your app be lua files that are in the users documents directory. Just reload the app, and you can test out changes to your lua files without needing to rebuild the app in XCode - a big time saver!
But, with Apples recent 3.1.3 SDK stuff, it got me thinking that the safest approach for doing this type of rapid prototypeing would be if you could use Objective C as the interpreted code... That way, worst case scenario, you could just compile it into your app before your release instead. I have heard that the lua source can be compiled to byte code, and linked in at build time, but I think the ultimate safe thing would be if the scripted source was in objective c, not lua. That way your source is always in objective c, regardless.
This leads me to wondering (i've searched, but come up with nothing) if there are any examples on how to embed an Objective C Interpreter in an iPhone app? This would allow you to rapidly prototype your app against the current classes that are built into your binary, and, when your about to deploy your app, instead of running the classes through the in app interpreter, you compile them in instead.
With the iPad and OS 4, bluetooth and virtual keyboards can work with iPhones and iPads... That's going to make this type of rapid prototyping something much more useful, at least for dev time. If you have an interpreter built into your app and have it on your iPad, for example, you can code against the interpreter while on the road, without XCode. And to me, the most useful way to get the source back to an "apple approved" state would be if the scripts were Objective C.
Objective-C is really just C with a runtime and some syntactic sugar. It's an inherently compiled language (I don't think there are any production-ready interpreters for C, although I might be wrong).
Xcode used to have a feature called ZeroLink to speed up compile time, but removed it in Xcode 3 because it caused too many bugs.
It's not exactly impossible, but it wouldn't be easy enough to be worth it. Objective-C isn't normally an interpreted language. This isn't insurmountable — interpreted vs. compiled is just an implementation choice in most cases. For example, Ruby is traditionally considered an interpreted scripting language, but MacRuby compiles it down to code just like Objective-C produces. So it would be possible to write an interpreter for Objective-C, but nobody has done this. You would have to write it yourself.
Also, the rules forbid interpreters other than Apple's Javascript interpreter. So far this hasn't been enforced on anyone, but if you're trying to be a very straight arrow, interpreted code is unfortunately out as well.
Well, there's a couple worthwhile points to bring up:
Why interpret Objective-C code when you can compile it? I understand the "rapid prototyping" idea, but part of the reason to do that in, e.g., Lua, is because Lua is a much terser language than Objective-C. I don't know if interpreting Objective-C will have as much of a bonus.
If you want to have plugins or dynamically-loadable modules in your app, you can always compile them as a separate bundle and load them, using NSBundle or a similar mechanism.
All that said, I don't know of any Objective-C interpreters. You'd likely have to write your own. I'm not sure if it would violate Apple's guidelines or not: it'd still be Objective-C code, but I thought they had rules against interpreted code, too. (I suppose they never envisioned a hypothetical scenario in which Objective-C was interpreted, though.)
There is a basic Objective-C interpreter:
Check out the posting:
Is there an Objective-C Interpreter for the Mac?
Also:
http://forrst.com/posts/Beginnings_of_a_Objective_C_Interpreter-Tdl
Ch is a commercial C/C++ interpreter. It's made by a company called SoftIntegration.
Not on IPhone, but on Simulator, you can do this with
Dynamic Code Injection Tool
http://dyci.github.com/
There's also another tool, that works a little different way, but allows same functionality
http://injectionforxcode.com/
You should take a look at cycript. You can hook into apps, replace methods on the fly, change variables, you-name-it. It's an hybrid language between Objective-C and JavaScript.
You'll need to jailbreak your iDevice to install it.
Take a look at the documentation for objc_msgSend() and other parts of the Objective-C Runtime Reference. You can essentially parse text and send it to the runtime.
I have a little script I wrote in python and it actually works on the iPhone via the terminal. I am looking for code snippets or documentation for the GUI writing for the iPhone -
Actually what I need is to implement an input and some output.
nothing fancy - for now.
I have found this page: http://www.saurik.com/id/5
but as i understand from the article i will need to write it in objective-c which i am not familiar with - do i have to? or can i write in python or just C?
and it is very descriptive, looking for more docs...
Thanks Alot :)
You cannot write an iPhone app in Python that will run on non-jailbroken phones. Apple's SDK license prohibits interpreted code on the iPhone, which definitely excludes Python. Although you can write OS X apps in Python using PyObjC, you still need to understand the Objective-C language both for documentation and for groking the many Cocoa patterns that are closely tied to Objective-C's way of doing things.
Learn Objective-C. For a programer that knows C or C++, it takes only a couple of days to become proficient in Objective-C. If you've never used a language that has pointers before, it may take a little longer. On the flip side, embracing Objective-C's dynamic nature is much easier for developers coming from dynamic languages as opposed to statically typed languages like C/C++/Java/C#.
There is a GUI sample in that link. The whole app is written in Python with ObjC runtime (but no ObjC code involved).
Still, the ObjC "feel" cannot be avoided because UIKit is designed for and uses ObjC. Note that the GUI programmed in Python is extremely slow on the iPhoneOS. Python can be used as testing, but never release an (interpreted) iPhoneOS Python GUI app to public.