ClaudiuB
11/09/2018, 5:49 AMcontext!!
versus context?
in my Fragments? I'm thinking using context!!
in my lifecycle methods and context?.let{}
where I get callbacksgildor
11/09/2018, 5:51 AMrequireContext()
to get non-nullable contextClaudiuB
11/09/2018, 5:52 AMgildor
11/09/2018, 5:54 AMdvlwj
11/09/2018, 6:04 AM!!
make the app crash when there is some error? i think its not wise for app that alr launchgildor
11/09/2018, 6:05 AM?
and just do nothing if contetxt is null, sometimes you need contextChristian Maier
11/09/2018, 6:17 AMrnpy
11/09/2018, 6:22 AM!!
instead of adding convoluted checks imho, as long as the stacktrace in case of a crash is clear enough (especially when working on legacy code)Christian Maier
11/09/2018, 6:32 AMgildor
11/09/2018, 6:34 AMI prefer methods like requireContext (in this case) or something like getOrThrow() instead ofinstead of adding convoluted checks imho!!
!!
dvlwj
11/09/2018, 7:31 AMClaudiuB
11/09/2018, 8:26 AMrequireContext()
. Is it valid to only use it in lifecycle methods ( onAttach() -> onDestroy
) ?rnpy
11/09/2018, 8:30 AMClaudiuB
11/09/2018, 8:35 AMcontext
starts being null? Like precisely after a lifecycle method?rnpy
11/09/2018, 8:45 AMonAttach
/ after onDetach
gildor
11/10/2018, 9:57 AMalso on user action I'd say, on a click listener for example it makes sense to assume the context is not nullActually this is not always true, click is also asyncronous action managed by looper's event loop and in some cases you can get call backs after fragment detach
igor.wojda
11/10/2018, 11:38 AMClaudiuB
11/10/2018, 12:15 PMval recyclerView: RecyclerView by bindView(R.id.recycler)
which ended up being non nullable. Is that safe?binding?. let {}
a lot in callbacks. Is there a way to check if we can do operations on our views?igor.wojda
11/10/2018, 4:19 PMstartActivity
. You can easily obtain it from custom application class (configured in AndroidManifest) and assume it will be initialises latter and always be non-nullable (utilising lateinit
modifier)
class MyApplication : Application() {
lateinit var context: Context
override fun onCreate() {
super.onCreate()
this.context = context
}
}
Then you can just staticky access it (not so nice) or inject it into Activity (proper way of doing things)tateisu
11/10/2018, 5:18 PMrnpy
11/10/2018, 11:45 PMval recyclerView: RecyclerView by bindView(R.id.recycler)
is not safe, it you try to access it before onViewCreated for example (or after view destroyed) it will throw an NPE, so technically using RecyclerView
instead of RecyclerView?
can be considered wrong. But it all depends on where you decide to draw the line for "too many checks", and what you want to do when one of these fail (in some cases you can just ignore what happened if the view is gone, but in others you could want to consider it an error)ClaudiuB
11/12/2018, 5:03 AMgildor
11/12/2018, 5:13 AMrnpy
11/12/2018, 8:57 AM