IssueTracker

Known bug, exists internally as #1566070. Currently target to Eclair.

do you have any recommendations for users of this widget until then?

Still getting null as convertView in FroYo, any update on when this will be fixed?

It's nor marked as fixed, so that's expected that the behavior is still broken :) There is currently no ETA for a fix.

Any recommendation how to work around this? We use a view switcher inside a gallery that switches from a ProgressBar to an ImageView, and its constructor is invoked for every single call of Adapter.getView... that's quite expensive (especially the ProgressBar ctor, since it's reloading its drawable every single time).

My Advice would be to simply fix the bug yourself by coping the source of the gallery and making the appropriate changes...
That's quite a work, but it worked for us (the source is sadly proprietary of the company I work at... someday I will try to convince my boss to release it to the public, or even directly contributing to the android source code).

Good luck !

Cheers! What I tried is this: since in our gallery, only 3 items are ever visible at once, I thought I'd be clever about it and pre-instantiate 3 items, keep them in a list, and index into that list using (position mod 3). That way I thought I could re-use these 3 viewes even if I have indefinitely many items. But nope, Android suddenly started to call galleryAdapter.getView() in an endless loop!

Bummer. Looks like it's not that easily fixed after all :-/

[Comment deleted]

Is there any progress with this issue?

 this is a serious bug.  why was it never addressed?

I wrote a quick hack to get the gallery performing much better. It's not perfect, but it's a good starting point. Just manage an array of views yourself, this isn't getting fixed any time soon. :)

http://robotoole.com/blog/wp/android-gallery-convertview-is-always-null/

The GalleryWidget is by far the worst UI Widget that is present in Android. It is jumping around in an unpredicted way and producing out of memory errors because of the bad recycling behavior. I hope this will be fixed.

Does anybody know of an OpenSource Solution for this?

If you don't mind commercial solution, our DroidUX GalleryFlow widget has solved this issue by implementing our own view recycling mechanism which results in a stable and better performing Gallery widget.  For more information, visit: http://droidux.com/products/widgets-list-of-widgets/galleryflows

[Comment deleted]

Any new on this? We kind of need a gallery that recycle its views, but we don't know where to start... Anyone has some advice? At least 50 pictures, and maximum around 100, need to be added to the gallery, so the solution Rob proposed is not good... Anyone something else?

Kind Regards

I have created a custom version of Gallery that recycles its views in about 70% - 90%. Its not perfect but it's better than what there is now. Its source is based on Android 2.3.4

Thanks for your reply! But what do you mean by saying that it recycles its view in about 70% - 90%? What with the other 10% - 30%? Will it work on android 2.2?

Kind regards

When I tested it, i noticed that in some edge cases the gallery destroys it's views instead of recycling them. Since I used the gallery only in set-top-boxes (which have no touch screens), I almost never reached those edge cases and had about 90% success rate.
I encourage you to test it yourself and fix, if indeed necessary, its recycling engine. Just don't forget to post your fix if you do decide to give it a try :)

oh and yes, it will definitely work on android 2.2

Owkey, thanks for your help! I'll let you know if I want to get / got a 100% safe solution! If somebody else has such a solution, plz let me know!

Kind regards

Thanks Amir! Works great!

What ever happened to internal [deleted issue]?  I only ask because...as evidenced by the "quick hack" caveats above, about 90% of the solutions I use from threads like this end up missing support for things like multiple view-type recycling and other things.  If one of these solutions is superior and Team Android truly doesn't need to do anything to resolve this, then why isn't that open-source code consumed by the SDK?

[Comment deleted]

I encounter this issue in the API Demo of the latest SDK (4.0.3).
Haven't it been resolved in this version?

In 2 months this bug will celebrate its 3rd anniversary.

Happy birthday, bug !

Looks like noone cared at Google.

Happy birthday, bug!

[Comment deleted]

Happy birthday, bug!

This issue comes from
* gallery widget too aggressive in recycling
* the fact that Gallery and AbsSpinner conflicts in the use of the mRecycler

Gallery widget recycle by position, it assume that every position is different rather then using group type like the ListView, which means it require a new position for every view.

If you (like me) have some code to get the image in background (with local caching) that set up the image once downloaded/decoded on the view you'll get a vibrating gallery when the user scroll (literally).

Apparently AbsSpinner onMeasure method try to use recycle to get views and see if he has already measured them, this end up like this:
* user scroll (right)
* Gallery ask for a new view for position 3 (example), say view A
* background (few millisecond) decode and set of the image (available locally, already cached) is set up to the view
* this cause a onMeasure to be triggered on the AbsSpinner
* which ask for recycled view 0, 1, 2, 3 which are currently visible == not recycled
* meaning it request new view to the adapter that has no way of knowing if the view is being required for measuring or because it's actually needed...


I ended up storing a map of position -> views in my adapter
when convertView is null I first check if I have a view for that position, if I have then I use it.
If I don't I create one.

I maintain a map of position -> view, and the reverse map view -> position

when a view match if the position is the same I do not bind data, I just give it back (usually this goes to AbsSpinner.onMeasure()), otherwise a bind my data.

I think to fix this Google should
* implement something like ListView to have view grouping and recycling by group and not by position
* make AbsSpinner maintain a map of "active views" and not using recycler to cache their size (why recycler??)
* provide code in Support package to use the new widget in previous versions.

I'd like to see a solution to this like anyone else :)

This definitely needs fixing. Still broken in ICS!

I just cant believe... This definitely needs fixing. Still broken in ICS![2]

Gallery is marked as deprecated and i think that's why they are not fixing this issue!!!

Which other widget should we use if gallery is deprecated?

THe ViewPager

"This widget is no longer supported. Other horizontally scrolling widgets include HorizontalScrollView and ViewPager from the support library."

http://developer.android.com/reference/android/widget/Gallery.html

By the way, this is the "easy way out", since ViewPager requires you, the dev, to take care about view caching. Also, while I think ViewPager has much better usability / feel to it, it has numerous other problems and bugs (page updates sometimes don't occur, this was supposed to be fixed in support-4x-r9, which however in turn introduced new bugs related to gestures). Also, ViewPager is weird in terms of the typical Android life-cycle, since your pages will NOT be constructed after onCreate finishes, and there's not even a callback for when your pages are available.

So we're left with one poorly coded widget to replace another poorly coded widget. Huzzah!

So wait...this was deprecated in Jelly Bean?!  Let me explain why deprecating the class was yet another horrible strategic move from Google's hard-working Android Team:
- What happened to feature planning for an OS?
- GalleryWidget hasn't been around long enough to deprecate it.
- Why don't we have just one widget that handles scrolling views?  Why do we have a GalleryWidget and a ViewPager?
- Why does Google insist that widgets which scroll horizontally are different from those that scroll vertically?
- What is the upgrade path for Honeycomb apps that used GalleryView to get to JellyBean+ViewPager?  It's not a drop-in replacement, right?
- Neither developers nor users are excited about Jelly Bean.  ICS was barely adopted earlier this year.  Earlier this year we were still building and testing for Honeycomb devices.  JellyBean doesn't solve the usability problems present in Android because they haven't even been discovered.  JellyBean doesn't make Android programmers more productive.  JellyBean has failed before it even had a chance.

Have a great weekend Team Android!

The problem has been that developers have abused Gallery.  It was only intended to be used for singular ImageViews, so the View caching wasn't an essential part and was never developed.  Unfortunately, due to lack of horizontal Views, many developers used it for more than it was intended.


> GalleryWidget hasn't been around long enough to deprecate it.

How long something has been around isn't as much of a factor in whether to deprecate it compared to its value; however, Gallery has been around since the beginning of Android.


> Why don't we have just one widget that handles scrolling views?  Why do we have a GalleryWidget and a ViewPager?

With Gallery deprecated, ViewPager is the only widget for handling horizontally scrolling Views (with the exception of HorizontalScrollView, but that has a different use).


> Why does Google insist that widgets which scroll horizontally are different from those that scroll vertically?

Good question.  My assumption is that this is a case of evolution.  Devices were traditionally portrait-based and vertical scrolling is natural in that orientation.  Horizontal scrolling was rarely used because it's less discoverable and less useful when you've got a device that's only 320dp wide.  With such thin displays, horizontal scrolling only makes sense when scrolling by full pages, but it is only starting to become a more expected (and thus discoverable) means of navigation.


> What is the upgrade path for Honeycomb apps that used GalleryView to get to JellyBean+ViewPager?  It's not a drop-in replacement, right?

Gallery is still available, but its use is discouraged.  ViewPager is available in the compatibility library, so it can be used from 1.6 and above.


> Neither developers nor users are excited about Jelly Bean.

That wasn't my feeling at Google I/O.  In fact, I'm thrilled that Google has put in so much effort toward improving the user experience.


> ICS was barely adopted earlier this year.

If Google waited for 100% adoption, we would never have seen Android 2.x.  ICS is a significant change from Gingerbread, so upgrades are a substantial amount of work for manufacturers.  The amount of work they have to do to go from ICS to JB is significantly less.


> Earlier this year we were still building and testing for Honeycomb devices.

Fortunately a large number of Honeycomb devices have moved to ICS and that will continue to be the case.  The 3.x userbase will continue to shrink as 4.x grows.  You should always build for the latest version and test for all versions you support.


> JellyBean doesn't solve the usability problems present in Android because they haven't even been discovered.

Many of them have been discovered and are being treated.  That's why we see changes to backstack handling, a push for consistent navigation, triple buffering for more immediate user feedback, expandable and actionable notifications, user-controlled notifications (i.e., the user can disable notifications from individual apps), read permission for external storage, etc.


> JellyBean doesn't make Android programmers more productive.

That's arguable, but the improved ADT does.


> JellyBean has failed before it even had a chance.

We'll have to agree to disagree on this one.

[Comment deleted]

> The problem has been that developers have abused Gallery.

Pragmatic developers are using the gallery for lack of stable alternatives (why reinvent the wheel in thousands of apps?). As mentioned in comment 39 deprecating the Gallery widget is the "easy way out" - instead to fix it or to replace it with a functional widget with adapter support (not another poorly implemented widget like the view pager - with the named use case of paging) .

There is still a need of a horizontal view pager or a horizontal list view with adapter support. The Gallery widget was a less-than-ideal solution - but it works. The deprecation is   precarious, because a developer never knows, if an app runs after the next (and too often) SDK update.

Fragmentation +1

There is a very interesting discussion going on around the topic of in-SDK widgets vs external library widgets on Cyril's blog: http://android.cyrilmottier.com/?p=746

Romain Guy has also left his thoughts on this. Deprecating Gallery seems to be part of Google's recent strategy to remove complex widgets from the SDK and either put them in the compat libraries or leave it to the community to build them. A difficult discussion IMHO, has both strong pros and cons.

deprecated