Solved Using StackView. What is better way?
-
Hello all!
I am trying to get info about better way of using StackView. I've been using it in different ways:- Creating components globally and is only calling them into StackView by ID:
ApplicationWindow { StackView {id: oStackView} Component {id: id1; CustomComponent1 {}} Component {id: id2; CustomComponent2 {}} Component {id: id3; CustomComponent3 {}} Component.onCompleted: { oStackView.push(id2); } }
- Creating component at time of pushing it into StackView:
var oComponent1 = Qt.createComponent("qrc:/Component1.qml"); oStackView.push(oComponent1);
The questions is:
- What is better way to use StackView because of both this variants of usage has advantages and disadvantages?
- What should I do if there are a lot of pages in navigation - clear all after every action or keep them in memory?
-
You can also push an url to a
StackView
:oStackView.push("qrc:/Component1.qml");
-
@bogong Hi,
Result will be the same in both cases, the doc about Item Ownership says:
only items that StackView creates from Components or URLs are destroyed by the StackView.
Note that items are destroyed only when
StackView.pop()
or ```StackView.replace()" is called. So you need to call them according to your UI navigation hierarchy.Also there is a third option which does not require to create a component :
oStackView.push("qrc:/Component1.qml")
-
-
@bogong Yes, that's exactly what we answered...
What is better way to use StackView because of both this variant of usage has advantage and disadvantage?
There is no difference, maybe an extra memory use when creating the component dynamically. But as @GrecKo suggested , it's simpler to use
oStackView.push("qrc:/Component1.qml")
What should I do if there are a lot of pages in navigation - clear all after every action or keep them in memory?
Nothing, StackView will manage memory according to calls of push(), pop() and replace()
But that's javascript so you don't have to worry about memory.
-
@Gojir4 said in Using StackView. What is better way?:
Nothing, StackView will manage memory according to calls of push(), pop() and replace()
Nothing, StackView will manage memory according to calls of push(), pop() and replace() - it will not just follow debugger and at least simple example https://forum.qt.io/topic/107493/how-to-get-list-of-all-items-in-qml-stackview-that-pushed-into-stack/3 If you not poping it out it will be holding in StackView and taking more memory. If the component content is heavy the memory usage might be big enough, especially if there are kind of actions around the timer. If you not making checking of existence of object in StackView it will duplicating ... And other, other, other ...
And again have you read questions? Do you really understand what I am asking about?
-
•What is better way to use StackView because of both this variant of usage has advantage and disadvantage?
•What should I do if there are a lot of pages in navigation - clear all after every action or keep them in memory?As you say, there is a trade off between memory consumption vs speed/ease of programming. So maybe not a "definitive answer", it depends on your usage.
I use
QStackView
, but from widget Qt, not QML. I presume principle is the same. FWIW, I create the pages dynamically (like your second approach) the first time they are accessed. I found with a lot of pages/widgets, initialization at program start-up time was taking some time, especially annoying when you are developing/debugging all day and most times you do not go into every page. Then for me I kept them in stackview once created first time, though you could dispose them and reset if short of memory. -
Independtly of optimizations, I prefered the first one. More clear code, and it's better when handling signals and slots. But, hey, it is my opinion.
-
Published example that is illustrated everything that I've wrote about. You might download and test it by your own and look on how the push carrying about memory ... For both variants. The preferred - the first and using replace if you have no chain of views or manually popping it out, if you don't want to care about manual objects destroying. If you fill so experienced to care about created objects manually - use second. Uncomment variants that you want. Both are there.
Issue closed.