Ionic View transition flickering

There are problem with view transition in latest version, leaving view takes half display and overlap enter view, here bug localization
View animations in 1.0.0-beta.13, all is ok animation smooth


View animations in 1.0.1 flickering http://plnkr.co/edit/1LYhSNLo5fxzMg1uzVGY?p=preview, many stage and leaving views created in dom on transition with style translate3d(33%, 0, 0) and not removed (http://joxi.ru/gV2VRBdiBdDv2v.jpg)
On my ipad mini, 1.0.0-beta.13 working much faster than 1.0.1

1 Like

+1 ! My nav bar flickers a lot with last version, but if I get the beta 14 instead, itā€™s way better !

Anything new about this issue ? There are a lot of things that have been improved since beta 14 that I donā€™t want to lose !

BUMP. @svsool you didnā€™t find anything to fix this ?

This nav bar flicker, is that happening when switching between tabs (ā€œion-tabsā€), and on an Android device?

If so then I may have a solution:

/*
    CSS styles to eliminate the annoying flickering header when changing tabs in an Ionic app on Android:
    http://forum.ionicframework.com/t/flickering-when-navigating-via-tabs-on-android/27281/2
*/
.platform-android .header-item.title {
    transition-duration: 0ms;
}
.platform-android .header-item.buttons {
    transition-duration: 0ms;
}

Thanks to:

5 Likes

@leob Thanks for trying to help :slight_smile:

I donā€™t have that issue when switching tabs but when loading a new page, simply the processing time of calculating the controller code and display the pageā€¦ I worked a lot on the performances of my pages and itā€™s a little better, but still very poor UX speaking.

Are you testing in a browser with ā€œionic serveā€ or on a device, and if so what kind of device? Is it a very old Android device? Then Crosswalk might help?

The CSS fix I sent you helped me out on an issue I had with ion-tabs. Without the CSS fix, changing between tabs would be accompanied by a clearly visible ā€œflickerā€ of the title/header bar which was extremely annoying and looked very, very unprofessional. It was totally unacceptable IMO, so the CSS fix made my day.

Now with other page clicks or transitions I donā€™t have a problem. Iā€™m quite satisfied with the performance of Ionic for my app and the device on which Iā€™m testing (Samsung Galaxy S3 Neo, June 2014) isnā€™t old but also isnā€™t really new. It runs Android 4.4.2 which certainly isnā€™t new.

(I tried Crosswalk on the device but didnā€™t see any advantages so Iā€™m not using it for now)

What device are you testing on? And what kind of stuff are you doing in your controllers, is it heavy calculations or what, or are your views complex?

@leob I tested on my Nexus 5, which is a pretty great device to work with, I think. Of course I do test also in the browser with ionic serve -l. The flicker is here in both, but much more visible on the real device.

When I take a look at my controllers and such, I donā€™t find them that complicated. I use a lot of factories though, with a lot of functions in each, but I donā€™t think it has anything to do with that problem - even more when you know that beta 14 is improving that transition issue a lot !

Iā€™m not using xwalk right now but I did once, didnā€™t notice any improvement, so I simply took it out. I donā€™t think it would help a 5.1 device anyway.

the main problem of flickering:

If you load async data or the scoe/view data changes a lot the device needs to render the transition and the changing data as well --> that is hard work.

if you enter a new view (forward-View) you can set a loading-variable --> hide all the changing content parts until the view is finally entered

$scope.entered = false;
$scope.$on("$ionicView.enter", function () { $scope.entered = true; });

I increased a lot of transition performance with that.

That looks very interesting ! If I understand well, you then use ng-if=ā€œenteredā€ in the view for every changing contentā€™s nodes ? Or are you suggesting to add the code for loading in the function triggered by $ionicView.enter ?

First one and a ng-show should work as well, it depends what content is shown during transition and how many data is changing in that time.

An example:

I had a complex app with a very large and nested list.

  1. First View of that state --> content is hidden until ionivView.enter is called
  2. leaving the view --> on ionicView.beforeLeave i set a flag hide the content again
  3. show cached view --> content is hidden until ionivView.enter is called

The hiding part if you leave the state is not needed for most of the state, because the caching works well on normal sized content.

Annnnd with the flag you can show a loading-spinner until the transition has finished :wink:

1 Like

I will test this in the coming days, and report how it went. Thanks a lot !

Still not clear about the exact issue, here but this is what I do:

In my controller I use ā€œ$scope.$on(ā€™$ionicView.beforeEnterā€™ā€¦ā€ and there I load my data by calling a service (itā€™s coming from a Firebase database ultimately). While the data is loading I display an $ionicLoading (hourglass/overlay), this displays on top of my view which is already visible.

(the field are initially ā€˜emptyā€™, which looks just fine while hidden under the overlay - no need to hide anything)

Most of the time I also cache the loaded data inside the factory, so that the next time I enter the view/controller itā€™s super fast (almost instantaneous). Even then Iā€™d display the hourglass but itā€™s so fast that you donā€™t see it.

One essential part of the technique: while loading the data, I donā€™t load individual data elements into ā€œ$scopeā€ because that would (might) trigger a digest every time. Instead, I use the ā€œcontroller as vmā€ technique and then after loading the data Iā€™m putting it into the ā€œvmā€ variable in one assignment, like this:

vm.article = angular.extend({}, service.loadArticle($stateParams.articleId));

When doing it this way I have a great and smooth UX (with a fairly limited amount of data I must say).
No ā€œlagā€, flicker or bad performance whatsoever.

Previously I used ā€œroute resolvesā€ as recommended by the (some) experts, but I refrain from that approach now. It resulted in a ā€œblankā€ screen prior to the data being loaded, which looked unprofessional.

It made the view transitions seem laggy and the UX much less smooth than when Iā€™m putting the service call/data load in the controller (see John Papaā€™s ā€œactivateā€ controller pattern).

Oh and if you have a big list then make sure to use ā€˜collection-repeatā€™ rather than the standard ng-repeat.

Very interesting food for my thoughts, thanks again. I also use Firebase as my backend, and will try your approach as well. I may have a heavier database than you, though.

I also discarded the ā€œresolveā€ solution, completely unresponsive.

And collection-repeat made me dream at the beginning, but I must say, itā€™s so hard to use when your blocks are not static (like a lot of my data will be - itā€™s free text entered by users). I prefer sticking to ng-repeat with infinite-scroll for now. Native scroll activation in Android made that a completely viable solution as long as you donā€™t have thousands of lines, I think, anyway.

Okay that is very interesting and potentially relevant information for me!

Right now I donā€™t have a big database but iā€™m planning to add realtime messaging to my app and will use Firebase for that. So the messages will get updated in realtime through Firebase and Iā€™d display them in a list.

(either collection-repeat, or Iā€™ll follow your suggestion; are you already aware of the ā€œtrack byā€ optimization?)

By the way, I added some info to my previous answer regarding the ā€œcontroller as vmā€ pattern that I use. I refrain from putting every item individually into $scope. Instead, I transition to the view, put a spinner/backdrop on top, load and assemble the complete object, and then I put that into the ā€œvmā€ variable in one go.

Interesting that for you the ā€˜route resolveā€™ thing also didnā€™t work out. Itā€™s recommended in many blog posts by the ā€˜expertsā€™ but for me it also didnā€™t work well, so as always you need to judge these things for yourself.

By the way, seeing that youā€™re also using Firebase: I have some intermittent connectivity issues with Firebase when testing on an Android device: Firebase timeouts, slow responses

Did you experience issues like this? How are your experiences with Firebase in general?

I have to say that apart from these (rare) issues Iā€™m quite happy with Firebase in general. These intermittent connectivity issues are a bit scary though, Iā€™m not sure how concerned I should be.

Hey, Iā€™m currently focused on Firebaseā€™s security rules for my app, so I will get back to that topic whenever Iā€™m finished with that. Will give feedback on each and every advice you guys gave here, of course !

Iā€™m aware of ā€œtrack byā€, yes, thanks. Itā€™s absolutely necessary for performances.

I need to say I didnā€™t have any connectivity issues with FB during my tests on my Nexus 5, and if it was a wide issue there would be more fuss online about it, so I guess you shouldnā€™t be too worried about it. I hope, at least ! As far as Iā€™m concerned, Firebase with AngularFire and its $extend capabilities are simply perfect for me. There are some services that are lacking, like push notifications handle linked to interactions with the database, or ā€œtriggersā€ that set actions to do whenever the database is updated, but overall itā€™s an amazing service.

Yes I also like Firebase a lot. Iā€™ve also dabbled a bit with Parse.com but Firebaseā€™s APIs and documentation look much more clean, simple and well thought out. The data model and the query model are simple and well conceived.

Parse is more of a ā€œeverything including the kitchen sinkā€ thing but their docs and APIs looked much less well thought out (apparently itā€™s based on the philosophy of the Backbone framework, which doesnā€™t make much sense to an Angular developer).

And no realtime capabilities of course.

Yes, Firebase lacks some things (e.g. push notifications) but I think thatā€™s a deliberate choice, and a good choice IMO, why would they add push notifications when everybody and their brother is already offering that.

Iā€™m not too concerned about my (rare) connectivity issues. Seems to be an artifact of the test/debug process on this particular Android device and if it would really keep popping up then I could add some workarounds (build some timeout and retry logic into my services).

Yeah and Iā€™m also planning on using the $extend capabilities of Firebase/AngularFire, it looks very powerful. Right now Iā€™m only using the basic features of Firebase and itā€™s already looking good.

By the way, youā€™re talking about the lack of ā€œtriggersā€ in Firebase (I suppose as a way to trigger some piece of server side processing). Well i saw that they thought about that, they call it Firebase Queue:

I suppose this is just what you meant?

Nope, I was speaking about classical triggers, as in mysql or othersā€¦ When something occurs, like an addition to the database, automatically do ā€œthisā€ (like populating another location of the database, for exemple). Since FB is denormalized DB, it would be very usefull - and I had confirmation from a FB dev that this is on their roadmap !

Haha I was a bit confused, this Firebase Queue thing is interesting but totally unrelated to ā€˜triggersā€™.

But, since Firebase is a realtime database, isnā€™t the ā€œtriggerā€ concept already built in, effectively?

I mean, you can connect a client (which can be a node.js server app, or whatever) to a Firebase ref, and then you can register an event listener which gets called when your data changes. In your node.js event listener you then simply perform the Firebase database updates that you want.

So, changes are pushed to you, instead of having to peek/pull all the time to check for changes. Thatā€™s the beauty of Firebase, and that amounts to having a ā€œtriggerā€ or not?

Sure, this would achieve the same effect, but I think Firebase should really be capable of doing almost everything (and more and more things as the time goes) without the need of a private server. Of course, thatā€™s my own opinionā€¦

Yes, I see what you mean. One thing which Parse.com does have and Firebase doesnā€™t is the ability to upload your own pieces of code which can be executed ā€œin the cloudā€ (hosted by Parse.com).

Parse.com calls this ā€œcloud codeā€ and itā€™s simply a piece of Javascript living on their servers (you donā€™t need to host it yourself) which you can trigger from your client or which can be triggered automatically.

Firebase doesnā€™t have that right now so any ā€˜intelligentā€™ processing needs to live in your client or on a server that you host yourself.