Downloading images and caching in memory is working. But there are no displayed image when I turn off internet connection. I expect that there should be displayed images from disc cache ...
Whole problem is described on stackoverflow
http://stackoverflow.com/questions/18633422/square-picasso-not-displaying-images-from-disc-cache
Can you provide a sample app? Are you using OkHttpDownloader
or UrlDownloader
? Its interesting you mention you can see the files in the folder but Picasso won't load them. A sample app would help a lot.
I constantly test our sample app to check disk caching works, and it does.
What phone/android version are you using?
I ran into something just like this, it was the server not providing the correct headers. This might not be a solution for you, but make sure to verify it is sending them correctly. I am currently waiting on our server team to update the implementation to be correct, but outside of that because we have no way to override them on the client.. I am out of luck for disk caching.
@dnkoutso I cannot send you sample app because picasso is used in big project in my work place. Maybe I will try sample app with pictures from server.
@DHucakby I will talk with people from server side. But tell me how correct headers should look like.
@kosttek Use a http debugging utility (A quick google search turned up this - http://web-sniffer.net/) and post the results of the 'Cache-Control' header in the response (if it exists at all).
@kosttek Understood. Creating a sample app might help you even diagnose the problem. If its an Http header problem try switching your client to use some of the sample urls from the sample app in picasso or any other Url for that matter.
Thanks for reporting this and don't worry it will be fixed one way or another.
Hi there, just to chip in some more infos (images are stored in S3).
The headers are:
Status: HTTP/1.1 200 OK
x-amz-id-2: ZkZhba5yomuP/5DFgz1KF5RXdhAWAX1TlYjiBCosdaKu4Yz7TRXLPBQR8TV/SK0Z
x-amz-request-id: 3FE71AFBDD04D9FF
Date: Mon, 09 Sep 2013 04:27:28 GMT
Last-Modified: Thu, 08 Aug 2013 03:26:17 GMT
ETag: "78fab4bd57d04c96c3403307b6ae0f16"
Accept-Ranges: bytes
Content-Type: image/png
Content-Length: 49750
Connection: close
Server: AmazonS3
So there is no Cache-Control header. However I tried again and upload a file with caching enabled:
Status: HTTP/1.1 200 OK
x-amz-id-2: TEIbZzBDzq/mv/GsiWEXqSC0UIPZA6/E18tpt1NjUxwxlI4d6geJY1QgVZihnpFo
x-amz-request-id: 0FD1B11A738D2436
Date: Mon, 09 Sep 2013 04:33:52 GMT
Cache-Control: max-age=315576000
Last-Modified: Mon, 09 Sep 2013 04:33:36 GMT
ETag: "4b445bf12af84091f93de44c3a85adca"
Accept-Ranges: bytes
Content-Type: image/png
Content-Length: 96122
Connection: close
Server: AmazonS3
This will also not trigger the image load from disk.
I can see the cache files in the /data/data/... directory though.
pom.xml just reads
<dependency>
<groupId>com.squareup.picasso</groupId>
<artifactId>picasso</artifactId>
<version>2.0.1</version>
</dependency>
those are headers of image from my service
Status: HTTP/1.1 200 OK
Date: Mon, 09 Sep 2013 08:03:04 GMT
Server: Apache-Coyote/1.1
Content-Type: image/jpeg
Via: 1.1 projectname.extranet.company.com
Connection: close
Transfer-Encoding: chunked
and those from some jpg found in the internet. This image is caching properly (yellow ribbon on top left corner).
Status: HTTP/1.1 200 OK
Date: Mon, 09 Sep 2013 08:04:44 GMT
Server: Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/0.9.8y
Last-Modified: Mon, 26 Mar 2012 18:51:54 GMT
ETag: "4948302-38a3-4bc29de2cc680"
Accept-Ranges: bytes
Content-Length: 14499
Connection: close
Content-Type: image/jpeg
It's really hard to say what's causing this without having something like https://github.com/square/okhttp/issues/270 to see what the response cache of the HTTP client is doing. In any case, Picasso plays NO PART in the actual disk cache so the problem is either in the HTTP client (unlikely) or in the headers returned with the request. Without stepping through the HTTP client's logic it's hard to tell just by looking.
Any updates around this?
I'm getting the same issue since yesterday.
Picasso can't load an image with this url:
http://hespress.com/thumbnail.php?file=kiosque1_855989950.jpg&size=article_medium
But he can load the same image from the server cache with a direct url:
https://t1.hespress.com/cache/thumbnail/article_medium/kiosque1_855989950.jpg
I think the server uses 2 load-balancing servers t1 and s1, and i hope i can get the first url working properly.
GET /thumbnail.php?file=kiosque1_855989950.jpg&size=article_medium HTTP/1.1:
Status: HTTP/1.1 200 OK
Server: zen
Date: Mon, 30 Sep 2013 13:27:54 GMT
Content-Type: image/jpeg
Connection: close
Content-Length: 8477
Last-Modified: Thu, 15 Mar 2012 09:45:00 GMT
Expires: Tue, 30 Sep 2014 13:27:52 GMT
Cache-Control: max-age=31536000
Cache-Control: public
Accept-Ranges: bytes
GET /cache/thumbnail/article_medium/kiosque1_855989950.jpg HTTP/1.1:
Status: HTTP/1.1 200 OK
Server: cloudflare-nginx
Date: Mon, 30 Sep 2013 13:28:07 GMT
Content-Type: image/jpeg
Content-Length: 8477
Connection: close
Set-Cookie: __cfduid=d1f7ca8f71a118eb3d88bacc2e4aac2241380547687584; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.hespress.com
Last-Modified: Thu, 15 Mar 2012 09:45:00 GMT
Expires: Tue, 30 Sep 2014 13:28:07 GMT
Cache-Control: public, max-age=31536000
CF-Cache-Status: HIT
Accept-Ranges: bytes
CF-RAY: b6141276f910479
I'm having this same issue in my app. In my testing, the disk cache is getting populated (@kosttek), but not being used EXCEPT when running on Android 4.4. I've tried on 2.3.7, 4.1.2, 4.2.2, 4.3, and 4.4. The only one that loads from the disk cache is Android 4.4. This is consistent whether running on a device or in the emulator.
I've created a bare-bones test project that exhibits this issue: https://github.com/mikejonesguy/PicassoTest
Android 4.4: (works as expected)
Android 4.3 and earlier: (loads from network even though image is present on disk)
Here's the contents of the picasso-cache folder:
root@generic_x86:/data/data/com.example.picassotest/cache/picasso-cache # ls
104fa73ef35f08124e3cd847c132576e.0
104fa73ef35f08124e3cd847c132576e.1
journal
root@generic_x86:/data/data/com.example.picassotest/cache/picasso-cache # cat 104fa73ef35f08124e3cd847c132576e.0
http://i.imgur.com/DvpvklR.png
GET
1
Accept-Encoding: gzip
HTTP/1.1 200 OK
19
Accept-Ranges: bytes
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Origin: *
Cache-Control: public, max-age=315360000
CF-Cache-Status: HIT
CF-RAY: d193016120707f7
Connection: keep-alive
Content-Length: 93846
Content-Type: image/jpeg
Date: Fri, 22 Nov 2013 22:52:02 GMT
ETag: "39825b3ee802929e4ab5971cd4f34a05"
Expires: Mon, 20 Nov 2023 22:52:02 GMT
Last-Modified: Fri, 12 Apr 2013 05:38:01 GMT
Server: cloudflare-nginx
Set-Cookie: __cfduid=d38897c621831b903923e4f1f4cc5e7611385160722893; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.imgur.com; HttpOnly
Vary: Accept-Encoding
X-Android-Received-Millis: 1385160719049
X-Android-Sent-Millis: 1385160718992
X-Imgur-Cached: 0
To quote JakeWharton: "We can't always know that the image came from the cache. We have to rely on certain synthetic headers reported by the HTTP client. If you use OkHttp this will always work correctly"
You have no dependency on OkHttp in your sample app. In 4.4 HttpUrlConnection is backed by OkHttp, so it makes sense that it works then.
Ah, that makes sense. I was starting to think I was missing something like
this given that it was only working for me properly on KitKat. Thanks, I
will try again with okhttp.
On Nov 22, 2013 7:01 PM, "Simon Vig Therkildsen" [email protected]
wrote:
To quote JakeWhartonhttps://github.com/square/picasso/issues/223#issuecomment-23628401:
"We can't always know that the image came from the cache. We have to rely
on certain synthetic headers reported by the HTTP client. If you use OkHttp
this will always work correctly"You have no dependency on OkHttp in your sample app. In 4.4
HttpUrlConnection is backed by OkHttp, so it makes sense that it works then.—
Reply to this email directly or view it on GitHubhttps://github.com/square/picasso/issues/237#issuecomment-29123237
.
@mikejonesguy were you able to solve that with the okhttp?
Yes, @paddyzab, it appears to be working as expected now on Android 2.3-Android 4.4 (I haven't tested prior to Android 2.3). Sorry for the false alarm.
Closing for now.
Please a help me ....how to code...
I want to show image from server .
In My project, I used cookie.
My Problem is I am OK for image(not with cookie), but
Images show error images(with cookie).
So , how do i code (to set cookie to server by using Picasso library).
Please help me.......
@mikejonesguy can you please post your sample project on Github. I am using OkHttp with Picasso but there is no picasso-cache folder in my device. The image is getting loaded everytime from the network only. Is this because CACHE-CONTROL headers are missing from my response?
I don't have the sample project anymore. My problem was solved when I added
OkHttp.
On Sat, Aug 9, 2014 at 6:41 AM, rahul690973 [email protected]
wrote:
@mikejonesguy https://github.com/mikejonesguy can you please post your
sample project on Github. I am using OkHttp with Picasso but there is no
picasso-cache folder in my device. The image is getting loaded everytime
from the network only. Is this because CACHE-CONTROL headers are missing
from my response?—
Reply to this email directly or view it on GitHub
https://github.com/square/picasso/issues/237#issuecomment-51685573.
This issue was closed because a third party solution handled it correctly?
Picasso isn't an HTTP client. Want a better disk cache? You need a better
HTTP client.
On Wed, Aug 16, 2017 at 10:16 PM Gary Paluk notifications@github.com
wrote:
This issue was closed because a third party solution handled it correctly?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/square/picasso/issues/237#issuecomment-322971012, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEEEckjvRFaxH6FXiy1pduQ4PYzDTsAks5sY8ydgaJpZM4A97Oy
.
Oh no... one of these conversations. So, you see, Picasso does download assets right?! And when you use a load from cache policy, it doesn't actually have any way to load the file if it doesn't exist in the cache. Well, we are programmers, we are there to automate processes of fallback policies. Just saying, and I'll leave that there other than to say that I was easily able to incorporate OkHttp and I am testing but Glide did this just fine so I'll hop on over back to that.
You need something like: NetworkPolicy.CACHE_IF_AVAILABLE
If it's not there in the cache, load from file/url etc using the exact same system that you use for .load()
Glide has it's own disk cache whereas Picasso chooses not to. That's why
Glide as a library is 5x larger and 5x more complex internally. Hence the
need for an HTTP client that doesn't suck when using Picasso.
Also, we don't care at all what you use.
On Thu, Aug 17, 2017, 12:18 AM Gary Paluk notifications@github.com wrote:
Oh no... one of these conversations. So, you see, Picasso does download
assets right?! And when you use a load from cache policy, it doesn't
actually have any way to load the file if it doesn't exist in the cache.
Well, we are programmers, we are there to automate processes of fallback
policies. Just saying, and I'll leave that there other than to say that I
was easily able to incorporate OkHttp and I am testing but Glide did this
just fine so I'll hop on over back to that.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/square/picasso/issues/237#issuecomment-322989523, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEEEdW14HSmIa33KbCZ7kReOIUu19Poks5sY-lhgaJpZM4A97Oy
.
Most helpful comment
Glide has it's own disk cache whereas Picasso chooses not to. That's why
Glide as a library is 5x larger and 5x more complex internally. Hence the
need for an HTTP client that doesn't suck when using Picasso.
Also, we don't care at all what you use.
On Thu, Aug 17, 2017, 12:18 AM Gary Paluk notifications@github.com wrote: