-3

Have a nice day I have a webservice which returns a complex array of byte[] of images from database, when i use the tester on internet the result is fast even when I get more of 7 or 10 images. On android I'm using a gridview to show up the images from webservice using ksoap, I don't have problem with 2 images but when I call for 7 images for instance, I cannot recieve any response from webservice, the method which I use to call to webservice get stuck and finally my android application get error "failed binder transaction".

If you know some tips for this issue I'll be glad for you.

thanks in advance

Luis Interiano
  • 11
  • 3
  • Nobody can diagnose the problem of you don't show us what you did. And asking for best practices is off topic on Stack Overflow. – Xaver Kapeller Apr 02 '15 at 18:24
  • Dear God! this is very bad approach for the battery. network connections are heavy. try to cache images and get them in one go in one thread. – Karan Apr 02 '15 at 18:25
  • @Kay There is nothing inherently wrong with downloading images at the same time in multiple threads as long as it is done right. Just look at Volley which actually advertises this feature. – Xaver Kapeller Apr 02 '15 at 18:33
  • Agreed and i know Volley or loopJ libs. But starting one thread and fetching X kb of data is much better than starting 7 threads to fetch X/7 kb of data in each thread, especially on 3G . ofcourse, I am assuming all images are uploaded on same server. Isn't it better to fetch-cache such images for the gridview? I try to minimize network calls as much as possible and cache data. – Karan Apr 02 '15 at 18:40
  • All in context of battery drain. – Karan Apr 02 '15 at 18:42
  • 1
    Well caching data is a no brainer, but when it comes to battery drain because of the 3g/lte connection than the amount of connections at the same time makes basically no difference. Regardless of if you download the data sequentially or in parallel you still need to download the same amount of data. The important part ist that you let the modem sleep as much as possible. Bundle requests together and download everything at the same time. If the modem has to constantly wake up download something and go to sleep again then you are really going to waste a lot of battery. – Xaver Kapeller Apr 02 '15 at 18:49
  • @Kay The batter historian tool which was released with Android 5.0 is really great in that regard because you can see exactly when and how much battery your app uses and you can easily identify potential problems. – Xaver Kapeller Apr 02 '15 at 19:56
  • @Xaver Yes, 7 simultaneous worker threads dividing payload among them does seem lesser wake time for the radio and good news for the battery life. But the new question would be memory usage due to these many threads. What can be an optimum way to do this task? At this point I think having maximum number of connections would be a good idea. Not a restriction by Android like Marcos said, but an optimum number of connection followed as good practice. will look into this further(and how to bundle requests). – Karan Apr 02 '15 at 20:37
  • Thanks for your comments, actually I just use one thread to get my information from webservice, i think that is necessary because with it I get the information that i need, as i mentioned above, my webservice returns images in array bytes[] from database, my android app get those bytes[] and save it into an arraylist and then i use it for gridview, When you said "to try to cache images" How can i cache those images if they come in bytes[]? – Luis Interiano Apr 02 '15 at 21:10

1 Answers1

-2

Remember to response.consumeContent() even if it fail so Android can free up connections.

Unknown sources says: By default Android limit network connections to be 2 at the same time. (updated for more at newer releases)[lack official reference]

So trying to open more threads will make then wait until one connection is free.

Marcos Vasconcelos
  • 18,136
  • 30
  • 106
  • 167
  • Can you add some links to official documentation which references this 2 connection at a time limit? I highly doubt that this is true. If it is then I would be really surprised as I have never ever run into that problem... – Xaver Kapeller Apr 02 '15 at 18:23
  • For example Volley can handle many http requests at the same time. Your statement that there is some kind of limit on concurrent connections seems more and more wrong. – Xaver Kapeller Apr 02 '15 at 18:35
  • I've been working on Android for 6 years and this is the first time I've ever heard of that. Such a limit makes no sense. Unless you can post some evidence I'm going to assume this is just wrong. – Gabe Sechan Apr 02 '15 at 18:57
  • Not sure where I saw this for the first time, but I'm working with a project for 3 years and I can see the limit happening, and it's not my Executor, its really network limit. I'm searching for official references of it. – Marcos Vasconcelos Apr 02 '15 at 20:55
  • Actually: http://www.browserscope.org/?category=network&v=top&ua=Android%202.2,Android%202.3,Android%203.1 http://www.stevesouders.com/blog/2011/09/21/making-a-mobile-connection/ I got the problem at Android 2.2, this was updated, still looking official references. – Marcos Vasconcelos Apr 02 '15 at 20:58
  • THis is a limit of the default Android browser, not the OS from what I can find. Big difference. Especially when it says a 6 second inactivity timeout, which is not the case of raw TCP sockets in Android. A UrlConnection shouldn't fall under this limit. – Gabe Sechan Apr 02 '15 at 23:58