All language subtitles for 28. Showing a Modal Bottom Sheet

To show a sheet, there is a built-in function Flutter offers us

that's good to show such a bottom modal sheet

I should say and since I want to show that sheet both when we click that floating action button and

when we click that action in the app bar, I will create a method that opens up that sheet so that we

can share that method with both places where we want to trigger it.

It will return nothing,

that method and I'll name it startAddNewTransaction.

The name might be a bit clunky but in the end that is what happens here,

it doesn't add a new transaction,

it starts the process of adding a new transaction,

it starts the process by showing the input area for that new transaction data.

So startAddNewTransaction is the method name and in there, you can call showModalBottomSheet,

a function provided by Flutter,

that's why this function is available here.

So this function can be called and showModalBottomSheet

now needs at least two arguments -

the first is a value for the context because internally, this function will use this strange context

object with which we haven't worked to show that modal sheet,

so we need to pass a value for context here.

The good thing is we get a value for context in here,

we get it passed into the build function automatically by Flutter but of course that's the wrong place,

we need it up here.

Solution is simple,

we accept it as an argument here and I'll name it ctx to avoid confusion with the names. So I forward

my context which I expect to get as an argument to showModalBottomSheet for the context argument

and then we also need a builder. Builder now is a function that needs to return the widget that should

be inside of that modal bottom sheet.

The builder function itself also gives us a context and I'll name this bCtx to really make this clear

that this is not the same value as this context.

This is the context we pass to this function to pass it to the modal bottom sheet,

the modal bottom sheet then starts building that sheet that slides in and to that builder, it again gives

us its own context, so its own package of meta information about that widget which it builds. We never

use that context,

well at least now we start using it here indirectly when we pass it to showModalBottomSheet,

we get it here nonetheless in the builder in case that inside of the builder where we now built the

widget that should be part of the modal sheet, in case we needed access to the context object there and

you will later in this module learn why you for example need the context, so we get it here in case we

need it even though we don't.

Since we don't use it, of course you could use that underscore thing to indicate I know that, I get it but

I don't care. Inside of the builder function here,

you now return something and that something now is the widget you want to show inside of that modal

sheet

and in my case, that of course should be that new transaction.

So here I want to show new transaction and for that, I now need to import my own new transaction widget with

that relative import path and new transaction now has one disadvantage,

it of course needs the add transaction function reference and we outsource that into user transactions

because up until now, that was the perfect solution,

we had new transaction and transaction list in there,

we had our transaction lists or a list of objects in there,

we had the add new transaction method in there and all that was hidden away from our main.dart file

and now all of a sudden, because we have to trigger startAddNewTransaction from in here, in the main.dart

file because here is where we have the app bar and the floating action button because we have

to trigger that function from in here,

we now have to bring new transaction back into that main.dart file and since that needs the add transaction

method, we now actually have to bring all our state logic into this file. So there is no way around it,

let's transform this stateless widget to a stateful widget.

At least we can do that automatically with the help of the refactoring tool,

if you click on it and then use the refactoring shortcut, you can choose convert to stateful widget

here, you automatically get your state object and now in there, I will basically grab my list of transactions

and add new transaction from inside the user transactions widget, add it in the main.dart file here below

title controller and amount controller

which I by the way don't need there anymore

and now with the transactions and the add transaction method brought over, we need to import our transaction

model to unlock that transaction class, so

let's add this import here and of course now that means that our user transactions widget unfortunately

is redundant and that is also something you'll have in Flutter development, which is why I'm showing

it here.

You will sometimes build a solution which you then have to break up at some point because you recognize

okay for this feature, I need to manage my state somewhere else,

otherwise I can't pass data around. Later in this course, we'll learn about a more elegant state management

solution, which avoids having solutions like this where we have to lift state up to the common denominator

but for the moment and for simple apps like this, it is fine and we also won't have a performance problem

if we use our main file for managing the state and for rebuilding everything on every change therefore.

We can get rid of the user transaction file however, we don't need it anymore

and in main.dart, we hence

now instead of returning our user transactions, return our transaction list widget, pass our user transactions

into it, user transactions is now managed here in the main.dart already in our MyHomePage

state class and the remaining thing we have to do therefore is that instead of importing user transactions,

that's the widget I just deleted,

we import the transaction_list.dart file with the transaction list widget.

Now with that restructuring, we can pass _addNewTransaction, so a pointer at this method, to

new transaction here

and now we have a setup here where we just need to wire up this startAddNewTransaction method, which

now should be _startAddNewTransaction because it's now part of that private state class

and therefore the convention is to make this a private method as well,

now we just have to use this method here and wire it up to our button in the action bar.

So here instead of doing nothing when we press this, we target startAddNewTransaction.

Now keep in mind that this requires the build context because it needs to forward that to show modal

bottom sheet,

so actually we need to call this as an anonymous function so that in here, we can call it manually and

forward context, which is this context value here and now we do the exact same for our floating action

button down here. And now with that if you save that and maybe restart the app because we changed a lot,

typically the app needs to be restarted thereafter,

if you do that now, if you press the plus up there, you'll see that this action sheet floats in and the same

for the floating action bar at the bottom.

That's a default feature you get,

you can also click the background to close it,

you can also click the actionsheet itself to close it,

that should eventually change in the future.

Until this changes, you can easily fix that by wrapping your new transaction in show modal bottom

sheet with a gesture detector which is another widget I mentioned earlier on a slide, which takes a

child,

in this case our new transaction and where you can register a certain gesture,

in this case onTap and simply do nothing when this gesture occurs. This catches this tapping on that

bottom sheet and avoids that the sheet gets closed

if you tap on the sheet. It still gets closed

if you tap on the background but not if you tap on the sheet. For this to work, you also need to set a

behavior and you need to set this to HitTestBehaviour.opaque,

this is important to catch the event and avoid the tap here on this gesture detector

which itself is invisible but which has the size of our new transaction widget, that a tap on that also

then still triggers a tap on the underlying modal sheet. With this setting, you catch the tap event and

avoid that it's handled by anyone else

and this avoids that the sheet closes when you tap on the sheet itself.

Again to my knowledge, this should change in the future,

so maybe when you're viewing this, you don't need to add this detector anymore.

Here you see now I avoid that this closes when I tap in here which is of course what I want,

I don't want to close the sheet when I tap in here,

I want to close it

however when I tap on the background and that is what's happening.