What would be more efficient in a kinda big application for a mobile application? Make a separate TabItem for each menu item or have one TabItem with an empty Rectangle that will become parent of the form of each Menu Item's Unit?
(I assume you mean reparenting the controls on a child form to appear within a container on your main form. If so you'll need to use (e.g.) a TLayout which will handle child controls better rather than a TRectange).
It depends what you mean by 'efficient'.
One big form will take longer at start up and consume more memory.
Creating content on demand will take longer at run time as each form is created and destroyed.
Related
So I have this GUI .ui file made with Qt, which is embedded inside a sidebar on some Qt app I'm working on. Problem : it gets shrinked to an unsuable size.
My ui form starts with a QWidget, which is the main and base area for adding more things. This is set to be a grid layout (I didn't insert a grid layout manually, I just set the base QWidget to have one using the dedicated button at the top).
And it contains one thing only : a tab widget with all my stuff inside on two tabs.
And that's it.
Of course I did play with the size policy of everything, it's all set to Expanding and all.
This form is embedded by code into a larger tab widget. There is a new tab for every new form, I have like 10 different forms like this one.
Some actually have a QMainWindow at their base, and are not shrunk to death. I don't understand the difference, but I when I set my base thing to be a QWindow, the form does not shrink.
I also have one form in another tab that has a QWidget at its base and is not shrunk to death.
Any other information I could provide to help you guys help me ?
Here's the issue, I build a special book reader/browser (For holy quran), my code behind loads the page and constructs how it should look. and then it should bind that look to a some kind of data-bindable custom control to view it properly. the problem is, the look differs from page to page, so I cannot bind to a certain control or wrap panel.
here's how it generally looks:
The decorative border top of the page is always there at any page, it indicates the part and chapter the viewer is in.
If you're starting a new chapter it have additional image under that decorative border or anywhere in the page (there can be multiple chapters in the same page) something like this
or this:
The normal text is not an issue, it's just a special font, however, I put each individual word in its own text block for reasons of user selection by word.
The issue here is, given the previous information, and knowing how random it is to place the decoration picture or the amount of words (text blocks) per page. how can I bind that to some kind of view to separate the view from the VM and Engine that builds the page.
my past solution was to actually build everything in the VM in a wrappanel built inside a scrollviewer having lots of textblocks and images according to the page. but that's naiive solution. I want to rebuild that in a more professional separated way. I also want to do this for Windows RT beside Windows phone so I need to reuse the code behind in a Portable class library.
I think all you need to do is slightly adjust your current design. So perhaps have a VM that represents the entire content, and that would have a Collection of say Pages or Sections. A second VM would represent the Page/Section, allowing you to create a property for the WrapPanel content (i.e. the words) and another property for the Header and or other things.
In the View you would have the scrollviewer and bind to the main VM collection. Then create another View or DataTemplate that represents the Page/Section.
You should be able to do this is a strict MVVM sense quite easily and it will be dynamic based on the content.
You could even cater for advanced scenarios where each section has a different template/view.
My understanding of GWT's Activities and Places is that for a given region on a screen you have an ActivityManager and an ActivityMapper. You can have multiple regions on the screen which means you can have multiple ActivityManagers and ActivityMappers (one per region). So, whenever there is a PlaceChange the ActivityManagers ask their respective ActivityMapper what activity it is supposed to be showing given the Place. This works great as long as your Places all have a common layout that they reuse in different ways to perform different activities. My question is how do we handle the case where different Places use radically different layouts? My first thought is to just have even more ActivityManagers and ActivityMappers, if the Place doesn't use a particular region then the ActivityMapper for that region will simply return null when we change to that Place. If there is a better way I would appreciate any wisdom.
I found it much easier to use a single ActivityMapper/ActivityManager pair for the entire app.
In a typical case you have a "menu" region and a "main" region. The menu region is very basic: a click on a menu item sends a user to a new place. It also highlights the newly selected item and resets the style of the previously selected item. All of this can be easily done in a simple widget that you can include in all views where this menu is required. Having separate ActivityMapper and ActivityManager for the menu region just complicates everything without providing any benefits.
I use the same approach for "top menu" region and "left menu/tree" region: a widget that tells the presenter which data to show in the "main" region.
I have over 50 different places in my app, and it really helps to have a simple architecture: each place corresponds to one view and one activity.
In most of the Activities and Places examples I've seen, people use a SimplePanel as the display for an ActivityManager.
I was wondering if there's a benefit to using a DeckPanel/DeckLayoutPanel instead of SimplePanel. It's fairly trivial to create a wrapper around a Deck panel that implements AcceptsOnWidget.
I haven't seen this topic discussed anywhere. Prior to MVP+Activities being commonly used in GWT, people generally used Tab panels (which internally uses deck type panels) and Deck panels to control switching between panels within a given view.
The difference between the two is SimplePanel.setWidget(..) will remove the previous child from the DOM and append the new widget whereas a deck type panel will use CSS to control visibility of the current panel (i.e. "display: none" to hide inactive panels).
If using a deck panel, it generally means you will have much more Elements in the DOM. I would imagine this uses more memory and makes the application "sluggish", even if those nodes are not visible ("display: none"). Is this true?
If this is true, why did Google use a deck panel style impl for TabPanel/TabLayoutPanel instead of internally using a SimplePanel?
Is one approach more favorable over the other?
Performance wise there is no difference. It all depends how you use it. In the DeckLayoutPanel all children are kept in memory. But if you would implement the same thing with a SimplePanel you need to keep a pointer to those same children yourself, so the memory footprint would be about the same. Unless with a SimplePanel you create and render a child each time it's shown and throw it away when hidden, which would possible be memory efficient (if the garbage collector does it's work), but it would be a hit on usability since rendering is expensive.
Second if you use a DeckLayoutPanel all it's children are created at once, while only one is shown. For performance this might not be optimal. So for this reason you could add a LazyPanel between the child and the DeckLayoutPanel, so it's only created when shown. But that might take some extra coding to make it work (because it's lazy you need to lazy initialze it which can cause some difficulties) However, still for the comparison between DeckLayoutPanel and SimplePanel it's only a matter of when you would create the children for the SimplePanel (all up front == same issue as with DeckLayoutPanel) and not something specific to the difference between DeckLayoutPanel and SimplePanel.
In general if you have a defined ordered set of children use a DeckLayoutPanel (like with a TabPanel) and if you have a undefined set SimplePanel is the better choice (like in MVP to show the current view).
DeckLayoutPanel internally holds collection of all your views (actually views that you've registered or displayed) in order to be able to determine sliding animation direction (depending if you go back or forward). Apart from this, I didn't notice that application become sluggish when switched from SimplePanel do DeckLayoutPanel. It's especially safe, when all your views are singletons. But please aware that in such case, when switching between the same view instance (for example main categories list -> subcategories list), DeckLayoutPanel may have some problems rendering sliding animation.
In my opinion there is no favorable solution - if you don't need "sliding" panels, I would not use DeckLayoutPanel (since all additional components increases complexity).
I use the MVP pattern in my project. According to it Place define view after a new Activity starts. In some cases when I have to save the content of some Text areas after change of Place. I think that it is not a good idea to put these text areas in Place, because they don't define business logic. To save them in View elements is not good either. How do I resolve this situation?
GUI elements (GWT widgets) belong in Views. Why do you think otherwise?
Then your View interface (or is it Display?) can have getTextData()/setTextData() methods to retrieve data in your TextBox.