"Each successive version of the Android platform can include updates to the Android application framework API that it delivers.
Updates to the framework API are designed so that the new API remains compatible with earlier versions of the API. That is, most changes in the API are additive and introduce new or replacement functionality. As parts of the API are upgraded, the older replaced parts are deprecated but are not removed, so that existing applications can still use them. In a very small number of cases, parts of the API may be modified or removed, although typically such changes are only needed to ensure API robustness and application or system security. All other API parts from earlier revisions are carried forward without modification."
If I write an app today using API level 20 (Android "L") features, it will not run on your API 19 phone, right?
Updates to the framework API are designed so that the new API remains compatible with earlier versions of the API. That is, most changes in the API are additive and introduce new or replacement functionality. As parts of the API are upgraded, the older replaced parts are deprecated but are not removed, so that existing applications can still use them.
That sounds like how Windows is designed and why it's such a mess.
I was thinking the same thing. That's new code on top of old code which makes the OS more bloated with every update.
This is the industry standard for SDKs. Old code runs, but new code gets more features. The alternative is forcing every developer to update old software, and that would never happen. That probably would be fine for a top-tier app like Strava, but not for smaller shop stuff like medical apps nurses use that are updated every two years.
You can also write iOS apps that target a range of SDK versions, but you'll have some pretty bloated code to manage it.
That sounds like how Windows is designed and why it's such a mess.
Spaghettiware
I read an article from John C. Dvorak on it, but it was in Dutch and I can't find the original on his blog. That search engine sucks (like many) And when I searched for "Windows has become spaghetti-ware" all results were in the form of "Windows has become slow" lol
That sounds like how Windows is designed and why it's such a mess.
I was thinking the same thing. That's new code on top of old code which makes the OS more bloated with every update.
Just like iOS. Many problems disappear when reinstalling as new, and then configuring all settings as they were and add in the apps. One thing with that strategy is that you'll lose your SMS history. Perhaps this can be resolved with iOS8/OSx10.10?
I read an article from John C. Dvorak on it, but it was in Dutch and I can't find the original on his blog. That search engine sucks (like many) And when I searched for "Windows has become spaghetti-ware" all results were in the form of "Windows has become slow" lol
The search engine rules. I didn't even have to type the 'h' in "spaghetti" and found the article:
If I write an app today using API level 20 (Android "L") features, it will not run on your API 19 phone, right?
That's what I was wondering.
People in this thread have been saying that developers should target Ice Cream Sandwich (API level 15) in order to reach the most people. In other words... to be safe... you shouldn't use any APIs or features that appear in later versions of Android (API level 16 and above)
But it sounded like Google Play Services fixed that... allowing older versions of Android to use those newer features.
People in this thread have been saying that developers should target Ice Cream Sandwich (API level 15) in order to reach the most people. In other words... to be safe... you shouldn't use any APIs or features that appear in later versions of Android (API level 16 and above)
But it sounded like Google Play Services fixed that... allowing older versions of Android to use those newer features.
So which is it?
Different services.
Google Play Services is an API that gives a developer access to Google Services. So you can integrate an app with g+ or Google Maps. They are allowing all Android API Levels to access the latest GPS APIs. So, you can implement an Android 2.2 app and your integration with Google Maps will be through the very latest Google Maps API.
On the other hand, that does not have anything to do with my Android 4.4-specific application running on a 2.2 phone.
People in this thread have been saying that developers should target Ice Cream Sandwich (API level 15) in order to reach the most people. In other words... to be safe... you shouldn't use any APIs or features that appear in later versions of Android (API level 16 and above)
Google Play Services is an API that gives a developer access to Google Services. So you can integrate an app with g+ or Google Maps. They are allowing all Android API Levels to access the latest GPS APIs. So, you can implement an Android 2.2 app and your integration with Google Maps will be through the very latest Google Maps API.
On the other hand, that does not have anything to do with my Android 4.4-specific application running on a 2.2 phone.
Ok... so Google Play Services just allows people with older versions of Android to access certain Google apps and services. It has nothing to do with the thousands of other individual APIs.
So if there was some groundbreaking new feature introduced in Android 4.4.... the user absolutely MUST have Android 4.4 to use that feature.
Ok... so Google Play Services just allows people with older versions of Android to access certain Google apps and services. It has nothing to do with the thousands of other individual APIs.
So if there was some groundbreaking new feature introduced in Android 4.4.... the user absolutely MUST have Android 4.4 to use that feature.
Is that right?
Correct, but a groundbreaking new feature in Google Maps could be made available for an app that runs on Android 2.2, assuming the devs implemented a feature that used it and released an app update.
Correct, but a groundbreaking new feature in Google Maps could be made available for an app that runs on Android 2.2, assuming the devs implemented a feature that used it and released an app update.
Gotcha.
But what about non-Google features?
For instance... Android "L" will introduce 5,000 completely new APIs. (some Google... some not)
So in order for a developer to use the new non-Google Service APIs... the user must have Android "L"
Instead... developers will forgo most of those new "L" features until enough people can use them... right?
I'm just trying to wrap my head around this.
iOS 7 is installed on 91% of its devices... which allows tons of people to take advantage of the new features introduced in iOS 7
But then I've seen comments saying "85% of Android users are using 4.X so it's not that bad"
That's fine if you only use the features introduced in Android 4.0. But if there is some amazing feature available in Android 4.4... your audience isn't so big after all.
For instance... Android "L" will introduce 5,000 completely new APIs. (some Google... some not)
So in order for a developer to use the new non-Google Service APIs... the user must have Android "L"
Instead... developers will forgo most of those new "L" features until enough people can use them... right?
I'm just trying to wrap my head around this.
iOS 7 is installed on 91% of its devices... which allows tons of people to take advantage of the new features introduced in iOS 7
That's the problem with their fragmentation and lack of order. Developers who want to target the highest number of potential customers have to focus on the APIs available for the highest number of potential customers. A developer could use the latest API for newer devices with a fallback for older OSes but that's a lot of extra effort.
But then I've seen comments saying "85% of Android users are using 4.X so it's not that bad"
That's fine if you only use the features introduced in Android 4.0. But if there is some amazing feature available in Android 4.4... your audience isn't so big after all.
I think Google uses that versioning system to make it seem better than it is, but each primary version number should be unique to a whole new set of APIs. Oddly Google goes the other way with Chrome by jumping up the primary version number seemingly every month.
For instance... Android "L" will introduce 5,000 completely new APIs. (some Google... some not)
So in order for a developer to use the new non-Google Service APIs... the user must have Android "L"
Instead... developers will forgo most of those new "L" features until enough people can use them... right?
I'm just trying to wrap my head around this.
iOS 7 is installed on 91% of its devices... which allows tons of people to take advantage of the new features introduced in iOS 7
But then I've seen comments saying "85% of Android users are using 4.X so it's not that bad"
That's fine if you only use the features introduced in Android 4.0. But if there is some amazing feature available in Android 4.4... your audience isn't so big after all.
That's the fragmentation problem with Android. There are API features that won't be utilized by many new apps until maybe a year after they land, when the number of phones running with support for a specific API version reaches a critical mass. Of course, legacy apps can maintain versions for different API levels, supporting both 2.2 and 4.4.4, for example, but with different .apk installations. Not many developers are set up to maintain 10 or 15 app versions for various APIs, deciding what new features to try to port backwards like that, and what to just leave out. iOS has a clear advantage here, because there aren't as many API levels out there in popular use.
That said, the new Android and iOS versions bring so much more than just the APIs. The look and feel, process scheduler, memory management, etc. On top of that, the Google apps themselves are my primary apps, and they keep versions around for all devices, especially the latest and greatest. So I can get a new phone with "L" in Oct or Nov this year, and be confident that all the Google apps will make full use of the new OS, and that my other primary apps (Strava, Waze, and Netflix) are probably already there as well.
That's the problem with their fragmentation and lack of order. Developers who want to target the highest number of potential customers have to focus on the APIs available for the highest number of potential customers. A developer could use the latest API for newer devices with a fallback for older OSes but that's a lot of extra effort.
I think Google uses that versioning system to make it seem better than it is, but each primary version number should be unique to a whole new set of APIs. Oddly Google goes the other way with Chrome by jumping up the primary version number seemingly every month.
Right... which is why Google also has the API Level numbers listed too.
4.X is meaningless when you consider:
4.0 = API Level 15
4.1 = API Level 16
4.2 = API Level 17
4.3 = API Level 18
4.4 = API Level 19
If you write an app to take advantage of features in 4.4 (API Level 19) it won't do all it's supposed to do if you have Android 4.3 or below (without a lot of workarounds, right?)
That sounds like how Windows is designed and why it's such a mess.
I was thinking the same thing. That's new code on top of old code which makes the OS more bloated with every update.
Just like iOS. Many problems disappear when reinstalling as new, and then configuring all settings as they were and add in the apps. One thing with that strategy is that you'll lose your SMS history. Perhaps this can be resolved with iOS8/OSx10.10?
Just buy iExplorer and export your SMS messages. Problem solved.
Comments
"Each successive version of the Android platform can include updates to the Android application framework API that it delivers.
Updates to the framework API are designed so that the new API remains compatible with earlier versions of the API. That is, most changes in the API are additive and introduce new or replacement functionality. As parts of the API are upgraded, the older replaced parts are deprecated but are not removed, so that existing applications can still use them. In a very small number of cases, parts of the API may be modified or removed, although typically such changes are only needed to ensure API robustness and application or system security. All other API parts from earlier revisions are carried forward without modification."
If I write an app today using API level 20 (Android "L") features, it will not run on your API 19 phone, right?
That sounds like how Windows is designed and why it's such a mess.
I was thinking the same thing. That's new code on top of old code which makes the OS more bloated with every update.
I was thinking the same thing. That's new code on top of old code which makes the OS more bloated with every update.
This is the industry standard for SDKs. Old code runs, but new code gets more features. The alternative is forcing every developer to update old software, and that would never happen. That probably would be fine for a top-tier app like Strava, but not for smaller shop stuff like medical apps nurses use that are updated every two years.
You can also write iOS apps that target a range of SDK versions, but you'll have some pretty bloated code to manage it.
Spaghettiware
I read an article from John C. Dvorak on it, but it was in Dutch and I can't find the original on his blog. That search engine sucks (like many) And when I searched for "Windows has become spaghetti-ware" all results were in the form of "Windows has become slow" lol
Just like iOS. Many problems disappear when reinstalling as new, and then configuring all settings as they were and add in the apps. One thing with that strategy is that you'll lose your SMS history. Perhaps this can be resolved with iOS8/OSx10.10?
Spaghettiware
I read an article from John C. Dvorak on it, but it was in Dutch and I can't find the original on his blog. That search engine sucks (like many) And when I searched for "Windows has become spaghetti-ware" all results were in the form of "Windows has become slow" lol
The search engine rules. I didn't even have to type the 'h' in "spaghetti" and found the article:
http://www.pcmag.com/article2/0,2817,2418117,00.asp
Blimey! I bet you didn't use DuckDuckGo. Thanks man
Blimey! I bet you didn't use DuckDuckGo. Thanks man
(google)
...
That's what I was wondering.
People in this thread have been saying that developers should target Ice Cream Sandwich (API level 15) in order to reach the most people. In other words... to be safe... you shouldn't use any APIs or features that appear in later versions of Android (API level 16 and above)
But it sounded like Google Play Services fixed that... allowing older versions of Android to use those newer features.
So which is it?
That's what I was wondering.
People in this thread have been saying that developers should target Ice Cream Sandwich (API level 15) in order to reach the most people. In other words... to be safe... you shouldn't use any APIs or features that appear in later versions of Android (API level 16 and above)
But it sounded like Google Play Services fixed that... allowing older versions of Android to use those newer features.
So which is it?
Different services.
Google Play Services is an API that gives a developer access to Google Services. So you can integrate an app with g+ or Google Maps. They are allowing all Android API Levels to access the latest GPS APIs. So, you can implement an Android 2.2 app and your integration with Google Maps will be through the very latest Google Maps API.
On the other hand, that does not have anything to do with my Android 4.4-specific application running on a 2.2 phone.
Based on this Google developers blog that would not be the correct way. Target the latest API version but support older ones.
http://developer.android.com/training/basics/supporting-devices/platforms.html
Ok... so Google Play Services just allows people with older versions of Android to access certain Google apps and services. It has nothing to do with the thousands of other individual APIs.
So if there was some groundbreaking new feature introduced in Android 4.4.... the user absolutely MUST have Android 4.4 to use that feature.
Is that right?
Ok... so Google Play Services just allows people with older versions of Android to access certain Google apps and services. It has nothing to do with the thousands of other individual APIs.
So if there was some groundbreaking new feature introduced in Android 4.4.... the user absolutely MUST have Android 4.4 to use that feature.
Is that right?
Correct, but a groundbreaking new feature in Google Maps could be made available for an app that runs on Android 2.2, assuming the devs implemented a feature that used it and released an app update.
Gotcha.
But what about non-Google features?
For instance... Android "L" will introduce 5,000 completely new APIs. (some Google... some not)
So in order for a developer to use the new non-Google Service APIs... the user must have Android "L"
Instead... developers will forgo most of those new "L" features until enough people can use them... right?
I'm just trying to wrap my head around this.
iOS 7 is installed on 91% of its devices... which allows tons of people to take advantage of the new features introduced in iOS 7
But then I've seen comments saying "85% of Android users are using 4.X so it's not that bad"
That's fine if you only use the features introduced in Android 4.0. But if there is some amazing feature available in Android 4.4... your audience isn't so big after all.
That's the problem with their fragmentation and lack of order. Developers who want to target the highest number of potential customers have to focus on the APIs available for the highest number of potential customers. A developer could use the latest API for newer devices with a fallback for older OSes but that's a lot of extra effort.
I think Google uses that versioning system to make it seem better than it is, but each primary version number should be unique to a whole new set of APIs. Oddly Google goes the other way with Chrome by jumping up the primary version number seemingly every month.
Gotcha.
But what about non-Google features?
For instance... Android "L" will introduce 5,000 completely new APIs. (some Google... some not)
So in order for a developer to use the new non-Google Service APIs... the user must have Android "L"
Instead... developers will forgo most of those new "L" features until enough people can use them... right?
I'm just trying to wrap my head around this.
iOS 7 is installed on 91% of its devices... which allows tons of people to take advantage of the new features introduced in iOS 7
But then I've seen comments saying "85% of Android users are using 4.X so it's not that bad"
That's fine if you only use the features introduced in Android 4.0. But if there is some amazing feature available in Android 4.4... your audience isn't so big after all.
That's the fragmentation problem with Android. There are API features that won't be utilized by many new apps until maybe a year after they land, when the number of phones running with support for a specific API version reaches a critical mass. Of course, legacy apps can maintain versions for different API levels, supporting both 2.2 and 4.4.4, for example, but with different .apk installations. Not many developers are set up to maintain 10 or 15 app versions for various APIs, deciding what new features to try to port backwards like that, and what to just leave out. iOS has a clear advantage here, because there aren't as many API levels out there in popular use.
That said, the new Android and iOS versions bring so much more than just the APIs. The look and feel, process scheduler, memory management, etc. On top of that, the Google apps themselves are my primary apps, and they keep versions around for all devices, especially the latest and greatest. So I can get a new phone with "L" in Oct or Nov this year, and be confident that all the Google apps will make full use of the new OS, and that my other primary apps (Strava, Waze, and Netflix) are probably already there as well.
Right... which is why Google also has the API Level numbers listed too.
4.X is meaningless when you consider:
4.0 = API Level 15
4.1 = API Level 16
4.2 = API Level 17
4.3 = API Level 18
4.4 = API Level 19
If you write an app to take advantage of features in 4.4 (API Level 19) it won't do all it's supposed to do if you have Android 4.3 or below (without a lot of workarounds, right?)
.
That sounds like how Windows is designed and why it's such a mess.
I was thinking the same thing. That's new code on top of old code which makes the OS more bloated with every update.
Just like iOS. Many problems disappear when reinstalling as new, and then configuring all settings as they were and add in the apps. One thing with that strategy is that you'll lose your SMS history. Perhaps this can be resolved with iOS8/OSx10.10?
Just buy iExplorer and export your SMS messages. Problem solved.
And how to import them onto my new iPhone, with its freshly installed OS? Can iExplorer do that as well?