I'm amused by what came to my mind because of what you wrote - I thought of 
having a website like that for mutual testing between Android developers.

We can call it "DroidSurfing" (like CouchSurfing), and the point is simple 
- registered like-minded Android developers let your code surf on their 
devices, and in exchange you provide the same luxury for other developers.
Of course, some minimal reputation monitoring is required, just to prevent 
malicious developers from spreading false results or from distributing 
someone's paid app for free...

On Monday, July 29, 2013 1:14:48 AM UTC+3, Kristopher Micinski wrote:
>
> I didn't posit that there were concrete things you could go out and 
> buy right now, so apologies if I misphrased.  I know a group who works 
> on a research project which does basically this, but there's no word 
> on whether it will be open source any time soon.  I think the idea is 
> what I just mentioned, collaborative crowd based testing services that 
> allow you to test on a wide range and variety of devices with very 
> expressive test scripts and possible end user testing when applicable. 
>
> Kris 
>
> On Sun, Jul 28, 2013 at 6:05 PM, Omer Gilad <omer....@gmail.com<javascript:>> 
> wrote: 
> > With all this talk I still haven't seen an example of a testing service 
> that 
> > can actually help me... 
> > Got any links? Anything with a reasonable price that can ease the pain 
> (and 
> > that you used for yourself)? 
> > 
> > BTW, I have worked in the past with some of those remote device 
> providers 
> > (like http://www.keynotedeviceanywhere.com/). 
> > It's very expensive to get a few hours with a device, especially if this 
> is 
> > something you have to do constantly with different devices each time 
> there's 
> > an issue. 
> > And the deal-breaker part - it's so slow, you'll actually have to waste 
> a 
> > whole hour just on installing your app and seeing LogCat. 
> > 
> > 
> > On Monday, July 29, 2013 12:48:16 AM UTC+3, Kristopher Micinski wrote: 
> >> 
> >> So in this case, how does a subscription based test service not help 
> >> you?  I'm not saying that a concrete one exists, but I think this kind 
> >> of debugging service (or coop, essentially) would be a good tool.  You 
> >> include a time metric, do some tasks to help other developers', and 
> >> they do some work of doing yours.  One of the problems here is the 
> >> heterogenous distribution of devices, but I don't think that's an 
> >> inherent limitation. 
> >> 
> >> I've thought about starting up one of these services for a while, but 
> >> don't really have the resources to do so. 
> >> 
> >> (I think in my previous posts you thought I was advocating a 
> >> pushbutton testing service: I wasn't.  But the point still stands: if 
> >> you want to test on greater devices, do it with a service and possibly 
> >> humans in the loop.  Big testing services should integrate this work 
> >> cycle too, for when pushbutton tests don't work...) 
> >> 
> >> Kris 
> >> 
> >> 
> >> On Sun, Jul 28, 2013 at 5:29 PM, Omer Gilad <omer....@gmail.com> 
> 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-d...@googlegroups.com 
> >> > To unsubscribe from this group, send email to 
> >> > android-developers+unsubscr...@googlegroups.com <javascript:> 
> >> > 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<javascript:>. 
>
> >> > For more options, visit https://groups.google.com/groups/opt_out. 
> >> > 
> >> > 
> > 
> > -- 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Android Developers" group. 
> > To post to this group, send email to 
> > android-d...@googlegroups.com<javascript:> 
> > To unsubscribe from this group, send email to 
> > android-developers+unsubscr...@googlegroups.com <javascript:> 
> > 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 <javascript:>. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>

-- 
-- 
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.


Reply via email to