I am wondering what is the best practice according to organization of widgets in Flutter. Let's image I am writing some bigger widget like side bar in the application. This widget consists of several smaller widgets (like title, some greeting, user data, list of menu buttons, etc.) that I know won't be reused in other widgets. And now my question is - should all of them be kept in the same file (widgets or methods that build these widgets) as their context is the same or maybe should I separate them into large amount of small files in order to write tests for them more easily?
Having a separate file shouldn't bring any testing-related advantages, as far as I know. Flutter unit tests are usually written in a separate directory anyway. Using a separate file for a widget is useful for readability and for re-use (as you mention) rather than for testing.
I personally try to have one public widget per file, and to break down complex widgets into smaller private classes (not methods) that reside in the same file. If a widget can be reused or if it's complex enough to make a file not readable, I declare it as a public class in a separate file.
Also: the more your codebase grows, the more you might find it useful to use directories (rather than files) to group together widgets that are used in the same "context".
Related
I saw many articles and videos on how to do responsive design in flutter.
But they all have in common, that they show a standard web page with menu, pictures, text.
What I call "real" in the title, means a full interactive application, so with displaying tables of data, providing input fields and other input elements, showing charts, ... - so all the interaction of a "real" application, not just a web site.
Simple example: If I have a large data table on a desktop screen, it has to be different on a mobile screen to show data in a way, the user can read it and use it sensibly.
So, how do I make the app responsive for all screen sizes without having to implement something twice or have case distinctions all over the place?
Refractor codes into widgets. (very important to reduce boiler plates)
Create an idea on how the webpage will look like based on 12 grid system
In build method check for screen size and return layout based on the screen size.
Please note
The widgets should be responsive by itself based on the size available. For example a chart widget. It should build a chart within the space provided by its parent.
There may be instances where in desktop some elements are in a row and the same element will be in a column in mobile. So you can also write sections like banner section (define web and phone layout), about us section etc so its easier to manage
Use wrap widget to automatically bring widgets down based on screen size
Use BoxConstrains and max width to control a Containers max width
For tables you can use packages like responsive tables
There have been a lot of talk on MVP and how it seperate the presentation logic from the view's implementation. These designs are good but I still have a question unsolved regarding to widget.
To develop a widget, (or possibly many small widgets included in a typical website), specially those designed with UIBinder, I found it very difficult to test (or just simple display) a widget's view implementation. The obviously way is to add it manually to an entry point class and display the widget only, which works but seems very tedious if the widgets are getting more and more.
So the question is: what's the best way to just simply display a widget when it's being developed? and possibly to interact with it?
Since you need to display the Widget and interact with it in order to test it you need a functional testing tool.
One such tool is Selenium.
I'm really struggling with a choice between the GWT Tree widget, which has been a part of GWT for ages; or the new CellTree, which is introduced by GWT 2.1.
The tree I want to present to the user is not particularly large, but I am very concerned about responsiveness.
The data at the nodes of the tree will be editable. By clicking on a node, the user will put the node into edit mode. Editing the more simple nodes will require only a single TextBox or TextArea; but others will involve several widgets, over which I want styling control via CSS.
I'm attracted to the CellTree approach because it seems to offer great flexibility and speed; however, the sample code for CellTree editing deals with only very simple data types: string, date, integer, etc. I don't know if CellTree is appropriate when you've got more complex node-editing needs.
What do you think? Is CellTree the best approach? Does CellTree replace Tree in general? What heuristics can I apply in choosing between them?
I'm using a CellTable with several custom input Cells, including one comprised of many widgets. It works great!
It took me a couple of hours to understand how to implement a custom Cell that could do complex operations - since a single instance of the Cell will flit around the CellTree, pretending to be many instances, you need to understand how it's getting its data and when it is refreshed and rendered. I learned a lot from the source of the DatePickerCell.
I can't speak for CellTree, but the CellTable is very flexible, was easy to program, and saves me hundreds of Widget instances.
Using CellTree is problematic. Because it hasn't good access to view implementation stored in CellTree. It cause problem (ex. for me :D) in making custom handlers for opening nodes with children by clicking on whole parent cell. Of course you can make custom cells by AbstractCell, where you must write own renderer.
I think this widget must be enchanced and more objects must be more visible for users.
Customizing CSS is simple. All what you have to do is extende CellTree.resource and insert own css based on celltree.css class names.
I'm designing the user interface. It has some static content and a lot of widgets.
Which is better?
HTML with a widget containing the other widgets
HTML containing all widgets
I addressed this very question in a presentation to a local JUG meeting the other day.
Which is better depends on what problem(s) you are trying to solve. Usually that means what pain you are trying to avoid from previous projects.
If you find it to be painful to include the static content in your GWT Module code, then your second option looks more appropriate. If the different widgets need to interact with each other (e.g. updating one refreshes the others), then your first option will contain the less pain.
Do you like the declarative style of GUI generation? If so, then consider using UiBinder which is included in GWT 2.
i'm also working on project with a lot of widgets (maybe over 250) and i think, one widget, which contains all others is the better way.
How about a mix? If there are widgets that logically go together, group them into a containing widget. Then put a smaller collection of widgets into your big containing widget.
Is there a good way to create a form in VB6 that can easily be embedded inside other forms?
On a few occasions recently, I've wanted to design and code a Form object that I could plug into several other "parent" forms. My goal is to create a centralized piece of code for managing several UI components in a particular way, and then be able to use that (both the UI layout and the logic) in more than one place. I'm certainly willing to use code (rather than the Design View) to load the child form.
The best I've come up with so far is to pull all of the interesting logic for the child form into a Class Module, and have each parent form lay out the UI (in a Picture control, perhaps) and pass that Picture object into the class module. The class then knows how to operate on the picture, and it assumes that all its expected pieces have been laid out appropriately. This approach has several downsides, and I'd like something a bit more elegant.
Take a look at VB6 UserControls; I think they are exactly what you need. You can create a UserControl within your project, add controls and code to that control, and then insert it onto a form just like standard VB6 controls. I've used UserControls to share UI layouts on many occasions and it works great.