This Is What Developing For Android Looks Like
61–70 of 94 posts
Re: This Is What Developing For Android Looks Like
#62Earlier quoted context omitted.
I'm not sure either, but I think screen size/resolution/aspect ratio and different hardware "tools" (ie cameras with different resolutions, does it have one led or 2 for flash, etc) have potential to be problems. I'd like to hear more on this issue though.
Because all PCs have the same screen size, resolution, and aspect ratio? Please.
Next time you fire up your image editing program on a PC resize the window to 90%, 70%, 50%, 30%. Try and use your application.
At the smaller windows sizes you just can't. There is simply not enough real estate to accommodate the UI.
Desktop applications have simply assumed you have a certain amount of real estate at some given level of technology. Anything better is usually just gravy since you have everything you need on your screen.
We know simply resizing does not work. Just try an iPhone app on an iPad at 2x.
I'd wager the points where you have to reconsider the UI are much closer together at small sizes. An extra half inch in screen size could allow just one more icon and make your app that little bit nicer to use.
Even if you fix the hardware compatibility problem (they solved it for PCs) it's still going to suck without new ways to design apps.
Re: This Is What Developing For Android Looks Like
#63Earlier quoted context omitted.
In all honesty, there is an interesting debate here. A lot of developers are saying 5-6 devices is sufficient for compatibility testing. But Animoca argues that doing 400 is actually a competitive advantage for them.
Firstly, it's not the headline I'm talking about. The whole tone of the article is "this is what developing for Android is like." Having to test on 400 devices is NOT what developing for Android is like, AT ALL. So you talk to many of the top developers. That's great, how about we hear from a selection of them? How many devices do most of them test on? Taking QA seriously is not the same thing as testing on hundreds…
They have an overflowing safe that is no longer able to contain all of the Android devices they QA test with...
Re: This Is What Developing For Android Looks Like
#64Earlier quoted context omitted.
In all honesty, there is an interesting debate here. A lot of developers are saying 5-6 devices is sufficient for compatibility testing. But Animoca argues that doing 400 is actually a competitive advantage for them.
Firstly, it's not the headline I'm talking about. The whole tone of the article is "this is what developing for Android is like." Having to test on 400 devices is NOT what developing for Android is like, AT ALL. So you talk to many of the top developers. That's great, how about we hear from a selection of them? How many devices do most of them test on? Taking QA seriously is not the same thing as testing on hundreds…
What I can do however, is do many stories per day, and consistently talk on background to multiple devs every week about their concerns. QA testing for Android has been an on-and-off concern for years.
Animoca has talked to me about it a couple times over the last 18 months, but this image for whatever reason happened to go viral.
This story hit a chord. I had some sense it would but I couldn't have 100% predicted it.
Re: This Is What Developing For Android Looks Like
#65Earlier quoted context omitted.
Tks, it's a simple headline that gets a point across. I talk on a weekly basis with many of the top-grossing devs on both platforms so I try to listen to their issues. This was not meant to be a warning for devs to stay away of Android, but doing more extensive QA testing is a reality of the platform. What's your app? How many DLs does it have? How many DAU do you have?
The apps I built varies. Some have hundreds, some have 10K+. But you know what's a better example? Netflix. They test on 10 phones & 4 tablets. http://techblog.netflix.com/2012/03/testing-netflix-on-andro... Netflix App has at least 10 million installs - https://play.google.com/store/apps/details?id=com.netflix.me... .
"We figured out the optimal combination of devices to give us maximum coverage. We are able to reduce our daily smoke automation devices to around 10 phones and 4 tablets and keep the rest for the longer release wide test cycles."
Re: This Is What Developing For Android Looks Like
#66Part of the problem is Google is releasing OSes faster than devices can keep up, and in a few cases I'm buying simply because the prior's OS is stuck yet I have to satisfy new devices users too. For example, I have Galaxy Tab from IO which is stuck on 3.1, but all new tablets use 4.0 and there's unexpected differences between them.
The killer reason for us is the dreaded 1-star review because we missed a particular combo (screen/OS). We have > 1M users between 2 apps w/ 4.2+ ratings each as a result.
Once you're making some good $$, you really can't afford not to have a device library.
Re: This Is What Developing For Android Looks Like
#67Earlier quoted context omitted.
Because it is early days for Android still (don't forget Android is less than 5 years old), and manufactures are still doing wacky things, and people are still uncovering bugs and edge cases. In the early days of MS-DOS compatibility was a big problem too. Magazines used to use MS Flight Simultor to test how compatible PCs were - plenty failed that.
There is a difference though: The IBM PC was the undisputed gold standard for compatibility. Software typically listed the hardware requirements as "IBM PC or 100% compatible". (Some non-IBM-compatible DOS hardware was sold, but it died out pretty quickly). It doesn't look like there any similar gold standard is emerging for phones.
For non gaming apps, testing on Samsung & HTCs is usually enough to cover 90% of the market.
Gaming graphics makes that more complicated, but the truth is that people still find driver and game bugs on Windows.
Re: This Is What Developing For Android Looks Like
#68I'm not an android developer, but I am curious. Why is it that testing on dozens/hundreds of platforms is considered essential for cell phones, but not for PCs? Is android just that much worse at abstracting hardware than traditional OS'es?
Re: This Is What Developing For Android Looks Like
#69Earlier quoted context omitted.
Firstly, it's not the headline I'm talking about. The whole tone of the article is "this is what developing for Android is like." Having to test on 400 devices is NOT what developing for Android is like, AT ALL. So you talk to many of the top developers. That's great, how about we hear from a selection of them? How many devices do most of them test on? Taking QA seriously is not the same thing as testing on hundreds…
This is "process" journalism where we figure it out as we go. I do several stories a day and frankly, the economic model that supports tech blogging today does not sustain a content model where I can write one story per day and interview dozens of sources. What I can do however, is do many stories per day, and consistently talk on background to multiple devs every week about their concerns. QA testing for Android has…
Now, hn, could we please not discourage authors from joining the discussion here? If you hit the down arrow and the post turns grey they really deserve an explanatory post. Even though it's "obvious".
Re: This Is What Developing For Android Looks Like
#70Someone needs to take a picture of all the desktop PCs, laptop PCs, tablet PCs, netbook PCs and then say "This is what developing for Windows looks like". I'm sure it would be an order of magnitude bigger, maybe 2 or 3 depending on how far back you decide to go. Or even add up all the mac models from the last 5 years. Heck, I have friends still using power PC macs.
Windows does a good job of abstracting the hardware away and preventing the OEMs from tweaking the APIs so this isn't an issue in most cases. The major exception is for the large game developers who have to buy tons of various configurations of GPUs and motherboards in order to test various configurations. Basic hardware accelerated graphics works well across platforms but AAA games use complex shaders and heavy opti…
The same is also true for Android. Most (all?) of the valid complaint about how hard it is to target different Android devices comes from game developers struggling to get which version of OpenGL to use, which OpenGL API calls are bugged on which devices, how to circumvent low level GPU limitations on this or that device, etc. And afaik, those are usually based on incomplete and broken implementations by GPU vendors as well. Same as with windows.
Most of the regular utility app, which use normal Android layout and API instead of OpenGL, are doing fine just testing their app in different AVDs (instances of the emulator) just to make sure they're compatible with different devices.
(then of course, there's a few newbies who didn't spend 10 minutes reading the guide for running on different devices on d.android.com, then whine their app's font looks different on a friend's phone. But I'm counting those out)