This solves the problem of mass data sets and heavy widgets crashing your app or making it slow to a crawl however, this efficiency comes with a price: there’s now a disconnect between the View and the single piece of data (or datum) that it represents. As you slide up and down in the list, views are recycled as they exit the screen, reinflated with new data, and pushed back into the other end of the widget where you’ll see them. The RecyclerView widget takes a much more practical approach: it will only inflate enough View objects to fill the screen (plus or minus a couple for smooth scrolling). Luckily, there’s a better way, the RecyclerView. However, if you have a very large dataset or if you start to use heavier widgets (such as ImageViews), you can easily create a massive and sluggish UI that eats your memory and slows your device while not even being visible on the screen. This won’t be an immediately obvious problem if you either have very few pieces of data or your views are light-weight. The ListView has a major drawback: for every data item in your list, a View is generated. onItemClickListener came back with the View that was tapped and the position in the data the view represented, allowing you to easily modify both. This widget was exceedingly convenient, as it provided an onItemClickListener for easy data interaction. When I first began using Android, back in the Jellybean days, displaying lists of data from a data source had a lovely widget that you could easily use called ListView. Android ListView, Inefficient but Convenient
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |