I've been working exclusively with ComponentArt controls and want to know what else is out there. What Grid and Treeview controls are worth investigating?
It doesn't matter if I need to pay for them... quality, speed, and reliability are key.
I've seen a few issues with the CA Grid Control has issues with setting the column width dynamically, and documentation is spotty. However it has a single programming model with the SOA offering. Are there better options out there?
Try dhtmlx Grid and dhtmlx TreeGrid , although these are javascript components we have used them with asp.net and find them to be very fast and flexible.
jqGrid is a nice AJAX-enabled grid written in JavaScript that has worked out well for me in several recent projects.
jQuery treeView looks like a bare-bones treeview that may be worth investigating, although I have not used it on any projects so your mileage may vary.
I use the Telerik's AJAX/Silverlight grids for my web apps and I am pretty content with them. The components are flexible and designed with the idea of rich set of features without compromising the overall performance. If you want to have a look at their online examples, go here.
Dick
Related
I'm allowing users to select an icon from the full list of FontAwesome icons (using a List<ImageVector>). I'm going to open a dialog, and show the icons as IconButtons arranged in the list. There are ~1600 icons.
I implemented it using a LazyVerticalGrid, with a fixed number of columns. It works, but there's some lag loading the icons, and lag when scrolling the icons.
I'm converting this from a React Native project where I did the same thing (with a larger set of icons, actually) and scrolling that was pretty snappy, so I'm assuming it's possible to do performantly on native. Perhaps ImageVectors are heavier than the SVGs I was using in React Native?
I'm planning to provide a search box in the dialog where users can filter the list down by doing a fuzzy search on icon names, so the grid will change over time.
What sort of patterns should I be looking at here? Is LazyVerticalGrid the way to go, or should I be using a different approach entirely?
On Laziness
For an overview of use cases and appliable patterns you might be interested in the Android Dev Docs' page on Lists and Grids, încluding the topics Large data-sets (Paging) and the Tips on using Lazy layout.
This might wake your interest on the Android Jetpack Paging Library androidx.paging, which is designed for loading and displaying pages from large datasets, basically uniting the concepts of Laziness and Caching.
Currently you're only using Laziness. As Bartek Lipinski commented, that should usually be fine when the graphics to display are static. However, when they have to be loaded asynchronously, Paging will probably improve your performance.
Some Rules of Thumb
Scrolling
Pattern
No
Column or Row will be enough
Some
Column or Row with modifiers verticalScroll and horizontalScroll
More, static content
LazyColumn or LazyRow, resp. for gridding LazyVerticalGrid or LazyHorizontalGrid
More to mass, dynamic content
LazyColumn or one of its relatives with LazyPagingItems, so using the Paging Library androidx.paging
Also, as the docs say, consider adding contentType
. However, as Bartek Lipinski remarked, one usually benefits of contentType when there are scrollable elements of various types -- not only SVGs as maybe in your case. Still, giving hints to the system doesn't hurt, at least.
On Vector Graphics
As discussed in the comments, esp. by Subfly and Bartek Lipinski, though Laziness should be the main thing here, another bottleneck could be the loading of vector graphics during runtime.
If the graphics used are of static nature, then consider the usage of vector graphic assets. Those are supported for SVG and PSD since Android 5.0 (API level 21). Take also a look on the recommendations and some aspects of support and restrictions on SVG.
Summary
The basic formula is Laziness + Vector Assets with focus on the first. One might spice that with contentType and Paging.
I've continued my journey with Singularity, and I'm enjoying experimenting with this framework. I've created an experimental site at Sassmonster.com (Github repository here at https://github.com/58bits/sassmonster).
I was discussing this framework, along with other 'semantic' frameworks (if that's the right term in this case) vs presentational markup frameworks like Foundation, and Bootstrap.
I was wondering if anyone could summarize the relative merits of the approach that Singularity (and the original Semantic Grid) takes - without requiring grid classes or attributes to be present in markup.
The main advantage, if I've understood this correctly, is the ability to dynamically change layouts independent of document source order or any fixed class attributes (e.g. new grid layouts and grid span settings at given breakpoints, including source order independent changes like a sidebar switching from the left to right sides).
I'm sure there are others but would be grateful for a summary from someone with more experience than I have ;-)
Lastly - in terms of the future of grid systems in general - will the general adoption of the CSS Grid Layout Module obsolete frameworks like Singularity?
The advantage to semantic frameworks is that they take abstraction a level deeper than class names. This gives you, the author, the flexibility to generate your own list of classes like Bootstrap or Foundation OR you can apply grid styles to any element without being restricted by classes. Classes are flat and inflexible but having logic abstracted to mixins provides significantly more flexibility.
The advantages you address have more to do with the output model. Singularitys default output mode is called isolation and you can read about how it works here: http://www.palantir.net/blog/responsive-design-s-dirty-little-secret. With singularity you can use old fashioned floats or even write modules for CSS grid layout if you want. Singularity was designed to be future-proof and provide a common framework to do many different things with grids.
Lastly, yes, grid layout does some really awesome stuff and I hope it makes Singularity and other grid systems obsolete. However the syntax and conventions of grid layout is not so great and you may want to abstract some of it out. Some of the conventions are similar to that of Singularity like ratio based column math so that is pretty cool.
The more modern UI frameworks offer some kind of support for complex ListItems. For example, a picture and 3 lines of text.
How can I do this in an eclipse RCP application? Are there any open source frameworks for this?
You could use a TableViewer and use an OwnerDrawLabelProvider. This label provider gives you complete control over what is drawn in the table rows. The disadvantage is that you do have to draw the rows yourself using GC based operations (not too hard for images and text).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am trying to decide between slickgrid and jqgrid. I think both of them are feature-rich. Jqgrid has great documentation, so its easy to get up & running.
I am trying to understand, how different they are, in terms of implementation details since I heard slick grid is lot faster. I was just wondering if anyone did some benchmarking / know the internals of each grid to provide some useful inputs.
Edit1: #oleg - Thanks for your response. Sorry, I was afraid that I might not have provided enough details. Although I do not have all the use-cases, but I will be using both the local data when data is small and server-side virtual scrolling, filtering, sorting etc. when data is large. Json will be the primary datasoure. I was trying to get inputs from someone who might understand the internals of both grids. I do not understand the client-side implementation enough to judge those myself. One of my colleague's mentioned that slick grid might be better since it was developed with virtual rendering and key-board support to being with. My question is open ended but the core-implementation of the grid might make it efficient in the more complex scenarios too i.e. sub-grids, trees etc. if there is no departure from the core design to handle any of those.
Ok, based on ur expertise of jqgrid, how would you respond to this snippet from Slick Grid ?
"Grid vs Data
The key difference is between SlickGrid and other grid implementation I have seen is that they focus too much on being able to understand and work with data (search, sort, parse, ajax load, etc.) and not enough on being a better “grid” (or, in case of editable grids, a spreadsheet). It’s great if all you want to do is “spruce up” an HTML TABLE or slap a front end onto a simple list, but too inflexible for anything else.
Data is complicated. It has business rules. It has non-intrinsic properties. Editing one property of an element can lead to cascading changes modifying other properties or even other elements. It has dependencies. What I’m saying, is that dealing with data is best left to the developer using the grid control. Trying to fit all of that into the grid implementation and API will only limit its applicability and add considerable bloat.
SlickGrid takes a different approach. In the simplest scenario, it accesses data through an array interface (i.e. using “dataitem” to get to an item at a given position and “data.length” to determine the number of items), but the API is structured in such a way that it is very easy to make the grid react to any possible changes to the underlying data."
Edit 2: Snippet from Datatables forum post : "*DataTables is trying to spruce up an HTML table. This can be seen, for example, by the use of the TABLE tag by DataTables, while SlickGrid uses DIV elements to create a display which looks like a table. As such, there are a number of techniques, like the virtual rendering, which can be used with the DIVs - but not with a table. It's not possible to simply render rows 100-110 and not the first 100 in a table, but it's no problem with DIVs, so I'm afraid that this isn't applicable at the moment. What would need to be done is to convert DataTables to using a DIV tag markup, but then you loose the primary goal of DataTables, which is focus on progressive enhancement and accessibility.*"
Thanks
I looked at jqGrid and SlickGrid and found that SlickGrid is much more elegantly written; less configuration is needed for most use-cases for SlickGrid; jqGrid, however, need less configuration to set up the more complex cases (such as virtual scrolling);
jqGrid might have better documentation but the server-side connection part for jqGrid is covered by a commercial offering and documentation on this part is more difficult to obtain than for the client-side.
SlickGrid, on the other hand, have some great examples which covers most use-cases and the source is full of comments and is accessible to anyone with some intermediate knowledge of javascript and jquery.
Having used both jqGrid & slickgrid in production/anger, here are my 2 cents:
jqGrid was very easy to get started with and hook in. However we quickly found ourselves grating against having to fit what we wanted into jqGrids way of doing things. We also found the editing capabilities difficult to implement and (from memory - this was a year ago) it forced you into a row edit model, rather than cell edit which did not perform well.
With slick grid we have yet to hit a feature that was missing / we could not easily plugin. The documentation was fairly non-existent but is now much better (https://github.com/mleibman/SlickGrid/wiki/_pages) but to date we've just been jumping into the source. Have to say the api is one of the best I've seen, and performance with large data volumes and complex editors has been excellent (some issues on ie7 but never isolated that to the grid vs our MVC framework & complex editors)
All in all, I'd highly recommend slick grid
Which language is more difficult to study: Chinese, Finnish or the language of some small Indiana folk?
The comparing questions are always too difficult. You have to have people who really good knows all the products which you want to compare. Moreover you should define which part of the product you plan to use just now and which could be important in the future. Do you use JSON or XML data for the grid input or you use local JavaScript data? Do you need to use standard grid or grid with subgrids, treegrid or a grid with grouping?
Before you not define the area of the usage of the grid more clear you will not receive any good answer. At the end is sometime could be even important which know-how you have currently and just which documentation or examples you can easy understand and use yourself. The experience of other people which you can use could be more important as the features of the product. If you look at the number of questions on the stackoverflow.com with the tags "jqgrid" and with the tag "slickgrid" you can see in what product could help you stackoverflow
I agree with #user175528. We've used the grid extensively in our application too and its built in formatters, editors and validators are really easy to use and its easy to write custom ones as well.
It handles large datasets well (and makes searching through them a breeze). Additionally, its easy to setup paging and sorting.
Initially when I started using the slickgrid, I had wrapped it in another widget so that I could move to another provider if need be, but as of now, it seems to work flawlessly.
I haven't gotten around to it yet, but I will be posing some good slickgrid examples on my blog.
Is there some standard way to make my applications skinnable?
By "skinnable" I mean the ability of the application to support multiple skins.
I am not targeting any particular platform here. Just want to know if there are any general guidelines for making applications skinnable.
It looks like skinning web applications is relatively easy. What about desktop applications?
Skins are just Yet Another Level Of Abstraction (YALOA!).
If you read up on the MVC design pattern then you'll understand many of the principles needed.
The presentation layer (or skin) only has to do a few things:
Show the interface
When certain actions are taken (clicking, entering text in a box, etc) then it triggers actions
It has to receive notices from the model and controller when it needs to change
In a normal program this abstraction is done by having code which connects the text boxes to the methods and objects they are related to, and having code which changes the display based on the program commands.
If you want to add skinning you need to take that ability and make it so that can be done without compiling the code again.
Check out, for instance, XUL and see how it's done there. You'll find a lot of skinning projects use XML to describe the various 'faces' of the skin (it playing music, or organizing the library for an MP3 player skin), and then where each control is located and what data and methods it should be attached to in the program.
It can seem hard until you do it, then you realize it's just like any other level of abstraction you've dealt with before (from a program with gotos, to control structures, to functions, to structures, to classes and objects, to JIT compilers, etc).
The initial learning curve isn't trivial, but do a few projects and you'll find it's not hard.
-Adam
Keep all your styles in a separate CSS file(s)
Stay away from any inline styling
It really depends on how "skinnable" you want your apps to be. Letting the user configure colors and images is going to be a lot easier than letting them hide/remove components or even write their own components.
For most cases, you can probably get away with writing some kind of Resource Provider that serves up colors and images instead of hardcoding them in your source file. So, this:
Color backgroundColor = Color.BLUE;
Would become something like:
Color backgroundColor = ResourceManager.getColor("form.background");
Then, all you have to do is change the mappings in your ResourceManager class and all clients will be consistent. If you want to do this in real-time, changing any of the ResourceManager's mappings will probably send out an event to its clients and notify them that something has changed. Then the clients can redraw their components if they want to.
Implementation varies by platform, but here are a few general cross-platform considerations:
It is good to have an established overall layout into which visual elements can be "plugged." It's harder (but still possible) to support completely different general layouts through skinning.
Develop a well-documented naming convention for the assets (images, HTML fragments, etc.) that comprise a skin.
Design a clean way to "discover" existing skins and add new ones. For example: Winamp uses a ZIP file format to store all the images for its skins. All the skin files reside in a well-known folder off the application folder.
Be aware of scaling issues. Not everyone uses the same screen resolution.
Are you going to allow third-party skin development? This will affect your design.
Architecturally, the Model-View-Controller pattern lends itself to skinning.
These are just a few things to be aware of. Your implementation will vary between web and fat client, and by your feature requirements. HTH.
The basic principle is that used by CSS in web pages.
Rather than ever specifying the formatting (colour / font / layout[to some extent]) of your content, you simply describe what kind of content it is.
To give a web example, in the content for a blog page you might mark different sections as being an:
Title
Blog Entry
Archive Pane
etc.
The Entry might be made of severl subsections such as "heading", "body" and "timestamp".
Then, elsewhere you have a stylesheet which specifies all the properties of each kind of element, size, alignment, colour, background, font etc. When rendering the page or srawing / initialising the componatns in your UI you always consult the current stylesheet to look up these properties.
Then, skinning, and indeed editing your design, becomes MUCH easier. You simple create a different stylesheet and tweak the values to your heat's content.
Edit:
One key point to remember is the distinction between a general style (like classes in CSS) and a specific style (like ID's in CSS). You want to be able to uniquely identify some items in your layout, such as the heading, as being a single identifiable item that you can apply a unique style to, whereas other items (such as an entry in a blog, or a field in a database view) will all want to have the same style.
It's different for each platform/technology.
For WPF, take a look at what Josh Smith calls structural skinning: http://www.codeproject.com/KB/WPF/podder2.aspx
This should be relatively easy, follow these steps:
Strip out all styling for your entire web application or website
Use css to change the way your app looks.
For more information visit css zen garden for ideas.
You shouldn't. Or at least you should ask yourself if it's really the right decision.
Skinning breaks the UI design guidelines. It "jars" the user because your skinned app operates and looks totally different from all the other apps their using. Things like command shortcut keys won't be consistent and they'll lose productivity. It will be less handicapped accessible because screen readers will have a harder time understanding it.
There are a ton of reasons NOT to skin. If you just want to make your application visually distinct, that's a poor reason in my opinion. You will make your app harder to use and less likely that people will ever go beyond the trial period.
Having said all that, there are some classes of apps where skinning is basically expected, such as media players and imersive full screen games. But if your app isn't in a class where skinning is largely mandated, I would seriously consider finding other ways to make your app better than your competition.
Depending on how deep you wish to dig, you can opt to use a 'formatting' framework (e.g. Java's PLAF, the web's CSS), or an entirely decoupled multiple tier architecture.
If you want to define a pluggable skin, you need to consider that from the very beginning. The presentation layer knows nothing about the business logic but it's API and vice versa.
It seems most of the people here refer to CSS, as if its the only skinning option.
Windows Media Player (and Winamp, AFAIR) use XML as well as images (if neccesary) to define a skin.
The XML references hooks, events, etc. and handles how things look and react. I'm not sure about how they handle the back end, but loading a given skin is really as simply as locating the appropriate XML file, loading the images then placing them where they need to go.
XML also gives you far more control over what you can do (i.e. create new components, change component sizes, etc.).
XML combined with CSS could give wonderful results for a skinning engine of a desktop or web application.