Related
I am working on an app for Android, but would like to have it ported in the future to iPhone and (if it seems to gain significant market share in the future) WP7/8.
I know nothing about any mobile platform other than Android. Should I be using C++ (NDK), Java, or something else to get as much portability as possible? I assume I will have to rewrite (or have someone rewrite) at lest part of it, but I would like to make as much of the codebase as possible portable.
Edit: It is a simple app that "scans" a barcode (camera) or has the number typed in, sends some information to a server, gets back some more info (probably in XML, but could be whatever works best) and displays it in a few simple screens.
Edit 2: The 4 parts I have, and would like to ideally make them portable are:
Scan a barcode (probably the hardest to make portable)
Allow entering a barcode number manually
Send and receive some custom data
Display a few screens (This can be in HTML, if I have an option to make it look "native", not like the browser window displaying a webpage it is)
For a non-trivial app that isn't a game, there are currently no mature solutions to this problem.
Tools like Titanium Mobile and PhoneGap are meant to help you do exactly what you want, but impose limitations on what your app can do and are so far at the cutting edge of development that they often introduce bugs of their own that you won't be able to fix. Additionally, you're at their developer's mercy when it comes to support for alternative platforms like WP7 or Blackberry. In some cases, these might be worth the risk, or you may get lucky, but you need to be wary before rushing to use them.
Often, the best technique is still just to develop independent codesbases. You can model them after each other in architectural terms, and if you do so it isn't typically that hard to translate between different platforms.
Another technique to aid in portability for many apps is to use embedded web browsers where it makes sense. This allows you design some of your views in HTML/CSS/Javascript rather than with native UI tools, and then just load them into the aforementioned embedded web browsers on each platform.
Depends on how many platforms you are aiming for.
I have some experience doing iPhone + Android. Honestly, I wouldn't spend too much time trying to learn a portability tool on top. I have done couple of apps (simple communication stuff + a light weight game) and my experience is so far - assumed you are familiar with both - it is far faster + easier to just write your app and then port it.
Besides the normal coding work, the most difficult tasks are to develop the app structure including the main classes and data structures - this you can copy basically 1 to 1 in terms of structure of course - not code.
Also since you will keep getting updates on different platforms like iOS (Android + Eclipse are a little slower it seems to come up with updates/upgrades), which make life easier all the time, you would most probably have a big disadvantage when relying on someone elses portability development toolkit.
So far - certainly not to be taken as a general rule - while development on iPhone took 100%, porting it on Android took at most 30-40%
This question is way too broad, it depends on what kind of app you're doing.
Generally speaking, if you're just as good off doing a web app, do that. It'll work across different platforms.
MonoTouch / MonoDroid by Xamarin (previously owned by Novell) allow you to write C# (the language used by WP7) for iOS/Android, respectively. It is not free, however.
I don't believe the frameworks go so far as to include cross-platform UI, but I'd say that's probably a good thing. At least your application logic can remain the same across platforms.
I've not used the framework myself, so I cannot vouch for it.
We do use MonoTouch/MonoDroid and it helps us to simultaneously support WM/WP7/Android/iOS. The common denominator of all these platforms (after employing Xamarin products) is .Net.
The policy of our company is to maintain toolkits for all platforms that provide similar UI. Then the apps can be written in a nearly platform-agnostic way. This isn't, however, a general statement as the independency refers to the specific types of applications.
I don't advise using our toolkits for your case as it looks like an overkill. However, investing into C#/.Net might not be a bad idea.
U should definitely go with the easiest route: Java.
You will still have to rework a lot while porting, but if you were using NDK, the overhead for Android itself might be similar.
(In an average app. As you havent provided too much information about the project, the answer couldnt be more specific. If you are developing a performance-critical app, like a 3D game, you should consider NDK for the high porfile program parts).
Edit: for this scanning solution, I would go with Java on android and wont bother with portability. For a project with such a clean application logic it wont worth the effort to make it portable (except if the aim of the project is to experiment with application portability, but as far as I got it, it isnt).
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've been developing for quite a while but while I consider myself competent (or better) with C++, Java, C# & AS3/Flex in areas from web-servers to desktop applications to 3D games, I'm aware all these languages are pretty similar; even on the libraries side I know what to look for based on using libraries that do similar things in another language.
But Objective C I understand to be a different kettle of fish, and developing for mobile devices has always struck me as likely to be hard work since you have to develop on your PC and test on the actual device itself - my experience developing for PS2 put me off such things due to poor debuggers and other tools.
What's the reality? Is it a paradigm shift to move from web-servers and desktop apps and rich web-clients to iPhone... or for an experienced developer is it just another language to learn and new libraries to play with? Is there anything to be scared about at all?
edit: My main question on Obj-C specifically was if it's a different way of programming, like it would be moving to Haskell from Java for instance. It sounds this is not the case.
For starters, ObjC is fairly easy to grasp so long as you focus on the fundamentals. Don't worry about the syntax, there's not much there above C which I will presume you already are familiar with. There are excellent books out there this book is the definitive guide I recommend to most new users, Erica Sadun also has a good book on iPhone development, I recommend both of these highly.
Secondly, the tools aren't hard to use, and you will be pleasantly surprised with the debugger and other tool integration. Instruments was a long time coming, but it's indispensable for catching things like memory leaks, cpu time usage, and now power consumption.
But really, nothing to be scared about, and as for another platform to learn; well, yes and no. There is always going to be another thing to learn, regardless of iPhone or something else. Don't resist. :)
There's definitely a "paradigm shift" (ugh, buzzwords):
You don't have all the memory in the world (and there's no swap either)
You don't have all the CPU time in the world
You probably don't want a binary bigger than about 20 MB (the size that can be downloaded over the cell network)
You can't just change the server backend to make things right.
Graphic design is important if you want to be successful (but you don't want to bloat your app)
Web requests take a while (a website with redirects feels really slow compared to the desktop beside it).
JavaScript animations are painfully slow (ever tried the Google Maps website on an iPhone?)
UI design is heavily constrained by the size of the user's finger (even though the iPhone 4 has a comparatively huge screen).
UI design is really tedious.
The user can do more things than clicking and typing.
I find that the biggest difference is in the UI, not in the language. Languages are easy. Libraries require a little reading/searching/asking around, but then they're easy. UI design and UI programming are very difficult to do well.
Objective C is different but not far removed from normal OO methods. The syntax was the larger barrier for me.
The problem I saw was/is you learn ObjC for iPhone, and you can't take the skill (ObjC knowledge) outside the Applesphere really. I haven't seen a use for it. I have a handful of books I went through to get my feet wet. Some of these, the Apress books, contained errors in the code walkthroughs causing me to Google the book errata countless times.. so be careful of that, if you learn that way.
Also, unless this has changed, you can only develop under OSX with the SDK tools because no Windows version exists to my knowledge.
With that, you also have to play by Apples development rules to get published into the AppStore, which has had its share of dev horror stories.
That said, a working app is fun and beautiful in the end.
On a scale of 1 to 10, it's about a 6.
Apple does use Objective C and it is different then normal C. So Iphone and IPad development can be hard if you've never used Objective-C before. If you are familiar at all with a language called SmallTalk, then Objective-C will be very easy for you to pick up.
Now other mobile devices, such as Android, uses Java. If you are competent in Java then Android development may be easier for you.
Some devices use Windows Mobile. If you are a .NET programmer, you can use .NET compact framework to develop Windows Mobile Apps.
Just so you know too, most mobile SDKs come with an emulator to test your app on. So if you don't have an iPhone, for example, you can still test your app with the emulator. I understand that the emulator is supposed to be 99% as accurate as an actual device
I don't think there's anything to be scared of.
The simulator's pretty alright, even if it can't handle some things - it's hard to simulate the accelerometer, for instance!
Once you're over the hurdle of figuring out what certs you need and setting up the iPhone development account and such, it's fine.
It's a bit of a pain writing something, loading it on the device, trying it out, etc., but the fact that you can actually debug the code running on the device makes it rather a lot nicer than it could be. (I had to maintain an application for the Nokia 9110, and there I had to edit, compile, load, run, crash blindly, stare at code, guess, edit, compile, etc.)
As a long time Windows C++ / .NET developer, I didn't find it very difficult to begin developing in Objective C.
There are some syntax differences that take some getting used to, but in general it similar enough to C/C++ to not feel like a completely new language.
Learning the library code and what you can and can't do easily seems like the larger challenge to me, which is going to be a challenge with any new platform.
I am writing a beginner book called Hello! iPhone, and I've made a mailing list of beginner tips to help people get started. After a week or so of tips, you'll be much more equipped to check out other books and understand the basics a bit better to judge.
http://loufranco.com/beginner-iphone-programming-tips/
It will take you through Hello, World and some other simple stuff (Outlets and Actions, basic memory management, etc).
I keep running across references to MacRuby and was wondering if any of you have used it for iPhone/Objective C programming.
The MacRuby website says, "the goal of MacRuby to enable the creation of full-fledged Mac OS X applications which do not sacrifice performance in order to enjoy the benefits of using Ruby."
So, my question is: what are the benefits of Ruby?
And, more importantly, what are the limitations?
I've not used MacRuby, but I doubt if it could be used for iPhone development because it is built on top of the Mac OS X Objective-C runtime and uses the Objective-C 2.0 garbage collector (instead of using its own). Although iPhone OS has Objective-C 2.0, it lacks the garbage collector (you still have to use retain/release-style managed memory), so I expect MacRuby would not work out of the box.
Also, MacRuby would not be useful for developing for the App Store since using interpreters (other than those supplied by Apple) is verboten.
An iPhone port of Ruby might work on a jailbroken phone, but the device has very limited RAM and CPU resources, so I'm not sure how successful such a port would be. I expect MRI is too slow and memory hungry to be useful on the iPhone, but one of the alternative Ruby interpreters might work well - a MacRuby with its own GC perhaps.
I can certainly see MacRuby having many advantages for Mac OS X development. Here are some things off the top of my head:
As a language, Ruby it is a joy to use. Blocks are lovely. It's very dynamic and has great support for meta-programming, making it possible to quickly produce very compact but still readable code.
Objective-C can be quite high-level when it's being Objective, but can get annoyingly low-level when it's being C. Ruby has less of the C-ness.
IMHO, Objective-C has some really weird syntax. You get used to it after a while, but it scares newbies. Ruby has a much more mainstream syntax, especially if you use foo.bar('baz') instead of foo.bar 'baz'.
Objective-C uses header files. I get annoyed cutting'n'pasting method prototypes between .h and .m files. Ruby has none of that.
MacRuby is really cool, but it still not production ready (even on OS X), and it will not work on iPhone for several reasons:
It uses the Objective C garbage collector, which is not available on the iPhone
It depends on bridge support, which is not available on iPhone
It depends on the LLVM backend, which is awesome, but is not yet production quality for ARM
JITs don't work on the iPhone because of its security model (calls to mprotect() fail in most cases).
I expect over time some of these issues will be resolved, and at some point in the future things like MacRuby will be available on the iPhone, but that is probably several years away at a minimum. If you want to develop for the iPhone now, or foreseeable future, MacRuby is not a realistic option.
The benefits of Ruby are a less obnoxious messaging syntax that's far easier to read and type than tons of nested square brackets and far greater dynamism. The downside is generally execution speed and the way Ruby users tend to gravitate toward overusing its more obscure metaprogramming idioms thereby turning even simple projects into monkey-patched spaghetti.
You're never going to run it on an iPhone unless Apple decides to lift the no-background-processes limitations currently imposed, so if that's all you're interested in, don't bother.