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.
Related
I am working in iPhone SDK.I have to convert from it to Crossplatform which may be either phonegap or titanium.As a iPhone Native application developer, I have some questions based on cross paltform.please consider the questions for other platforms android,etc also.I have already seen the stackoverflow Link.
1)Is it possible to get equal functionalities of all APIs which are in iPhone SDK through HTML5 and javascript?
2)If Apple releases New Version of iPhone SDK,will New APIs be included ASAP in Crossplatform?
3)If The App crashes in some situation, can I fix immediately through Device Debugging as we do in native Language?
4)The applications developed by Cross platform will be approved by Apple legaly?For example If i want to do live streaming in iphone , The restrictions have mentioned in Apple website.has it been followed by crossplatform?
5)will Application developed by cross platform take more memory?I mention the size of device build for appstore?If we develop the same through objective C,will size be reduced?
***My Conclusion is When we want to develop simple Applications for Multiple devices,crossplatform is suitable.Am I right?***I hope doing through native language(iphonensdk, Android) will avoid lot of Unnecessary things.
No.
If the API can be made available, it depends on how fast the creators of the framework implement it.
In principle, yes, as those frameworks employ a limited amount of OS capabilities to run web-technology (in most cases). This "wrapper" behaves as any native app does. For the content however the rules of the frameworks development language apply. It may be harder compared to native development to track down errors, since they must "pass the shell". Html errors for example may produce the same error for their enclosing webview again and again, despite being different in origin.
Propably.
That's hard to tell. It may depend on the framework. I wouldn't worry about the code as other ressources like imagery are usually the heavier load. But it may be very well the case that those frameworks bring along imagery necessary for their UI elements, since they do not rely on OS elements entirely. Compared to a native app which comes with no extra ressources at all, a crossplatform app with the same functionality might take more memory.
As to your conclusion: You're right. However I'd still encourage anyone to develop native applications whenever possible. Crossplatform frameworks tend to be slower at runtime and, in some cases, produce very ugly apps. I know several examples of apps which have been created with a variety of crossplatforms and I don't like any of them. They just don't feel right. Partly that's due to their UI elements which don't look and feel as you'd expect it on the platform you're on.
The principle behind crossplatform frameworks may appear to be logical, tempting and in some cases, straight economics mandate their use. But, for the time being, I find the results far from being satisfactory and for that reason would never touch a crossplatform framework.
In my experience (with a closed, private, expensive x-platform thing purchased by the employer), it was utterly frustrating, and incredibly difficult. Therefore, it is my preference to maintain multiple native apps.
The UI considerations that can be made/handled by the native app, as well as the functionality and speed gained by doing it natively, IMHO, far outweigh the benefit of having to write it 2 or 3 times.
In an ideal world, you would have a specialist for each platform that can lead the team on the "deep" things, and then everyone can generalize for all of the platforms, increasing their depth through the course of the project.
There seem to be lots of answers for cross-platform frameworks for devices (iPhone + Android), and cross-platform frameworks for desktops (Mac + Win + Linux). This is a different question regarding a suitable framework, methodology, template app, tutorial, or just helpful hints, on developing native apps (not just web apps) that are cross-platform portable between a device OS and a desktop OS.
I want to write a app that can run on both my iPhone (or iPad) and also be compiled to run natively on Mac OS X (and not just run in the Simulator). I am willing to live with only basic UI elements that are common to both platforms (only 1 window, generic buttons, textfields, etc.)
What's the best methodology to build a pair of apps, with the minimum number of #ifdef's and other platform specific code rewrites, that will run on my iPhone and natively on my MacBook?
There is no easy way to do this using standard UI controls. AppKit and UIKit are completely different animals. Even the basic UIView and NSView are very different in structure and function. At that level, you won't see anything that could be made cross-platform.
However, there are display elements that can be made to work on Mac and iOS with minimal changes. Core Animation CALayers are one such element, in that they are the same on Mac OS X and iOS. This is why we chose to use them as the basis for the Core Plot framework, which uses an almost identical codebase to display graphs on Mac and iOS. There are a few platform-specific things to tweak (like the inverted coordinate system a UIView applies to its backing layer), but most of the code will translate to both platforms.
You mention writing a game. If you are using OpenGL ES for this, much of the rendering code you write will also work on the Mac. There are a few things you will need to alter, but for the most part OpenGL ES is a subset of desktop OpenGL. However, for a simple 2-D game I'd recommend sticking with Core Animation unless you really hit a brick wall, performance-wise, simply because you will write so much less code.
The items I've mentioned so far have all been in the View portion of the Model-View-Controller design pattern. Your controller code will be application-specific, but you may be able to make most of that platform-independent. If you use a simple model, or even one that relies on SQLite or Core Data for persistence, that should be trivial to make work on Mac and iOS with the same code.
A Mac application and an iOS one (even between the various iOS devices) will have a very different core design. You can't just shoehorn something from one platform into another. Games are probably more portable than anything else, but you will still need to do some custom work to reflect the unique attributes of each computing device.
I'm also struggling with this one; I'm using Unity3D and the free license doesn't allow native OS X plug-ins.
I've just spent the last hour reading through http://rayvinly.com/how-to-build-a-truly-universal-framework-for-ios-and-mac-with-just-a-single-codebase/
Ray has done a super presentation, you can download his 30 page ebook document! He also provides a template project.
I'm thinking I could use this setup to create a single drawing surface (so, a single window on both platforms) which I could draw to using SpriteKit.
Then wrap mouse/touch input to create a unified input.
As for ready-made frameworks, http://chameleonproject.org/ looks interesting.
http://kivy.org/#home looks much more interesting: multiplatform Python wrapping GLES2
Also http://polycode.org/ http://qt-project.org/
What did you choose in the end?
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.
If I create an App for the iPhone (OS 3) will it run without modification on an iPod Touch or will I need to create a separate binary? If it is the same runtime, does it just have stubs for the iPhone only features or do you have to check feature by feature using UIDevice to ensure the particular class/method is supported on the device to avoid a crash?
Sorry for the elementary questions, can't find a simple explanation of this anywhere.
Cheers
Dave
EDITED: Based on discussions below:
How can you check if a device supports making calls? At the moment I am assuming if it is an iPod Touch it can't. Is there a way of finding out what shared applications/URL schemes are supported by a device?
You shouldn't really try to guess what the device is. You're far more future-proof if you test for the specific functionality you're trying to use. After all, in the future there might be iPods with cameras. Or compasses (which are on some iPhones but not others).
Since it sounds like all you want to do is see if you can open a URL, why not use -[UIApplication canOpenURL:] ? (This would presumably work on iPod touches that had applications that could handle VOIP -- I don't know if any such exist, but I think it's an example of why you need to test for functionality and not make assumptions based on hardware or OS version.)
The app will run on an iPod touch, no need to compile a separate version. Features that require an iPhone (e.g. camera) will not work, obviously.
What such features do you intend to use? You may provide alternatives for iPod users or alert them that e.g. no camera is available.
This question adresses how to check if a microphone is present: Detecting iPhone iPod touch accessories
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.