The easiest library to show skeleton screens in an Android app.
License: Apache License 2.0
Reported by @TurKurT656
I'm using DataBinding library to set data to the RecyclerView:
@BindingAdapter("binding:setData")
fun <T> RecyclerView.setRecyclerViewData(data: List<T>?) {
data?.let {
if (adapter is MyAdapter<*>)
(adapter as MyAdapter<T>).submitList(it)
}
}
so I think when data is on loading state the library changes RecyclerView to KoletonView and because of that the BindingAdapter function never invokes. I've updated the sample project to demonstrate the issue.
I've a BindingAdapter for setting skeleton:
@BindingAdapter(
"binding:loadSkeleton",
"binding:skeletonLength",
"binding:skeletonCornerRadius",
requireAll = false
)
@JvmStatic
fun loadSkeleton(
textView: TextView,
loadSkeleton: Boolean,
skeletonLength: Int?, // Default is 5
skeletonCornerRadius: Float?, // Default is 8
) {
val sLength = skeletonLength ?: 5
val sCornerRadius = skeletonCornerRadius ?: 8f
if (loadSkeleton)
textView.loadSkeleton(sLength) {
cornerRadius(sCornerRadius)
color(R.color.my_custom_color)
}
else
textView.hideSkeleton()
}
Now I want to add an attribute to change the color of skeleton. Koleton doesn't support @ColorInt and only works with @ColorRes and because of that I have to import R class inside my xml files which is not a good practice. But If koleton supports ColorInt I can simply change my color with this code:
<TextView
...
binding:skeletonColor="@{@color/my_custom_color}" />
Свойство android:allowBackup
Свойство определяет, возможно ли сделать резервное копирование всех защищенных файлов приложения (из директории /data/data/com.app.pkgname/*). Копия будет сохранена на SD карту (/sdcard). С одной стороны, атакующий с физическим доступом к устройству получает все защищенные данные при помощи adb. С другой стороны, вредоносные приложения могут иметь доступ к любым файлам на /sdcard.
Уязвимый файл | ./koleton-base/src/main/AndroidManifest.xml
Параметр | @android:allowBackup
Значение | —
Рекомендуемое | false
| Уязвимый файл | ./koleton-sample/src/main/AndroidManifest.xml : 7 |
|---|---|
| Параметр | @android:allowBackup |
| Значение | true |
| Рекомендуемое | false |
| Уязвимый файл | ./koleton-singleton/src/main/AndroidManifest.xml |
|---|---|
| Параметр | @android:allowBackup |
| Значение | — |
| Рекомендуемое | false |
Свойство android:protectionLevel
Свойство определяет наличие прав, требуемых для использования данного разрешения. Если значение установлено в normal, то атакующий сможет также его использовать у себя в приложении. Если установлено в dangerous, то при попытке установить приложение атакующего пользователь увидит предупреждение. Если в signature, то приложение атакующего должно быть подписано тем же самым ключом, что и атакуемое приложение (что невозможно, поэтому данное значение считается безопасным).Таким образом, данная настройка предотвращает использование данного разрешения третьими лицами.
| Уязвимый файл | ./koleton-singleton/src/main/AndroidManifest.xml |
|---|---|
| Параметр | @android:protectionLevel |
| Значение | — |
| Рекомендуемое | signature |
| Уязвимый файл | ./koleton-sample/src/main/AndroidManifest.xml |
|---|---|
| Параметр | @android:protectionLevel |
| Значение | — |
| Рекомендуемое | signature |
| Уязвимый файл | ./koleton-base/src/main/AndroidManifest.xml |
|---|---|
| Параметр | @android:protectionLevel |
| Значение | — |
| Рекомендуемое | signature |
These are my codes
Please guide me
`
override fun showLoading() {
binding.apply {
foodsList.loadSkeleton(R.layout.item_foods)
}
}
override fun hideLoading() {
binding.apply {
foodsList.hideSkeleton()
}
}
'
The problem is that sometimes the TextView's text is coming from api call and until that the text is empty and when I set skeleton on it the skeleton is not visible. I can set a dummy text on it until network response but I think this is an ugly solution.
It would be great if We can add an option to set a loading length on TextView skeleton.
When I set the recyclerView's height to wrap_content Skeleton does not show up. But On match_parent and fixed height values everything works fine
Current workaround is to use intermediate parent, but it's looks ugly I think =)
<androidx.swiperefreshlayout.widget.SwipeRefreshLayout
android:layout_width="match_parent"
android:layout_height="match_parent">
<FrameLayout
android:layout_width="match_parent"
android:layout_height="match_parent">
<androidx.recyclerview.widget.RecyclerView
android:layout_width="match_parent"
android:layout_height="match_parent"
app:layoutManager="androidx.recyclerview.widget.LinearLayoutManager"
/>
</FrameLayout>
</androidx.swiperefreshlayout.widget.SwipeRefreshLayout>
I've applied "android:translationY" to the skeleton view but it doesn't seem to work
when I call the API I start the loaded and when the data got added into recyclerview then I hide the View Using recyclerViewForum.hideSkeleton() then it didn't work
./gradle/wrapper/gradle-wrapper.jar
Gradle is a build tool with a focus on build automation. In versions prior to 7.2, start scripts generated by the application plugin and the gradlew script are both vulnerable to arbitrary code execution when an attacker is able to change environment variables for the user running the script. This may impact those who use gradlew on Unix-like systems or use the scripts generated by Gradle in thieir application on Unix-like systems. For this vulnerability to be exploitable, an attacker needs to be able to set the value of particular environment variables and have those environment variables be seen by the vulnerable scripts. This issue has been patched in Gradle 7.2 by removing the use of eval and requiring the use of the bash shell. There are a few workarounds available. For CI/CD systems using the Gradle build tool, one may ensure that untrusted users are unable to change environment variables for the user that executes gradlew. If one is unable to upgrade to Gradle 7.2, one may generate a new gradlew script with Gradle 7.2 and use it for older versions of Gradle. Fpplications using start scripts generated by Gradle, one may ensure that untrusted users are unable to change environment variables for the user that executes the start script. A vulnerable start script could be manually patched to remove the use of eval or the use of environment variables that affect the application's command-line. If the application is simple enough, one may be able to avoid the use of the start scripts by running the application directly with Java command. -
Gradle is a build tool with a focus on build automation. In versions prior to 7.2, start scripts generated by the application plugin and the gradlew script are both vulnerable to arbitrary code execution when an attacker is able to change environment variables for the user running the script. This may impact those who use gradlew on Unix-like systems or use the scripts generated by Gradle in thieir application on Unix-like systems. For this vulnerability to be exploitable, an attacker needs to be able to set the value of particular environment variables and have those environment variables be seen by the vulnerable scripts. This issue has been patched in Gradle 7.2 by removing the use of eval and requiring the use of the bash shell. There are a few workarounds available. For CI/CD systems using the Gradle build tool, one may ensure that untrusted users are unable to change environment variables for the user that executes gradlew. If one is unable to upgrade to Gradle 7.2, one may generate a new gradlew script with Gradle 7.2 and use it for older versions of Gradle. Fpplications using start scripts generated by Gradle, one may ensure that untrusted users are unable to change environment variables for the user that executes the start script. A vulnerable start script could be manually patched to remove the use of eval or the use of environment variables that affect the application's command-line. If the application is simple enough, one may be able to avoid the use of the start scripts by running the application directly with Java command.
As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the permissions of temporary files it created so that only the current user was allowed to access them. Unfortunately the fixcrlf task deleted the temporary file and created a new one without said protection, effectively nullifying the effort. This would still allow an attacker to inject modified source files into the build process. -
As mitigation for CVE-2020-1945 Apache Ant 1.10.8 changed the permissions of temporary files it created so that only the current user was allowed to access them. Unfortunately the fixcrlf task deleted the temporary file and created a new one without said protection, effectively nullifying the effort. This would still allow an attacker to inject modified source files into the build process.
The HTTP client in Gradle before 5.6 sends authentication credentials originally destined for the configured host. If that host returns a 30x redirect, Gradle also sends those credentials to all subsequent hosts that the request redirects to. This is similar to CVE-2018-1000007. -
The HTTP client in Gradle before 5.6 sends authentication credentials originally destined for the configured host. If that host returns a 30x redirect, Gradle also sends those credentials to all subsequent hosts that the request redirects to. This is similar to CVE-2018-1000007.
In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. The problem has been patched and released with Gradle 7.0. As a workaround, on Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. If you are unable to change the permissions of the system temporary directory, you can move the Java temporary directory by setting the System Property java.io.tmpdir. The new path needs to limit permissions to the build user only. For additional details refer to the referenced GitHub Security Advisory. -
In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. The problem has been patched and released with Gradle 7.0. As a workaround, on Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. If you are unable to change the permissions of the system temporary directory, you can move the Java temporary directory by setting the System Property java.io.tmpdir. The new path needs to limit permissions to the build user only. For additional details refer to the referenced GitHub Security Advisory.
The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900. -
The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900.
Gradle versions from 1.4 to 5.3.1 use an insecure HTTP URL to download dependencies when the built-in JavaScript or CoffeeScript Gradle plugins are used. Dependency artifacts could have been maliciously compromised by a MITM attack against the ajax.googleapis.com web site. -
Gradle versions from 1.4 to 5.3.1 use an insecure HTTP URL to download dependencies when the built-in JavaScript or CoffeeScript Gradle plugins are used. Dependency artifacts could have been maliciously compromised by a MITM attack against the ajax.googleapis.com web site.
In Gradle before version 7.0, files created with open permissions in the system temporary directory can allow an attacker to access information downloaded by Gradle. Some builds could be vulnerable to a local information disclosure. Remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. Sensitive information contained in these files can be exposed to other local users on the same system. If you do not use the TextResourceFactory API, you are not vulnerable. As of Gradle 7.0, uses of the system temporary directory have been moved to the Gradle User Home directory. By default, this directory is restricted to the user running the build. As a workaround, set a more restrictive umask that removes read access to other users. When files are created in the system temporary directory, they will not be accessible to other users. If you are unable to change your system's umask, you can move the Java temporary directory by setting the System Property java.io.tmpdir. The new path needs to limit permissions to the build user only. -
In Gradle before version 7.0, files created with open permissions in the system temporary directory can allow an attacker to access information downloaded by Gradle. Some builds could be vulnerable to a local information disclosure. Remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. Sensitive information contained in these files can be exposed to other local users on the same system. If you do not use the TextResourceFactory API, you are not vulnerable. As of Gradle 7.0, uses of the system temporary directory have been moved to the Gradle User Home directory. By default, this directory is restricted to the user running the build. As a workaround, set a more restrictive umask that removes read access to other users. When files are created in the system temporary directory, they will not be accessible to other users. If you are unable to change your system's umask, you can move the Java temporary directory by setting the System Property java.io.tmpdir. The new path needs to limit permissions to the build user only.
Hello
I have implemented your lib normally it's working fine but when I used Recyclerview inside anther recycler view is not working
Thanks in advance
When i implement this library in kotlin it is working fine but when i implement in java class of my project...its not working
in JourneyDetailFragment, i add loadSkeleton to clBody and it gets call after clHeader skeleton is done.
body constraints are OK when skeleton loaded, but when it gets hide, it loses its constrains and goes on top.
i couldn't realize what's the problem, so it will be great if you could explain what happened there?
I have an issue with this library:
I call an external API via Coroutines and fetch the data. When I receive the data I want to hide the skeletons but it doesn't work. My code below:
CoroutineScope(Dispatchers.IO).launch {
val response =
service.fetchResults(finalUrl)
withContext(Dispatchers.Main) {
try {
if (response.isSuccessful) {
textViewTitle.hideSkeleton()
}
} catch (e: HttpException) {
Log.d("TAG", "error ")
} catch (e: Throwable) {
Log.d("TAG", "error" + e)
}
}
}
}
Any ideas?
Undeliverable exception received, not sure what to do
io.reactivex.exceptions.OnErrorNotImplementedException: koleton.custom.RecyclerKoletonView cannot be cast to androidx.recyclerview.widget.RecyclerView
hello , i'm trying to hide skleton from a view when api response received but when i call view.hideSkleton() i get this error ...
I have a situation where my view doesn't set up data in advance, I need to request data set up after the network, and the skeleton screen doesn't appear at this time
Hello, you have done a great work with this library!
My only issue is that sometimes the layout is calling requestLayout() multiple times.
Is this a bug?
Hi,
The following error is occurring.
Fatal Exception: java.lang.IllegalArgumentException
Wrong state class, expecting View State but received class androidx.recyclerview.widget.RecyclerView$SavedState instead. This usually happens when two views of different type have the same id in the same hierarchy. This view's id is id/rv_popular_show. Make sure other views do not use the same id.
I have a recyclerview with two viewtypes.
binding.recyclerview.loadSkeleton(R.layout.item_header_news) {
itemCount(1)
}
binding.recyclerview.loadSkeleton(R.layout.item_news_articles){
itemCount(5)
}
What is the correct way?
Should I give two viewtypes like above?
Doesn't matter what layout file I pass in the parameter, it is taking the R.layout.item_header_news skeleton.
Urgent. Can somebody help me in this?
TnQ for this great library .
There is an issue with RTL layouts. I have a TextView in End of the screen:
<TextView
android:id="@+id/card_type_action"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="مدیریت کارت ها"
android:textSize="14sp"
android:layout_marginEnd="@dimen/dimen_16dp"
app:layout_constraintTop_toTopOf="parent"
app:layout_constraintEnd_toEndOf="parent"
/>
When I call loadSkeleton function on the view, It goes to the start of the screen with exact amount of margin. and after calling hideSkeleton it goes back to end of the screen.
It's pretty well written, but this hiding of the displayview is a bit lost on me...
I have a BottomSheetDialogFragment with this layout:
<androidx.constraintlayout.widget.ConstraintLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
>
<androidx.recyclerview.widget.RecyclerView
android:id="@+id/category_list"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_marginTop="16dp"
app:layoutManager="androidx.recyclerview.widget.LinearLayoutManager"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent"
tools:listitem="@layout/item_category"
/>
</androidx.constraintlayout.widget.ConstraintLayout>
but calling loadSkeleton function does not show the skeleton on it. I've tried a simple textView and it worked but on RecyclerView nothing happens
First of all, Thank you for your fast bugfixes. I appreciate that.
I'll try to help you with reporting bugs and as soon as I can, I will contribute on the lib.
About this issue, take this layout hierarchy:
<androidx.core.widget.NestedScrollView
android:layout_width="match_parent"
android:layout_height="match_parent">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical">
<androidx.recyclerview.widget.RecyclerView
android:id="@+id/rv_first"
android:layout_width="match_parent"
android:layout_height="wrap_content" />
<androidx.recyclerview.widget.RecyclerView
android:id="@+id/rv_second"
android:layout_width="match_parent"
android:layout_height="wrap_content" />
</LinearLayout>
</androidx.core.widget.NestedScrollView>
So when I try to call .loadSkeleton() function on both of the RecyclerViews their order changes. so on loading state the first RV shows at bottom and the second one shows at the top.
Hi, @ericktijerou will support be added to compose ?
Need to move this library since jcenter is getting deprecated
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.