What is the best practice way to manage multi panel (i mean page) application for GWT (in terms of performance, memory usage etc.)
Should i create all widgets and change their visibility or create and remove widget on request.
You might be interested in Large scale Application Development and MVP in terms of best practices to manage a multipage application.
Speaking of re-using Widgets (since they are costly to build) a factory approach to produce them on the fly and keep the instances of costly ones for re-use has worked well for me so far. One thing to keep in mind is to clear the states(values of textboxes etc.) before re-using them. Unless my page is a multi-panel page with hundreds of widgets, I prefer creating them on the fly, instead of re-using, since it has no noticable impact on user performance. I beleive memory should not be an issue unless your app consists of thousands of pages and you keep a reference of each and every single one of them.
Last but not least benefit of using a ClientFactory is you can switch your factory implementation with another-one (ClientFactoryMobile..) with deffered binding depending on the platform your app is being loaded thus making switching user interfaces a breeze.
Related
I'm slightly new to Flutter and just want to ask some questions/clarifications regarding the development using it. I am currently building a flutter app and wanted to change the layout based on different devices and orientations. I created 2 different dart files containing different app layouts of my Login page (LoginMobile.dart and LoginTablet.dart respectively). I created also a separate dart file (LoginComponents.dart) to store "all" the object UI/components of my login form (txtEmail, txtPassword, btnLogin, etc.). I heard doing like Widget txtEmail() {return TextformField(...);} is not advisable as it can affect the app performance, so I tried making them as classes. Am I doing it right? Is it okay to store multiple stateful widgets in one dart file(?) since the txtPassword have a setState() for show/reveal password and the btnLogin for the authentication process. Is there any negative effects that I may face in the long run if I continue doing it this way? Any tips and advise were highly appreciated. Thanks!
Storing your widgets in a single file is okay but would cause confusion when making a large app. when the amount of widgets is getting increased in that file it would be harder to do a small change because its harder to find the widget.
i would recommend using multiple files, so you can find them and organize them easily.
Yes, you can. But point comes to maintainability. I prefer to keep one public widget which having the same name as the filename and remaining private widgets.
So now ques is How many widgets in a single file?
Its actually depend there is no such rule to restrict the limit of file. Different authors having different preference. I prefer try to keep 5-6 classes(widgets) and
each one having 5-6 functions.
Try to make a file single responsible i.e(5-6 classes together responsible for single functionality). Don't make god class which having unrelated concerns together later it will pains(haha)
If it's a common widget keep them separate to respect DRY principle(Don't repeat yourself)
If the widget is further divided into 3-4 widgets or it children widget change depend upon rest response keep seprate for good practise
Bonus Tip: try using code folding shortcuts to push a little more
I was new to the flutter so I build a full application without using state management, all my screens in the application built with the stateful widget
what is the danger of that if many users used it?
You risk not being able to scale your code well. From passing data down the widget tree to passing data to screens etc., this will require a lot of lines which will lead to un-maintainable code. For small projects though, you don't really have to use state management libraries such as BLOC and Scoped Model.
As the project scale, I believe you will have performance issues due to using setState() and without inherited widget your UI will re-render again every small change or action in your screen.
Also, Your code will get complicated as project scale because you are not separating your logic in a separate file (using bloc, provider or whatever), It will be a mess as UI and business changes.
Most users won't know the internal architecture of your app unless they are good programmers themselves. But the goal of building applications is to attract users, and expand customer base. And this will require you or your company to add additional features in the future to accommodate their needs, and when you try to make even a subtle change to the source code, it will take more time and you will be prone to add new bugs to your application as your models and views are all mixed together.
Another reason is that you can't (as far as I know) test an app which doesn't have any type of state management.
On a Google IO Talk it was mentioned that widgets make your apps run slow and you should avoid them at all cost. But I would like to use the gwt-bootstrap widget library. This would pollute my ui.xml with a lot of widgets.
The reason I use this library and not the standard gwt bootstrap.js file, is because I don't want to include the library nor do I want to use the customize option of bootstrap. The reason would be the large initial download and the annoyance of having to be aware of possible missing features when added code to the UI.
So my questions are:
- Do the widgets slow down the app significantly?
- What number of widgets should be fine?
In the google IO talk they had a max of around 10, I don't remember well.
Do the widgets slow down the app significantly?
It depends. It depends whether you make a mobile app, whether you care about old browsers (IE8, I'm looking at you), etc.
What number of widgets should be fine?
Widgets within a composite widget? widgets displayed at the same time on the screen? Widgets within the whole app?
We use tens of widgets and I don't think they slow us down (server side and moving data across the wire are what take most of the time, not the client side). But our lowest-level widgets, among the ones that we reuse the most, and sometimes a bit complex, aren't (all) composites, and use event delegation.
My rule of thumb is: if an Element is enough (such as a SpanElement to display some data, or an InputElement for a textbox where you don't care about events), then use it. If you need events, then use a widget. The exception to the rule is if you're building a reusable complex widget and using event delegation wouldn't add too much complexity to it compare to composing widgets.
Remember: premature optimization is the root of all evil, and the 3 rules of performance are measure, measure, measure.
BTW, your reasons for using gwt-bootstrap rather than bootstrap.js are misinformed: gwt-boostrap loads bootstrap.js like you could do it yourself, and thus won't save you from that large initial download.
I have read that gwt-ext is slow and it seems too bulky. How does this compare with Ext-GWT? Are there any other libraries out that can easily handle dragging, resizing, minimizing?
In my opinion there are no real worthy GWT widget libraries that I want to even consider. If there is a widget missing you can always try to get one included in the incubator, this way it will maybe end up in the GWT distribution one day.
The bigger, impressive looking ones tend to be a wrapper for an existing JS widget library. Which means that you have to pass on many of the benefits of GWT.
Others like Rocket GWT are a complete rewrite of existing widgets which ties you to another abstraction. That means that if you need extra widgets outside of the Rocket ones you will need to use widgets that follow different design principles.
I tend to stick to the default ones and I use the incubator widgets but I always try to keep those dependencies to a minimum since these are still changing dramatically (changing classnames, packagenames, complete design changes, ...). You do not want to keep on modifying existing code.
In most cases I just create my own widgets that does what I need and nothing more. That takes a lot less time to create than if I have to implement a complete API that would cater a lot more usecases.
Have you looked at http://www.smartclient.com/smartgwt/showcase/
The controls are licensed as LGPL, but advanced server site libs are only included in the professional edition.
we're having some success with Mosaic from the GWT incubator. You'll wish for better documentation, but once you get past that you'll find useful widgets (split panels, etc.) that you can mix with gwt's basic widgets.
I am considering making use of GWT as the front-end to an existing web application.
I can't justify a complete rewrite to 100% GWT in one go. It is likely that I would migrate parts of the system to GWT gradually. However for consistency I would like to make use of the GWT TabPanel, MenuBar, etc as global interface elements from day one.
As an experiment to see how 'legacy' parts of the system could be incorporated, I have done the following.
The application's main page template now loads a small 'wrapper' GWT module on every page. This GWT module looks for a selection of DIVs in the dynamically generated host page. If the DIV is found, a suitable widget is slotted into place, i.e. menuBar, tabPanel.
A lot of the configuration for the included widgets can also be slotted into the host page as JSON structures. For instance, I have implemented an adapter that dynamically sets up a TabPanel in this way. I've also added some very simple widgets that load remote HTML, etc.
As a prototype, this all appears to work perfectly and loads quickly.
However, it seems that GWT apps are really designed to be run from a single host page, not hundreds of dynamically generated ones.
Can anyone highlight any issues that the above approach may run into, particularly as the GWT module increases in size? I would aim to keep the legacy wrapper module intentionally lean. Other functionality would be implemented in separate modules.
How have other people integrated GWT into their front end in a gradual fashion?
One of the ways GWT was designed to be used is exactly as you've used it. We have done that in many of our apps - where there is one GWT module with multiple 'parts' that are loaded based on whether a given id exists on a page or not. So I don't see that you'll have any issues at all going this way. We often use this approach even for new web applications, where we just want a few 'widgets' on the page, rather than coding the whole application in GWT.
It won't make a huge difference, but one thing I would suggest is not putting the GWT javascript code into your main template, but rather only put it on the pages that need it. It's true that if you're not running HTTPs it is cached basically forever, but it seems wrong to get people to load in the module if it's not actually needed on that page. This of course depends on how people use your site, if they are likely to download it anyway then it won't make any difference.
You're doing it right. Avoid avoid avoid the temptation to try to 'minimize' the GWT footprint by breaking it up into multiple separate apps.
The key to GWT performance is to have as few downloads as possible and to make sure they're cached. Loading a 250k bundle once is much better than two 200k bundles and because compression get's better with larger files you really start to reap benefits as things grow.
y-slow & firebug can be really helpful when it comes to convincing yourself of this.
One performance trick you might check out is available in the sample chapter here: http://www.infoq.com/articles/progwt
It shows a mini-architecture around loading GWT widgets into any number of slots and pre-populating data in JavaScript variables. This allows your GWT widgets to load and not require a second HTTP GET to get the data they use. In practice I found that this was a nice performance boost.