[Interest] Stack view and lazy loading of big Qml files

[VStevenP]

If you implement app pages in a ListView like I suggested, you really can't disable the animations between pages, and the regular swipe transition is all that is available.  Yes, this is limiting.
You don't need to disable interaction with the List itself.  If each delegate instance is an app page, the QML components on each page will receive the mouse events they are supposed to, due to the natural handling of nested components in QML.  This is one of the beauties of the QML language - the ability to nest components and have the components that are laid inside a container not have their mouse events stolen by the container.
Steve PavaoKorg R&D
      From: Nuno Santos <nunosantos at imaginando.pt>
 To: VStevenP <vstevenpavao at yahoo.com> 
Cc: "interest at qt-project.org" <interest at qt-project.org> 
 Sent: Wednesday, January 7, 2015 5:53 AM
 Subject: Re: [Interest] Stack view and lazy loading of big Qml files
   
Hey Steve,
That seems a nice suggestion.
Questions: 
- How do you disable or change the animations between index change?- How do you disable interaction with the list itself, because I would need to interact with the content of the page.
I will give it a try in the meanwhile.
Thanks!
Regards,
Nuno 



On 05 Jan 2015, at 23:06, VStevenP <vstevenpavao at yahoo.com> wrote:
Hi Nuno,
You might wish to consider using a ListView whose delegate is a Component which contains a Loader.
That way, app pages are just delegate instances created and managed by the ListView.  You can use the cacheBuffer property of the ListView to manage how many delegates (pages) are instantiated a.k.a. loaded.
My group is using this technique to handle loading and unloading of related application pages.  It's easy to flick between the related pages this way, helping to ensure that nearby pages are loaded and cached, and therefore quickly available to the user, while other pages which are not neighboring pages can be loaded later as needed by the ListView.
I don't think you'll want to load all your application pages at the start.  Here's why:  The QML engine can sometimes keep up to 4 copies of your pages.  This was explained at QtDevDays, but I can't recall the exact details.  Any way, if your app pages use decent size graphics, the amount of actual RAM used by a page can be up to 4X that at certain times.  Therefore, it makes sense to have an evolved page loading strategy, so you don't use excessive RAM in tablet and embedded environments, where RAM resource may be more scarce.
Steve PavaoKorg R&D
      From: "interest-request at qt-project.org" <interest-request at qt-project.org>
 To: interest at qt-project.org 
 Sent: Tuesday, December 30, 2014 6:00 AM
 Subject: Interest Digest, Vol 39, Issue 60


   
------------------------------

Message: 2
Date: Tue, 30 Dec 2014 09:10:12 +0000
From: Nuno Santos <nunosantos at imaginando.pt>
Subject: [Interest] Stack view and lazy loading of big Qml files
To: Interests Qt <interest at qt-project.org>
Message-ID: <756C12DE-64F5-4E60-9322-80882481FFEC at imaginando.pt>
Content-Type: text/plain; charset=utf-8

Hi,

I have a stack view which will be used to load the main content of application views.

Currently, when I select a new view, I pass the url of the correspondent Qml file. I use the replace method because in fact i?m only interested in the transition animation.

The problem is that in arm devices like android and ipad, the transition is not immediate due to the fact that the Qml being loaded are quite heavy.

The app users won?t understand that so I wanted to load all the views without showing them and instead of passing the url I would pass the id of the component. 

My questions are: 

What is the best way of doing that?
Where should I keep the elements without having them rendered on the screen?
Is there any other way of making this?

Thanks in advance,

Regards,

Nuno Santos

------------------------------

   



  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150110/e379ca92/attachment.html>