Please help test: Angular 1.3, improved transitions, cached views (repost)

yes, you are right, thanks @claw

The new tabs CSS style or behavior on Android is a little strange here.

Suppose we have two tabs each with child views as follows:
Tab 1: rootview A -> detailview A
Tab 2: rootview B -> detailview B

With the nightly builds on android, initially rootview A/B will have tabs on top, while detailview A/B will have tabs hidden automatically.

However, if the app state changes from one tab to another tabs’s detailview using $state.go calls (e.g., rootview B -> detailview A), now detailview A become the history root of tab 1 with tabs visible, while rootview A will have tabs hidden.

This is kind of weird for my apps. Any suggestion how to avoid such problem? Or, is it a feature or a bug?

@claw There are many scenarios for the $ionicSlideBoxDelegate to find the correct slidebox instance. Would you be able to recreate you’re scenario where it’s not working? Thanks

@wedgybo Thanks for the codepen! I just made another update to harden the chance of the app crashing. Thanks again!

@donl This is how material design does their tabs. When you start at the root of the tabs, then go one level in, it covers up the tabs, and when you go back it reveals them again. The problem with their design is when you switch which is the root of the tabs, like in your case. I think what’s important is to only have one view that’s the root of each tab, instead of switching it around. This is pretty screwy to how material design works, and I could very well be wrong and would love some research/clarification on it. But if going from the tab root, to a detail A covers up the tab, and then later you go directly to detail A, how do you get back to the tabs? Or, if you go to detail A before going to the tab root, how would it go back to tabs?

Devices used for testing :

  • Nexus 5 - OS : Lolipop 5.0
  • iPhone 4S - OS : iOs 8.0

Just updated to the nightly build, and I have to say those transitions on android are looking mighty good. Switching between views is much much faster. The only thing that is still slow compare to iOs for (for me) is scrolling through a list with images (using js based scroll on android devices is still slow about 40FPS compare to iOs : 60 FPS).

Good job guys

http://plnkr.co/edit/ulFiD5hPLD5NX5JpyIrB?p=preview still broken (renders slider content invisible) after slider updates @ nightly-868

@JesperWe Could you elaborate? Everything seems to be working. How do I get it to be broken?

@claw, @adam I’m still seeing the problem with the delegate. @claw, are you generating your modal via a service? I think this might be the problem I’m seeing.

Here’s a codepen http://codepen.io/wedgybo/pen/WbrMgr

@wedgybo Could you describe the problem? What am I looking for? How do I replicate the problem?

Sorry I put the instructions in the info. I’ve just updated it again as I’d made an error.

Go to About Tab → Open Contact Modal → Next Slide

Open up the console and you should see an error

Delegate for handle ā€œslideboxtestā€ could not find a corresponding element with delegate-handle=ā€œslideboxtestā€! select() was not called!

Will be back soon if you need more info

@wedgybo Your codepen is missing a few things. In the HomeTabCtrl, it needs $ionicSlideBoxDelegate injected. Also, your ModalService isn’t passing in a scope, which is what the delegate service uses to find the active scope. http://codepen.io/adamdbradley/pen/RNrMXo

I know this sounds unlikely to you, but nightly 870 fixed my problems… 863 had them.
So thanks.

1 Like

@adam thanks for looking at it. I’m not sure if maybe you saw the unedited one. If so apologies for wasting your time. I’ve updated it again here. http://codepen.io/wedgybo/pen/WbrMgr

The difference between mine and yours is I’ve got the creation of the modal in a factory so that the same modal can be summoned from many controllers. It appears this causes an issue with the isActiveScope as one is never found.

Any chance of you taking another look? I set the scope of the modal like so. <ion-modal-view title="Contact" ng-controller="HomeTabCtrl">

Quick Edit: I’ve made a more complete example of pretty much what I’m trying to achieve and was working previously. Let me know if it’s crazy and there’s a better way of doing it or whatnot.

@adam yeah, you’re right about the material design guides and that’s also what i like the new style. the problem here is the root of the tab is changed internally when using $state.go() to jump between states, actually I want the root of tabs to be determined by the state url.

Jumping between views may seems strange, but in my opinion there are useful cases and could be more flexible for better user experiences. In the meantime I will try to find alternative solutions.

Any way to specify tab visibility for each view in the templates?

What would be the best way to preload/render views into the cache? I have a giant list of cards which can each be clicked, taking you to it’s details page. The first details page to load is choppy, but all subsequent loads are very smooth. Thanks in advance!

I have a left side menu , When I switch menu content ,

the left side start animate will wait right side animation complete.

It looks strange , This is my code issue or new version issue ? is there new menu start demo ?

@areschen Could you provide a codepen replicating the problem? I’m not sure how you’re app is setup to have caused this issue. Thanks

One issue I have noticed on Android is related to losing scroll position when bringing the keyboard up on a device. When the keyboard is brought up on a device every ionScroll in a cached view has its scrollTop set to 0. I can’t reproduce this issue on an iPhone.

This issue on Android occurs with and without the ionic keyboard plugin.

I thought it may be related to the keyboardBrowserFocusIn function that does this (see the comment) -

function keyboardBrowserFocusIn(e) {
  if( !e.target || e.target.readOnly || !ionic.tap.isTextInput(e.target) || ionic.tap.isDateInput(e.target) || !keyboardIsWithinScroll(e.target) ) return;

  document.addEventListener('keydown', keyboardOnKeyDown, false);
 
  // I thought these two lines below might be the cause but apparently not
  document.body.scrollTop = 0;
  document.body.querySelector('.scroll-content').scrollTop = 0;

  keyboardActiveElement = e.target;

  keyboardSetShow(e);
}

Any ideas on what is causing this on Android? I haven’t had time to test using Ionic beta 13 but I’m thinking it is something to do with cached views in the latest Ionic.

Thanks!

Hi, I’ve been testing the latest nightlies and came across 2 slide box bugs (unrelated to the getbyhandle issue)

  1. Nested slide boxes no longer work. They used to in beta 13 - wondering if you can add that support back (wasn’t able to manage it myself).
  2. The slider pager doesn’t work fully either. if you try to swipe right (go left) on the left-most slide, the pager loses track of the active one until a valid slide is made in the right direction.