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.
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 would like to build an iphone/ipad app that has social networking capabilities and the ability to sell magazines and specific articles. I would also like this app to be able to be as flexible as possible for future features.
Should I insist the developer use objective C or could he accomplish the same thing with HTML5 etc..
If you're the client, and have specific technical requirements, you should document them from a technical POV. If not, well that's why you're hiring a developer--for their expertise.
There's pros and cons to each and we'd need to have a lot more project details to be of any specific help for you.
Do note that selling items via an app has its own set of red tape political issues with Apple. You may want to tackle that aspect of the project first. If you don't want to route any payments through Apple so they can take their cut, then you might want to rethink the app model and consider a mobile web site avenue instead.
UPDATE:
In general, here's some high-level comparisons:
Native Apps:
Pros
can access native device functionality directly
can leverage the native UI more directly
can be much more performant in situations like heavy game animation, 3-d, image/video editing, ec.
may be smaller file sizes
Cons
have to be written per-device
different devices use different native IDEs and Languages
HTML5/Phonegap apps
can be written with cross-platform Web standards
can still leverage native device features to an extent
are easier to port from device to device (though still takes effort)
Cons
you won't be creating graphic-heavy game-type apps with it now
may be a bit slower than a native app
Pure HTML5 local web app
This is different than something like a phonegap solution. PhoneGap takes HTML5 and compiles it into native code. That means you can send it through the app store. There's another option, however, where you put the HTML5 app on your web server, and then a user requests to keep it locally on their device. The advantage is that this allows you to bypass the app store completely (though in most situations, people prefer to go through the app store)
I would say, "no", you shouldn't insist the developer use Objective-C. At least not unless other requirements not mentioned dictate the need for a native app. As DA mentioned, there are App Store policies that would need to be complied with for native apps that can be avoided by creating a web app. Also, if you choose, it would be easier to produce a web app that could be used across other platforms rather than being restricted to the iPad.
I'm considering building an application for Windows Phone 7, Android, iphone, ipad, and potentially more. Since i'm going to be leveraging a similar look and feel and content, it seems to me like it might be worthwhile to try to create a common base structure that I could reuse across environments.
For instance, i could define the structure of the UI using XML or something, or utilize some common construction of the application which I could build a translator to gen the code in other environments, or even something else. I'm in the very, very beginning stages of thought, and was wondering if anyone has tried this and come up with a good approach? Any ideas?
Thanks.
Beyond simple applications, it not going to happen.
The are a number of problems you will face like:
Different native programming languages on different mobile platforms.
Different UI paradigms on the different mobile platforms.
Very different screen sizes even on the same mobile platform (e.g. iphone vs ipad).
UI Localisation
To really take advantage of each mobile platform, you need to build the UI for that platform to maximise it's UI paradigm. It also matters what screen sizes you want to support, catering for small screen sizes can hamstring you in what you can display in the UI unless you build different screen layout for different screen sizes to give a better UI experience (a lot of work). This can be a big problem on one platform let alone expanding it to other platforms.
For the platforms listed, you can try using mono, but that will only help in the following ways:
One programming language (C#) instead of a different language per platform.
Application engine logic can be shared between platforms.
Native UI per application.
The cons of using mono would be:
You still need to write the UI layer per platform as mono binds to the underlying UI api.
Mono runtime overhead in size and sometimes speed.
Mono on the mobile platforms are still new, I have developed one iphone application in monotouch and I found lots of first-release type problems with it.
If you don't mind some of the con's then mono can be a great platform for developing certain levels of applications.
I have found that trying to define a master UI layout just doesn't work in all situations in any application that gets to complex in the information it needs to display to the user. No matter how "complex" you can define the layout, something will break it. You either have to live with a "bad" UI in some cases or have a maintenance overhead.
I like to develop an application for the mobile platform to try can get the most out of that platform and it's features. This may mean that other platform versions of the app may work differently but at least it will feel correct on that platform.
There are some x-platform kits: appcelerator, phonegap, etc. Or you could go the hybrid route and use something like mono as a half measure, then there is the possibility of building a web app with html5.
I wouldn't try to roll my own, that's for sure
Be careful when translating iPad to Android designs. Hopefully this article can help you out:
http://morriscodes.blogspot.com/2012/09/designing-for-android-tablets-vs-ipad.html
I am working on iPhone app development currently (primarily native app using Obj-C and some web app using jQTouch). My question is regarding the future of this space;
In say 3 years time, what do you think would be preferred (native or web app) ?
What are the strengths going to be for native app (I know for certain types like Games, people prefer native than browser-based, but will that remain that way forever)
Some people say HTML5 will replace native app development, as it will be "code once, run anywhere" kind of thing (like common for iPhone, Android, BB phones). So do you think HTML5 can completely eliminate native app development.
I know the mobile space is constantly changing with new technologies coming up regularly and hence one cannot say with certainty what the situation will be 3 years forward. But I think there are projections being made by many agencies. So are there any reputed ones which can give a general idea or some sense of what might happen in future.
My main aim is what exactly should be my focus (like what technology/platform/native-web apps), if I want to look at the mobile space for the next 5-10 years.
Please provide as many responses as possible.
My 2c.
The popularity of web based apps will continue to grow. Whether it will pass native apps I don't know. For them to be on par in terms of numbers in 3 years doesn't seem unrealistic.
Native apps have the following benefits:
Better performance (potentially)
Fewer restrictions on accessing device resources
Greater control of execution of application
HTML5 won't completely eliminate the need for native apps (see point 2 above). Even Google who are creating an entirely web based OS (ChromeOS) don't seem to be looking to get rid of Java/Dalvik for Android based dev.
"code once, run anywhere" is very unlikley for anything but the simplest of apps/functionality.
"Code once, compile for each supported platform then test everywhere" is much more realistic.
I'd recommend focusing your education on what makes a great mobile regardless of platform and looking at web based development.
1: Native. It will always be preferred, as it is the most convenient type of app. Personally, I only have one web-app on my phone.
2: The iOS-framework. It is really the largest upside of the native apps. And the fact that they are easily downloadable through the App Store.
I need help clearing up some questions regarding these several third party dev-support frameworks (e.g. ViXML, Titanium Mobile) which promise iPhone app development at lightning speed using only Javascript and XML, without knowledge of Objective-C.
Questions
Are there any features possible on a regular Xcode development platform that are NOT possible for someone creating an app using these frameworks?
Is there any real savings in money and time when working with these platforms?
The approach to simplify development like this has been tried time and again, on many different platforms.
You always have the problem that the development framework will lack some features the "real" system has, and while sometimes a passthrough mechanism is offered it is invariably clunky.
Sometimes they do offer speed gains, but the degree to which they benefit you depends on the domain you are in - Unity is a great example of a framework that obviously saves people a ton of time developing games.
I personally think, that outside of gaming I don't think the benefit of using a third party framework to be really worthwhile. All of the best apps are ones that leverage the system to the fullest in terms of animation or UI abilities, meaning that someone spending some time crafting will be able to make a nicer looking app than someone who has to rely on the abilities of a framework.
The other problem you can run into is that no matter how popular a third party framework is, you are always going to have lots more support for the official platform - like the number of books around today on Objective-C and iPhone development, or even the very active Objective-C support on this very site.
The only exception would be if you had to have a cross-platform app and the app supported development for all the platforms you need. But even then I would argue for making the iPhone app distinct and take fullest advantage of the platform, or your app will languish and other competitors will overcome you.
Q1) Yea, performance. Javascript is slow on the iPhone, because the processor is slow. It's just a cold hard truth. Heck, loading NIBs vs using hand coded views is slow, because of the processing and loading involved, and that's simple compared to Javascript. Javascript is wonderful, but partly because we have really fast processors today. The iPhone (nor the Pre for that matter) have particularly fast processors, and Javascript's performance suffers because of it.
I have not used the frameworks, so can not comment on their productivity claims.
For question 1: non-native apps may not be able to access GPS information or other hardware on the phone.