Please help test: Angular 1.3, improved transitions, cached views, etc

@brandyshea I’m seeing the update in this file: http://code.ionicframework.com/nightly/js/ionic.bundle.js Maybe it was a CDN caching issue. Which file are you referencing that doesn’t have the expire option?

I checked 818 earlier and it wasn’t there but now it is. I guess it was a caching issue. Everything is working, thank you. :slight_smile:

1 Like

@adam any news on the first pen’s problem?

Adam, I just updated to 831. I’m getting a general impression that click responsiveness on device has slowed down. It’s not severe, but just a little bit nagging. I reverted back to 804 and the response is instantaneous. Back to 831 and it is just slightly less so.

I don’t know if it’s worthy of an official bug report, but perhaps you can just check on device yourself.

Something also seems a bit odd with slidebox. Before, the transitions were nice and smooth and a little rubber-bandy if trying to swipe beyond the first or last slide. Now… not so much. It’s a harsh snap back into place. Again, this is possibly just a perception/preference issue, but the slidebox is a little less “fun”.

FYI : This is fixed in 831. Maybe earlier too but not sure

@Calendee I built my app about one hour ago, and the click to open modals are a bit slow compared to changing views. I didn’t make a codepen to reproduce it yet. Tested on Android.

Thanks for the feedback. I agree - opening a modal for the first time is definitely slower. After the first time, it is more responsive.

Agree. Loading of views is a bit slower since the 80x build on Android. Please fix

@felquis Thanks again for the great codepen and description. For the first scenario, everything is working as expected, but what’s happening is an async race when fired within afterEnter, and the “cached” elements may not have been updated yet. If you put a timeout of like 10ms it should work as you’d expect.

For tabs scenario that was a good find. I just committed a fix and the unselected tabs should be cleared out now (as of build 832). Thanks!

Thanks @adam :slight_smile:

So the previous cached view is not deleted?

@BAHbKA We had to use Intel’s Crosswalk to get close to iOS performance from scrolling. I thought it wouldn’t make much difference since we were already testing with a 4.4 device, but it made a huge difference.

Hey guys,

I’ve linked it here and I don’t know if it’s an nightly-specific problem, but it appears that $ionicTabsDelegate.select() doesn’t work, see plunker below :

View Caching and State Resolution… I am preparing data in via “resolve” in my state definitions. What I would like to do, is detect as part of my data preparation whether the data I am injecting into my view has changed and ensure that if it has, that my view is either purged from the cache or that I can access the newly resolved values in the “enter” event handler. By debugging, I see that my resolve functions are being called for each state transition, but since these resolved values are provided via injection in the controller’s constructor, I am assuming that I don’t have access to the these provided values in my handler for the “enter” event? Any thoughts?

PS. This forum is practically impossible to search

@WidawskiJ Thanks for the description and codepen! The fix for finding the correct tab instance is in as of build 833. Thanks!

Hi guys, did not know you were over here to discuss beta14 so I opened an issue on Github:

Sorry about that.

About the cache, It does not work well out of the box, indeed when I switch between views the content cached are not scrollable anymore and actions are not bound correctly (button are not clickable etc.). At the moment, to make my app work I had to deactivate it:

angular.module('mateProfiler').config(['$ionicConfigProvider', function($ionicConfigProvider) {
    $ionicConfigProvider.views.maxCache(0);
}]);

I noticed that only this solution completly disables the cache:
$ionicConfigProvider.views.maxCache(0);

Indeed, I try with:

 .state('tab.cars', {
                cache: false,
                url: '/cars/:carsId',
                //.....
  })

but it doesn’t really remove the cache.
Indeed, the controller is reloaded, but the DOM is still cached, leading to some flickering just before reloading data through Ajax calls.

Any idea why ? or is it a current bug ?

@Shprink Thanks for the codepen and description above, I’ll also look into that one. For this comment:

when I switch between views the content cached are not scrollable anymore and actions are not bound correctly (button are not clickable etc.)

Would you also be able to create a codepen replicating the issue? I haven’t come across that scenario yet, so I’d like to see how your app is structured to make it easier to narrow down the problem. Thanks

In 833, after arriving at a view, for a good .5 or .6 seconds after the transition is complete, taps are completely missed.

This happens until div class=“click-block click-block-hide” changes back to "div class=“click-block” which for some reason takes a while.

Thanks.

@Mik378 As of build 835, if the active view in a tab should not be cached, and the user selects another tab, then the deselected tab’s active view should now get removed the DOM element. Hopefully this fixes @Shprink’s issue too. Thanks!

1 Like