you said "Android was DESIGNED to use Dalvik as the NATIVE path"
Can you tell me what the "N" in NDK stands for? I'll save you the trouble - from Android.com
NDK is designed for exactly what I said it would be used for. To write native code for either code reuse or performance reasons
This decision of writing native code vs using the java virtual machine is not an issue on iOS because all apps are compiled as native code. Apple's approach is to target the native architecture, not a virtual machine, and to have the compilers do the work of targeting multiple architectures, which is always going to result in more efficient code than a virtual machine approach.
And I don't know where you get the idea that implementing the core app logic in cross platform code hurts the final app experience at all. On the contrary, this is the way to ensure consistent functionality across platforms and to correct and fix bugs.
Maybe native is the wrong word. What I mean is that the SDK/Dalvik is the Programming Method Android was developed around, how Google intended Apps to be developed so that they function properly with android. VM apps are also usually a much smaller .apk, which is really important for Android devices because of how they handle app storage. The NDK uses Native code, but it is not the "Native" path developers should take when bringing their apps to Android.
That's why the final app experience is hurt if you insist on making ALL apps using the NDK. Sure, on the devices you compile it individually for it might work ok (assuming the owner didn't mess with their drivers) but the experience across android will be subpar because your app will not work on a majority of devices because you (most likely) won't take the time and optimized it around different chipsets. On top of that, Most "native code" ports of iOS apps to android tend to copy virtually everything about the iOS app, down to the UI. They don't take advantage of Android differences (Back button, background syncing, the menu key, etc) Aka lazy devs. This leads to a poor experience for the android user because it means that they'll have to relearn their entire way of navigating an app because some dev didn't take the time to actually develop their app for Android.
The Virtual machine isn't perfect, but it's the only way you can give applications a way to run across multiple hardware sets since app space is limited and you can't just pack your .apk full of specific coding for each type of processor. Is it "Inferior" to single platform native code? Yes. But until App storage space becomes a non-issue (so you can pack whatever specific code you need into the .apk) or hardware makers settle on similar parts. The Latter will not happen. Because even if the Hardware is tightly controlled by a central group this will not mean that everything will play nice. (Look at WindowsPhone7 upgrade fiasco's) Developing for Android is Fundamentally different from developing for iOS. This does not mean it's fundamentally inferior, it means that you cannot expect to do the same thing you've always been doing, wiggle around some code, and have a new distribution market. Even IF you could develop in Native code, doing that would result in an inferior product to someone who actually built the app for Android.
And yet again, what your complaining about has absolutely NOTHING to do with the survey at hand or with Fragmentation as This survey or most consumers look at the problem. In fact, most devs don't look at it this way either because they DO use the SDK. This whole tangent you've gone off about "Cross Platform" fragmentation is a moot point, because even IF I could find something to answer this question to your liking you'd then bring up app profitability on android or some other topic (that's not related to the article) for whatever reason.
Messaging apps are developed using the SDK, which automatically handle different resolutions, speed and hardware configs. This is easily available knowledge.
THe ONLY fragmentation issues come up when you're working with the NDK, or your app requires an API level not available in older versions (which most don't)
If I assume that my app will work on all Android devices without testing, I am a bad developer. Assumption is the mother of all f***ups.
Even on iOS, even though iOS supports multiple languages natively, some messaging apps have problems with non alphanumeric languages, the selection of Chinese characters don't show up because the text box is too short. All these can be prevented with proper testing.
My point remains the same, I can code, test against the reference handset and pray it is enough.
Alternatively, I can do my job as a developer and test against most handsets to ensure my users get what they paid for and save my support team the hassle of dealing with problems that can be eliminated before launch. If I can't do that, I rather walk away.
If I assume that my app will work on all Android devices without testing, I am a bad developer. Assumption is the mother of all f***ups.
Even on iOS, even though iOS supports multiple languages natively, some messaging apps have problems with non alphanumeric languages, the selection of Chinese characters don't show up because the text box is too short. All these can be prevented with proper testing.
My point remains the same, I can code, test against the reference handset and pray it is enough.
Alternatively, I can do my job as a developer and test against most handsets to ensure my users get what they paid for and save my support team the hassle of dealing with problems that can be eliminated before launch. If I can't do that, I rather walk away.
You of course should be able to test the applications, and most developers do. (Google has a built in error report system for if apps crash as well, that users can opt to send you data). But what I'm saying is that the SDK allows you to code your app without having to code it for each specific hardware/software combination. Some tweaking may still be required, but the SDK minimizes it greatly.
You of course should be able to test the applications, and most developers do. (Google has a built in error report system for if apps crash as well, that users can opt to send you data). But what I'm saying is that the SDK allows you to code your app without having to code it for each specific hardware/software combination. Some tweaking may still be required, but the SDK minimizes it greatly.
My complaint has never been about having to code for different devices, it is the testing that is a problem. The sheer number of devices to test makes it a huge task.
Think about it another way, if I create a website I test it against the major browser engines on the market to make sure it displays correctly. IE, Safari, Chrome, Firefox and Opera. Now imagine if all of a sudden instead of just 5, there are 100 different browser engines. My development time stays the same but I now need to spend 20 times as long on testing.
Do you think Mac developers test on every Mac model? Do you think that cross-platform developers test on every possible configuration of computers available in the market?
No dev who wants to stay in business could possibly afford what you suggest is the only way to avoid "f**ups".
Yet software happens, profitably, on every platform, every day.
That pretty much sums up the compatibility issue.
Any decent developer will test against at least all current models. Meaning the MacBook, MacBook Air, MacBook Pro, Mac Pro, iMac and Mac Mini. That is only 6. If you are really careful, you test 9, including the 2 Airs and 3 MBPs. Double that for 2 OS versions.
Comments
you missed my edits to my post last post.
you said "Android was DESIGNED to use Dalvik as the NATIVE path"
Can you tell me what the "N" in NDK stands for? I'll save you the trouble - from Android.com
NDK is designed for exactly what I said it would be used for. To write native code for either code reuse or performance reasons
This decision of writing native code vs using the java virtual machine is not an issue on iOS because all apps are compiled as native code. Apple's approach is to target the native architecture, not a virtual machine, and to have the compilers do the work of targeting multiple architectures, which is always going to result in more efficient code than a virtual machine approach.
And I don't know where you get the idea that implementing the core app logic in cross platform code hurts the final app experience at all. On the contrary, this is the way to ensure consistent functionality across platforms and to correct and fix bugs.
Maybe native is the wrong word. What I mean is that the SDK/Dalvik is the Programming Method Android was developed around, how Google intended Apps to be developed so that they function properly with android. VM apps are also usually a much smaller .apk, which is really important for Android devices because of how they handle app storage. The NDK uses Native code, but it is not the "Native" path developers should take when bringing their apps to Android.
That's why the final app experience is hurt if you insist on making ALL apps using the NDK. Sure, on the devices you compile it individually for it might work ok (assuming the owner didn't mess with their drivers) but the experience across android will be subpar because your app will not work on a majority of devices because you (most likely) won't take the time and optimized it around different chipsets. On top of that, Most "native code" ports of iOS apps to android tend to copy virtually everything about the iOS app, down to the UI. They don't take advantage of Android differences (Back button, background syncing, the menu key, etc) Aka lazy devs. This leads to a poor experience for the android user because it means that they'll have to relearn their entire way of navigating an app because some dev didn't take the time to actually develop their app for Android.
The Virtual machine isn't perfect, but it's the only way you can give applications a way to run across multiple hardware sets since app space is limited and you can't just pack your .apk full of specific coding for each type of processor. Is it "Inferior" to single platform native code? Yes. But until App storage space becomes a non-issue (so you can pack whatever specific code you need into the .apk) or hardware makers settle on similar parts. The Latter will not happen. Because even if the Hardware is tightly controlled by a central group this will not mean that everything will play nice. (Look at WindowsPhone7 upgrade fiasco's) Developing for Android is Fundamentally different from developing for iOS. This does not mean it's fundamentally inferior, it means that you cannot expect to do the same thing you've always been doing, wiggle around some code, and have a new distribution market. Even IF you could develop in Native code, doing that would result in an inferior product to someone who actually built the app for Android.
And yet again, what your complaining about has absolutely NOTHING to do with the survey at hand or with Fragmentation as This survey or most consumers look at the problem. In fact, most devs don't look at it this way either because they DO use the SDK. This whole tangent you've gone off about "Cross Platform" fragmentation is a moot point, because even IF I could find something to answer this question to your liking you'd then bring up app profitability on android or some other topic (that's not related to the article) for whatever reason.
Messaging apps are developed using the SDK, which automatically handle different resolutions, speed and hardware configs. This is easily available knowledge.
THe ONLY fragmentation issues come up when you're working with the NDK, or your app requires an API level not available in older versions (which most don't)
If I assume that my app will work on all Android devices without testing, I am a bad developer. Assumption is the mother of all f***ups.
Even on iOS, even though iOS supports multiple languages natively, some messaging apps have problems with non alphanumeric languages, the selection of Chinese characters don't show up because the text box is too short. All these can be prevented with proper testing.
My point remains the same, I can code, test against the reference handset and pray it is enough.
Alternatively, I can do my job as a developer and test against most handsets to ensure my users get what they paid for and save my support team the hassle of dealing with problems that can be eliminated before launch. If I can't do that, I rather walk away.
If I assume that my app will work on all Android devices without testing, I am a bad developer. Assumption is the mother of all f***ups.
Even on iOS, even though iOS supports multiple languages natively, some messaging apps have problems with non alphanumeric languages, the selection of Chinese characters don't show up because the text box is too short. All these can be prevented with proper testing.
My point remains the same, I can code, test against the reference handset and pray it is enough.
Alternatively, I can do my job as a developer and test against most handsets to ensure my users get what they paid for and save my support team the hassle of dealing with problems that can be eliminated before launch. If I can't do that, I rather walk away.
You of course should be able to test the applications, and most developers do. (Google has a built in error report system for if apps crash as well, that users can opt to send you data). But what I'm saying is that the SDK allows you to code your app without having to code it for each specific hardware/software combination. Some tweaking may still be required, but the SDK minimizes it greatly.
You of course should be able to test the applications, and most developers do. (Google has a built in error report system for if apps crash as well, that users can opt to send you data). But what I'm saying is that the SDK allows you to code your app without having to code it for each specific hardware/software combination. Some tweaking may still be required, but the SDK minimizes it greatly.
My complaint has never been about having to code for different devices, it is the testing that is a problem. The sheer number of devices to test makes it a huge task.
Think about it another way, if I create a website I test it against the major browser engines on the market to make sure it displays correctly. IE, Safari, Chrome, Firefox and Opera. Now imagine if all of a sudden instead of just 5, there are 100 different browser engines. My development time stays the same but I now need to spend 20 times as long on testing.
Do you think Mac developers test on every Mac model? Do you think that cross-platform developers test on every possible configuration of computers available in the market?
No dev who wants to stay in business could possibly afford what you suggest is the only way to avoid "f**ups".
Yet software happens, profitably, on every platform, every day.
That pretty much sums up the compatibility issue.
Any decent developer will test against at least all current models. Meaning the MacBook, MacBook Air, MacBook Pro, Mac Pro, iMac and Mac Mini. That is only 6. If you are really careful, you test 9, including the 2 Airs and 3 MBPs. Double that for 2 OS versions.
That is a very small number compared to Android.