4 ms·

A lot of people here seem to be asking "so what?" In my small experience, the "so what" is that, for example, just today I get an email saying that feature X o

A lot of people here seem to be asking "so what?" In my small experience, the "so what" is that, for example, just today I get an email saying that feature X of my app doesn't work on tablet Y. So now what? Do I go and buy that tablet to see what the problem is? Hardly worth it for the money I make from Android. This sucks for developers for obvious reasons and it sucks for consumers as it's pot luck whether an app will work for you, especially if it's not one of the top 5 devices. I've read it's terrible for 3D programmers as often devices just flat out lie about the GL capabilities they support. Exhibit A: Apportable's android device library https://twitter.com/chinmaygarde/status/349809877176156160/photo/1 https://twitter.com/chinmaygarde/status/349809877176156160/p...

deleted 13y ago
[deleted]
Groxx 13y ago
While Apportable is a very nice example, they're also doing something rather crazy - "cross compiling" apps into a wildly different set of hardware, software, and OS targets. And trying to be efficient about it, for graphics performance. That isn't simple anywhere. I'd call it flat out amazing that they have apparently mostly succeeded, and a massive testament to the level of consistency that does exist.
- threeseed 13y ago
  Cupboards like that are very normal. The last three places I've worked at had similar cupboards in order to support the array of Android devices. And they were just run of the mill web companies. The problem really isn't Android but everyone's screwed up implementation of it.
  - Groxx 13y ago
    From everything I've seen, that's still an exceptionally large cupboard. High-performance uses (games) have big cabinets because, yeah, that's where fragmentation can be extremely damaging. The fragmentation there is real, and can be very painful, and I totally agree that it sucks. But in "run of the mill web companies"? Where I work, we have ~6, but 99%+ of the time we just use our Nexus 4s because 99.9%+ of the time it "just works" everywhere, especially if you stick to an older API / support library and know the quirks. We support 2.2+, have a few 3.0+ and 4.2+ features, and it has been terrifically easy to handle our range - much easier than iOS. The other devices are to see how using the app feels on different sizes / performance classes. Getting that feel is important, but it just requires a couple "token" devices.
orky56 13y ago
I completely agree. As an app developer, it gets very frustrating to see a certain percentage of users who are dealing with issues and not having a consistent approach to solving their issues. It's definitely gotten to a point where we have 3 classes of devices (and thus users) similar to how PC software used to be (and probably still is). 1. Performance: These devices can run your app smoothly even with a large number of assets demanding computational/graphics processing. 2. Basic: These devices can open and run your app but it starts to lag when pushed to the limit. 3. Incompatible: These devices don't make the cut in terms of specs and it's worth not even allowing the app to be downloaded. The quickest way to deal with this is to eliminate the bottom wrung of devices by choosing only to deal with the more recent Android versions since older devices may not be able to upgrade. From there, it's probably worth excluding certain devices based on your app's performance trends (crashes, lags, customer complaints). Obviously, the most optimal solution is to continuously optimize your app to further include more devices.

deleted 13y ago

[deleted]

Groxx 13y ago

While Apportable is a very nice example, they're also doing something rather crazy - "cross compiling" apps into a wildly different set of hardware, software, and OS targets. And trying to be efficient about it, for graphics performance. That isn't simple anywhere. I'd call it flat out amazing that they have apparently mostly succeeded, and a massive testament to the level of consistency that does exist.

threeseed 13y ago
Cupboards like that are very normal. The last three places I've worked at had similar cupboards in order to support the array of Android devices. And they were just run of the mill web companies. The problem really isn't Android but everyone's screwed up implementation of it.
- Groxx 13y ago
  From everything I've seen, that's still an exceptionally large cupboard. High-performance uses (games) have big cabinets because, yeah, that's where fragmentation can be extremely damaging. The fragmentation there is real, and can be very painful, and I totally agree that it sucks. But in "run of the mill web companies"? Where I work, we have ~6, but 99%+ of the time we just use our Nexus 4s because 99.9%+ of the time it "just works" everywhere, especially if you stick to an older API / support library and know the quirks. We support 2.2+, have a few 3.0+ and 4.2+ features, and it has been terrifically easy to handle our range - much easier than iOS. The other devices are to see how using the app feels on different sizes / performance classes. Getting that feel is important, but it just requires a couple "token" devices.

orky56 13y ago

I completely agree. As an app developer, it gets very frustrating to see a certain percentage of users who are dealing with issues and not having a consistent approach to solving their issues. It's definitely gotten to a point where we have 3 classes of devices (and thus users) similar to how PC software used to be (and probably still is). 1. Performance: These devices can run your app smoothly even with a large number of assets demanding computational/graphics processing. 2. Basic: These devices can open and run your app but it starts to lag when pushed to the limit. 3. Incompatible: These devices don't make the cut in terms of specs and it's worth not even allowing the app to be downloaded. The quickest way to deal with this is to eliminate the bottom wrung of devices by choosing only to deal with the more recent Android versions since older devices may not be able to upgrade. From there, it's probably worth excluding certain devices based on your app's performance trends (crashes, lags, customer complaints). Obviously, the most optimal solution is to continuously optimize your app to further include more devices.