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

ionic-v1
1

We’ve added some major upgrades in this last beta with an improved navigation and transition system, and Angular v1.3.

There are several breaking changes in this release, but we believe they’re necessary for Ionic to be a 1.0 worthy framework. In most cases, it should significantly improve performance and reduce/prevent memory leaks. Please read through this carefully to see how it may affect your app.

To help test, you can hook your app to the nightly builds: http://code.ionicframework.com/#nightly or with bower.

(the original post has gotten too large and unmanageable, and a majority of the content is no longer relevant, so we we’re reposting it to clean things up)

Refactor:

  • Cached Views:
    • Previously, as a user navigated an app, each exiting view’s element and scope would be destroyed. If the same view was accessed again then the app would have to recreate the element. Views can now be cached to improve performance.
    • Now, when a view is exited, its elements are left in the DOM, and its scope is disconnected from the cycle. When navigating to a view which is already cached, its scope is reconnected, and the existing element which was left in the DOM becomes the active view.
    • This also allows for scroll position of previous views to be maintained (without skippy jumps).
    • Config variables can be used to disable view caching, IE set to 0, or change the maximum number of views to cache.
    • Individual ionViews can disable caching by using the cache-view="false" attribute, or from its $stateProvider.state config.
    • Note: Views with many large images or videos should not be cached.
    • The ionNavView docs have more further documentation.
  • Navigation: Refactored for improved performance
    • Reduced DOM manipulations
    • Cached Views (see above)
    • Increased transition FPS for smoother animation
  • Angular v1.3:
    • Upgraded Ionic to work with Angular v1.3.
    • In general Ionic just works with the upgrade, but the required change was that animations in v1.3 uses promises, whereas in v1.2 animations used callbacks.
    • Check out the Angular 1.3 ng-europe presentation and Migrating from 1.2 to 1.3 for more information.

Features:

  • Platform Specific Transitions: Transitions between views now default to the transition style appropriate for each platform.
    • For example, iOS will move forward by transitioning the entering view from right to center, and the exiting view from center to left. However, Android will transition with the exiting view going from bottom to center, covering the previous view, which remains stationary.
    • Platform transitions are automatically applied by default, but config variables and custom CSS allows these defaults to be easily overridden.
  • ionNavTitle: Use the nav title directive to set custom HTML the for the header bar’s title from within an ionView template. This gives each view the ability to specify its own custom title, such as an image or any HTML, rather than being text-only.
  • enable-menu-with-back-views: In many mobile apps, sidemenus are disabled on child views. The enable-menu-with-back-views attribute determines if the side menu is enabled when the back button is showing.
    • When set to false, any buttons/links with the menuToggle directive will be hidden, and the user cannot swipe to open the menu.
    • When going back to the root page of the side menu (the page without a back button visible), menuToggle buttons will show again, and menus will be re-enabled.
    • ionSideMenus docs
  • menuClose: Closes a side menu which is currently opened. Additionally, the menuClose directive will now cause transitions to not animate between views while the menu is being closed.
  • ionNavBackButton: The back button icon and text will automatically update to platform config defaults, such as adjusting to the platform back icon.
    • To take advantage of this, the ionNavBackButton directive should now be empty, IE <ion-nav-back-button></ion-nav-back-button>.
    • The back button can still be fully customized like it could before, but without any inner content it knows to style using platform configs.
    • ionNavBackButton docs
  • navBar button primary/secondary sides: Primary and secondary sides are now the recommended values for the side attribute, such as <ion-nav-buttons side="primary">.
    • Primary buttons generally map to the left side of the header, and secondary buttons are generally on the right side.
    • However, their exact locations are platform specific.
    • For example, in iOS the primary buttons are on the far left of the header, and secondary buttons are on the far right, with the header title centered between them.
    • For Android however, both groups of buttons are on the far right of the header, with the header title aligned left.
    • Recommendation is to always use primary and secondary so buttons correctly map to the side familiar to users of a platform.
    • In cases where buttons should always be on an exact side, both left and right sides are still available.
    • ionNavButtons docs
  • $ionicView Events: Now that views can be cached, controllers may only load once, which may change how you’d expect data to load.
    • New events have been added that get emitted from the view’s scope: $ionicView.enter, $ionicView.leave, $ionicView.loaded.
    • These events also contain data about the view, such as the title and if the back button should show, along with transition data, such as the transition type and direction that was used.
    • ionView docs
  • Override Transition Type and Direction: As a user navigates the app, Ionic automatically applies the appropriate transition type for the platform, and the direction the user is navigating. Both can be overridden in numerous ways: config variable, view attribute, stateProvider property, or attribute on the button/link that initiated the transition.
  • navDirection: An attribute directive that sets the direction which the nav view transition should animate.
  • navTransition: An attribute directive that sets the transition type which the nav view transition should use when it animates. Using none will disable an animation.
  • $ionicConfigProvider: Configs can be changed using the $ionicConfigProvider during the configuration phase of your app. $ionicConfig can also set and get config values during the run phase and within the app itself.

Breaking Changes:

  • Animation CSS: The CSS for view transitions have changed. This is a breaking change only if Ionic apps had customized Ionic’s animation CSS. Additionally, all keyframe animations were removed since they weren’t being used. (20Kb saved!)
  • $ionicPlatformDefaults: Platform config variables are no longer in the $ionicPlatformDefaults constant, but within $ionicConfigProvider.
  • navClear: The navClear directive was created to do what the new side menu enable-menu-with-back-views attribute accomplishes and has therefore been removed. Additionally, the new navTransition and navDirection directives are more useful and granular.
  • scrollView.rememberScrollPosition: This method has been removed since it is no longer needed with cached views.

Deprecated:

  • ionView.title: The ionView directive used the title attribute, but this can cause the tooltip to show up on desktop browsers. The title attribute will still work for backwards compatibility, but we now recommend using view-title, such as <ion-view view-title=”My Title”>.
  • ionNavView animation attribute: The animation attribute can be safely removed as it is no longer used for nav views. Instead use $ionicConfig.
  • ionNavBar animation attribute: The animation attribute can be safely removed as it is no longer used for nav bars. Instead use $ionicConfig.
  • $ionicNavBarDelegate#changeTitle: To set a title you now use title(value) (with an argument). The changeTitle() method will now produce a console.warning message, but it can still be used for this version.
  • $ionicNavBarDelegate#setTitle: To set a title you now use title(value) (with an argument). The setTitle() method will now produce a console.warning message, but it can still be used for this version.
  • $ionicNavBarDelegate#getTitle: To get a title you now use the return value of title() (no argument). The getTitle() method will now produce a console.warning message, but it can still be used for this version.
  • $ionicNavBarDelegate#back: The back() method has been removed in favor of using $ionicHistory.goBack(). Additionally, $ionicGoBack() is added to the rootScope. $ionicHistory docs
  • $ionicNavBarDelegate#getPreviousTitle: The getPreviousTitle() method has been removed in favor of $ionicHistory.backTitle(). $ionicHistory docs
  • $ionicViewService: In the navigation refactoring, $ionicViewService was split up into two factories, $ionicViewSwitcher and $ionicHistory. The $ionicHistory is largely what $ionicViewService was, but now between the two there is a better separation of concerns for improved testing. $ionicHistory docs

Note: Past nightly versions had a refactored slidebox, however, we decided to pull it out for this release

What’s next!

  • Now that view elements are cached in the DOM, we’ll be adding the “swipe to go back” feature.
  • Since Android provides the necessary scroll events, we’ll be refactoring our scrolling so we can remove JS scrolling on Android devices.
  • This is the last beta!! Once the swipe to go back and removal of JS scrolling on Android updates are added we’re going to call Ionic v1.0 feature complete, and roll out the release candidate.
  • With the new navigation and transition system we’ve got a lot more power for animations. In the near future we’ll be creating an animations pack that can easily extend Ionic’s animations.
9 Likes
3

Hope you don’t mind, but I’m going to repost this from the old one.

Anyone else seen infinite digest issues when using $stateChangeStart to check authentication status? Did not see this problem in Beta 13. I’ve got it now in 800 and 805 & 840. Not sure if it existed prior to that on the new nightlies.

I’ve tried to make a demo but can’t reproduce the problem that my app has.

UPDATE : I have a working sample. http://codepen.io/calendee/pen/zxGRza5
UPDATE : Opened issue : https://github.com/driftyco/ionic/issues/2638

To reproduce this, you must use Ionic CLI to create a local app. The problem will NOT be demonstrated in Codepen(not sure why).

So, do the following :

UPDATE : Corrected link to codepen sample

  • ionic start digestProblem http://codepen.io/calendee/pen/zxGRza
  • cd digestProblem
  • ionic serve 9000 9001 (or whatever your preference)
  • Note that the app works just fine. You were heading towards /tab/home and got redirected to /signin because the auth check always returns false.
  • Now, replace the Beta 13 files in www/lib/ionic with nightlies
  • Open the console in your browser. You’ll still be on the signin page
  • Reload the browser at http://localhost:9000
  • Notice that the app is repeatedly trying to access /tab/home even though you are redirecting to signin.
  • Finally, angular kills the digests and you end up in the signin state
  • Notice that even if you comment out the $state.go(“signin”);, the app is still constantly trying to reload /tab/home
4

Hi again @adam! I think the fix for the menuClose directive (in response to my post on the previous topic) broke the sidemenu transitions. Previously the transitions were hidden when going from one page to another, but now it is showing transitions. Also, dragging to open the menu doesn’t work once you’ve navigated to a new page in the menu.

To reproduce, go to this codepen:

  1. Drag the screen to open the menu
  2. Click on “Find Locations”
  3. Try to drag the menu open - it shouldn’t open
  4. Click back and forth between the menu items to see the transition animations

Something else I noticed - when you use menu-toggle=“left” on the menu icon it is hiding the menu icon on other pages where the menu should be. Is this expected behavior? See this codepen to see what I mean. Open the menu and go to “Find Locations” and the menu icon disappears.

Sorry if this has already been addressed. Thanks for all the hard work!

6

@brandyshea What you’re doing is overkill for the side menu. You’re creating a <ion-list> with child <ion-item>s, then adding an inner <label> and adding your own ng-click, to call a custom method, that manually toggle’s the left menu, then does a state transition. But there’s more to the menuClose directive than just that.

You should be using menuClose directive like you did in your previous post. And if you still want to use your custom ngclick, then you have to run the same code that menuClose is doing. I wouldn’t say anything is broken, and to keep things simple I’d recommend this structure, and if you’re going to customize your own, then they need to do the same things the provided directives do.

1 Like
7

Hi guys,

I have this right sidemenu with a search box at the top but, when I
test in an Android device, every time I focus on the search text box to type
the device’s keyboard appears the sidemenu closes.

Any ideas?

Thanks

8

Hey guys,

again, duplicating this here in case (and I think it is) it’s a nightly issue : SlideBox : GetByHandle not working in modal

it appears that the slidebox getbyhandle doesn’t work properly when called and returns undefined.

Ideas?

Thanks

9

Since Android provides the necessary scroll events, we’ll be refactoring our scrolling so we can remove JS scrolling on Android devices.

Can’t wait for this one! Currently scrolling on Android devices knocks out ionic.

2 Likes
10

Is this happening in the nightly builds or beta 13?

11

Getting the same problem here. It’s due to the isActiveScope check when looking for a delegate. I think the issue is the slidebox scope is not in the same tree as the scope of the current active view. It’s in a sibling tree because of the way the modal works. This means it’s being filtered out when looking for the delegate.

I’m looking for a fix just now, but I’m sure @adam or someone would be able to find a fix quicker :smiley:

12

Somewhere between Build 805 and 837 (I didn’t download any of the ones in between) something changed that broke scrolling content in modals for me.

I have a tab with a modal that looks like this:

<ion-modal-view has-header="true" title="...">
    <ion-header-bar align-title="center">
      ...
    </ion-header-bar>
    <ion-slide-box show-pager="false" on-slide-changed="slideChanged($index)">
        <ion-slide ng-repeat="single in data.object track by $index">
            <div ng-if="single.hidden == false" class="padding">
                <ion-content class="padding">
                    ... lots of content needs scrolling here ...
                </ion-content>
            </div>
        </ion-slide>
    </ion-slide-box>
</ion-modal-view>

In Buil 805 this works fine, but in later builds the fails to get a properly calculated height (it has height: auto;), and so only a small part at the top is displayed.

I have solved this for the moment by a css rule

.scroll-content {
    display: table;
}

but I don’t think it is supposed to be like this (it worked fine in b13 too…)
[update] this solution work in chrome but not on devices so I guess I don’t have a solution after all… :slight_smile:
I have updated my http://plnkr.co/edit/KFYgUst3zOq7AXkZ4fRz?p=preview to show the problem.

13

@JesperWe Thanks for the codepen and description, sounds like the same issue as this one: SlideBox : GetByHandle not working in modal from @WidawskiJ

To narrow down the issue, I think it’s because the abstract tab state has a different historyId as the modal, so when it’s trying to look up the slidebox instance inside of the modal it’s seeing the wrong historyId. I’ll start digging into this to find the fix. Thanks for reporting this!

14

What’s the best way to help test? What do I download, from where? And how do I install it correctly?

15

Sorry, guess I neglected to state how to help test. I updated the original post with this:

To help test, you can hook your app to the nightly builds: http://code.ionicframework.com/#nightly or with bower.

16

Hmm… Not sure about that. The @WidawskiJ linked issue seems like a functionality (Javascript) problem. My issue is just CSS related, I think. (Could be wrong of course…)

17

Great job on Beta 14!

We are experiencing some issues with the side menu and Android, though. I created a bug report with a Codepen here: https://github.com/driftyco/ionic/issues/2674

Will this particular issue be fixed by the Android scrolling overhaul? Also, do you have an estimate for when it will be ready? We have an Android app ready to go once this issue is solved.

18

Hi,

I have built a test application based on sidemenu app template on ionic beta 13; I only have added a popover with two item in playlists page.
I have tested the application in Web Browser (Chrome) and the items in the popover work well: they show visual feedback when clicked.
I have built the android application and I have installed it on my Nexus 5 (Android 5) and the popover items have no visual feedback. This issue seems different from known slow button feedback issue: in this case there are no feedback at all.
Is there a solution to this in the upcoming beta 14?

Thanks.

19

@vrifino I plan on fixing the issue described before the beta14 release. This is happening with the back button. As for the commonly known slow button feedback issue, that should be fixed too. Thanks

20

@Calendee I’m not seeing this happen. I followed your steps exactly. http://ajoslin.co/10kNX

21

Keyboard plugin is not working on nightly on ios devices. I’m using ngCordova. But when I call $cordovaKeyboard.hideKeyboardAccessoryBar(true) it doesn’t work. The input elements in a modal still hides under the keyboard. And it’s weird when I click on an input it scrolls the modal down before going up, I wonder why.

Seems like abandoning ngCordova and call it directly as recommended in the README works.

– edit –
The scroll problem is still there.

– edit –
Seems like ionic keyboard plugin didn’t scroll correctly, as it seems to scroll a bit but the input element is still under the keyboard. Testing on ios simulator.
When I focus on an input box the modal will first got pulled down depending on how deep the input is relative to the screen, then when keyboard is up the view is pulled back up but since the initial pulling the result screen is offset therefore the input is still behind the keyboard. On nightly-857. Seems like this only happens when disableScroll(false) is set. But when disableScroll(true), the content doesn’t get scroll up enough to be above the keyboard.

Actually I just noticed it is doing the same thing here on ios 8 safari:

I also noticed that in div.scroll, the style="-webkit-transform: translate3d(0px, 0.09454708454008155px, 0px) scale(1);" is close to the initial position without keyboard which means it cannot scroll pass keyboard since keyboard takes up the bottom half of the screen.

1 Like