awesome-android-ui: the Demo column is empty in every table

Three columns per table, and the third one is never filled in

Every section in this list is a markdown table with the same header: Name, License, Demo, followed by a separator row of three dashes. What follows the header is where it gets thin. In the Jetpack Compose table, all eight rows, from Landscapist to SSComposeCookBook, carry a name and a licence and nothing in the Demo cell. The same holds for the forty rows of the Layout table, from WaveView through TagSphereView. The third column is a promise the file does not keep.

So the list gives you a name, a repository link and a licence, and asks you to do the rest. To know what any of these libraries looks like you have to open the repository, find the screenshot or sample app yourself, and judge whether the design suits your app. For a section with forty entries that is forty separate investigations, and the list has saved you only the part where you typed the words into a search box.

The visuals are not missing from the repository, they are just not next to the entry. An art/ directory sits at the root beside README.md, so images exist somewhere in the project; a reader scanning the tables for evidence will not find them there.

The licence cell is a link, and one row answers UnKnown

The licence column looks more useful than it is. Most rows link Apache License V2 to apache.org/licenses/LICENSE-2.0 or MIT to opensource.org/licenses/MIT, so the two common cases are one click away. Two rows are different. AndroidViewHover answers UnKnown, with the capital K, which records that nobody checked rather than that the licence is unusual. Flipboard's BottomSheet links to a License file inside the repository itself, at a path that ends in master, so the target moves if the project renames its default branch.

The practical effect is that the column is a pointer, not a verified fact, and a link to a licence page only tells you what the maintainer of the list believed when the row was written. It does not tell you the version of that library you would install, and a project can change licence between releases.

The list itself is a separate matter. A LICENSE file at the root covers the list, whose repository licence is MIT, and that licence says nothing about the forty libraries it points at. When you adopt one of the entries you are taking on a dependency with its own terms, and the list is not the place those terms are recorded.

WaveView appears twice, and the list does not say which copy is current

Duplicate names are the fastest way to get stuck. WaveView appears twice in the Layout table, once from john990 and once from gelitenight, both under Apache License V2, with nothing to distinguish them. DraggablePanel from pedrovgs sits above DraggablePanel2 from hoanganhtuan95ptit, and the repository path behind the second name also ends in DraggablePanel, so the label and the link disagree. Yalantis is behind both Phoenix and Taurus. SwipeBackLayout and SwipeBack come from two different authors, and daimajia is behind both AndroidSwipeLayout and AndroidViewHover.

Some of those pairs are the normal shape of this corner of the ecosystem, where a library is forked because the original stalled and the fork gets the fixes. That is exactly the case where the list is most useful and least helpful: the answer to which one to use is almost always the maintained fork, and the file gives you no way to tell the maintained one from the abandoned original.

Consequence for a reader is concrete. You cannot search this document by name without getting collisions, and when you get one, the tie-break is to visit both repositories and read their commit dates yourself. That is a five minute task per duplicate, and there are at least half a dozen.

Sixteen sections named after widgets, and one named after a toolkit

The index is the argument of the list in seventeen lines. It opens with Jetpack Compose and then moves through Layout, Button, List / Grid, ViewPager, Label / Form, Image, SeekBar, Progress, Menu, ActionBar, Dialog, Calendar, Graph, Animation, Parallax, Effect (Blur... etc) and Other.

Sixteen of those seventeen are widget categories, and they are categories from the View era of Android UI. ViewPager and ActionBar are concepts a Compose developer reaches for through different primitives, which means a reader arriving from Compose has to map the taxonomy onto a mental model the list does not share. The one section named after a toolkit holds eight rows, sitting above a Layout table with more than forty.

That ratio is the honest summary of the file. It is comprehensive about third-party View-era widgets and thin on everything else, so for a Compose shop its value is the eight rows plus the names of libraries that predate or ignore the toolkit. The Effect entry, labelled with a bracketed ellipsis, is a small sign of how the sections are written: a category opened for one idea and left open-ended.

There is nothing to install here, because the repository is a markdown file

The top level of the project is .github/, .gitignore, CODE_OF_CONDUCT.md, LICENSE, README.md and art/. There is no source directory, no build configuration, no package manifest, and the language field for the repository reads as unknown. The release list is empty because the project has no releases: it is a document, not a package.

That is worth stating plainly because the search terms people use for this repository include download, and there is nothing to fetch. A reader who wants a pull to refresh layout cannot add this list as a dependency; the only thing it offers is a set of hyperlinks into other people's repositories, each of which you then evaluate on its own terms.

There is no contributing file either. The Maintainers section contains a single link to one GitHub profile, which means the person who decides what enters the list is one account, and the file that would tell a newcomer how to propose an entry is not in the repository. The submission route is an issue or a pull request with no published rules attached to it.

The last push was 2026-06-05, and no row records a date

The last push to this repository landed on 2026-06-05, and that is the only temporal fact the project offers. No row carries a version number, a release date or a last commit, so the file cannot tell you when any library it names was last touched, or whether that library still supports the Android version you are building for.

Read carefully, that silence cuts both ways. An entry with no date is not evidence that a project is abandoned, because nothing in the format would have recorded its death either. Equally, a row that looks current is not evidence of health, since a table written years ago and a table written last month are formatted identically. The list is a snapshot with no version attached to it, and you cannot tell how old the snapshot is from the inside.

For a list of this size that is a reasonable trade, and there is a cheap partial signal available: open the repository from the row and look at its own commit history and releases. That check is exactly what the empty Demo column and the missing date column push back at you for every entry.

The first-party alternative is the toolkit the list itself has a section for

Any list like this is only worth reading against the alternative of not needing it, and for Android UI that alternative is the platform's own component set and Jetpack Compose. The difference in approach is where the compatibility burden sits. A first-party component is versioned with the platform you compile against, so it tracks your target SDK by construction. A third-party view is a separate project with its own release rhythm, its own build dependency and its own idea of which Android versions it supports, and none of that is visible in a row of this table.

The list is honest about this by existing at all. Its Jetpack Compose section holds Landscapist, Orchestra, Flinger, compose-backstack, ComposeClock, ComposeCookBook, a neumorphism kit and SSComposeCookBook, which is a short list by design: the toolkit already covers most of what the other sixteen sections cover for older code.

So the decision to reach for an entry here is a decision to take on an outside dependency's cadence and licence in exchange for a behaviour the platform does not give you. Judge the entry on its repository, not on the fact that it made this table.

Editorial conclusion

Use the list as a starting map when you need a widget for a specific job and want twenty names instead of one, because the section structure narrows the search faster than a package index would. Do not use it to choose a library on its own: no row records a version, a release date or a working demo, duplicate names appear without a note about which copy is current, and one licence cell reads UnKnown. Before you commit, open the repository behind the row and check the last release and the Android version it targets, and treat the list's own last push on 2026-06-05 as the only freshness signal the file gives you.

Frequently asked questions

Official sources

1. Official README
2. Project repository