1,446 karma · joined July 12, 2009
Edit:
Please see my reply to the comment below.
Also, this is from the preface of the book:
Fortunately, there is an alternative. You can build a web app using open source, standards based web technologies (jQuery and jQTouch, in particular), release it as a web app, and debug and test it under load with real users. Once you are ready to rock, you can use PhoneGap to convert your web app to a native iPhone app and submit to the App Store. If it is ultimately rejected, you aren’t dead in your tracks because you can still offer the web app. If it is approved, great! You can then start adding features that enhance your web app by taking advantage of the unique hardware features available on the device. Sounds like the best of both worlds, right?
So, the step to wrap your app with something like PhoneGap is only needed if you want to sell your app on the AppStore. You can try to submit and then, if it is approved, you may add more hardware dependant features (which aren't covered at all by this book).
Anyway, IIRC there's still some C++ somewhere (some parts of Core Audio, for instance) and some sample code from Apple itself also uses C++ here and there.
This is obvious. That's what they are for. But on the iPhone the tedious stuff is dealing with the APIs. And you would not gain much just by wrapping them with another language.
> The real problem here is that interpreters for the iPhone seem to be a gray area at best (see discussion elsewhere here).
As I have stated many times in other threads, there are apps (published on the Appstore) written with squeak smalltalk, games made with Unity (which uses javascript on top of Mono for scripting the game logic) etc.
What you can't do is to expose the interpreter to the user or to make it run code downloaded from the web.
Even if this wasn't the case, how could Apple even know, for instance, that I have statically compiled the Lua interpreter and used it to script part of the logic of my app?
Still, I would suggest people who are seriously interested in developing for the iPhone to check if plain Objective-C works for them, first.
My recipe is:
- Objective-C for the minimum necessary to deal with the iPhone specific APIs.
- plain C for critical parts which need to be optimized for speed and memory consumption.
- your favorite embeddable language implementation (mine at the moment is TinyScheme, but I've also used Lua) for scripting.
Also, consider that often you may need to include libraries written in c or c++. This is trivial to do from Objective-C.
Performance will be affected, heavily, since you're running everything on top of an interpreted language (with garbage collection) which then must call the equivalent Objective-C function, for every single line of code.
Moreover, I don't believe that any of these wrappers (for Lua or any other scripting language) will ever cover all the APIs available on the SDK. So, what happens when I need to call one of these? What if I need to use some other library written in c, or c++? And what if I've use this code to write some apps, the projects stops being maintained and the API changes with a new release of the OS?
What does make sense instead, is to use a language like Lua as it is intended, embedding it in your app and writing only the interfaces for the parts that should interact with it. For instance, if you're writing a game, it would make sense to embed Lua to code the game logic (which would be completely independent from the iPhone specific stuff).
Just my two cents.
I'd rather build one myself with a nicer case.
A better way would be to use the ipod with a dock with a proper line out (the basic dock from Apple has one).
If you need to send the signal to something else it would be better to buy something with a line level output and connect it to an amplifier.
http://www.repubblica.it/2009/09/sezioni/esteri/suicidi-fran...
BTW, have you looked at squeak smalltalk? (http://www.squeak.org/)
I used it to make a full-featured offline mail reader for a BBS I used to frequent in a few hours. Anyone remember offline readers (http://en.wikipedia.org/wiki/Offline_reader)? :-)
You can do this with Redis too.
It has not been killed but got 0 points and 0 comments.
I thought it was entertaining too.
http://liquidrescale.wikidot.com/
Here's the presentation (SIGGRAPH 2007) from the authors of the library used in the plugin:
For realtime 3d graphics there's cl-opengl (http://common-lisp.net/project/cl-opengl/). I'm using it right now with sbcl and the glut wrapper (cl-glut). It comes with some examples too.
The assignment was about implementing the functionalities of a simple library management app. And it was explicitly to test using pointers, linked lists ecc.
The requirements were fully implemented. And all the queries were handled by functions which were completely separated from the gui code.
Basically, instead of a textual menu (1 - borrow, 2 - return etc.) you had a Mac Os menu and the results were presented inside fields in a window instead of a textual output.
If I had to convert the program to a textual interface by editing my source (instead of doing everything from scratch) it would have took me 5 minutes (or less). IIRC the code was already there and simply commented out.
Keep also in mind that our lab was full of Macs (50-60 machines) with just a PC (which, btw, has been used by a guy who had made the app with his own advanced textual interface - something like ncurses - and who had a similar fate as mine). So I thought it was a plus to use the native gui of the OS we were using all the time.
> Of course, it doesn't matter now.
Of course. It happened 17 years ago :-)
An assignment for an exam was to make a simple library management program in pascal (cataloging books, leading, receiving them back etc.), mainly to test our understanding of pointers.
Even if we also had Macs at the university, we've been asked to make a command line app. But, since I was studying the Mac OS gui programming by myself, I made a graphical application instead.
The assistant professor that was evaluatings our assignment didn't believe that I had made it myself. She probably couldn't understand it herself (but, obviously, all the relevant functions were separated from the gui code). So she asked me to rewrite everything from scratch as a command line application in a couple of hours in front of her.
I managed to do it but I was really really pissed off. Shortly thereafter I started working and dropped out.
I still have a boxed copy of Symantec Think Pascal. I used it to make my first steps in window based/event driven applications programming on the Mac (in 1990).
I remember coding my first apps invoking the system calls directly to create windows, handling events (see where the user clicked) etc. Then I moved to Codeworrior which had a nice c++ framework.
p.s. Sorry, I couldn't resist. It' just a joke. Please take it lightly.