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 
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.
- First View of that state --> content is hidden until ionivView.enter is called
- leaving the view --> on ionicView.beforeLeave i set a flag hide the content again
- 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 
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.