Remember when Steve Jobs insisted that big phones are stupid? The iPhone 5 was designed to be as big as possible while still allowing a user's finger to touch controls anywhere on the screen. I totally agreed with that, and sort of still do, but when I hold an iPhone 5 it feels like a sad little baby phone. In fact my next phone will probably be a plus model.
While I've embraced big phones for their media consumption gusto, I still drop my phone on my face in bed often, reaching for that effing done button. Or have to shimmy the phone down my one handed grip to tap some control in the nav bar while my other hand holds my iced coffee.
That's why I love it when devs keep all that in mind when designing their interfaces. Apple to some degree has dealt with this problem by making the slide to the right the defacto gesture for going back, you don't have to reach up to the Navigation Bar to go back a page. They also introduced Reachability, which seemed like a really dumb concept but I use it daily.
One of my favorite examples of an app caring about people dropping their phone on their nose is in Overcast. When you view the podcast you are listening to, you can drag down from any area, and it collapses. I wanted to created this in one of my apps, so I set out to do it.
Most of you will find yourselves in a situation where you want to show some information in a modal. You can use the native modals for this, and NativeScript has a super easy way to get this running cross platform. But I'm not a huge fan of those, they take you out of context a bit, they're not easily dismissable, and you need to implement a communication method between the modal view and your parent view that just adds a bit of overhead you may not want to deal with.
So I created my own "modal", really just a layout that sits on top of my main content, but is hidden by default, and I show it when necessary. I wanted to animate it in, give a control to close it that animates it out, and let the user drag it down to dismiss it.
Here's what I came up with:
There's a lot going on there behind the scenes, but it works. But recently I got sick of recreating this logic all over my app, so I took the time to separate it out into a helper function that I can call easily from anywhere, I just need to setup the UI elements, and call a
My insecurity just informed me that I need to include a disclaimer here: There are probably better ways to do this. But I threw it together in the way I knew how, and it may evolve over time. Use what you find useful.
The code above are the layout elements for the modal I'm going to display. Some CSS accompanies it to add some rounded corners, margin, padding etc, but this can look like anything. I'm going to focus more on the gesture logic here than the UI, but there are some important pieces of the puzzle here.
For this approach, the GridLayout needs to be somewhere in the UI where it sits on top of your page content. A good thing to do is to build the UI without hiding it at first so you can quickly spin up a nice looking view, then hide it using a property in your binding context, in this case
The notable pieces of this UI are the dimmer (
#createTicketDimmer), the container (
#createTicketContainer), the header (
id="mypOverlayHeader"), the close button (
id="closeMypOverlayButton"), the main content section (
id="mypOverlayContent"), and the dissmiss note (
The container is the element that should animate when opened, closed, and dragged. It contains the header and the main content. I'm using angular so I added the angular way of targeting UI elements in your view and access it using @ViewChild.
@ViewChild("createTicketContainer") createTicketContainer: ElementRef;
This is an element that sits underneath the container and dims the content behind it. In this case I am using the nativescript-blur plugin, made by yours truly, to blur the background on iOS and darken it on android. I also use @ViewChild to grab it in my TypeScript file.
This is simply a Label that will show when the user has dragged the overlay down an appropriate amount, indicating that if they remove their finger, the overlay will close.
This is a GridLayout, given a specific ID (mypOverlayHeader), and its the header for the modal, containing a title and a close button. I use an ID here, which I will explain in a minute.
This is a StackLayout containing the content of my modal. In this case its a ScrollView containing some form data. I identify it with @ViewChild, I'll explain why soon.
This is a button that closes the modal. If you are Andre the Giant from The Princess Bride, you may be able to easily tap it, and maybe you prefer to dragging down. All these things are possible. I use an ID for it, you'll find out why soon.
Ok, I've outlined the necessary UI components, now lets see how they all work together.
I've got a helpers file that contains some simple helper functions I use throughout my app. Eventually I hope to make this into a plugin, but for now the logic is stored in helpers.ts.
From my parent view, I call a function that accepts some arguments and shows the modal, and the helper function handles the panning gestures, the close button, the drop to dismiss note, and callback for when its shown and closed. Here is the interface for the arguments:
And heres my show function:
And then, all the @ViewChild's I set up above come into play when I actually want to show the overlay. Here's how I call showMypOverlay:
That passes the elements the function needs to handle all the overlay interactions.
Pretty straightforward! Now lets look at the close function:
droppingto true, to indicate that the overlay is currently being animated off the screen.
readyToDropin a minute.
You'll notice the close button in the UI (
id="closeMypOverlayButton") calls this function, so right now we have a modal overlay that looks good, animates in, animates out, and displays a dimmer underneath it. That's pretty good, but the whole point here was to be able to drag it out of view. Let's take a look at that logic. This is a long function, so I'm going to break it up and comment in between.
The reason I need the ScrollView Element is because I am watching the pan gesture on the overall container. So that gesture will return values regardless of if the scroll view is scrolled down at all. The problem this creates is you could be at the end of your scroll view, trying to scroll back up to the top, and that pan gesture would drag the overlay down. We dont want the overlay to drag down until the scrollview inside it is scrolled all the way to the top. So if there is a scroll view in the content, I set the drag position. On iOS, the scrollview's vertical offset becomes negative when the user engages the elastic behavior of scrollviews, so we turn that number positive, and multiply it by a little, because the nature of the elasticity is such that the scrollview wont pull down as far as your finger goes, giving the impression that there is resistance at the top. So the variable scrollerDragPosition is the position that the container should drag down to, which is 50% more than the position the scrollview drags down to.
This if clause evaluates a few difference scenarios. The first one above is if the user is dragging the header. The reason this is important is because we want the user to able to drag the overlay down and out of view even if the scrollview is at a position other than all the way at the top (
scrollView.verticalOffset <= 0). So if they are dragging the header, they are dragging down (
event.deltaY >= 0), and the overlay isnt currently dropping, then translate the overlay to wherever the user's finger is. In other words, the user is straight up dragging the overlay down, it responds exactly to the user's finger movements.
In this case, a ScrollView does exist, and the verticalOffset is less than 0 (meaning the user is engaging the elasitic behavior), the user is pulling down, and the overlay is not currently dropping. In other words, they've scrolled all the way up in the ScrollView, so we need to drag the overlay down. The reason we need to use scrollerDragPosition here is because if we use deltaY on the pan geseture event, the overlay will JUMP down once the scrollview reaches the top. This isnt a problem if the user is at the top when they engage the pan gesture, but imagine the user is a little bit down the scrollview. They scroll up, engaging the pan gesture. The pan gesture's deltaY value starts at 0, but is at 22 by the time the scrollview's verticalOffset gets to 0, so the overlay will JUMP down to 22. Using the scrollerDragPosition, it uses the negative value of the verticalOffset, so the overlay will mostly follow your finger.
In this case, there is a scrollview, but the content inside it is shorter than the view itself, so the scrollview doesnt scroll! We use scrollableHeight to check that. So this case is similar to as if there were no scrollview at all.
And finally, if theres no scrollview, the overlay just follows the user's finger, as long as its moving downward (deltaY is greater than or equal to 0.)
This next fairly large block of code handles the drop to dismiss note. If scrollerDragPosition is greater than 0, we need to watch that value to know when its appropriate to drop the overlay. If not, it means there is no scrollview or its content doesnt scroll, so we need to watch the pan gesture's deltaY value.
I haven't mentioned
buzz yet, this is a simple fun little addition. Once the user drags the overlay down past the point where it will dismiss if they let go, it vibrates a little bit as an extra indicator. Only on iOS though (Brad Martin rolls his eyes).
Also in this block of code we toggle the readyToDrop boolean, which we will evaluate in the next block.
The pan gesture comes with a state property that gives you clues into what is happening. A state of 3 means they lifted their finger off the screen. That's useful to know! So we set readyToDrop to true if they dragged it down more than 150 points, and set it to false if they didn't. So, if readyToDrop is false and they let go, we animate it back up to the top. If its true and they let go, we drop that sucker. Hide the Drop To Dismiss note, call the close function (see above), and celebrate.
That's pretty much it! There's more logic in my parent view, for example in the close callback I am doing a few clean up things like toggling the boolean that hides the whole GridLayout etc. The nice thing about this approach to is I can call the close function from my view as well, so in this case when they submit the form, I show a spinner and then close the overlay programmatically once the http request comes back. So I just call helpers.mypCloseOverlay(), and it already has my close callback saved from when I showed it.
Here it is in all its glory:
Here's the whole function: