Closed
Bug 905685
Opened 11 years ago
Closed 11 years ago
Implement proper asynchronous and incremental favicon loading in the new about:home
Categories
(Firefox for Android Graveyard :: Awesomescreen, defect, P1)
Tracking
(firefox26 fixed, firefox27 fixed, fennec26+)
RESOLVED
FIXED
Firefox 27
People
(Reporter: lucasr, Assigned: nalexander)
References
Details
Attachments
(5 files, 6 obsolete files)
92.02 KB,
patch
|
Details | Diff | Splinter Review | |
39.02 KB,
patch
|
sriram
:
review+
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
1.71 KB,
patch
|
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
1.71 KB,
patch
|
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
69.62 KB,
patch
|
Details | Diff | Splinter Review |
I bit of context here: getFaviconsForUrls() was originally written with a very specific use case in mind (favicons in the awesomescreen search). This was a very controlled use case because there was a maximum number of items (100). With the new code, we're abusing it by using it in lists that can have an arbitrary number of items (e.g. the bookmarks list). Which is why getFaviconsForUrls() is blowing up after setting up sync (see bug 904081). Our current approach for loading favicons is very fragile for a number of reason: 1. It assumes the favicon mem cache will be able to hold all favicons for the list, which is not necessarily the case (especially for long lists). 2. It's not very memory efficient: we'll be allocating a huge array of strings just to run the query and, more importantly, a huge list of images to put in the memcache (which will then be discarded by the memcache just after). The right thing to do here is to load favicons asynchronously and incrementally. I recommend using a little library called Smoothie which I wrote as a standalone open source project: https://github.com/lucasr/smoothie It provides a simple API to do exactly what we want here. Also, it supports pre-fetching offscreen items so that we don't show temporary placeholders too often as you scroll. In any case, I filed bug to tackle a proper implementation for favicon loading.
Reporter | ||
Updated•11 years ago
|
Blocks: new-about-home
Priority: -- → P1
Reporter | ||
Updated•11 years ago
|
tracking-fennec: --- → ?
Updated•11 years ago
|
tracking-fennec: ? → 26+
Reporter | ||
Comment 1•11 years ago
|
||
Attachment #802246 -
Flags: review?(sriram)
Reporter | ||
Comment 2•11 years ago
|
||
Attachment #802247 -
Flags: review?(sriram)
Reporter | ||
Comment 3•11 years ago
|
||
Attachment #802248 -
Flags: review?(sriram)
Reporter | ||
Updated•11 years ago
|
Attachment #802246 -
Attachment is patch: true
Reporter | ||
Comment 4•11 years ago
|
||
Reporter | ||
Comment 5•11 years ago
|
||
A bit of context here: my initial plan was to simply use Smoothie for incremental favicon loading. I actually wrote the patch. But while working on it, I got this feeling that maybe Smoothie is a bit overkill for such a simple use case. So, I decided to write a simpler UiAsyncTask-based solution as an alternative. Pros and cons of each approach: Option 1: UiAsyncTask-based solution Pros: - Simpler code - Uses our existing background thread infra. - No new dependencies. Cons: - No favicon pre-fetching, more likely to frequently see blank state before favicon is loaded - No gesture awareness, scrolling the list will trigger-and-cancel a bunch of tasks Options 2: Smoothie-based solution Pros: - Offscreen favicon pre-fetching, less likely to see blank state before favicon is loaded - Gesture awareness, no wasted resources while scrolling, for example. Cons: - Adds a new dependency, maintained by me but still... - More inherent complexity/risk, Smoothie's code base is not big but not tiny either. - Creates its own background thread pool, not necessarily a problem but it's a relevant aspect. - Adds a few kbytes to the apk. - Likely to increase about:home's memory footprint a bit. In summary: the Smoothie-based solution is more robust but maybe it does more than we actually need. The UiAsyncTask-based solution is simpler but a little less robust. Given that we're soon merging m-c to aurora, I'm leaning towards the simpler UiAsyncTask-based solution for now. We can re-evaluate that in the next cycle.
Reporter | ||
Comment 6•11 years ago
|
||
FYI: I posted the Smoothie-based solution patch here just for those wondering how the code would look like.
Comment 7•11 years ago
|
||
Comment on attachment 802246 [details] [diff] [review] [Option 1] Implement incremental favicon loading in about:home Review of attachment 802246 [details] [diff] [review]: ----------------------------------------------------------------- All my hard work of refactoring is "gone.. gone.. gone!!"
Attachment #802246 -
Flags: review?(sriram) → review+
Comment 8•11 years ago
|
||
Comment on attachment 802247 [details] [diff] [review] [Option 1] Avoid decoding and scaling favicons if they're in the memory cache Review of attachment 802247 [details] [diff] [review]: ----------------------------------------------------------------- Please confirm if this piece is needed. If so, please try moving the decodeByteArray() off the UI thread. r- just to make sure we don't lose track of the discussion. ::: mobile/android/base/home/TwoLinePageRow.java @@ +192,5 @@ > + // cached yet, try to find it in the cursor. > + Bitmap favicon = Favicons.getInstance().getFaviconFromMemCache(url); > + if (favicon == null) { > + int faviconIndex = cursor.getColumnIndex(URLColumns.FAVICON); > + if (faviconIndex != -1) { To the best of my knowledge. This portion was a piece of dead code. We are always going to the memcache to get it (probably I didn't remove this piece). Do we really need this? Even i so, I wouldn't recommend decoding byte array on the UI thread while binding. It's better to do it in an async-task.
Attachment #802247 -
Flags: review?(sriram) → review-
Comment 9•11 years ago
|
||
Comment on attachment 802248 [details] [diff] [review] [Option 1] Avoid showing previously set favicon while new image is loading Review of attachment 802248 [details] [diff] [review]: ----------------------------------------------------------------- This piece feels like re-setting the images when the view is re-used in ListView. I somehow don't like this approach. This should be done in a recylerlistener with the HomeListView. Using AsyncTask to qualify if a view is requesting a new favicon or not doesn't sound right. This piece should be done when the view is moved to the scrap heap -- through OnRecyclerListener.
Attachment #802248 -
Flags: review?(sriram) → review-
Comment 10•11 years ago
|
||
Just confirming: UiAsyncTask runs on a single thread right? So basically we are using a single thread to post these tasks, instead of going the standard Android way of leaving it to Android to figure it out.
Reporter | ||
Comment 11•11 years ago
|
||
(In reply to Sriram Ramasubramanian [:sriram] from comment #8) > To the best of my knowledge. This portion was a piece of dead code. We are > always going to the memcache to get it (probably I didn't remove this > piece). Do we really need this? Even i so, I wouldn't recommend decoding > byte array on the UI thread while binding. It's better to do it in an > async-task. I actually wondered about the same thing but forgot to mention here. Yeah, you're right, this is probably not being used anymore. I'll double-check and update this patch accordingly. And yes, image decoding and scaling should not be done in the main thread.
Reporter | ||
Comment 12•11 years ago
|
||
(In reply to Sriram Ramasubramanian [:sriram] from comment #9) > Comment on attachment 802248 [details] [diff] [review] > [Option 1] Avoid showing previously set favicon while new image is loading > > Review of attachment 802248 [details] [diff] [review]: > ----------------------------------------------------------------- > > This piece feels like re-setting the images when the view is re-used in > ListView. > I somehow don't like this approach. This should be done in a recylerlistener > with the HomeListView. There's no practical difference between clearing the image in an RecyclerListener and when the Adapter's getView() is called. In both cases, the image will be cleared before the AsyncTask is executed. Doing this in a RecyclerListener would require us to change HomeListView to know its children types (TwoLinePageRow in this case) which would be an unfortunate coupling. > Using AsyncTask to qualify if a view is requesting a new favicon or not > doesn't sound right. This piece should be done when the view is moved to the > scrap heap -- through OnRecyclerListener. Not entirely sure what you mean here but we need to use the AsyncTask to track that because the async loading might finish at any point. One thing I forgot to do in the first patch is to reset mLoadFaviconTask to null once it finishes. I'll update it. Just to be clear: the idea here is that TwoLinePageRow fully owns its async loading routines with depending on which type of parent it has. In other words, we shouldn't assume that TwoLinePageRow is going to be used in a HomeListView with a specific RecyclerListener to cancel tasks or clear state for it.
Reporter | ||
Comment 13•11 years ago
|
||
(In reply to Sriram Ramasubramanian [:sriram] from comment #10) > Just confirming: UiAsyncTask runs on a single thread right? So basically we > are using a single thread to post these tasks, instead of going the standard > Android way of leaving it to Android to figure it out. Yep. Makes me wonder if we actually should be using a thread pool instead, which means using AsyncTask.execute() on pre-HC and AsyncTask.executeOnExecutor() on post-HC. Something tells me we should.
Reporter | ||
Comment 14•11 years ago
|
||
Changed it to use AsyncTask with thread pool instead. That should give us more throughput to load favicons while scrolling.
Attachment #802246 -
Attachment is obsolete: true
Attachment #802935 -
Flags: review?(sriram)
Reporter | ||
Comment 15•11 years ago
|
||
The code to load favicons directly from the cursor was dead code indeed. Removed.
Attachment #802247 -
Attachment is obsolete: true
Attachment #802936 -
Flags: review?(sriram)
Reporter | ||
Comment 16•11 years ago
|
||
Same thing, just rebased.
Attachment #802248 -
Attachment is obsolete: true
Attachment #802937 -
Flags: review?(sriram)
Comment 17•11 years ago
|
||
Comment on attachment 802935 [details] [diff] [review] Implement incremental favicon loading in about:home Review of attachment 802935 [details] [diff] [review]: ----------------------------------------------------------------- Looks good.
Attachment #802935 -
Flags: review?(sriram) → review+
Updated•11 years ago
|
Attachment #802936 -
Flags: review?(sriram) → review+
Comment 18•11 years ago
|
||
Comment on attachment 802937 [details] [diff] [review] Clear favicon until the new image finishes loading in TwoLinePageRow Review of attachment 802937 [details] [diff] [review]: ----------------------------------------------------------------- The recycler listener is used for these cases. Basically, a list is usually made of homogenous entries. (There might be different kinds too, like tweets or fb posts, but we don't have that problem). In this case, the list knows the kind of "child" it shows. And list takes care of moving the view to its heap. So, to me, the list should trigger the "recycling" of the view. I agree that the list shouldn't be setting the image-resource to null/0. But then, it can call "view.recycle()" or something. setOnRecyclerListener(new OnRecyclerListener() { public void onMoveToHeap(View view) { if (view instanceof TwoLinePageRow) { ((TwoLinePageRow) view).recycle(); } } }); This feels a better approach to me. The recycle() method is same as your clearImage() method. If you don't feel good about this, you could probably do the re-setting in onDetachedFromWindow() of TwoLinePageRow. That's another better place. I somehow don't like calling clearImage() from somewhere deep in the code. r- to get your opinion (as a reminder to review it again).
Attachment #802937 -
Flags: review?(sriram) → review-
Comment 19•11 years ago
|
||
Comment on attachment 802935 [details] [diff] [review] Implement incremental favicon loading in about:home Review of attachment 802935 [details] [diff] [review]: ----------------------------------------------------------------- Hello there, I see you're trampling on my new favicon caching system - Over in bug 914296 I implemented incremental loading in a way that avoids duplicating logic in the way that you just did. Let's combine our solutions to produce the best of both worlds. ::: mobile/android/base/Makefile.in @@ -224,5 @@ > home/HomePager.java \ > home/HomePagerTabStrip.java \ > home/HomeBanner.java \ > home/FadedTextView.java \ > - home/FaviconsLoader.java \ Getting rid of this is an extremely excellent thing to do - I tried this over in bug 914296, but couldn't work out the specifics. The various refactorings you've done to kill this off are very worthwhile. ::: mobile/android/base/home/TwoLinePageRow.java @@ +250,5 @@ > setBookmarkIcon(NO_ICON); > } > } > + > + private class LoadFaviconTask extends AsyncTask<Void, Void, Bitmap> { This is an unnecessary duplication of logic that already exists here: http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/Favicons.java#253 It seems to me that combining the first half of this patch with my patch from the other bug yields an optimal solution - you fixed the simplification I couldn't figure out, and my more general caching system solves the problem that led you to this without the need for duplication.
Reporter | ||
Comment 20•11 years ago
|
||
(In reply to Sriram Ramasubramanian [:sriram] from comment #18) > Comment on attachment 802937 [details] [diff] [review] > Clear favicon until the new image finishes loading in TwoLinePageRow > > Review of attachment 802937 [details] [diff] [review]: > ----------------------------------------------------------------- > > The recycler listener is used for these cases. Basically, a list is usually > made of homogenous entries. (There might be different kinds too, like tweets > or fb posts, but we don't have that problem). > In this case, the list knows the kind of "child" it shows. And list takes > care of moving the view to its heap. So, to me, the list should trigger the > "recycling" of the view. I agree that the list shouldn't be setting the > image-resource to null/0. But then, it can call "view.recycle()" or > something. > > setOnRecyclerListener(new OnRecyclerListener() { > public void onMoveToHeap(View view) { > if (view instanceof TwoLinePageRow) { > ((TwoLinePageRow) view).recycle(); > } > } > }); > > This feels a better approach to me. The recycle() method is same as your > clearImage() method. If you don't feel good about this, you could probably > do the re-setting in onDetachedFromWindow() of TwoLinePageRow. That's > another better place. I somehow don't like calling clearImage() from > somewhere deep in the code. > > r- to get your opinion (as a reminder to review it again). We're talking about different things here. This patch is not about recycling (as in "freeing resources") when a ListView row is moved to the scrap heap. Let me rephrase this to frame the intent of this patch a bit more clearly. You should see the clearImage() method more like an updateRowWithProgressUi() thing. Imagine that instead of showing an empty image while the favicon is loading, we showed, say, a throbber. Would you do it in a RecyclerListener on in the row itself? It would not make sense to trigger a row's progress UI in the RecyclerListener, would it? This is about the internal state of each row and should managed by the row itself, not its container. There are more complex UIs where the the container has to manage the state of its children a bit more explicitly e.g. for managing memory more efficiently. But that's not the case here. Coupling HomeListView and TwoLinePageRow is neither necessary nor wanted here. We should not require every container of TwoLinePageRow to be responsible for managing each row's state.
Reporter | ||
Comment 21•11 years ago
|
||
(In reply to Chris Kitching [:ckitching] from comment #19) > Comment on attachment 802935 [details] [diff] [review] > Implement incremental favicon loading in about:home > > Review of attachment 802935 [details] [diff] [review]: > ----------------------------------------------------------------- > > Hello there, > I see you're trampling on my new favicon caching system - Over in bug 914296 > I implemented incremental loading in a way that avoids duplicating logic in > the way that you just did. Let's combine our solutions to produce the best > of both worlds. I'm happy do adapt this for the new API as a follow-up. Your Favicons.getSizedFaviconForPageFromLocal() seems to be exactly what we need here. However, we should not block on bug 914296 to land this fix because the new Favicons API is a fairly risky change and we should probably land it only after the merge next week. So, I suggest you to rebase your patch to not include my changes here. Include your changes *on top* of my patches instead. > ::: mobile/android/base/Makefile.in > @@ -224,5 @@ > > home/HomePager.java \ > > home/HomePagerTabStrip.java \ > > home/HomeBanner.java \ > > home/FadedTextView.java \ > > - home/FaviconsLoader.java \ > > Getting rid of this is an extremely excellent thing to do - I tried this > over in bug 914296, but couldn't work out the specifics. The various > refactorings you've done to kill this off are very worthwhile. > > ::: mobile/android/base/home/TwoLinePageRow.java > @@ +250,5 @@ > > setBookmarkIcon(NO_ICON); > > } > > } > > + > > + private class LoadFaviconTask extends AsyncTask<Void, Void, Bitmap> { > > This is an unnecessary duplication of logic that already exists here: > http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/Favicons. > java#253 Yes, but not exactly. The current Favicons API doesn't have a getSizedFaviconForPageFromLocal() which is what we'd need here. The existing code in Favicons is all geared towards the download-store-cache use cases, again not what we need here. Also, the current Favicons code currently uses UiAsyncTask which simply uses a background thread but we want to use a thread pool to get better favicon loading throughput as you scroll the lists. I could do these changes to Favicons but it would be a fairly risky change to do at this point. Besides, this code is going away in the next days anyway. > It seems to me that combining the first half of this patch with my patch > from the other bug yields an optimal solution - you fixed the simplification > I couldn't figure out, and my more general caching system solves the problem > that led you to this without the need for duplication. Yeah, we should definitely change this code to use the new API. But we need a fix for this bug that can be merged to aurora next week.
Reporter | ||
Comment 22•11 years ago
|
||
Comment on attachment 802937 [details] [diff] [review] Clear favicon until the new image finishes loading in TwoLinePageRow Hopefully the intent of the patch is a bit more clear now (see comment #20). Requesting review again.
Attachment #802937 -
Flags: review- → review?(sriram)
Updated•11 years ago
|
Attachment #802937 -
Flags: review?(sriram) → review+
Reporter | ||
Comment 23•11 years ago
|
||
Rebased and tweaked a few things. Worth a new review.
Attachment #806297 -
Flags: review?(sriram)
Reporter | ||
Updated•11 years ago
|
Attachment #802935 -
Attachment is obsolete: true
Comment 24•11 years ago
|
||
Unbitrotting that for you... Since this series has been bitrotted and stalling my other Favicon work for almost a week now - fixing it myself.
Attachment #802937 -
Attachment is obsolete: true
Comment 25•11 years ago
|
||
I also had a hard time figuring out the proper ordering of these patches... How come they're not numbered?
Attachment #802936 -
Attachment is obsolete: true
Comment 26•11 years ago
|
||
Comment on attachment 806297 [details] [diff] [review] Implement incremental favicon loading in about:home Review of attachment 806297 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. Please add a followup patch if the AsyncTask could be made static. ::: mobile/android/base/home/TwoLinePageRow.java @@ +252,5 @@ > setBookmarkIcon(NO_ICON); > } > } > + > + private class LoadFaviconTask extends AsyncTask<Void, Void, Bitmap> { Could we make this class static? @@ +281,5 @@ > + if (TextUtils.equals(mPageUrl, mUrl)) { > + setFaviconWithUrl(favicon, mUrl); > + } > + > + mLoadFaviconTask = null; It's just me. But I dont like something like: mLoadFaviconTask = new AsyncTask() { onPostExecute() { mLoadFaviconTask = null; } }; That breaks the encapsulation. An object of a class is reset inside the class. You could probably call a callback on the class and that can reset it. I remember doing this for some other class, which I forgot now. That callback will know the mPageUrl anyways. This could be a followup.
Attachment #806297 -
Flags: review?(sriram) → review+
Reporter | ||
Comment 27•11 years ago
|
||
(In reply to Sriram Ramasubramanian [:sriram] from comment #26) > Comment on attachment 806297 [details] [diff] [review] > Implement incremental favicon loading in about:home > > Review of attachment 806297 [details] [diff] [review]: > ----------------------------------------------------------------- > > Looks good. Please add a followup patch if the AsyncTask could be made > static. > > ::: mobile/android/base/home/TwoLinePageRow.java > @@ +252,5 @@ > > setBookmarkIcon(NO_ICON); > > } > > } > > + > > + private class LoadFaviconTask extends AsyncTask<Void, Void, Bitmap> { > > Could we make this class static? See comment below. > @@ +281,5 @@ > > + if (TextUtils.equals(mPageUrl, mUrl)) { > > + setFaviconWithUrl(favicon, mUrl); > > + } > > + > > + mLoadFaviconTask = null; > > It's just me. But I dont like something like: > > mLoadFaviconTask = new AsyncTask() { > onPostExecute() { > mLoadFaviconTask = null; > } > }; > > That breaks the encapsulation. An object of a class is reset inside the > class. > > You could probably call a callback on the class and that can reset it. I > remember doing this for some other class, which I forgot now. That callback > will know the mPageUrl anyways. > > This could be a followup. I see your point but only partially agree. It depends on how you look at the role of the AsyncTask in TwoLinePageRow. I tend to see it as part of the state of the view in which case it does make sense for the AsyncTask and the view to share state e.g. in the same fashion that we usually have private listeners sharing state with its parent view. But I want you to be happy, so I filed bug 917848 :-)
Updated•11 years ago
|
Blocks: FaviconRevamp
Reporter | ||
Comment 28•11 years ago
|
||
Pushed: https://hg.mozilla.org/integration/fx-team/rev/1e94c7dd02ec https://hg.mozilla.org/integration/fx-team/rev/e87b2835091c https://hg.mozilla.org/integration/fx-team/rev/93185fb06908
https://hg.mozilla.org/mozilla-central/rev/1e94c7dd02ec https://hg.mozilla.org/mozilla-central/rev/e87b2835091c https://hg.mozilla.org/mozilla-central/rev/93185fb06908
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 27
Reporter | ||
Comment 30•11 years ago
|
||
Comment on attachment 806297 [details] [diff] [review] Implement incremental favicon loading in about:home [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 862793 (fig) User impact if declined: Our current approach to loading favicons doesn't scale well, especially on lower-end devices and profiles with a large number of bookmarks. See comment #0 for more details. Testing completed (on m-c, etc.): Landed in fx-team. Risk to taking this patch (and alternatives if risky): Medium risk. The patch is simple but touches a core part of our new about:home code. We can wait a couple days before uplifting. String or IDL/UUID changes made by this patch: n/a
Attachment #806297 -
Flags: approval-mozilla-aurora?
Reporter | ||
Comment 31•11 years ago
|
||
Comment on attachment 806377 [details] [diff] [review] Clear favicon until the new image finishes loading in TwoLinePageRow. [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 862793 (fig) User impact if declined: Our current approach to loading favicons doesn't scale well, especially on lower-end devices and profiles with a large number of bookmarks. See comment #0 for more details. Testing completed (on m-c, etc.): Landed in fx-team. Risk to taking this patch (and alternatives if risky): Medium risk. The patch is simple but touches a core part of our new about:home code. We can wait a couple days before uplifting. String or IDL/UUID changes made by this patch: n/a
Attachment #806377 -
Flags: approval-mozilla-aurora?
Reporter | ||
Comment 32•11 years ago
|
||
Comment on attachment 806378 [details] [diff] [review] Don't try to load favicons from cursor in TwoLinePageRow. [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 862793 (fig) User impact if declined: Our current approach to loading favicons doesn't scale well, especially on lower-end devices and profiles with a large number of bookmarks. See comment #0 for more details. Testing completed (on m-c, etc.): Landed in fx-team. Risk to taking this patch (and alternatives if risky): Medium risk. The patch is simple but touches a core part of our new about:home code. We can wait a couple days before uplifting. String or IDL/UUID changes made by this patch: n/a
Attachment #806378 -
Flags: approval-mozilla-aurora?
Comment 33•11 years ago
|
||
Comment on attachment 806297 [details] [diff] [review] Implement incremental favicon loading in about:home Has been on central for 6 days now so let's get it to Aurora and broaden the coverage.
Attachment #806297 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Updated•11 years ago
|
Attachment #806377 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Updated•11 years ago
|
Attachment #806378 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 34•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/59d9eff1d3ed https://hg.mozilla.org/releases/mozilla-aurora/rev/3fde1bdc6d01 https://hg.mozilla.org/releases/mozilla-aurora/rev/bd33971cc395
status-firefox26:
--- → fixed
status-firefox27:
--- → fixed
Assignee | ||
Comment 35•11 years ago
|
||
README: "Smoothie provides a simple API to load ListView/GridView items asynchronously, off the UI thread." This import tracks the commit at https://github.com/lucasr/smoothie/commit/6cf9a344c3917330987f46a6220013df66088739
Assignee | ||
Updated•11 years ago
|
Assignee: lucasr.at.mozilla → nalexander
Assignee | ||
Comment 36•11 years ago
|
||
(In reply to Nick Alexander :nalexander from comment #35) > Created attachment 819215 [details] [diff] [review] > Part 0: Import smoothie library and build smoothie.jar. is developed at > https://github.com/lucasr/smoothie. From the > > README: "Smoothie provides a simple API to load ListView/GridView > items asynchronously, off the UI thread." > > This import tracks the commit at > https://github.com/lucasr/smoothie/commit/ > 6cf9a344c3917330987f46a6220013df66088739 This will not include smoothie.jar in geckoview_library. You'll need to add the jar during make package; see mobile/android/geckoview_library/Makefile.in.
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•