Hey Mike I still didn't get answers to my questions about this service... What are the remote devices that the code is running on? Do I need to instruct a user to install this on his own device?
On Monday, July 29, 2013 8:56:12 PM UTC+3, Mike wrote: > > Use my App, you can run code on remote device, not just read logs: > https://cloudshellapp.appspot.com/ > https://play.google.com/store/apps/details?id=com.cloudshell > > The App will allow you to run code on remote Android phones, > so you can fix the bug on the phone you do not have physical access to. > > On Monday, July 29, 2013 2:57:18 AM UTC-4, Piren wrote: >> >> 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
