Do tell us of an instance in the past two to three years where that would have been beneficial for iOS.
A Google Play Services-like feature might have helped get some of these fixes out faster. I've no idea how difficult it would be for Apple to separate core apps from the OS itself so perhaps it's a moot question. http://macmint.com/apple-releases-ios-7-0-6-fix-ssl-bug/
That's part of the problem with pretty much everything Google does that I have to assume it's purposely done to avoid transparency. You say Google Android to refer to non-forked versions of Android but the forked version are still using Android which comes from Google. To not cal it Android is like saying Android doesn't use Linux simply because Google did their own thing with it.
This issue goes further when they do API changes but still refer to Android by a specific version number which only looks like it's done so they can claim a higher install base for a given arbitrary value to help obfuscate the amount of fragmentation they really have.
But I don't think it's all from a choice to muddle the facts, I think the other part is simply from bad planning, like with their size chart which has a lot of overlap for the various size categories.
I look at all this and think what a nightmare for developers and customers alike.
Sorry Soli. Just saw this post so I wasn't ignoring you.
I'm not really clear on what point you're trying to make. Google obviously has no control over what Amazon chooses to do with their own Android-based OS build. GOOG committed to AOSP long ago and to their credit still contribute to and maintain it even tho Amazon, Nokia and others who use it for commercial benefit aren't contributing back to it. Are you perhaps saying Google should never have open-sourced any part of the OS and blocked any efforts for others to commercially use it in any way? Or are you proposing that Google help Amazon in developing and maintaining a highly-customized and modified fork of Android that serves only Amazon's purposes? I don't think Amazon even acknowledges that their OS is Android-based, nor how much of Android remains in it.
I'm a bit confused as to what you're trying to say.
In which case you have fragmentation because some devices (Amazon, Chinese vendors) don't connect to Google Play, and others aren't updated even though they conceivably could be. Which is just another dimension of fragmentation introduced in an effort to roll out security updates across a fragmented core OS that cannot be updated on many devices for either device compatibility reasons or device vendor negligence (they don;t work to offer the updates, preferring their customers to be forced to buy a new handset or tablet).
If they don't connect to google play, then they aren't an android service counted in Googles stats
Which was released in 2011. Put in perspective, the phone Apple released in 2011 will be discontinued in three weeks, having received three years of software updates since. And where are the Android software updates?
Different screen pixel density requires different assets. So to support both an iPad and an iPhone, and all it's versions you need 4 sets of assets ,one for every screen size. On Android this just gets impossibly unrealistic to do, so you instead pick the least common denominator between them. In most cases this means omitting "Retina" display versions and just pixel-doubling the assets, at the expense of the image fidelity.
To give you an idea. If you program with Unity, there's at least 3 different GPU types, 2 different pixel densities, and 2 different "aspect ratio" layouts. The Least common denominator for all devices is 4:3 or 16:9, in which any other aspect ratio is then letter boxed. But 3D graphics doesn't care about pixel density, if you have a larger screen, you can just scale up and the worst that will happen is the textures aren't fine enough to make it not look ugly, but at least it scales up. Because the device has a limited amount of RAM, you're often forced to do this anyway. The different GPU types however kills performance. PowerVR is the top of the line, Mali is the bottom. Unity projects tend to ship with a mixture of PVR and Adreno textures on Android.
That's just covering the screen issues. On iOS, they all use PowerVR, so the texture compression is not an issue, and that's why the iOS version of the very same project will be faster no matter what.
Android devices have an ugly kludge for native development and that's the Java/Dalvik parts, that make it a pain in the ass for developers to use. Read the documentation, Google doesn't want you to even use the NDK, but most developers that I'm aware of know Java is a horrible language to develop a game in (no matter what the success of Minecraft will tell you) and will go straight to the NDK. So when you see Intel touting x86 Android images, those come with a ARM to x86 binary translator, so you're still not getting native x86 performance.
Amateur developers don't even know where to begin with Android. You download all this cruft from all over the internet, including a pile of obsolete software (JDK 6 when JDK 7 is current.) iOS, you just download XCode, nothing else.
Amateur developers don't even know where to begin with Android. You download all this cruft from all over the internet, including a pile of obsolete software (JDK 6 when JDK 7 is current.) iOS, you just download XCode, nothing else.
You just go to developer.android.com and download the Eclipse ADT package with has the SDK built in. Yes, you may have to install JDK 6.0 and Apache Ant but the links are right on the developer page so this is not like some huge issue.
Or you can download and install the Android Studio bundle which should also have everything but the JDK which can be JDK 6+.
You just go to developer.android.com and download the Eclipse ADT package with has the SDK built in. Yes, you may have to install JDK 6.0 and Apache Ant but the links are right on the developer page so this is not like some huge issue.
Or you can download and install the Android Studio bundle which should also have everything but the JDK which can be JDK 6+.
- Screen display sizes & densities aren't a deal breaker - but it's time consuming and requires research and knowledge of as much of the ecosystem as possible.
- API inconsistencies and improvements across versions you don't have access to isn't a deal breaker (for others...) - but then you have to find which APIs can go where, to what capacity, and how, for at least 3-4 different versions of Android.
- Spotty hardware support (both on-running and even initially out of the box, depending on the device) isn't a deal breaker - but it's a pain to have to figure out what exactly the producers of the product did and how to achieve "normal" results in scenarios like this (I'm sure you've seen the accelerometer hardware... issue [more of neglect by device makers] within Android devices... ugh).
On it's own, having to run through a process of collecting components and configuring development tools and environments may not seem like a big issue. But stack 4-5 other "not big issues" on top and you've got a lot of time lost. It just seems like it's never just "a few caveats".
This is really where Android starts to look bad to me.
Edit: These are just some of the more common and public knowledge issues I've encountered within Android - diving deeper there are so many more time sinks.
- Screen display sizes & densities aren't a deal breaker - but it's time consuming and requires research and knowledge of as much of the ecosystem as possible.
- API inconsistencies and improvements across versions you don't have access to isn't a deal breaker (for others...) - but then you have to find which APIs can go where, to what capacity, and how, for at least 3-4 different versions of Android.
- Spotty hardware support (both on-running and even initially out of the box, depending on the device) isn't a deal breaker - but it's a pain to have to figure out what exactly the producers of the product did and how to achieve "normal" results in scenarios like this (I'm sure you've seen the accelerometer hardware... issue [more of neglect by device makers] within Android devices... ugh).
On it's own, having to run through a process of collecting components and configuring development tools and environments may not seem like a big issue. But stack 4-5 other "not big issues" on top and you've got a lot of time lost. It just seems like it's never just "a few caveats".
This is really where Android starts to look bad to me.
Edit: These are just some of the more common and public knowledge issues I've encountered within Android - diving deeper there are so many more time sinks.
Folks don't get how much easier Android is to deal with vs Symbian. Yes, iOS is smoother still but Android is by no means overly difficult for a developer.
App exposure and monetization is more of an issue. Pretty much the indie period is over (for both iOS and Android) except as a side hobby you can make beer money off.
Folks don't get how much easier Android is to deal with vs Symbian. Yes, iOS is smoother still but Android is by no means overly difficult for a developer.
App exposure and monetization is more of an issue. Pretty much the indie period is over (for both iOS and Android) except as a side hobby you can make beer money off.
I dare to say that through my experience developing for Android, itis difficult. It's not because it is hard by any means, but because of all of the reasons I explained above and in my other posts.
Which is more than good enough for plenty of high quality developers to say, "F that." and move to other platforms for better toolkits and encourage others to use those platforms through their work (apps) or own experiences with the platform. I was one of those for a very long while and will continue to be after my work with Android is complete.
IOS 7, 91% of IOS users. Android 4, 85.7% of Android users. Of course, that doesn't have the click bait ring to it does it?
-kpluck
So what's your point? There are major security vulnerabilities in all but the latest release, so we should get excited about the version beginning with a 4?
No doubt that's what you meant as it's pretty clear what I had to say was 100% correct, and even verified as such by Eric.
No, I meant lie.
And add "be boring" to that statement.
Your constant need to defend Google speaks volumes.
Obviously, you believe they need to be defended which, in itself, is quite interesting.
Nothing you post here changes the fact that Google is a one-trick pony that has failed to successfully monetise the majority of their many, badly thought out and implemented ideas.
Comments
In this case the guy is a professor at UC Riverside.
http://macmint.com/apple-releases-ios-7-0-6-fix-ssl-bug/
...and some white hats too thank goodness.
How so if the the problem for both is the same (missing features) solution for both is the same (buy new hardware)?
Sorry Soli. Just saw this post so I wasn't ignoring you.
I'm not really clear on what point you're trying to make. Google obviously has no control over what Amazon chooses to do with their own Android-based OS build. GOOG committed to AOSP long ago and to their credit still contribute to and maintain it even tho Amazon, Nokia and others who use it for commercial benefit aren't contributing back to it. Are you perhaps saying Google should never have open-sourced any part of the OS and blocked any efforts for others to commercially use it in any way? Or are you proposing that Google help Amazon in developing and maintaining a highly-customized and modified fork of Android that serves only Amazon's purposes? I don't think Amazon even acknowledges that their OS is Android-based, nor how much of Android remains in it.
I'm a bit confused as to what you're trying to say.
85.7 PERCENT OF ANDROID USERS ARE ON 4.0 OR UP! Nice click bait article!
If they don't connect to google play, then they aren't an android service counted in Googles stats
Features dependent on HW in some way, not APIs.
oh so explain Siri then? Why can't an iPhone 4 or iPad 2 run Siri? Siri is a SOFTWARE that runs off of a server. It requires no new hardware to run.
THIS should be the headline.
"91 percent of iOS users run iOS7, while 85.7 percent of Android users run Android 4.0 or up"
Which was released in 2011. Put in perspective, the phone Apple released in 2011 will be discontinued in three weeks, having received three years of software updates since. And where are the Android software updates?
Two things:
Different screen pixel density requires different assets. So to support both an iPad and an iPhone, and all it's versions you need 4 sets of assets ,one for every screen size. On Android this just gets impossibly unrealistic to do, so you instead pick the least common denominator between them. In most cases this means omitting "Retina" display versions and just pixel-doubling the assets, at the expense of the image fidelity.
To give you an idea. If you program with Unity, there's at least 3 different GPU types, 2 different pixel densities, and 2 different "aspect ratio" layouts. The Least common denominator for all devices is 4:3 or 16:9, in which any other aspect ratio is then letter boxed. But 3D graphics doesn't care about pixel density, if you have a larger screen, you can just scale up and the worst that will happen is the textures aren't fine enough to make it not look ugly, but at least it scales up. Because the device has a limited amount of RAM, you're often forced to do this anyway. The different GPU types however kills performance. PowerVR is the top of the line, Mali is the bottom. Unity projects tend to ship with a mixture of PVR and Adreno textures on Android.
That's just covering the screen issues. On iOS, they all use PowerVR, so the texture compression is not an issue, and that's why the iOS version of the very same project will be faster no matter what.
Android devices have an ugly kludge for native development and that's the Java/Dalvik parts, that make it a pain in the ass for developers to use. Read the documentation, Google doesn't want you to even use the NDK, but most developers that I'm aware of know Java is a horrible language to develop a game in (no matter what the success of Minecraft will tell you) and will go straight to the NDK. So when you see Intel touting x86 Android images, those come with a ARM to x86 binary translator, so you're still not getting native x86 performance.
Amateur developers don't even know where to begin with Android. You download all this cruft from all over the internet, including a pile of obsolete software (JDK 6 when JDK 7 is current.) iOS, you just download XCode, nothing else.
87.8% of all statistics are made up!
LOL look at GeritolGuy go. I hope you get employee of the month.
Amateur developers don't even know where to begin with Android. You download all this cruft from all over the internet, including a pile of obsolete software (JDK 6 when JDK 7 is current.) iOS, you just download XCode, nothing else.
You just go to developer.android.com and download the Eclipse ADT package with has the SDK built in. Yes, you may have to install JDK 6.0 and Apache Ant but the links are right on the developer page so this is not like some huge issue.
Or you can download and install the Android Studio bundle which should also have everything but the JDK which can be JDK 6+.
You just go to developer.android.com and download the Eclipse ADT package with has the SDK built in. Yes, you may have to install JDK 6.0 and Apache Ant but the links are right on the developer page so this is not like some huge issue.
Or you can download and install the Android Studio bundle which should also have everything but the JDK which can be JDK 6+.
- Screen display sizes & densities aren't a deal breaker - but it's time consuming and requires research and knowledge of as much of the ecosystem as possible.
- API inconsistencies and improvements across versions you don't have access to isn't a deal breaker (for others...) - but then you have to find which APIs can go where, to what capacity, and how, for at least 3-4 different versions of Android.
- Spotty hardware support (both on-running and even initially out of the box, depending on the device) isn't a deal breaker - but it's a pain to have to figure out what exactly the producers of the product did and how to achieve "normal" results in scenarios like this (I'm sure you've seen the accelerometer hardware... issue [more of neglect by device makers] within Android devices... ugh).
On it's own, having to run through a process of collecting components and configuring development tools and environments may not seem like a big issue. But stack 4-5 other "not big issues" on top and you've got a lot of time lost. It just seems like it's never just "a few caveats".
This is really where Android starts to look bad to me.
Edit: These are just some of the more common and public knowledge issues I've encountered within Android - diving deeper there are so many more time sinks.
- Screen display sizes & densities aren't a deal breaker - but it's time consuming and requires research and knowledge of as much of the ecosystem as possible.
- API inconsistencies and improvements across versions you don't have access to isn't a deal breaker (for others...) - but then you have to find which APIs can go where, to what capacity, and how, for at least 3-4 different versions of Android.
- Spotty hardware support (both on-running and even initially out of the box, depending on the device) isn't a deal breaker - but it's a pain to have to figure out what exactly the producers of the product did and how to achieve "normal" results in scenarios like this (I'm sure you've seen the accelerometer hardware... issue [more of neglect by device makers] within Android devices... ugh).
On it's own, having to run through a process of collecting components and configuring development tools and environments may not seem like a big issue. But stack 4-5 other "not big issues" on top and you've got a lot of time lost. It just seems like it's never just "a few caveats".
This is really where Android starts to look bad to me.
Edit: These are just some of the more common and public knowledge issues I've encountered within Android - diving deeper there are so many more time sinks.
Folks don't get how much easier Android is to deal with vs Symbian. Yes, iOS is smoother still but Android is by no means overly difficult for a developer.
App exposure and monetization is more of an issue. Pretty much the indie period is over (for both iOS and Android) except as a side hobby you can make beer money off.
Folks don't get how much easier Android is to deal with vs Symbian. Yes, iOS is smoother still but Android is by no means overly difficult for a developer.
App exposure and monetization is more of an issue. Pretty much the indie period is over (for both iOS and Android) except as a side hobby you can make beer money off.
I dare to say that through my experience developing for Android, it is difficult. It's not because it is hard by any means, but because of all of the reasons I explained above and in my other posts.
Which is more than good enough for plenty of high quality developers to say, "F that." and move to other platforms for better toolkits and encourage others to use those platforms through their work (apps) or own experiences with the platform. I was one of those for a very long while and will continue to be after my work with Android is complete.
lol@Symbian vs Android,btw:)
IOS 7, 91% of IOS users. Android 4, 85.7% of Android users. Of course, that doesn't have the click bait ring to it does it?
-kpluck
So what's your point? There are major security vulnerabilities in all but the latest release, so we should get excited about the version beginning with a 4?
No, I meant lie.
And add "be boring" to that statement.
Your constant need to defend Google speaks volumes.
Obviously, you believe they need to be defended which, in itself, is quite interesting.
Nothing you post here changes the fact that Google is a one-trick pony that has failed to successfully monetise the majority of their many, badly thought out and implemented ideas.
It's a shame, really.