We currently use react-base-table as our solution for an infinitely scrolling table component, but it runs into performance problems with a large number of columns because it does not virtualize horizontally. My understanding is that ag-grid does, so we are looking at it for primarily performance reasons.
Our app defaults to displaying data (log events) from bottom to top. The user is initially placed at the bottom of a potentially large virtual dataset (could be millions of events), and they scroll up to load and view more events (200 at a time).
After reading through ag-grid docs and searching here, I don't see anything about support for an upward direction for infinite scroll. Am I missing anything?
I've tried implementing it with the default row model, but am running into errors (eg "cannot draw while in the middle of drawing rows"). The 'onViewportChanged' event I'm using to trigger a fetch is called several times when rendering, and messes up our data model. Infinite scroll seems like the correct approach.
Yes, it is possible.
You will need to set serverSideInitialRowCount={1000} so the grid could adjust scroll size. And then in the onGridReady event call api.ensureIndexVisible(999).
The grid will request only the last data block, and will request other blocks as you scroll up.
Related
I have a grid view which is showing the heal status of many different services, and coloring them and/or auto-opening a webpage when the service goes down. The problem is that the elements which are off the screen are not being checked, which is more efficient, but not what is desired in this case.
I guess it's behaving similarly to the RecyclerView in android?
I want to be building the widgets which are checking service health even when they are not visible on the screen.
Currently the services don't start being checked until the moment I scroll them into the screen.
Assuming you are currently using the GridView.builder constructor, I recommend using the "normal" GridView constructor (with a children property). Since GridView.builder only builds the elements currently visible for efficiency reasons, the elements that are not rendered on the screen won't run your back end logic.
For more information, see the official docs:
[GridView.builder] constructor is appropriate for grid views with a large (or infinite) number of children because the builder is called only for those children that are actually visible.
Here you'll find alternatives:
The most commonly used grid layouts are GridView.count, which creates a layout with a fixed number of tiles in the cross axis, and GridView.extent, which creates a layout with tiles that have a maximum cross-axis extent.
I'm running into a problem of how to display sequences of core data entities on a single graph, if there are time gaps between sequences.
I got a fixed-length bar graph (backed by UITableView) with each bar represented by a core data entity, all entities are timestamped and follow each other, so sorting such data results in a graph like below. The good thing about such graph is that NSFetchedResultsController can be used to dynamically update the table view in response to new events being added. The result is that it appears to the user that new bars are added on the left as time goes by.
My problem is that I want to expand this graph and make it 24 hour long and scrollable side to side. In this case, there will be episodes where no data will be present in the app. The end result is that if I rely on NSFetchedResultsController when there are gaps in data, and I want to display blank cells for missing data.
I'm interested in how you would approach the problem.
I see two potential solutions:
1) Drop the approach of using NSFetchedResultsController, and instead manually calculate the number of bars in a UITableView. Each bar is defined by a start date and an end date. Then I can use NSFetchRequest with predicate to query each bar's data. If there's an event with a timestamp that falls within the bar's date range, then a bar is shown, otherwise a blank is shown.
The problem with approach #1 is that it is slow, and while it does allow scrolling through the entire data set, it is slow and laggy, as each fetch request is executed for each new bar. Additionally, I need to manually refresh the table in response to new data being added, which is difficult to implement properly.
2) Maybe I can pre-populate the data set with blank events, and then "fill them in" as data becomes available. This would allow me to keep the table view with fetched results controller, resulting in smoother scrolling, but at the price of significantly increasing the persistent storage used by the app (as blank entities will be created between app use).
I'm wandering if there's an additional approach that I'm not thinking of. How would you create a side scrollable bar graph that would allow for "gaps" in the app's persistent data storage?
Thank you for your input!
Your question really doesn't have (or shouldn't have) anything to do with Core Data or NSFetchedResultsController. How your graph view draws the data it's given is entirely up to the graph view. There's no reason that you couldn't write a graph view that uses NSFetchedResultsController and deals appropriately with gaps in the data, but UITableView was never intended to deal with missing/empty cells.
The problem is not that you're using either Core Data or NSFetchedResultsController. The problem is that you're abusing UITableView.
Drawing a bar graph is pretty easy -- it's just a series of rectangles drawn at appropriate locations. You can give your view a fetched results controller and have it look at the fetchedObjects property to get the current list of objects. It can then render as many of those objects as it likes, and it can use the start and end date of each object to locate the drawing on the graph. Put your graph in a UIScrollView so that you don't have to worry about scrolling. If the graph can get large, add tiling so that you're only drawing the parts that the user is looking at, just like UITableView does.
It looks like you're currently drawing some content above your table view, too. If you create your own graph view, you might consider drawing that additional content (the red line, the red and green bubbles, the high REM probability thing) at the same time. Doing that will make it easy to ensure that all that content is located correctly on the graph (which is probably a bit of a pain with your current scheme).
I have a set of items with images, videos and .gif images that are displayed in a UIWebView that are being rendered dynamically when user scrolls to the bottom of the scree and reaches the end of the current UIScrollView offset. When downloading the items from the web I can display an activity indicator that makes user experience smooth and nice, but when I have all the data cached and retrieve it from cache I have a pretty annoying lag when all the items are being rendered at the same time (5 items per loading operation). My question is: Is it possible to somehow remove the lag from the UIScrollView when rendering items on it? And how can I display an activity indicator when rendering items on main thread? Specifically the lag happens when user scrolls to bottom, the scroll freezes, all items are rendered and scroll continues to go to bottom with the same force user has dragged it with.
P.S. I cannot use UITableView, so please do not suggest using it instead of scroll view.
You should consider using NINetworkImageView from the Nimbus project: https://github.com/jverkoey/nimbus
The reason it works well in your scenario is because it's manipulating the fetched image on a different thread. It does things like cropping and resizing and just gives you the end result on the main thread.
For a more complete sample, please see my answer here: https://stackoverflow.com/a/10361005/434841 for a similar question.
I'm trying to develop a scrollable tile map in Cocos2D which uses an UIPanGestureRecognizer to do the dirty work, but while developing it, stumbled upon some problems for which I would like to ask for an advice.
The basic scrolling management works fine, it's precise and accurate and works by adding the translation recognized by the pan gesture manager to the tiles of the map. The problem is that the map is large and I just draw a small viewport of it, while I want to manage it like it's scrollable without any problem.
What I was thinking about is that, as soon as a whole row or column get out of the visible screen, it is moved to the opposite side, the corresponding texture rects are updated (I'm working entirely with a CCSpriteBatchNode), so that it will continuously update the viewport to make the whole thing work. This seems fine but I've found many problems in dealing with when to move the row/column, how to keep track of this issue (eg when pan changes direction from forth to back) and many little details which make me think that I should find a better approach.
Is there a common solution to my problem? That is: managing a scrollable viewport of a tilemap which should move over the whole map so the to the end user it seems like as if the map is infinite.
Thanks in advance
I solved my issue by developing a viewport in which rows and columns are effectively moved from left side to right side and from top side to bottom side.
This is done automatically when a new column or row enters the viewport and it's made by expanding the drawn viewport over the real one by an amount which is enough to avoid any graphical issue to the user.
I'm trying to implement a view that shows a grid of information without using a UITableView, however, since I'm displaying about 36 different statistics, with its label I will have to initialize and use 72 UILabels. Does having so many UILabels mean that my iPhone app's performance will be significantly negatively affected? Is there a way to reuse some of the UILabels to decrease the number of UILabels that must be loaded at one time, or should I just resort to drawing everything on a surface instead?
First of all you should test the interface your thinking of and see if it takes a performance hit. Having a lot of labels all loaded at once will increase your memory footprint but depending on what else is going on in the app, it might not matter.
Secondly, you can't easily reuse the labels but it is possible. However, you would have to constantly monitor the displayed area of the scrollview and move the labels frames around as the view scrolled. I doubt you could do that efficiently. It would take a lot of coding in any case.
Thirdly, any grid like layout can be easily displayed in a table without making it look like a table. For example, the photopicker layout is a table but it looks like a bunch of icons on a white background. Another app I saw used a table to display paragraphs of text but it looked like an ordinary scrolling textview. Every row in a table can be customized to display exactly what you want. In principle, you could use a different cell for every row and they could all be unique in their height and contents.
The advantage of the table is the the table manages what is and is not on screen for you. It does reuse cells and their contents which makes them more efficient. The table also makes it easier to manage a lot of data.