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.
Related
I am in possession of a dictionary application (takes in text as input, outputs definitions + grammar analysis). I have all the source files (about 50 pages of code), written in Ada, as well as Windows and Unix executables. I want to be able to use this dictionary in an iOS app.
I'm not at all familiar with Ada, so my question is, in a nutshell—are there any shortcuts to somehow wrap the application and use it on iOS? Or is the only way just re-writing the entire application in C/Objective-C?
Shark8 mentioned JVM-targeted Ada. ACT sells a version of Gnat that targets the JVM. However, I do not believe iOS devices currently run Java. Apple does not want to lose control of the platform, so they do not allow any development environments other than their own, which is Objective C based. I understand the Java folks are working to fix this, but even if they do Apple will probably refuse to allow any such app into their online store. Note that this is not a problem unique to Ada. Any app written in any language other than C or Objective C has the same problem with iOS. (This is one of the many reasons why developers tend to prefer to target Android platforms than iOS).
So what you really need is something that can get your code compilable with Apple's Objective C compiler. Supposedly Objective C is a strict superset of C. If this is true for Apple's implementation, then an Ada compiler that outputs compilable C sources should do the job for you.
Fortunately, there is such an Ada compiler (or at least there used to be). AdaMagic at one point had C available as a "target". It is now sold by SofCheck. When last I saw a discussion of it years and years ago, they referred to it as a "service" as much as a compiler, so it may not be cheap. But if you have a real business need, it would certainly be cheaper than spending man-years rewriting a working app.
Your other option of course would be to say "Screw Apple and their facist OS", and shoot for Android instead. Sadly, for business reasons, that may not be feasible. :-(
Update (2016/2012): The assets of SofCheck have become available from AdaCore, as the two companies have merged in early 2012.
I want to be able to use this dictionary in an iOS app.
Well, if there is an Ada compiler that targets iOS -- and there probably is considering that GCC has an Ada front-end -- then re-using the packages should be straight-forward so long as the source isn't compiler- (for a different compiler) or architecture-specific.
The most experience I have with porting Ada to other architectures was to port some code I had compiling to the native machine to the JVM (there's an Ada compiler which targets the JVM); the "gotchas" were more along the line of the JVM's case-sensitivity interacting with Ada's case insensitivity for naming classes and packages.
I'm considering writing an app for both platforms, but the iPhone app must be bug-free and on time, so I want to write it first. I have no experience with either platform.
It would appear to be that applications written for Android in Java can be converted (imperfectly) to Objective C using XMLVM, after which one could fix it up and make it work with a lot less work.
My question is, can it be done the other way around? I don't see a theoretical reason why it can't, but I haven't found anything that suggests that it's been implemented. (Of course, I'm not fixated on XMLVM; if there's a different solution, I'd be happy to use it.)
Looks like it can't be done.
XMLVM converts bytecode (JVM bytecode, .NET bytecode, or Ruby YARV bytecode) to several different languages, including Objective C. It can't convert Objective C source or compiled code.
This question is related to one of my others about C: What can you do in C without “std” includes? Are they part of “C,” or just libraries?
I've become curious lately as to what is really contained the the core Objective-C language, and what parts of the Objective-C I've done for iPhone/OS X development is specific to Apple platforms.
I know that things like syntax are the same, but for instance, is NSObject and its torrent of NS-subclasses actually part of "standard" Objective-C? Could I use them in, say, Windows?
What parts are universal for the most part, and what parts would I only find on an Apple platform?
If you want, giving an example of Objective-C used elsewhere as an example of what is more "universal" would help me as well.
Thanks! =)
There are only two current implementations of the core Objective-C libraries, previously known as the NextStep (hence NS prefixes) and OPENSTEP: GNUStep and Apple's OS X. On Linux, if you maintain compatibility with the OPENSTEP specification, GNUStep works very well. However, the specification is ancient, and modern code for OS X will likely not work correctly (especially in the UI area). The situation on Windows is even worse.
You can use the Objective-C language anywhere GCC supports the build target. The "NS" classes are not part of the language proper.
If you're trying to maintain compatibility across platforms in your code base, stick to C or C++, only move UI specific behavior to Objective-C.
Objective-c is C plus these keywords:
#interface, #implementation, #protocol, #end, #private, #protected, #public, #try,
#throw, #catch, #finally, #class, #selector, #encode, #"string", #synchronized,
#property, #synthesized
Plus the message sending syntax: [anObject aMessage];
EDIT
Given that you have an objective-c compiler such as GCC you still need an Objective-c runtime in order to make the above stuff work. e.g. [anObject aMessage] is actually compiled to
objc_msgSend( anObject, #selector(aMessage));
...therefore the symbol objc_msgSend is one of several that must exist at runtime. In theory this could be provided by a compiler intrinsic but in practice you are probably going to link to an Objective-c runtime library - a quick search of my hard drive shows i have three installed:- Apple's, GNUStep, and Cocotron - there are more but Apple's (open source) is without doubt the most important and influential.
With an Objective-c compiler and runtime - but without any Apple Objective-c frameworks (NSObject, etc.) - you have a fabulous and very useful C-with-Classses that is much simpler (where simpler means 'better for me') than C++.
You can a lot on Windows using Cocotron, which is a free implementation of Apple's frameworks. It's not complete, and you may run into bugs, but if you're lucky, you can compile your Xcode project as a Windows app without too many changes.
None of the class library is part of the language itself. If you want to see the core Objective-C types, look in include/objc. The core language itself, without any added library, is really scant and not particularly useful.
In practice, however, Objective-C is just about never used outside of the context of an OpenStep framework like Cocoa or GNUstep. So you could view that as the de facto standard library, in which case Foundation is almost universal. (Not 100% of Foundation is that way, but the majority is.)
Now that monotouch is banned, I was wondering if there is a way to translate C# (or some other language) into Objective-C? I won't mind using Apple's API as long as I don't have to declare my variables in 3-4 stages (ivar-property-synthesize-dealloc). All I want is a less wordy language, to concentrate on my intent and not on the compiler syntax.
You should pause to see what actually happens instead of assuming Monotouch is banned.
Or, learn Objective-C. It's good for the mind to learn a new language anyway. And the frameworks will make more sense to you.
You could always define your own meta language for objects, write your intended meaning, parse that file, and paste the newly manufactured code into XCode.
And if you're really dead-set against ObjC and XCode, Apple has given you your ultimatum: use it or leave.
If it turns out the way people are suggesting it will turn out, then the answer to your question doesn't actually solve your problem.
The SDK agreement make specific mention to the 'originality' of the Objective-C (and other languages). Translating from C# to Objective-C breaches this requirement that applications be originally written in Objective-C.
Secondly, Monotouch already supports full AOT compilation.
Translating would be against Apples policy because your code must be originally coded in C, Obj -C, C++.
Coming from originally learning Java its really not that hard. Is the declaration of variables in multiple places really your main objection? Its easy to do and gives you tight control over your program. It is also suspected that iPhone OS 4 needs native code to be able to multitask properly. It makes sense as well otherwise they would of amended the current licence agreement if they wanted to stop Adobe.
This is something I wrote last year and may help you with the transition - Objective C by example for a C# developer, assuming Monotouch is actually forbidden.
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.