Mark Murphy
08/05/2019, 10:41 PMclass SampleRosterFragment : Fragment() {
override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View =
inflater.inflate(R.layout.empty_frame, container, false)
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
(view as ViewGroup).setContent {
Padding(10.dp) {
}
}
}
}
This code causes the IDE and Gradle to go ballistic, with inscrutable error messages:
class SampleRosterFragment : Fragment() {
override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View =
inflater.inflate(R.layout.empty_frame, container, false)
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
(view as ViewGroup).setContent {
MaterialTheme {
Padding(10.dp) {
}
}
}
}
}
Yet that same MaterialTheme
construction works fine from an activity.
I notice that the demos seem activity-centric, though I'm not certain if that is due to current Compose limitations or is tied to other concerns for how you are using those activities.Leland Richardson [G]
08/05/2019, 10:48 PMimport androidx.compose.composer
at the top of this file. This import is currently needed, but the IDE marks it as unused and sometimes removes it.
2. the first example is “working” because you have Padding(10.dp)
and not Padding(padding=10.dp)
. There is currently an issue where calls to composable functions that don’t use named arguments end up going down a code path that fails in terms of doing the right code generation, but doesn’t fail enough to complainMark Murphy
08/05/2019, 10:50 PMimport androidx.compose.composer
-- thanks!themishkun
08/06/2019, 8:42 AMMark Murphy
08/06/2019, 11:06 AMthemishkun
08/06/2019, 12:52 PMMark Murphy
08/06/2019, 1:06 PMViewModel
system, the Navigation component, etc.). I suppose it is possible that they would retreat from that approach and go with one-activity-per-screen, but it seems unlikely. I am assuming that there will be some other pattern emerging that will avoid fragments yet will still have few activities.
Plus, part of my experimentation will be on patterns for how to migrate to Compose from existing code. Developers who try to adhere to current Jetpack guidelines will have lots of fragments and few activities. A likely migration step to Compose will be to keep the fragments for a while, but replace their layouts with @Composable
functions. After that, they would start looking into replacing the fragments with... whatever comes next that ties Compose into the Navigation component.
I might use your suggestion for some of my early explorations of the @Composable
functions supplied by the Compose libraries, though. Thanks for the recommendation!themishkun
08/06/2019, 1:14 PMViewModel
and NavigationComponent
, but I think that they are the bandaids for the current problems of the outdated UI framework. With the approach Compose enables you really don`t need much of these tools, because it offers more straightforward and controllable way to do UI development