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.
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 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/
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.
I have a set of functionality (classes) that I would like to share with an application I'm building for the iPhone and for the Blackberry (Java). Does anyone have any best practices on doing this?
This is not going to be possible as far as I understand your question - the binary format for the iPhone and Java are not compatible - and even for a native library on a blackberry device.
This is not like building for OS X where you can use Java unfornately the iPhone doesn't support Java.
The best idea is probably to build you library in Objective-C and then port it to Java which is an easier transition than going the other way. If you programme for Objective-C and make sure you code has no memory leaks - then the changes are not so complex.
If you keep the structure of your classes the same then you should find maintenance much simpler - fix a bug in the Java and you should find it easy to check for the same bug in the ObjC methods etc.
Hope this helps - sorry that it is not all good news.
As Grouchal mentioned - you are not going to be able to share any physical components of your application between the two platforms. However you should be able to share the logical design of your application if you carefully separate it into highly decoupled layers. This is still a big win because the logical application design probably accounts for a large part of your development effort.
You could aim to wrap the sections of the platform specific APIs (iPhone SDK etc.) that you use with your own interfaces. In doing so you are effectively hiding the platform specific libraries and making your design and code easier to manage when dealing with differences in the platforms.
With this in place you can write your core application code so that it appears very similar on either platform - even though they are written in different languages. I find Java and Objective-C to be very similar conceptually (at least at the level at which I use it) and would expect to be able to achieve parity with at least the following:
An almost identical set of Java and Objective-C classes with the same names and responsibilities
Java/Objective-C classes with similarly named methods
Java/Objective-C methods with the same responsibilities and logical implementations
This alone will make the application easier to understand across platforms. Of course the code will always look very different at the edges - i.e when you start dealing with the view, threading, networking etc. However, these concerns will be handled by your API wrappers which once developed should have fairly static interfaces.
You might also stand to benefit if you later developer further applications that need to be delivered to both platforms as you might find that you can reuse or extend your API wrappers.
If you are writing a client-server type application you should also try and keep as much logic on your server as possible. Keep the amount of extra business logic on the device to a minimum. The more you can just treat the device as a view layer the less porting you'll have to do over all.
Aside from that, following the same naming conventions and package structure across all the projects helps greatly, especially for your framework code.
The UI API's and usability paradigms for BlackBerry and iPhone are so different that it won't be possible in most cases to directly port this kind of logic between apps. The biggest mistake one could make (in my opinion) is to try and transplant a user experience designed for one mobile platform on to another. The way people interact with BlackBerrys vs iPhones is very different so be prepared to revamp your user experience for each mobile platform you want to deploy on.
Hope this is helpful.
It is possible to write C++ code that works in both a BB10 Native app and an iOS app.
XCode would need to see the C++ files as ObjectiveCPP code.
I am currently working on such a task in my spare time. I have not yet completed it enough to either show or know if it is truly possible, but I haven't run in to any road-blocks yet.
You will need to be disciplined to write good cross-platform code designed w/ abstractions for platform-specific features.
My general pattern is that I have "class Foo" to do cross platform stuff, and a "class FooPlatform" to do platform specific stuff.
Class "Foo" can call class "FooPlatform" which abstracts out anything platform specific.
The raw cross-platform code is itself not compile-able on its own.
Separate BB10 and XCode projects are created in their respective IDEs.
Each project implements a thin (few [dozen] line) "class FooPlatform" and references the raw cross-platform code.
When I get something working that I can show I will post again here...