Very precise. I am most impressed because you covered something that most new programmers don't get i.e. null isn't bad. When you integrate server side code with APIs, Services etc you actually sometimes look for nulls to tell you another part of the story. So coming from a hard core Java background I've learnt to use nulls to advance my coding strategy. I think what this null safety does is great for clean code and efficiency but I guess having to tackle this stuff way back in the day made me a stronger programmer.
Yeah null can be really powerful. And while we should already be writing code where we should be aware of null, and be able to use it, null safety will ensure that our code won't run into any null issues. (unless we override it)
I will add however that personally I avoid null as much as possible. Even a persons name that could be anything will not be a long uuid string. Use a type or const to match. Even in external apis that you control. It is better to avoid them where possible. This way you can know whether a null came from somewhere unexpected (a code bug) more easily.
@@tadaspetra I would argue to the contrary,kotlin has to support the jvm libraries hence the need for runtime checks.to have full soundness data should be immutable.
Brilliant and fun. I am definitely in the second category myself. My worry is dependencies. Would not be fun if a package I'm using or want to use isn't (going to be) migrated.
I recently upgraded my flutter to 2.0 nd now im facing a bit uneasiness/uncomfortable adapting to null safety ... Like the defalut type is non nullable now nd when you have to make it nullable u declare it statistically nd later it will throw runtime exceptions conflicting with other non nullable types objects nd what to do fr this is just declare all other objects that will be related to the particular nullable obj to nullable type(?) ... And then the next step is to check the objs type nd the value it stores by declaring null assertion (!) and what it dose is it will check whether the objects is null or non nullable nd if it's null then it will throw exception in the runtime ... And other alternatives beside these static methods is (late) it will only be initialized when its needed ... which is it will remains lazy until it receives a data in future ... So at first it will be really uncomfortable to adapt to null safety IMO nd my personal experience i miss thosr nullable days so badly but it can't be helped we have to move on .. I may be incorrect in some points above pls do correct me in the reply .
Personally I am just waiting lol. But really you have 2 options, switch to beta channel and convert early, OR just be aware of current codebase null types to make the transition easier
For the first one you will be able to assign it at a later point, but it still can’t be null. This can be useful in some very specific situations, like initializer lists potentially. But realistically most apps can be built without using late or !. It’s for very specific situations
@@tadaspetra gotcha. Late sounds like a promise to be a String, '' is an empty string. I usually use it to mean something, a default before being set... or count it being '' but not null.
dude its brilliant the way you explain things quick and easy
Thank you so much! That is my goal, and the main thing I hope to keep improving. Making tough topics simple!
You basically just unveiled null safety for me 🙌🏾. Awesome 👍🏾
That was my goal! Glad I could help!
Comment for the yt algo because this video is great 👏
Ayyy appreciate it :)
Just subbed to your channel , keep it up man
Thank you so much!
Very precise. I am most impressed because you covered something that most new programmers don't get i.e. null isn't bad. When you integrate server side code with APIs, Services etc you actually sometimes look for nulls to tell you another part of the story. So coming from a hard core Java background I've learnt to use nulls to advance my coding strategy. I think what this null safety does is great for clean code and efficiency but I guess having to tackle this stuff way back in the day made me a stronger programmer.
Yeah null can be really powerful. And while we should already be writing code where we should be aware of null, and be able to use it, null safety will ensure that our code won't run into any null issues. (unless we override it)
@@tadaspetra yeah that's the right word.. We should null aware while writing code! Next week hits -20.. My malkos offer still stands! ;-)
@@yoapps137 😂😂
I will add however that personally I avoid null as much as possible. Even a persons name that could be anything will not be a long uuid string. Use a type or const to match. Even in external apis that you control. It is better to avoid them where possible. This way you can know whether a null came from somewhere unexpected (a code bug) more easily.
this is awsome bro, I have a two-year-old project to be migrated to null-safty, thanks man
thank you .. I am a biggner for a long time and feel it's been a while semce i really learned somthing other than bignner things
Thanks a lot, great video as usual ❤
Thanks man. I'm looking forward to migrate an app that was handed over to me. I hope it will be safer and the migration will be as smooth as possible.
Awesome explanation. Clear and concise. Thank you
Thank you!
Not only swift but Kotlin does it too. I would argue they used Kotlin implementation as a template.
Kotlin has null safety. But it is not _sound_ unless they updated something really recently
@@tadaspetra I would argue to the contrary,kotlin has to support the jvm libraries hence the need for runtime checks.to have full soundness data should be immutable.
@@tadaspetra darts implementations is potentially dangerous with the ability to mix null safety code and non null safety code.
Brilliant and fun. I am definitely in the second category myself. My worry is dependencies. Would not be fun if a package I'm using or want to use isn't (going to be) migrated.
I recently upgraded my flutter to 2.0 nd now im facing a bit uneasiness/uncomfortable adapting to null safety ...
Like the defalut type is non nullable now nd when you have to make it nullable u declare it statistically nd later it will throw runtime exceptions conflicting with other non nullable types objects nd what to do fr this is just declare all other objects that will be related to the particular nullable obj to nullable type(?) ...
And then the next step is to check the objs type nd the value it stores by declaring null assertion (!)
and what it dose is it will check whether the objects is null or non nullable nd if it's null then it will throw exception in the runtime ...
And other alternatives beside these static methods is (late) it will only be initialized when its needed ... which is it will remains lazy until it receives a data in future ...
So at first it will be really uncomfortable to adapt to null safety IMO nd my personal experience i miss thosr nullable days so badly but it can't be helped we have to move on ..
I may be incorrect in some points above pls do correct me in the reply
.
Pretty sure C# is null safe as they only introduced nullable types about a year after the first release.
C# has null safety, but not “sound” null safety
Great! Subbed.
Since my last update to the last flutter version, My code dosn't work fine. Can u please update your video about Getx.
Fantastic, thank you for this
3:11 After the variable type :)
Increíble muchas gracias excelente explicación!
Thank you!
Thank you for watching
Subbed
What do we need to do while working on a current Flutter project to get ready for Null Saftey?
Personally I am just waiting lol. But really you have 2 options, switch to beta channel and convert early, OR just be aware of current codebase null types to make the transition easier
ty
Can "late"be used as lazy instatiation?
Yes. That’s what it’s for, so you can instantiate it later but before it gets used
I am 2 nd category;)
Hehe me too
What's the difference between:
late String myString;
and
String myString = '';
For the first one you will be able to assign it at a later point, but it still can’t be null. This can be useful in some very specific situations, like initializer lists potentially. But realistically most apps can be built without using late or !. It’s for very specific situations
@@tadaspetra gotcha. Late sounds like a promise to be a String, '' is an empty string. I usually use it to mean something, a default before being set... or count it being '' but not null.
It's not about being lazy, it's about be able to build with flutter dependency hell
After watching this video, I am less afraid of Null Safety
It is not so bad
You know, you can teach a 6 year old flutter.
Haha thank you. That means a lot! That’s exactly my goal to try to make it simple as possible