8

What I'm a bit unsure about with Volley is the RequestQueue, ImageLoader objects and ImageLoader.ImageCache implementations..

In the examples I have come across they are instantiated in onCreate() but it doesn't seem to make sense to create a new request queue for each and every activity. I also have loads of activities and services and I will be using it everywhere. If I really do have to instantiate them in each Service or Activity, how expensive are they?

What is best practice production apps are using to instantiate and access these objects?

Eurig Jones
  • 8,226
  • 7
  • 52
  • 74
  • [here are some tutorials](http://androidcustomviews.com/portfolio/volley-easy-fast-networking-for-android/) for volley library may be it helps you. – Girish Bhutiya Aug 07 '13 at 06:41

1 Answers1

10

My experience with Volley is that I would initiate a RequestQueue inside of the Application class passing it a global context to the application. I can't see the downside to doing this just make a static reference to the RequestQueue as such:

public class MyApplication extends Application
{
    private static RequestQueue mRequestQueue;

    @Override
    public void onCreate() {
        super.onCreate();
        mRequestQueue = Volley.newRequestQueue(getApplicationContext());
    }

    // Getter for RequestQueue or just make it public
}

In the documentation as you can for the Application class it quotes:

Called when the application is starting, before any activity, service, or receiver objects (excluding content providers) have been created. Implementations should be as quick as possible (for example using lazy initialization of state) since the time spent in this function directly impacts the performance of starting the first activity, service, or receiver in a process. If you override this method, be sure to call super.onCreate().

So it is safe to assume our RequestQueue will be available to dispatch Requests in a Service, Activity, Loader etc.

Now as far as the ImageLoader is concerned I would make a singleton class wrapping some functionality so you only have one instance of ImageCache and one ImageLoader, Ex.

public class ImageLoaderHelper
{
    private static ImageLoaderHelper mInstance = null;

    private final ImageLoader mImageLoader;
    private final ImageCache mImageCache;

    public static ImageLoaderHelper getInstance() {
        if(mInstance == null)
            mInstance = new ImageLoaderHelper();
        return mInstance;
    }

    private ImageLoaderHelper() {
        mImageCache = new MyCustomImageCache();
        mImageLoader = new ImageLoader(MyApplication.getVolleyQueue(),mImageCache);
    }

    // Now you can do what ever you want with your ImageCache and ImageLoader
}

If you want a really good example of ImageLoading with volley check out this sample project it is really useful.

Hope this helps.

Brosa
  • 1,169
  • 9
  • 19
  • Excellent, this is what I needed. And when you say documentation, where did you find it? Also, as well as the RequestQueue, i am also using an ImageLoader and an ImageLoader.ImageCache implementation. Do you think these are also safe to be used on the application level? – Eurig Jones Jun 27 '13 at 07:05
  • There isn't to much documentation on Volley sadly this is one of the downfalls. There documentation for the Application class can be found here: http://developer.android.com/reference/android/app/Application.html I will make an edit for what you should do with the ImageLoader. – Brosa Jun 27 '13 at 07:07
  • I agree that a singleton is the way to go. However the current implementation does not allow for easy cancelation of image requests ie. there is no way to tag these requests. I'm currently modifying the NetworkImageView class to pass the activity name as the tag to allow for easy cancelation if images when changing to a new activity. – slott Jul 09 '13 at 10:40
  • Just a note. The constructor should be private. Otherwise, nice job. – SBerg413 Nov 01 '13 at 14:54
  • why we have to do this in case of image loading private static ImageLoaderHelper mInstance = null; – blackHawk Mar 24 '17 at 01:41