For reasons that are hard to understand, since Audio Queue Services are a pure-c wrapper, the only example for recording, SpeakHere:
Is a pretty large and interesting working application, which is a lot to parse for an example
Includes .cpp files and even some .mm files. For the obj-C programmer that only occasionally uses pure C, this is a big hurdle.
Are there any examples of using AudioQueueServices, especially recording, via a simple example that does not use C++?
Related
I have to show other people a project I'm working on but I want to protect a framework in the project from being readable. I just packed all the code in the framework and added it to the project.
The problem is that when the framework calls some delegate methods and I set a breakpoint to those Xcode shows the full .m / .mm files where those calls come from. How can I prevent that? I want to protect my code.
You are only seeing the code because it's available on your machine and Spotlight can find it. If you distribute the compiled framework binary, the source will not show up in the debugger, though the names of methods will. Stripping the binary ("Strip Linked Product") will remove some names of functions, but not methods, since these have to be available at runtime in order for message dispatch to work. This will make it harder to make use of crash logs, so I don't generally recommend it unless you really need to save space.
Keep in mind that there is only so much you can (or should) do to protect against reverse engineering. All languages are subject to reverse engineering, but ObjC is particularly susceptible by its nature. See Decompiling Objective-C libraries for more discussion on that.
Compile your framework into a binary. This will "protect" the source code from being readable, with only the header files (you choose) to be exposed.
Assume I'm developing a typical Mac or iOS application using Apple's latest Xcode tools. Further assume that I am primarily developing this application using Objective-C and leveraging all of the relevant APIs from Apple's Cocoa or Cocoa Touch frameworks.
Let's say that I don't currently have any plans to use C++ or Objective-C++ in my code base, but I suspect that some time in the future I might want to sprinkle in a little Objective-C++ here an there.
So I'm considering naming all of my .m files as .mm instead, just in case. (This will have the desireable effect of a cleaner history in my SCM system, as I won't have to rename files later.)
Is this a bad idea? Is there any reason why using .mm files is definitely or significantly worse than using .m when the file doesn't actually contain any Objective-C++?
Presumably this file extension flips some switch in the compiler which will then have to parse the source code for not only ObjC, but also C++. Does this have a significant negative effect on build times for moderate-to-large code bases?
Does it have any other negative (or positive) effects that I should keep in mind?
NOTE: please do not respond with any comments about whether ObjC or C++ is better. That is not what this question is about.
It's not the worst idea, but it's not really a good idea, either.
The main purpose of Objective-C++ is to act as a bridge for Objective-C code that needs to use a C++ library. Thus, in most projects, almost all of the code is plain old Objective-C, with maybe a few .mm files to create a "wrapper" object to talk to the C++ library.
Therefore, it is extremely unlikely that you will need to change significant parts of your code over from Objective-C to Objective-C++. You shouldn't have a lot of file renames in your SCM history.
The main problem with using Objective-C++ everywhere is that you will be following "the road less traveled": 99% of the tutorials you read and open-source code you use and learn from will all be written to be compiled by the Obj-C compiler. Using the Obj-C++ compiler will be mostly the same, and probably won't make a difference most of the time, but you will eventually run into some problem that is due to Obj-C++ being compiled slightly differently, but when you find the bug it won't be obvious, and you'll spend a lot of time trying to diagnose it before you realize that it is because you are using a less well-tested compiler setup.
If you have a lot of C++ experience and find yourself "needing" features from C++ in your code, you probably don't really need them, you probably need to spend a little more time figuring out how to do the equivalent in Objective-C. When in Rome, do as the Romans do.
In general, "just in case" is not a good reason to stray from standard practice. You often wind up spending a lot of effort on something you aren't going to need.
Quote from Barry Wark:
The major disadvantage to using .mm over .m for "normal" Objective-C
is that compile times are significantly higher for Objective-C++. This
is because the C++ compiler takes longer than the C compiler. With
Xcode 3.2 and higher, Objective-C code can use the Clang frontend tool
chain to significantly speed up Objective-C/C compiling times. Since
Clang does not yet support Objective-C++/C++, this further widens the
gap in compiling times between the two.
BUT
UPDATE Feb 17, 2012 As of Xcode 4.0 (with LLVM 3.0), Clang has
supported Objective-C++. Even C++11 support is quite strong now.
So I think that its ok to use .mm as long as if you only use C features, .mm files should generate code that performs very similar to .m
As I wrote in a comment, C++ is not a strict superset of C, so it's possible you'd run into cases where you use e.g. C99 code which will not compile if you put it in an Objective-C++ file. I had this problem recently using C99 compound literals.
Yes, it's bad idea.
When I see a .mm file, I expect it to have C++ code (in addition to Objective-C of course). There are a few things not directly related to OOP that are a bit different in C++ comparing to C.
So name all your Objective-C files as .m. As soon as you need any C++ features – rename it to .mm and verify that everything works.
You get bonus points if you keep your header files C++–less.
.mm extension means Objective-C++ file. Compiler takes more time to compile c++ code than C code.
So, if it is not required, keep the extension as .m only.
From my experience (at Apple):
1) the xcode team thinks about c++ last (took forever to get blocks support in objc++)
2) objc++ is much slower in compiling
I'm developing experimental multiplayer roguelike for iOS. Players will be connected via GameKit API and they'll be put in one dungeon. There is various actions that players can perform, so I want to make one device be a host, and to implement some sort of RPC for sending/receiving of this actions (and pretty complicated state of dungeon when game starts)
I need some compact and fast serialization. I'm choosing between protobuf and binary plists. Binary plists looks pretty simple to use for objc objects serialization/deserialization (this is important point, cause its experimental non commercial project), but it looks inefficient. Protobuf looks efficient, but totally alien. Any alternatives?
Edit: just found http://msgpack.org/. Looks like a way to go
Protocol buffer serialization should be faster than binary plist.
Also, if you want to make the game again on android or any other platform then protocol buffers will be your friend. (platform independence)
Working with protocol buffers on ios can be a pain in the beginning. Just setting up the project with XCode takes up a lot of time.
Initially i tried to work with objective c version of protobuf, but i had to drop it completely because of some limitations in the library.
I have now added the google source code directly on Xcode, ands its working perfectly. check out this answer. Through this you'll be able to start working with protobufs in your project easily.
I'm planing to write my algorithmic codes in Matlab. And I need to convert .m files into a format where Objective-C can access. When I try mcc, the following error appeared.
The -t switch is no longer supported; the Compiler no longer generates C/C++
source code for M-functions (it generates wrapper functions instead, see
the documenation for -W).
If mcc is not creating C source codes how can i generate wrappers? and do i have to copy both m file and the wrapper in order to make everything working?. And will those wrappers work in iOS??
MATLAB Compiler does not convert MATLAB code into C code, and has not done so for a long time now.
Instead, it archives and encrypts your MATLAB code and creates a wrapper (which could be an executable, a library or, if you have access also to any of the Builder products, a .NET assembly, a Java .jar file, or an Excel add-in). This wrapper dearchives and decrypts your MATLAB code, and executes it against the MATLAB Compiler Runtime, which needs to be included with your application (but is freely redistributable).
You are not going to be able to run the MCR on iOS - its footprint is just too big. If you are targeting another platform with Objective-C, you could produce a library using MATLAB Compiler and call that from your Objective-C.
MATLAB Coder (not the same as MATLAB Compiler) can convert a subset of the MATLAB language into C code. If you are targeting iOS this would be one approach, or you could alternatively run your MATLAB code remotely, and have your app access it via the web.
I'm a little confused by what you have written so I may not be answering your real question:
The Matlab documentation provides clear instructions on how to use the Matlab engine from C programs. Since Objective-C is just C with knobs on, I see no reason why you shouldn't call the engine from an Objective-C program. All that the Matlab engine will see when it is running are valid calls, it has no clue what language the calling program is written in.
I think that for your usage of mcc is irrelevant; what you need is an Objective-C compiler on your Mac. The Matlab documentation suggests that the compiler included in XCode up to v4.1 is OK for Matlab engine applications. In my experience, it may take a little fiddling with compiler options to make a more recent compiler work with your installation of Matlab, but no more than that.
If you plan to use Objective-C calling Matlab, you may not want to start by writing M-files for your algorithmic core. Actually, you probably will, but the Matlab engine doesn't really run M-files, it executes commands sent to it by an external program, such as your Objective-C program. Your development route might be (1) write M file to implement algorithm, then (2) write Objective-C program calling Matlab engine at critical steps when the Matlab functionality is required. You could write your application to make the engine run an M-file (I think) but this is outside my experience.
While you can use Matlab to run a compiler to build your programs, in this case you are probably better using XCode (or your preferred Mac IDE) to build your programs, taking care to ensure that the right linkages are made to the Matlab engine. Again, the documentation explains what you need to do.
No wrappers are involved. No M-files are required. And good luck getting the Matlab engine running on iOS !
I want to know if there is a way in c++ or objective-c to get the BPM of a Mp3 file.
i found until now a source code for stuff that do it on wav files and not on mp3 file,
BPM (or beat) detection is a complicated algorithm that involves analyzing the sound stream in different ways. For this to happen, at least internally the MP3 must be decoded. Typically these are things you'd actually write in a language such as but not limited to C++ or Objective-C.
There are many libraries / pieces of code available that solve both problems, or in the case of beat detection: take a shot at it.
There's certainly no way to do BPM detection in the core C++ or Objective-C languages. You need to write the functionality yourself or take advantage of one of the many libraries that provide it.
If you can't find a suitable library that supports MP3 directly then you're going to have to decode to PCM first.