There is a lag between screen transitions on Cordova Android

[michaelwhelehan]

Hi there

Please see this screencast to better illustrate my point https://youtu.be/0GkDwy_Ood0

Regards Michael

[gadicc]

Thanks, Michael. That looks really bad. Can you try with v0.1.33-pre.2 and look for anything useful in the console? See the new section about Performance in the FAQ on the website, at the bottom of the page. I suspect some reactive computations (that are slower on mobile) are holding up the animation.

[michaelwhelehan]

Will check it out

[ganySA]

I have had a similar problem on my iphone, in fact one challenge i have with meteor in general and building for mobile is that blaze rendering takes a bit of time specially on the bigger layouts - big lists of items.... what makes this more of a nuisance is that re-rendering when using iron router moving from one route then back to the list

The only way i have managed to get around this (and i am still playing around with it) is actually to load many layouts and trick blaze into a singleton type way of operation (just keep them loaded permanently) and use something like the following on routes. var myview = FView.byId('myview'); var content = myview.view.getContent(); content.hidden = false;

It keeps the bigger views "alive" permanently in the background but hidden and then you dont ever use blaze to totally re-render a view.

I dont know if anyone else has a better approach - i am pretty new to famo.

[gam-ragnar]

@ganySA did you try using https://atmospherejs.com/meteorhacks/subs-manager ?

[ganySA]

@timfam

I dont think that is where i have the problem because all my routes have the same subscriptions... I believe the way iron router works is that if you have the same subscriptions between routes it keeps them alive - i could be wrong... and in my case i am not changing subscriptions between routes.

It appears to me that when i go back to the a long listing - blaze is struggling to re-render the 50-100 odd items in the list - horrible that there isnt a singleton option for blaze and that in an "if" type condition or {{>yield}} it destroys the html elements and re-creates them :(

[ganySA]

--> sorry to add - you dont feel this at all in a non mobile app, but when you go mobile it just looks painfully slow and isnt fluid at all.

I think for mobile apps i would much rather load all my templates up front and then "reset" them and bring them to the foreground when i need them - specially if i use something like Ground.db subscriptions (offline cached data for meteor)

Just trying to work out how to animate a surface into view from the hidden state where i have the big lists!

[gam-ragnar]

from subs-manager

Subscriptions Manager caches your subscriptions and runs all the subscriptions that have been cached when a route is changed. This means that when switching between routes, the user will no longer have to wait. Also, Meteor won't need to re-send data that's already in the client.

And I think using ground.db helps. However loading every thing at onset means very slow loading app. Better to figure a way to hold rendered routes in cache

[ganySA]

@timfam

Have a look at this http://stackoverflow.com/questions/21101782/meteor-and-iron-router-subscription-lifetimes

Same subscription between routes = no reloading by default for iron router.

[Wenape]

When changing routes there's lots of thing that can slow the process down. A good option, specially for mobile is to have most of your data preloaded (subs-manager, grounddb).

Also, try rendering just the basic stuff first to get a smooth route change animation. When the route changes just render the basic structure of the new route (headers, backgrounds, text placeholders).

When the animation is finished and the basic stuff is rendered, then you 'fadeIn' the heavy content such as a ScrollView with many items.

There's even more to be done, when rendering the 'heavy stuff', try just rendering the stuff that can be seen within the viewport plus maybe a couple of more items. When the user scrolls down/right you then render more items.

[gadicc]

Yeah, I don't think the issue is subscriptions, more rendering. You're right, the reactivity can take up a lot of time.

1. Since the 0.1.33-pre.1 release, we can divide up Meteor's flush cycle if all the invalidated computations would take more than a single animation frame to run.

2. However, if a single computation blocks for more than a frame, there's nothing we can do about that. Currently, up to the app developer to mitigate this, but, am trying to figure out the best patterns and maybe a way to automatically do this for everything (it's a big project though).

Besides for #2, yes, avoiding to rerender the same templates can help a lot! That means with iron-router, keep the same template but use reactivity to e.g. control the RenderController for what to show. The other really good option to use another router that doesn't couple routes with UI, like meteorhack's flow-router, but I don't have any examples with that yet.

[gadicc]

hey wow i feel like everyone is in this thread, it's awesome :) thanks everyone for getting involved, it's great seeing how the community has developed that people are all helping each other :)

[michaelwhelehan]

Thanks a lot for all the feedback guys, will do some hacking over the weekend to see what I can come up with!

[ganySA]

Hi all

@gadicc i agree the more feedback and comments the better!

Probably not the best topic for this thread but i think the best thing for the community would be to build a skeleton app. There are some basics - especially for mobile that really would drive behaviour e.g

1. a simple skeleton app that shows how nesting surfaces work (surface controllers, surface views, surfaces etc)
2. a mobile version with tabs (probably the most common) - i still havent managed to get this right - well probably not the right way at least.

Its been a journey for me learning famo... i must admit i havent gotten round to how eventing works properly i always seem to be writing wrapper templates around surfaces and then templates within them to get events to work the way i want :/ when i get some time i will post an example of this.

I really think famo will do well - especially for mobile! great article: http://www.ibm.com/developerworks/library/wa-famous/

Cheers all.

[gadicc]

@ganySA - there's a WIP, https://github.com/gadicc/fview-demo/. i just don't have time to work on it atm. pull requests welcome :> but yes i agree.