Hey Jens, I came up with a little workaround.
It's not great, but I'll put it up here in case anyone else runs into this
kind of problem on CBAndroid and Picasso. For any other users, they would
need to inject any more information about their setup (e.g. in my actual
code, I retro-fitted the Uri to actually contain docId and attachment name,
but I'm ignoring that code for now).
public class CouchbaseDownloader implements Downloader {
private Database database;
public CouchbaseDownloader(Database database) {
this.database = database;
}
@Override
public Response load(Uri uri, boolean localCacheOnly) throws IOException {
try {
Attachment image =
database.getDocument(uri.toString()).getCurrentRevision().getAttachment("image");
InputStream stream = image.getContent();
return new Response(stream, true, image.getLength());
} catch (CouchbaseLiteException e) {
e.printStackTrace();
}
return null;
}
}
I also created a singleton wrapper for Picasso - this is strictly due to
how this app is currently structured, and where the Database becomes
available. Ideally, using Dagger, you could inject this in a base module,
but I'm stuck with this wrapper solution until I can get around to a
re-factoring...
public class CBPicasso {
private static Picasso singleton = null;
// Using the same fluent API call as Picasso proper
public static Picasso with(Context context, Database database) {
if (singleton == null) {
synchronized (CBPicasso.class) {
if (singleton == null) {
singleton = new Picasso
.Builder(context)
.downloader(new CouchbaseDownloader(database))
.build();
}
}
}
return singleton;
}
}
On Tuesday, September 9, 2014 3:41:54 PM UTC-4, Suresh Joshi wrote:
>
> I was debating using a custom interface that routes appropriately,
> however, that might mean I would need a separate image caching handler
> (this all stems from possible memory issues of our app when handling
> images, Picasso deals with images really well, which is why I want all my
> images loaded into memory through Picasso).
>
> From what I've read, ideally Picasso is a singleton, and now I'm just
> determining if you can change 'downloaders' on the fly. If so, then this
> whole thread might become moot! (I really hope)
>
> On Tuesday, September 9, 2014 3:35:50 PM UTC-4, Jens Alfke wrote:
>>
>>
>> On Sep 9, 2014, at 12:25 PM, Suresh Joshi <[email protected]> wrote:
>>
>> Picasso is an image loading/smart caching library (something like
>> FastImageCache for iOS). OkHttp is a HTTP protocol library, that Picasso
>> uses internally. I'm trying to override OkHttp to point at the filesystem
>> instead of a web URL (there aren't too many other ways to customize how
>> Picasso works)
>>
>>
>> Hm. But the images are already downloaded. Are you trying to get them
>> into Picasso just because the rest of your app is hardwired to go through
>> Picasso to access resources? If so, could you abstract that to a custom
>> interface, and have the implementation call either Picasso or CBL?
>>
>> —Jens
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/mobile-couchbase/674122d7-0900-461a-bcbe-9aa211b17338%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
