I was looking for a ListPreference in which the user can change the order of items from a list. The items would be draggable and can be re-ordered by the user.
I saw this in my custom ROM (and I'm almost sure I saw it in Cyanogenmod) for the QuickPanel. Here's a screenshot to get the idea through:
I know how I can make custom ListView items and set the icon to indicate that the items are draggable, but I don't know how to make them draggable, and change the order accordingly. As for saving them in the preferences, I found this which could be implemented easily.
PS: I know Cyanogenmod is open-source, but I couldn't find the source for this particular thing :( The closest I could get was this, which should be somewhere near the other screen...
Thanks in advance for any tip about this.
UPDATE: I ended up using the files from the accepted answer, with additions and modifications. I am listing them here for further reference.
Use a custom Adapter (ArrayAdapter in my case), to implement the visual feedback that this item is draggable, which is an ImageView near the TextView. This is optional.
Set a DragListener and RemoveListener to update the list accordingly. The ListView does not do that automatically. And it depends on the Adapter you are using.
There was a line that casted a View to a ViewGroup, it made some errors, so I removed the cast without any issue, it was not needed. (in the onInterceptTouchEvent method).
Change mRemoveMode = 1; in the constructor of TouchInterceptor, or one of: FLING = 0; SLIDE = 1; TRASH = 2;. I think for TRASH, a resource should be available too.
I actually took the file not from the answer's link but from the Cyanogenmod one, which I already had, but I guess these files were the same.
These are the actual files in the project (at r12, at the time of writing):
The Preference using this ListView
The ListActivity with the listeners and the Adapter
The actual ListView
I hope it helps somebody else :)
There is no built-in widget to do this, but you may want take a look at the custom implementation used by the AOSP music player to allow for re-ordering of songs in playlists.
TouchInterceptor.java
That's the class which is extending ListView and is responsible for handling all of the MotionEvents and re-ordering its items, as well as detecting swipes for deleting items. You can see it implemented into an activity here in the TrackBrowserActivity.java class.
It has three interfaces you should also be aware of: DragListener, DropListener, and RemoveListener. You can use these interfaces to provide it callbacks to fire for those events, so that you can update changes made to the list order to your SavedPreferences (since the ListView will not handle that for you).
You can easily extend or modify the TouchInterceptor class to add additional functionality since the low-level stuff is all there for you.
Related
I'm using Recyclerview to show a list. I want to delete some items like IOS. In my listview template I have added a button to delete item which is invisible by default. In my activity I have another button attached at bottom (Not part of listview) and on tap of this button I want to make all delete buttons of listview visible.
My Question is how can I get reference to all delete buttons of listview in activity and is it the right way to do this?
Thanks
Assuming you have ViewHolders set up, you already have references to all the buttons in your list. All you have to do is to make them visible for every item in the list with a simple loop.
In case you haven't implemented ViewHolders I suggest you check out the documentation and take a look at some simple tutorials on how to use them.
On a side note. If I understood correctly you're making a bottom tab for your app and since you referenced iOS I gotta say this; Remember that Android and iOS are two unique operating systems with their own ways of handling things. Check out Googles pure Android documentation.
In your question title you say RecyclerView, but in your text you say ListView. The solution is similar either way, but it's best to be perfectly clear what you're doing.
In either case, there are at least two different solutions.
First, you could use a boolean flag to determine if all the the item buttons should be showing or not. You check this flag at the time the item view is inflated or created and toggle the button accordingly. If the boolean flag is ever changed, the easiest thing to do is tell the RecyclerView/ListView that the underlying data has changed and to redraw all the views. Call notifyDatasetChanged on the adapter.
The other thing you can do at the time the item buttons should change is iterate all the visible item views, find the button, and change its visibility. With RecyclerView, you can do this, and with ListView you can do this.
This is not a code problem, I interpret the guidelines as that being OK.
I've been researching a way of building an infinitely scrolling calendar-like view in Android, but I've reached an impasse.
Right now my dilemma is that most of the similar views available have their children placed relative each other in a recurring style. With this I mean:
item 4 comes after item 3, which comes after item 2, and there is constant padding/margin between all items.
What I need is a way to produce an infinitely long scrollable view that may, or may not, contain items. The items should be placed at variable positions within the view. The best way I can describe a similar looking view is a one-day calendar-like view that is infinitely scrollable.
So far my best two bets are using the new RecyclerView with a custom LayoutManager (this seems very complex and still not perfectly documented by Google though). I like this approach because, among other things, it is optimized for displaying large sets in a limited view.
My other solution would be to build a completely custom View. However, with that solution I loose the adapter unless I build a container view (which is probably more complex than building a layout manager).
How would you go about solving such a problem? Tips are appreciated, I don't need code examples, just ideas which path is the best to solve this problem.
Thanks.
Apologies if I've misunderstood the guidelines
Edit: How I resolved this problem
My first solution to use RecyclerView with a special Decorator seemed promising, but it remained a "hack" so we decided not to go for that solution since we were afraid of the complications that it would create down the line.
To solve the problem I went with a SurfaceView instead of an Adapter, this means having to rewrite all the adapter-functionality for my SurfaceView but it seemed to be the best way of solving this issue of very custom drawing and layout managing for my use-case.
It still would be nice to build a custom Viewgroup that can handle this kind of layout problems.
ListView and ListAdapter are based on a fixed list, so the current infinite-scrollers just keep adding more and more data to the end of the list.
But what you want is scroller similar to Google's Calendar app which has a bi-directional infinite scroller. The problem with using ListView and ListAdapter in this case is that if you add data to the front of the list, the index of any one item changes so that the list jumps.
If you really start thinking about this from the MVC perspective, you realize that ListAdapter does not provide a model that fits this need.
Instead of having absolute indexing (i.e. 1, 2, 3, 4, etc), what you really want is relative indexing, so instead of saying "Give me the item at index 42" you want to say "here's an item, give me the five items before it". Or you have something like a calendar date which is absolute; yet — unlike your device's memory — it has effectively no beginning or end, so what you really want here is a "window" into a section of that data.
A better data model for this would be a kind of double-ended queue that is partly a LRU cache. You place a limit on the number of items in the structure. Then as prior items are loaded (user is scrolling up) the items at back end are pushed off, and when subsequent items are added (user is scrolling down), items at the front are pushed off.
Also, you would have a threshold where if you got within a few items of of one edge of the structure, a "loadNext" or "loadPrevious" event would fire and invoke a callback that you set up to push more data onto the edge of the structure.
So once you've figured out that your model is completely different, you realize that even RecyclerView isn't going to help you here because it's tied to the absolute indexing model. You need some sort of custom ViewGroup subclass that recycles item views like a ListView, but can adapt to the double-ended queue. And when you search code repos for something like this, there's nothing out there.
Sounds like fun. I'll post a link when I get a project started. (Sadly, it won't be done in any timely manner to help you right now, sorry.)
Something that might help you a little sooner: look at Google's Calendar implementation and see how they did it: Google Calendar Git repo
What you may be searching for is a FragmentStatePagerAdapter , where you can implement a swiped view, meaning when the user (for example)swipes to the right, a completely new view is displayed.
Using a FragmentStatePagerAdapter , you can handle a huge amount of views without overflowing the memory, because this specific PagerAdapter only keeps the views' states and is explicitly meant to handle large sets of views.
Keeping your example of a calendar, you can implement swiped navigation between for example weeks and generate the week views on demand while only keeping for example the year and the week's number as identifiers.
There are plenty of online tutorials for Android, maybe you have a look at this one
(FYI, I'm targeting 2.2 Froyo in my project, so any solution would have to work at that build level.)
What I want to do seems quite simple; show a list of items in a ListView, and allow the user to tap to select multiple items before performing an operation on all of them at once.
To provide a little more detail, I am binding a ListView to an array of objects. The screen consists of other controls, with the ListView in the middle. Each list item has several components; two images, and a text label. NO checkbox. Instead, when the user taps an item, the background should change to indicate that it is checked. If the item is tapped again, the background should change back to indicate it is not checked. The user may tap one or more items. If the user scrolls the list off the screen and scrolls it back, the state of those items should be preserved.
From what I've researched, I gather that I need to:
use a Drawable as the background for the list items with selectors for checked, pressed and default states
create a custom class extending LinearLayout or RelativeLayout and implementing Checkable, then use this as the root View for the list item layout
I've found several tutorials online, but none work. Either they have runtime errors, or simple don't do anything... pressing the buttons does not change their appearance to checked.
I found an alternative approach in the O'Reilly "Android Cookbook." Rather than doing all of the above, they add a boolean to the objects the ListView is bound to, then manually add code to change that boolean when a list item is clicked and to change the background in the adapter for an item where the boolean is true. In other words, they don't use Checkable at all. This does not seem like an ideal solution to me; abandoning the Android API in favor of custom hacks often seems to cause bugs later on, and I'm uncomfortable with adding GUI information (whether or not an item is selected) to what should be a purely data-carrying POJO conceptually representing a chunk of information.
My question is this: does anyone have a WORKING tutorial to accomplish what I have described, using Android's Checkable functionality? Or is this so problematic that something like the O'Reilly hack always has to be used?
I have never read Android Cookbook but their strategy is exactly what I would do. I would decline to call this a hack and suggest this is the kind of thing that the Android framework intends to do. A selected state in my opinion is part of the model you wish to protect, I do see how it could be in a gray area as it removes the purity of your POJO's.
There is a second strategy you could use to protect the purity of your POJO's use the state of the background to find if something is selected or not. Additionally you could also use a plain color resource instead of a drawable background.
I need some valuable advice from you guys...
I have a UI where I have to drag objects from one view to another.
I have a rough sketch of this UI below
I think I have to create a custom view for this. I have to drag a square and a ball from bag 1 and bag2 [both bags are scrollable, can contain 10 to 60 items each] and drop it to the closet one by one. and later I have to find the number of items in the closet. The items in the closet must be arranged in a well maintained fashion [may be ...like 6 in a row].
Where should I start?
How many custom views should I use?
Is there a simple and effective UI solution for this?
Happy coding..!
I would suggest a design with three different GridView objects laid out inside a ViewGroup that supports dragging objects from one GridView to another. The objects would be custom ImageView subclasses so you'd have a place in code to support a drag-and-drop protocol of some sort and because you'd likely want to associate some data that is specific to your application with the objects being dragged.
As for the drag-and-drop protocol, you could consider an adaptation of the Android Launcher drag-and-drop framework or the current drag-drop classes described on the Android developers' website. I don't have much to say about the current drag-drop classes. I have not tried them yet, but understanding them is on my to-do list. However, I have done an adaptation of the Launcher code, and I have written it up on my blog and posted demo apps and source code there. See Drag-Drop for an Android GridView.
With the framework that originated in the Android Launcher, you have a good set of classes and interfaces to work with. Some of the objects include: DragLayer, DragSource, DropTarget, DragController, DragView. The DragLayer is a custom ViewGroup within which all drag-drop operations occur. It delegates handling of all the touch events to a DragController, which is the object that does the actual moving of objects around on the screen. As it does so, it interacts with DropTarget objects to give the user visual feedback that something is being dragged and that a place to drop something is available. A DropTarget is an object where something can be dropped. A DragSource is the interface for objects that can be dragged within the DragLayer. The Launcher framework is a good one because it gives you a way to think about dragging and dropping and how you want to divide up the responsibilities defined by the framework.
The reason I suggest GridViews for your problem is it sounds like you are thinking that way already. The closet has "maybe 6 in a row" so that could be a GridView with one or more rows depending on how screen space you have. A GridView would also work for the container that holds the squares and circles. If that is a good fit, you could study the code in my drag-drop tutorial and see if that makes it easy for you to move objects from one GridView to another.
In my demo program, I ended up with a custom subclass of ImageView that I called an ImageCell. These are views that are on the grid. An ImageCell allows objects to be dragged from them and onto them. For awhile as I worked on the tutorial, I had a custom GridView class too but ended up with the standard GridView. It sounds like you'd want a custom GridView because it sounds like being in the closet is different than being in the other sections. Having it gives you a convenient place for the methods you have not thought of yet.
I hope some of these suggestions prove useful.
Depends on the Android version you are targeting. For 11 and above you can use the built in drag and drop functionality, otherwise you are pretty much on your own. I would normally advice you to implement some sort of a long press action that might even allow you to select multiple items and move them in batches, which would be a really simple thing to implement.
If you really need DnD you should check out this example, it should give you some idea on how to make your own implementation.
I think that bag1, bag2 and closet can be three instance of the same configurable custom view (let's name it CustomBagView).
CustomBagViews should be responsible for displaying items (using a gridview of imageview for example).
I think those will not need to handle drag & drop directly but they should support
removing and adding elements
provide a setOnItemTouched(Interface_class) callback setter.
Then you will need to code a Container custom view (let's name it BagContainerView) that will contain the three bags and handle the dragging & dropping from the bags.
You will provide a handleDrag callback to each bag using CustomBagView.setOnItemTouched, then track the finger motion in it.
When the dragging finishes, you must find where it ends, locate the right 'customBagView' and ask it to add the item to its list.
i implemented a listview which implements SectionIndexer ...
everything fine so far.
Normally the items are sorted by Name, but i also offer the option to sort the list in a different way - by distance (from the user to the objects).
So, when the list is sorted the 2nd way, i want to hide the previously generated SectionIndex.
I'm just not able to do so.
I tried, re-writting most of the methods,
I tried it with a separation in the Constructor (clear why it doesnt work, it doesnt get called a second time)
I even tried it with implementing a second listadapter, and just using a different one? Even in this case the SEctionIndex is shown! I really don't understand this one.
So would be really great, if anyone knows whats going on :)
thanks a lot, mike
Your observations are correct. Let me tell you first why the constructor never gets called the second time. SectionIndexer are a special kind. They create the index only once for a particular set of data and re-use them on that adapter. The bigger issue which I had come across was when the underlying data changed for the adapter, the sectionIndexer still remained the same.
Check my Question and the answer there.
Coming back to your query here.
If you change the orientation after selecting the second option, you would observe that the constructor will get called and you will be able to re-populate the sectionIndex again. So basically you need to call onSizeChanged again and get the sectionIndex repopulated.
When you Short your List with different way ,you have a two option to load again .
after filled those new collection for adapter
1) you can make a notify this adapter .
2) you can fill set adapter again .
If by SectionIndexer which remains displayed you mean the section overlay you can achieve this by calling setFastScrollEnabled(false) before to switch to your other listadapter which does not implements SectionIndexer.