Use Interface instead of abstract ListPreloader

In your examples the ListAdapter and the final ListPreloader are strongly connected. Using an Interface will remove this strong connection.

Using an interface that an Adapter can implement has the following advantages:
 1. the dimensions don´t must be passed to the ListPreloader while the Adapter has the first access to the dimensions of the ImageView
 2. you don´t have to pass the items to the ListPreloader, while the Adapter already has the newest set of items (e.g.: CursorAdapter)
 3. in most cases the ListAdapter already has an RequestBuilder, so you don´t have to pass them twice
 4. you get rid of an extra class (ListPreloader) you have to implement

Take a look at adjusted samples in this PullRequest (e.g.: FlickrPhotoList [FlickrPhotoList.java](https://github.com/DavidWiesner/glide/commit/78e46914d418885eeffaedade154bb677a18dc31#diff-ce67ed1d36407a6c2aa6b69fd7d9132f) )

To achieve i moved the abstact methods to an new interface PreloadModelProvider that later will be passed as argument to the ListPreloader

**Future Work**
Think about changing the request to the PreloadModelProvider to  load the preload items one by one instead of requesting a list of items. If you do so you can get ride of the extra List of items will be created in the Adapter.

regards,
David




I think this is a bug. The first time you create the views, they won't have been measured and  ``getWidth()`` and ``getHeight()`` will probably return 0. I think you can get away with it in the grid fragment because those ``ImageViews`` have fixed dp dimensions. In the Giphy sample where the ``ImageViews`` have ``match_parent`` as the width and in the photo list where the ``ImageViews`` use ``layout_weight``, you're probably getting incorrect dimensions.

A ``Runnable`` posted on the view typically is called after the ``View`` is measured and so will get valid sizes. We should at least retain that behavior for the Giphy and PhotoList classes.

In the future, or if you're up to it, it may make sense to extract another interface that is responsible for providing sizes, and provide one implementation that uses fixed dimensions, and another that uses an [``OnPreDrawListener``][1] in the same way [``ViewTarget``][2] does, and that can be provided with a View to set its dimensions from. 

[1]: http://developer.android.com/reference/android/view/ViewTreeObserver.OnPreDrawListener.html
[2]: https://github.com/bumptech/glide/blob/master/library/src/main/java/com/bumptech/glide/request/target/ViewTarget.java#L113