I'm using Objective-C/C++ and I have an Objective-C class that is a wrapper for a C++ class, are there any special concerns I need to be aware of in order to use fast app switching?
It is my understanding that the iPhone will auto-magically save state for Objective-C objects, but I'm not sure if I need to do any special work to enable support for C++ objects. My C++ class does not have any virtual functions.
By fast app switching you mean multitasking?
There's nothing additional you need to do - iOS 4 will handle the task suspension and resume transparently, unless you need to perform background tasks, regardless of whether you're using objective c++ or just plain objective c.
Related
MonoTouch has automatic garbage collection on the iPhone. Couldn't someone prematurely implement garbage collection for Objective-C on iOS? I'm not the guy to do it, but I'm curious as to why or whether this is impossible.
I know that projects like this exist: what does it take to use them on iOS? Since they are in C/C++ anyway, and Objective-C contains those languages as subsets, but yet, those languages are actually aware of the system architecture... I'm out of my depths here...
While we're here, if anyone knows of any attempts to implement a GC on iOS, links would be helpful...
I don't think it's possible. The problem is that Objective-C is used inside the system library too. In OS X where garbage-collected Objective-C is supported, there are in fact three modes when you compile a code:
the function compiled can be only called from non-GC environment.
the function compiled can be only called from GC environment.
the function compiled can be called both from GC and non-GC environment.
See the discussion here, for example. The point is that the system library needs to be in the third mode in order for the OS to support both non-GC and GC apps. And in OS X, the libraries come in this hybrid mode. In iOS, I guess it comes in the mode 1. (I don't know for sure because I haven't jailbroken my phone, though.)
If you have complete control over both the system library and your app, it's possible to make them all garbage collected, but unfortunately we're not in that stage yet.
I'm sure we'll have GC in iOS in two years.
Nothing stops you from building your own garbage collector for your app. Or importing another project that will handle it. Again, for your app.
more discussion:
Is garbage collection supported for iPhone applications?
if your app use this solution , do do you plan port the app to other platform ? for example, iPhone app --> Android or Backberry.
I do not want user it , but some code is exist ...
Any Cocoa code is not going to be easily portable to Android or Blackberry, regardless of whether or not you use KVC or KVO, since Objective-C doesn't exist on those platforms. If you want a cross-platform app, your best bet is to write basic underlying code (such as data models) in C or C++ and write the GUI in Cocoa.
I have used both KVC (key value coding) and KVO (key value observing) in applications in the past and find it to be a very useful feature of cocoa (and cocoa touch). It does create some challenges for porting, however I do not have any plans to port to Blackberry or Android at the moment.
I was wondering if anyone knew how iSimulate automatically registers/hooks itself into a debugged iDevice application? It's as simple as including the static library (and a couple of frameworks) and it just works. There are no methods or functions to call. How is this possible?
Short answer: using categories in Objective-C, you can extend or augment any class in the system, including core classes and NSObject itself. (Similar to "monkey patching" in Ruby for example.)
The actual communication is most likely a broadcast, sending packages that don't expect to get an answer back. When you start your app, it just starts intercepting these packages. So it's the simulator app that hooks into the iSimulate stream, rather than iSimulate somehow "reaching into" your app.
Have a look at the open source accelerometer simulator project. You could easily extend it to broadcast touches too, and basically duplicate what iSimulate does. And you learn about the nifty side of Objective-C.
I dabbled in some iPhone development and there seems to be two strategies:
use the iPhone specific libraries with ObjectiveC & XCode
use cross-platform libraries like OpenGL, OpenAL with C/C++ and an editor of your choice
Coming from the Windows/Linux C/C++ world, I took the second strategy and used Emacs and C/C++ for my app. I used a single ObjectiveC shim that passed messages into my application that was entirely C++. In theory, the main portion of it would run on other platforms if I replaced the outer wrapper that does iPhone specific stuff like allocation sound buffers, discovers file paths, etc.
So, what proportion of iPhone developers are embracing the XCode/ObjectiveC/iPhone-specific-libraries and what proportion are keeping that at a distance and writing more cross-platform-like code?
I think that when writing games you can get away with cross-platform libraries.
When writing anything other than games though, you will have to do a significant portion in Objective-C anyway. For that reason I personally think it is easier to do the entire app in Objective-C.
I'd much rather code an app using pure C api such as OpenGL, rather that Cocoa Touch. So I'm wondering: is it feasible? Will I be able to maintain the same user experience that you get with Interface Builder?
None of the UI components have OpenGL equivalents. Is it possible? Yes. Is it sensible? No - you would be much better off learning how to use IB and the UIView classes. Coding the UI in OpenGL would be like painting your house with an artist's brush, using hand-made paint instead of Dulux.
Unless you are working on a game, users will expect your user interface widgets to work the same way they do in other applications. You can never emulate that properly, especially if apple decides to fix certain issues in future firmware upgrades, etc...
You will also need Cocoa for integrating with the system in general to store data, prefs and so forth. Is there any specific reason for your reluctance to use Cocoa? If it's because you feel an aversion to learning objective-c, then you really ought to give it a proper chance. It's a great language for building ui apps. If you are trying to port an existing app, then I would suggest building a wrapper that will interact properly with the iphone and call your c code from there.
This is not a fruitful answer (for that, see AirSource's) and rather a comment on your answer about not using Objective-C, but I learned Objective-C a few months after C# and I find I work well in both. Give it a chance and it will surprise you. There's a learning curve and they are different, but the interface tools in particular are so far ahead that you'll probably find it worth your while. It will definitely be better for you and for your app's users than hand-rolling it in OpenGL.
Depends on your app. Mine's an "immersive" game, so I'm using openGL
instead of CocoaTouch,
with a sprinkling of Core Graphics/UIKit calls to generate nice textures.
If I had to display any kind of standard, non-trivial widget, I'd use CocoaTouch.