I need to display a Recyclerview that can have any amount of subheadings. Sadly I only found solutions that support a depth of one. This isn't enough for my case.
I could have something like this:
Heading 1
Subheading 1
Subsubheading 1
Subsubsubheading 1
Subheading 2
Heading 2
...
You get the idea. Futhermore, it would also be quite useful if the user can expand these headings and their content like in MS Word. How does one achieve this behaviour (if possible without external libraries)? Thank your for you support!
I ended up using a combination of the approach from user3170251 and my own. Because my headers are from different models I used an interface and all models implement that interface.
The recyclerview only gets a list of objects that implement the interface. By checking the type of the current element it knows whether it is a read-only header or a normal element with special on-click functions. Now, to have some sort of hierarchy you need to store the depth in the model itself. So the data hierarchy that the recyclerview sees is still a flat list, but by saving the depth in the model itself I can give headers with a deeper depth a smaller font size.
The answer from Anshul Aggarwal on Is there an addHeaderView equivalent for RecyclerView? really helped me out.
Related
I'm using Android Paging Library, and probably don't use it 100% correct.
I have a RecyclerView and a SnapHelper to basically implement a ViewPager.
My pages are per date, e.g. 2019-03-21, so there can be infinite amount of pages.
What I implemented is a ItemKeyedDataSource<String,String> which has the date as its param, and on loadAfter and loadBefore, all I do is add/sub a day.
This currently works just fine. If, for example, I load 2019-03-21, then I can easily cycle to its neighbors 2019-03-20 and 2019-03-22.
However, I'd like to add a feature to load a specific date, and then scroll there.
Using PositionalDataSource doesn't sound good either, since I can't say there's a finite count of items in my list.
I feel like I'm doing it wrong. Just not really sure what.
Also, if there's another way that doesn't include paging (sounds reasonable, since my paging is just doing some calculations but doesn't retrieve data), that's good too.
Well, I went for the alternative approach.
I'm using a regular list and adapter.
I'm using a list with padding for both sides (a list of 50 dates, while the initial date is at index 24), and when reaching index 10 or 40 (depending if we go up or down) I'm calculating a new list and post it instead of the old one.
It looks like an infinite list and everything looks good enough, so it works for me.
If anyone wants more details, please comment and I'll try to help.
Background: I have done a bit of looking into Caching in Spring and it seems like a great way to save time for common read operations. My code currently has a loop over a large number of items, where I am performing logic to see if certain other objects are connected in a way through common items. A way to think about this is similar to a shopping website's related items showing up when you view a certain item. The values I use to determine this are complex, but that is the basic idea.
On loading the item page there is a very long load time trying to compute and figure out which other items are related in some way as to display links to them. Instead of computing this list every time an item page loads, I have started "caching" items with a list of their recommended items. Many things in the system can trigger a need to recalculate these relations: adding/removing properties to items, adding/removing items, etc.
Problem: My "cache" is simply a singleton object containing a Map for items and their related objects. The process of iterating through every item in the system when any change to the cache is needed is very time consuming and process intensive. Java Caches don't seem to be the right answer due to constant changes to items. Is there any other design patterns that I am overlooking for this design? Caches seem to be close, but I am not sure if this problem fits into the mold of caching, due to it being a little more complex then a bulk amount of reads to a single item.
Are caches the way to go with this? If caching isn't the right solution, what is?
It seems that caches are not a solution for your problem, but they might help you in reaching a solution.
For example instead of caching the created items another approach is to cache information that rarely changes but is crucial to create the lists.
Spring function based caching (ie #Cachable) might come in handy, either for caching or invalidation.
The next level is to examine different types of caches (ie. redis) and what they offer in terms of algorithms, sorting and Pub/Sub.
I have to represent tree data having number of levels in android app. As per native API, using list view we can provide only two levels. It is also reasonable because using fat fingers we can't expand or shrink tree properly.
So is there any alternative way to represent this tree like data?
Can you not 'drill-down' by clicking on the second level. The second level then becomes the first level (visually) and you then add in the third level as the second level (visually). You will need a 'back' button of some sort to move back up.
Or do you need to show the whole tree at once? What is in your tree? Just labels/names, or multiple data values per node?
Also, a long shot - but for ideas (if you like writing your own components):
http://www.cs.umd.edu/hcil/treemap-history/
I have a program which has a structure like this.
Document which contains (up to 20)
Chapters which contain (up to 100)
Pages which contain (up to 20)
Elements
This structure is represented by JPanels in my program. Meaning this structure has to be visually represented, and I'd rather not make a whole complex of ArrayList (unless absolutely neccessary) since each JPanels have a ZOrder of component, and a getParent() method.
This structure is one-dimenisonal, meaning that the parent has an one-dimensional array (and when I say array, it's purely descriptive, I don't mean ArrayList or anything similar) of its children. Each individual element has an index which represents it's location in(on?) it's parent. Number of elements in a page, and pages in a chapter is inconsistent.
It's easy to get the child's index within it's parent, but what about it's grandparents?
Since the elements can be (and usually are) numbered, having a one numbered list per chapter, I'd have to know the index of element in the Chapter, so I can adjust the numbers when a new element is added to the list (it doesn't have to be added in the end).
This can be solved in two ways (that I know of, that is):
Have an ArrayList in each chapter that keeps all the elements. This would require me that, everytime I add a new element to any page, to add it to the chapter array too.
To accomplish that I'd have to go trough all the previous pages, add up all the elements on them and add index of the new element on the present page to that number, the result being the index of the new element in the chapter, and therfore, in the array. And do that each time I add a new element.
Recreate the arrayList each time I need to get the order of elements in the chapter. Which again means going trought each page and adding each element one after another until I reach the end of chapter. And I'd need it each time a new element is added.
So the question is, which of this two methods is better (more efficient memory or processor time wise)? Which is more in the spirit of Java and programming altogether? Is there a third option that I am unaware of??
Chapter example:
Page one {
1. something
2. more something
3. nothing
.
.
.
16. still nothing
}
Page two {
17. maybe something
18. nope, still nothing
.
.
.
21. giberish
}
etc.
The question is: Which way of doing it is better? If you have a better idea, you can tell me, but I want to know which way of the above two is better non the less.
You need to make a tree. For some reason, programmers want to flatten everything out into tabular structures. You are talking about a tree, you need to either use one or make one.
Sadly, there is nothing in the Java Collections for implementing Trees. You can make them fairly easily.
If you have things that are different contained in the tree, but that need to be treated similarly (as nodes), then do a simple implementation of the Composite Pattern. A good example is a filesystem tree: each node is either a Folder or a File. If you both have them implement an interface called FilesystemItem, then you can put them into their tree structure.
Since you are doing a Document, I would recommend Composite.
I have a table that displays the output from a database, this can often be up to or over 10,000 rows. I'm looking to implement a 'quick find' function that will allow the user to easily scroll to a row with the value for which they search.
The idea is for this to be very similar to Chrome or Firefox's quick find. So:
User hits 'CTRL+F'
A box pops up:
The user can then quickly skim through the table pushing / or /\ to each matching value
My question is, does such a table already exist? I have looked at NatTable and XViewer but they both seem like rather large additions for a relatively minor change.
Another library I've looked at that is close to fitting the billl is Lucene TableSearcher unfortunately this is designed for filtering rather than highlighting. However it may be an avenue worth investigating.
It's not quite the same, but JFace does have support for filtering views. You type in a text box and view contents shrink to what matches the filter. It's basically another way to present search/find functionality to the user.
You can see this in action in Eclipse Preferences (the filter text field about the navigation tree in the dialog). See org.eclipse.ui.dialogs.FilteredTree class. I don't believe there is a FilteredTable or equivalent, but underlying facilities are pretty generic, so it shouldn't take much work to put one together. Take a look at FilteredTree source and go from there.
The solution I chose wasn't as simple as I'd hoped but has a satisfactory performance.
The tables involved are virtual tables that can be very large. So on top of this upon loading the dataset we start a thread to build an index in the form of a list. Because these tables can be very large (but aren't often) we set a 50mb limit to this list and stop indexing it when we hit it. For most cases this is perfectly acceptable but for the larger tables it means that whilst it may be slower, it is considerably more stable than other options.
The 'search' is a simple SWT textbox with ModifyListener that iterates over the list, performing a 'contains' on each entry. Upon a match the row and column are calculated from the index number (0=0,0, 1=0,1 ..).
It would have been nice to have a simple 'drop in' solution for this but all of the tables on offer had too many features.
Use FilteredItemsSelectionDialog dialog box