Situation
Need to present text files as a list of editable sentences or phrases as shown in the example below, for the purpose of a speech therapy tool. This was relatively easy.
The colored flags can be added, removed, or dragged to new positions as needed, and can be set to snap-to-character or snap-to-word (they will also eventually display data).
This was achieved by sub-classing EditText, to take advantage of all the in-built features like word-wrapping, spell-checking, text-selection etc.
Problem
The number of phrases or sentences in a document can be large, so using a simple LinearLayout in a ScrollView to display them is no good in this case.
To efficiently display my FlaggedEditText widgets the solution needs to take advantage of view recycling, so ListView is an obvious consideration. But as shown by the number of S.O. questions out there, ListView and EditText don't play nice together.
The requirements of the list are that:
FlaggedEditText widgets get focused when touched (the item containing the FlaggedEditText also gets selected).
Notification when an item in the list has been edited (including which item).
Standard gestures such as fling.
I've tried out numerous approaches suggested in the many S.O. questions over the past few days, to try and bend ListView to my requirements, but all seem to have their own short comings and result in hacky, messy code.
Questions
Does anyone know of any existing alternatives to the standard Android ListView out there, that are more EditText friendly?
Alternatively, does anyone have a clean, efficient, definitive approach to getting EditText working as desired in the standard ListView?
Finally, I'm considering sub-classing AdapterView to make my own FlaggedEditText specific ListView alternative. But if the issues stem from AdapterView of which ListView is also an indirect subclass, then I'd be wasting my time. Has anyone already been down this path?
Edit
Jim's excellent response below, and a recent viewing of Romain Guy and Adam Powell's old Google I/O 2010 presentation The world of ListView have suggested a possible solution.
In the I/O talk I was reminded that they convert views to bitmaps for some of their optimizations. Since only one EditText at a time can ever be focused for editing, I'm thinking I can sub-class ListView to provide an interface which, if ChoiceMode is single, will give the Rect of the selected Item and bitmaps of the ListView regions above and below the selected item. This could then be used to temporarily overlay the ListView with a vertical LinearLayout containing the "above" bitmap, an active FlaggedEditText and the "below" bitmap.
In this way, the FlaggedEditText widgets can effectively act as non-focusable EditText's in the ListView, but when an Item is selected, interaction is with the temporary overlay.
The "above" and "below" bitmaps could also easily be tinted to suggest inactivity.
Additional
In fact, I've just realized I probably don't even need the Rect of the selected Item from the interface. The "above" and "below" bitmaps and a FlaggedEditText using the same LayoutParams as per the ListView should be enough.
Many of the answers out there do not seem to describe the core issues surrounding this "problem" and why it is not "solved." The "problem" you face is that an EditText can expand and/or scroll, along with your ListView. Also, the expanding soft keyboard forces the ListView to redraw causing problems with keeping track of the focused item. And when an item is focused and has dynamic content, UX confusion can occur with touch gestures (e.g. if you touch an item in an EditText like the cursor and then swipe, did you want the cursor to move? Or the entire list?) It can lead to a lot of user frustration.
I'm sure you've seen this post:
Issues focusing EditTexts in a ListView (Android)
This creates problems in correctly displaying the elements within the ListView, problems with recycling properly (the redraw) and problems with gaining focus correctly. It is possible that creating a custom class that extends AdapterView will work, but it will probably still feel like a hack, and probably will not work as you want it to or it will be a large effort.
You will need to do a lot of backend measuring of the fonts, images and "visible" (or partially visible) items in the custom object that also account for the keyboard animation and dual scrolling (the ListView can scroll and so can the EditText - or the EditText will change in size, forcing the parent custom AdapterView to determine if it should also scroll and whether views have become visible or invisible as a result of adding or removing text/images from the focused object).
If you make assumptions like "the EditText will never be larger than X height" then you may get it to work, but obviously that is a very customized solution, which is why it is not easily implemented and isn't supported generically.
Also, you will need to make UX decisions about how to handle a focused item that has scrolled off the screen (you can track it easily, but if it scrolls back onto the screen, but it can interrupt user expectations about how swipe and touch gestures are handled - for example, does the cursor in the EditText move or does the entire list? if an image is touched, does a swipe move the image or does it scroll the list? You can assume it is not focused, but then a "redraw" event can make it lose focus unexpectedly, like the current ListView implementation.) In other words, you are likely to end up with many unanticipated odd UX issues...
Your best solution will probably be to use a dialog pop-up as mentioned in the post I referenced above. Or, when an item is tapped to be edited, you could have a layout appear above or below the ListView. You may possibly get the ListView to scroll and lock to it - to have it appear as if it were in the ListView - but again, that would be hard with the soft keyboard changing the usable portion of the screen - you can expect "drag" or a slow feel to the "snap" effect. And you will need a "done" button...
To get your custom EditText to work with this suggestion, in the ListView you could disable it and make it non-focusable, then place an empty layout over the entire EditText that captures and processes the touch/fling/swipe events. This "invisible" layout may be the only option you really have.
In other words, you should probably plan to change your UI/UX rather than try to force Android to figure out how to handle several dynamic, and possibly conflicting or unpredictable, aspects of the UX interaction of these layouts.
Related
I have a details fragment that is using a DetailsOverviewRow and FullWidthDetailsOverviewRowPresenter. When the page first loads the action buttons are selected. When I press down once, focus leaves the buttons and nothing else happens. When I press down a second time focus moves to a ListRow that is further down the page. I'm trying to figure out why the overview, or body as it's called in the presenter, section doesn't focus.
Should there not be a second 'state' between the two screenshots where the overview/body is readable?
Possibly of note. The DetailsFragment isn't declared in an activities xml, I'm changing fragments manually using FragmentTransactions. Also, the Fragment is instantiated using a static create method (source below).
Thanks in advance.
Activity xml
DetailsFragment java
I haven't tried this example in particular, but from my time spent with Leanback support library, I learned that even though a lot of helpful stuff is indeed provided, a lot is not :D
So I would try these things:
1) Make sure that something in the area you want visible is focusable. (Clickable elements should be focusable by default, but better check too) What I mean is that on the screenshot, there is just text, no buttons or editable content in that area. So when you press down, there is nothing to focus. What happens if you make the body TextView focusable?
(Yes, one would expect that the support library would take care of that, but that might not be the case.)
2) Find out what actually gets focused when you press down, since as you said, the focus leaves the buttons - but where does it go? (How to find out which view is focused?) You might have a "direction problem" somewhere. That is - the focus travels based on the view hierarchy tree, not based on what we see on the screen. In some cases, it is possible to skip some elements or get stuck somewhere by moving focus through an unexpected part of the view tree, that makes sense for the algorithm, but isn't logical from the human perspective.
The details presenter focus works this way :
1) First focus is given to Action buttons. Right/left nav press shifts the focus right/left between action buttons.
2) Down nav press from actions row shifts the focus from actions row to details row (individual details items itself are not focusable), this is achieved by shifting the Thumbnail anchoring position to further south.
3) Down nav press from details row shifts the focus from details row to related row.
So the details row gains focus by changing the anchoring position of Thumbnail image. Is your thumbnail image changing its anchoring position when pressing down from actions row?
Hate to answer my own question. This was due to my failure to RTFM. I was creating the fragment UI after a network request completes. For the FullWidthDetailsPresenter to work properly it and the ClassPresenterSelector() should be initialized in the fragments onCreate() method.
I need a component that works like the picture below but I'm having trouble coming up with some kind of decent solution that works.
I want the list to have a center locked selection but being scrollable with the d-pad. This is for an application running on a TV so no need for touch scroll. So when pressing down on the remote d-pad the list will scroll and a new item will size up and the current selected one will size down and the new selection will still be in the middle.
I've tried doing this using a ListView that I extended and programmatically scrolling when pressing down or up. On scroll finished I called notifyDatasetChanged() on the ListView for re-inflating of the childs and in the ListViews adapters getView() I made the animation of the view located at the current selected position.
This is not optimal since I need to call notifyDatasetChanged(), which re-inflates all visible views, for the animation to apply. The UI becomes laggy when doing this and scrolling fast. It's also not possible to make som kind of compress animation when current selected item goes out of selection. There is also some trouble with the end items (read views) such the first or last in the list when doing animation of them, the may sometimes go out of screen.
I think that his must have been done before and maybe I'm missing it when searching for an answer.
Have anyone done something similar or do you have some suggestions of how this can be achieved? Maybe I'm just starting of with the wrong component here..
Regards,
Kristoffer
I created a scrollable custom ViewGroup which has several >200 EditTexts in it (not all of them are shown at the same time - I am using a recycler). The problem I am having is that the scrolling is very slow.
Interestingly, I don't have the problem if I do one of the following
1) disable the editText [editText.setEnabled(false)]
or
2) If I change the view from EditText to TextView
Any ideas on what the issue could be?
EditText is huge. Take a look especially at all those methods it inherits.
Why don't you try using just one EditText with 199 custom TextViews or a large grid of rectangles drawn within a Canvas? You could always customize your TextViews (or your drawn grid of rectangles) to make them look like edit boxes, but only use one EditText for the cell that has the focus itself.
That's even how Excel works for some of the functionality it has. It can edit a cell directly (yes), but it also has a static cell on the upper left of the Excel spreadsheet to show you the content of a formula (that may already be rendered as a view within the focused cell itself). You could do something similar yourself. You could extend an EditText to do all the hard stuff, like auto-complete, etc, but you could just draw the text inside the rectangle that has focus (or insert it inside the particular TextView that has focus).
Take a look at this example:
https://github.com/dennis-sheil/android-spreadsheet
He seems to be using mostly TextViews (although TextViews are heavy too, I'm starting to think that the Canvas may be better for something like this, and that everything could be simulated with the drawing method, by everything I mean the blinking cursor, the highlighting of the cell, the character by character typing, etc). With the Canvas at least, you can easily tell it what part needs to be drawn, and what part is off the screen and doesn't need to be drawn, so you're less likely to get into memory problems.
It can be issue with focusing the EditText during the scroll or you create too much objects and it is slow. Use ListView with EditText. Recycle views using viewHolder pattern. It will be smooth but I'm not sure if it is what you are looking for.
I am trying to make a ListView for showing lyrics. I have very little experience with making custom compound views. So I would like to know what my approach should be to make this view. The ListView must have these features
auto-scrolling based on the song (the timing information will be stored in the list adapter)
highlighting the current line which is being played on the audio
indentation on some lines to make it look more like a nicely formatted poem
users should not be able to scroll the list when the song is playing (i.e. the list is being auto-scrolled) but it should be scrollable when the song is paused
I don't know if the view should extend list view or not. If not then what should it extend and what should be my approach?
Frankly, I really don't have enough information to answer this completely, but this is what I would do:
If it were up to me, since you don't want a scroll capability at all (you want to make it appear as if it is scrolling, not to actually allow the user to scroll), I would not use any of the complex views like ListView or ScrollView, I would just write a custom view, simply extending View. I would override it's onDraw() method and use Canvas.drawText(...) to draw the words, having two different Paints, one for the current word and another for all other words. As for the "scrolling" effect, you can keep a number that represents the current top line that you can see, and add one to this number when you want to scroll to the next line. However to make it smooth you can manipulate where exactly you start drawing the texts and move it slowly upwards, so that it would appear that everything is scrolling down.
** Maybe it would be better to use SurfaceView here instead of just View, especially if you want a background image and smooth blending and better a look, since SurfaceView is much better for complex drawings **
If that is too complicated for you and you want to use existing views entirely without doing any of the drawing yourself, I would recommend a vertical ScrollView, you fill the ScrollView with horizontal LinearLayouts for each line, and each of those is filled with TextViews for every specific word. You can programatically build the TextViews and the LinearLayouts. Use ScrollView's scrollTo(...) or SmoothScrollTo(...) to scroll to the right location. You can prevent the user from scrolling by capturing all the motion events before they are used to scroll.
Both approaches will of course require you to maintain some form of data structure to hold the times each word is selected.
I find listView recycles its views too fast.
When my listView scrolls, views falls off the screen gets removed right away.
Each cell(row) has image loaded using universal-image-loader.
Views which fell off the screen has to reload the image when they comes back into visible area. (it shows the stub image for short time period and loads the correct image).
I definately need to keep the view recycling behavior, but can I modify the list view's behavior so that user won't notice constant reloading of images?(maybe I keep 2-3 times of # of views in a cache than a regular list view would)
Unfortunately the code for ListView and friends is horribly complicated by the fact that it's designed to scroll unevenly-sized items without knowing the height ahead of time. That makes it brutally difficult to run with anything but the default behavior. In addition, most of the methods you'd need access to, to easily customize the behavior are hidden or private. It would be a massive job to try and roll your own (across multiple platforms, subtleties of scrolling, flinging, dragging, scrolling, keyboard focus &c).
The best solution is probably to maintain an image cache that fills in lazily around the view positions that are active. Not neccesarily easy. But way easier that trying to mess with ListView.
A very useful API for this is ListView.setRecyclerListener(AbsListView.RecyclerListener listener), which gives you a hook to track which images are actively displayed.
I can suggest you to use a ScrollView instead of the list view. The ListView is designed to display a lot of data efficiently, that's why your off screen items are destroyed. In which concerns the scroll view, once loaded, you will be able to scroll up and down without recreating the off screen objects (because they ill not be destroyed).
See: http://developer.android.com/reference/android/widget/ScrollView.html
EDIT:
If it is mandatory for you to use the listView, you cluld take a look here: How do i prevent recycled ListView items from showing old content?
There is a posibility to override the listView getView method and keep more items not to be destroyed that the number the listView is keeping.