* 겪고 있는 문제 상황을 최대한 자세하게 작성해주세요.
* 문제 해결을 위해 어떤 시도를 해보았는지 구체적으로 함께 알려주세요.
pixel_3A 등으로 시작하는 에뮬레이터 2개를 눌러도 실행되지 않고 아래와 같은 메모? 식으로만 나타납니다.
아무리해도 에뮬레이터가 나타나지 않습니다.
run without debugging 을 하면 폰 모양 안에 나타나는 게 아니라 사각형 패널?로만 나타납니다.
material
package:flutter/material.dart
Flutter widgets implementing Material Design.
To use, import package:flutter/material.dart.
www.youtube.com/watch?v=DL0Ix1lnC4w
See also:
flutter.dev/widgets/material for a catalog of commonly-used Material component widgets.
material.io/design for an introduction to Material Design.
material.io/components for the Material 2 specification.
m3.material.io for the Material 3 specification.
==================================
abstract class StatelessWidget extends Widget
package:flutter/src/widgets/framework.dart
A widget that does not require mutable state.
A stateless widget is a widget that describes part of the user interface by building a constellation of other widgets that describe the user interface more concretely. The building process continues recursively until the description of the user interface is fully concrete (e.g., consists entirely of [RenderObjectWidget]s, which describe concrete [RenderObject]s).
www.youtube.com/watch?v=wE7khGHVkYY
Stateless widget are useful when the part of the user interface you are describing does not depend on anything other than the configuration information in the object itself and the [BuildContext] in which the widget is inflated. For compositions that can change dynamically, e.g. due to having an internal clock-driven state, or depending on some system state, consider using [StatefulWidget].
Performance considerations
The [build] method of a stateless widget is typically only called in three situations: the first time the widget is inserted in the tree, when the widget's parent changes its configuration (see [Element.rebuild]), and when an [InheritedWidget] it depends on changes.
If a widget's parent will regularly change the widget's configuration, or if it depends on inherited widgets that frequently change, then it is important to optimize the performance of the [build] method to maintain a fluid rendering performance.
There are several techniques one can use to minimize the impact of rebuilding a stateless widget:
Minimize the number of nodes transitively created by the build method and any widgets it creates. For example, instead of an elaborate arrangement of [Row]s, [Column]s, [Padding]s, and [SizedBox]es to position a single child in a particularly fancy manner, consider using just an [Align] or a [CustomSingleChildLayout]. Instead of an intricate layering of multiple [Container]s and with [Decoration]s to draw just the right graphical effect, consider a single [CustomPaint] widget.
Use const widgets where possible, and provide a const constructor for the widget so that users of the widget can also do so.
Consider refactoring the stateless widget into a stateful widget so that it can use some of the techniques described at [StatefulWidget], such as caching common parts of subtrees and using [GlobalKey]s when changing the tree structure.
If the widget is likely to get rebuilt frequently due to the use of [InheritedWidget]s, consider refactoring the stateless widget into multiple widgets, with the parts of the tree that change being pushed to the leaves. For example instead of building a tree with four widgets, the inner-most widget depending on the [Theme], consider factoring out the part of the build function that builds the inner-most widget into its own widget, so that only the inner-most widget needs to be rebuilt when the theme changes.
When trying to create a reusable piece of UI, prefer using a widget rather than a helper method. For example, if there was a function used to build a widget, a [State.setState] call would require Flutter to entirely rebuild the returned wrapping widget. If a [Widget] was used instead, Flutter would be able to efficiently re-render only those parts that really need to be updated. Even better, if the created widget is const, Flutter would short-circuit most of the rebuild work.
This video gives more explanations on why const constructors are important and why a [Widget] is better than a helper method.
www.youtube.com/watch?v=IOyq-eTRhvo
The following is a skeleton of a stateless widget subclass called GreenFrog.
Normally, widgets have more constructor arguments, each of which corresponds to a final property.
class GreenFrog extends StatelessWidget {
const GreenFrog({ super.key });
@override
Widget build(BuildContext context) {
return Container(color: const Color(0xFF2DBD3A));
}
}
This next example shows the more generic widget Frog which can be given a color and a child:
class Frog extends StatelessWidget {
const Frog({
super.key,
this.color = const Color(0xFF2DBD3A),
this.child,
});
final Color color;
final Widget? child;
@override
Widget build(BuildContext context) {
return ColoredBox(color: color, child: child);
}
}
By convention, widget constructors only use named arguments. Also by convention, the first argument is [key], and the last argument is child, children, or the equivalent.
See also:
[StatefulWidget] and [State], for widgets that can build differently several times over their lifetime.
[InheritedWidget], for widgets that introduce ambient state that can be read by descendant widgets.
