I'm starting using Swift for my new audio app and I need to use Apple Core Audio library.
Let's be honest, Swift is a great language and I love it but as soon as we have to use C, pointers and other stuff it becomes really annoying to use it.
In order to make it a clear and clean interface I would to know you thoughts about interfacing Core Audio and Swift.
I thought to use C++ (for the convenients std::vector and more) or C but both require using bridging.
So my questions are:
Do you use pure Swift or C/C++Bridge when you use Core Audio?
Which one will be the faster?
I think I found the answers so I will leave it here if somebody is interested
The bridge approach is preferred. As invalidname (Chris Adamson) said in media framework talk you have to Render unto Caesar the things that are Caesar's, and unto God the things that are God's i.e use C for C API and Swift for swifty things.
Talking about performance I found an article which discusses about it. The conclusion is that for primitive type there is no problem by making all the type conversion, calling C function and making the backward type conversion. But for some type like String/char*, struct and more complicated type you could encoure performance decrease.
Btw don't hesitate to add more things if you think it could help other people.
Related
I was wondering whether it is good to use swift programming language to create a framework for iOS application. I doubted how do we expose public interfaces in framework If I use swift. Usually ObjC framework has .h files in header folder inside the framework but swift can't.
See below post from apple https://developer.apple.com/swift/blog/?id=2
Appreciate any response on this post.
There are a few limitations regarding distributing Swift libraries, bundles, frameworks, etc...
You will need to document your API as relying on a header files only for developers to peruse won't cut it.
Mixing Swift and Objective-C is easy because of bridge technology but the technology doesn't extend to incompatible types across the bridge (struct is one of them.)
You need to package your Swift libraries in dynamic libraries. There is no way around static libraries in Swift.
Most of the early issues with naming have been ironed out, but there are still some gaps in what's available in foundation.
The C invocation is getting better with and even Swift2 deals with C function pointers in a less obscure way but Swift 2 is not out yet.
Some esoteric things you are used to with Objective-C are harder to implement with Swift. If you are going to lose the safety mode of Swift to be able to bit cast your objects, that defeats the purpose.
For most of these reasons, although I love the new language syntax, I chose to continue development of frameworks used in my app with the proven Objective-C and decided to move all the UI stuff in the application side to Swift. When Swift 2 is released, I will then reconsider this choice.
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.
First I went and purchased:
Beginning iPhone Development: Exploring the iPhone SDK
And it said I should know Objective-C
Then I went and purchased Learn Objective–C on the Mac by Mark Dalrymple, Scott Knaster
And it said I should know C
then now I'm at the beginning with Learn C on the Mac by Dave Mark
So this is the long journey I need to take to finally start producing actually GOOD apps for the iPhone
C > OBJECTIVE-C > APPS?
Nah, forget learning C, just go straight to Objective-C. My humble opinion.
If the Learn Objective C book assumes you know C then is it likely to not go into the code in as much detail as you need, making it more difficult for you. However you don't need to learn all of C, or even a lot, so working through a book will take some time.
Better, as silky says, jump straight into Objective-C, and when you struggle just come to SO
If you're a complete beginning to computer programming, I might get some information about programming in general before going to Objective-C; it's an easy language, but it would help to general programming constructs (like if statements, etc) and how they work before you learn how Objective-C does it.
I would think that you WOULD want to learn C first. Most objective-c books are going to presume that you know the difference between pointers and values, that you know basic looping and control statements, and that you understand arrays, structs, and functions.
Contrary to some other advice, unless an objective-c book you buy specifically starts from zero and makes that claim, I WOULDN'T just jump in. People will say that objective-c is easy, but that's not necessarily true, since with compiled languages (unlike interpreted ones where speed doesn't matter so the runtime can hide complexity via abstraction) the devil is in the details.
If you read an objective C book and you don't know what the "*" is for in front of a variable, start with C. My two cents.
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 managed to avoid C and C++ up until now (except for a few HelloWorlds), and have instead worked in higher-level languages. I've worked and lived in VB6, then Java, then C#, then ActionScript, and now Ruby.
I've recently become curious about programming for the IPod Touch/IPhone. Though I've seen some possibilities for avoiding ObjectiveC (like Mono for IPhone), I'm curious about Objective C. Mostly: does it require the developer to handle garbage collection and manage pointers and that sort of thing?
Edit: I am totally open to the possibility that my concept of higher- and lower-level languages is incorrect or misleading.
Garbage collection: yes, but not nearly as bad as C or C++. Once you understand Objective-C garbage collection it's really easy. It doesn't take that long to learn or master either.
As far as pointers go - you'll be using pointers far less frequently than you would in C or C++. Yes, a bit of knowledge about pointers is useful (knowing the difference between declaring NSString * and NSString) but that's also not that complicated.
Personally I would avoid all the "higher-level" languages that are emerging for iPhone development. They really only eliminate the need for you to learn Objective-C but still force you to use the native framework (Cocoa Touch). They add complexity for laziness sake. Objective-C can be learnt in a week, debugging framework nuances takes a lot longer. But then again, it is only my opinion.
edit:
C# memory management can also be a pain if not done correctly. Yes, there's a garbage collector that works in a lot of cases. However, there are also objects that need to be disposed and not disposing them correctly can lead to memory leaks. Creating your own IDisposable objects can also be tricky if you're not 100% sure what the order of the Disposing sequence is. I've seen a lot of projects where developers get this horribly wrong. Basically what I'm saying is that the Objective-C memory management is not more complex or more technically difficult than the Dispose chain in C#/.NET
There is garbage collection for Objective-C but not for the iPhone, i. e. if you write software for the iPhone you have to handle the memory stuff on your own, but this is no general Objective-C problem.
"Mostly: does it require the developer to handle garbage collection and manage pointers and that sort of thing?" - on the iPhone, yes.
It's not as "high-level" as C# and Java, IMO, but it's still considered a high-level language, just like C++ and, yes, C.
Objective C does have garbage collection, but the iPhone Object C does not.