Well, after i started encountering such issues i just LOADED my app with debugging information, like, seriously redonkulous amounts of logging. There's nothing the app didn't log, sorted with tags and extra information to say exactly what is doing on and why. It was easier to fix bugs of even things i did not have in my hand... heck, most of the bugs i solved were of devices i never even held. (all the logs were surrounded by a constant variable that was set during compilation, so that code never made it to release versions, it makes it easier to manage app versions).
I guess that will not be as easy to do with a game, but it should still be better than what you have now. You can make it a "feature" of the app, let the user community engage with you (the developer) and "actively participate in the creation of the game" and what not... you'll solve bugs, they'll feel as a contributer and get their apps running better. If your game is a paid game, make sure the debug versions are limited in capability and will only be good for debugging. On Monday, July 29, 2013 12:29:25 AM UTC+3, Omer Gilad wrote: > > What you wrote is the obvious part of what I do - test with beta users. I > agree that this is a must. > > The problem is, sometimes it's impossible to debug what you find. > When the issue is not a simple crash stack trace - but rather some > behavior, or display issue, you can't just keep ping-ponging versions with > a user without wasting whole days on that... You need the device in your > hand. > And as an indie developer, it's practically impossible to get a hold of > many different devices. > > > On Sunday, July 28, 2013 12:47:30 PM UTC+3, Piren wrote: >> >> Wrote a lengthy response but my browser decided not to post it, so here's >> the short version: >> >> - That's a known problem with android development, it was obvious about a >> couple of months after it came out. when the premise of the system is to be >> open and as varied as possible, this kind of issues are a given. >> - Under your limitations, the best approach is to release the app only to >> a small subset of devices it was tested on and expand that subset as time >> goes on. Use an open beta group for devices you do not have access to. Even >> Netflix was released on only 5 devices. >> - iOS development might not have this issue (it has fragmentation, but it >> isn't the same as android's), but over all i believe android has a more >> developer friendly ecosystem... instead of being frustrated with this, >> you'll find more than enough other iOS specific issues that will frustrate >> you.. especially since you're used to how Android is. >> >> >> >> On Friday, July 26, 2013 1:39:14 AM UTC+3, Omer Gilad wrote: >>> >>> .I am wondering how developers here are dealing with the fact that there >>> are 1000's of devices out there, some of them running your applications in >>> very broken ways >>> .I keep running into these kind of issues again and again for the past 3 >>> years, and to be honest, I'm fed up with it >>> .I've decided to move to iOS development, and the only way to convince >>> me otherwise is to give me a decent, reliable way of dealing with >>> fragmentation >>> >>> So what do you do when you develop a game, for example, and try to >>> create a high-quality user experience on Google Play? >>> Do you do your QA on 50 different devices? 100? 1000? >>> Or do you just shoot blindly and hope that it works, or wait for users >>> to send you bug reports? >>> >>> To make it clear, I'm not talking about "official" fragmentation. >>> I don't talk about different screen sizes, densities, features, OS >>> versions and so on. >>> I talk about the "unofficial" fragmentation. The fact that most devices, >>> even the popular ones from the big companies like Samsung, HTC, Motorola, >>> LG and so on, contain tons of implementation bugs that prevent apps from >>> working correctly. >>> I'm talking about the fact that you can call a certain simple API, test >>> it on a stock Android ROM (like on Nexus 4), and then have your application >>> crash on some Samsung, that decided to break the implementation because of >>> some customization. >>> >>> How can people stand that? >>> How is it possible to write code, when the machine that executes it is >>> completely broken in unexpected ways? >>> >>> I'm really fed up with it. >>> About 50% of my Android development time is wasted on babysitting broken >>> devices. >>> I'm waiting for an official Google response about this, and what have >>> you been doing in all those years to fix that. >>> I've heard about things like "conformance tests" for devices and so on, >>> but the reality is far from acceptable in this area. >>> >>> ,Looking forward for helpful responses >>> Omer >>> >> -- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
