Skip to content

Commit 86c82a8

Browse files
getActivitygetActivity
committed
新增英文版的文档和 Demo apk
1 parent 886790f commit 86c82a8

25 files changed

+804
-963
lines changed

‎Adaptive-en.md‎

Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
# About Attribute Adaptation Issues
2+
3+
* Hello, if you are new to this library, you can ignore this. If you have used the `ShapeView` library before, that is, versions below `9.0`, you need to adapt after upgrading to version `9.0`, otherwise `Android Studio` will report a `compilation failed` error. I apologize for this issue. The naming of `xml` attributes in lower versions was not very standardized. Now, in version `9.0`, it has been optimized. Although the cost of this change is relatively high, I will do it without hesitation. If you use `ShapeView` but do not want to adapt, please do not upgrade the library version.
4+
5+
#### Adaptation Plan for Upgrading from Version 9.2 to 9.3
6+
7+
* Modification
8+
9+
* Changed the attribute name `app:shape_strokeGradientColor`, please use `app:shape_strokeGradientEndColor` instead
10+
11+
#### Adaptation Plan for Upgrading from Version 9.0 to 9.2
12+
13+
* New Attributes
14+
15+
* Added `app:shape_radiusInTopStart` attribute
16+
17+
* Added `app:shape_radiusInTopEnd` attribute
18+
19+
* Added `app:shape_radiusInBottomStart` attribute
20+
21+
* Added `app:shape_radiusInBottomEnd` attribute
22+
23+
* Supplement Attribute Values
24+
25+
* Added several layout reverse direction attribute values for `app:shape_solidGradientOrientation` and `app:shape_strokeGradientOrientation` attributes
26+
27+
```xml
28+
<!-- Draw gradient from left to right (0 degrees) -->
29+
<enum name="startToEnd" value="10" />
30+
31+
<!-- Draw gradient from right to left (180 degrees) -->
32+
<enum name="endToStart" value="1800" />
33+
34+
<!-- Draw gradient from top left to bottom right (315 degrees) -->
35+
<enum name="topStartToBottomEnd" value="3150" />
36+
37+
<!-- Draw gradient from bottom left to top right (45 degrees) -->
38+
<enum name="bottomStartToTopEnd" value="450" />
39+
40+
<!-- Draw gradient from top right to bottom left (225 degrees) -->
41+
<enum name="topEndToBottomStart" value="2250" />
42+
43+
<!-- Draw gradient from bottom right to top left (135 degrees) -->
44+
<enum name="bottomEndToTopStart" value="1350" />
45+
```
46+
47+
#### Adaptation Plan for Upgrading from Version 8.5 to 9.0
48+
49+
* Added
50+
51+
* Added `app:shape_strokeGradientOrientation` attribute
52+
53+
* Deleted
54+
55+
* Deleted `app:shape_useLevel` attribute, reason: rarely used, if needed, please raise your voice
56+
57+
* Modified
58+
59+
* Changed the attribute name `app:shape`, please use `app:shape_type` instead
60+
61+
* Changed the attribute name `app:shape_topLeftRadius`, please use `app:shape_radiusInTopLeft` instead
62+
63+
* Changed the attribute name `app:shape_topRightRadius`, please use `app:shape_radiusInTopRight` instead
64+
65+
* Changed the attribute name `app:shape_bottomLeftRadius`, please use `app:shape_radiusInBottomLeft` instead
66+
67+
* Changed the attribute name `app:shape_bottomRightRadius`, please use `app:shape_radiusInBottomRight` instead
68+
69+
* Changed the attribute name `app:shape_startColor`, please use `app:shape_solidGradientStartColor` instead
70+
71+
* Changed the attribute name `app:shape_centerColor`, please use `app:shape_solidGradientCenterColor` instead
72+
73+
* Changed the attribute name `app:shape_endColor`, please use `app:shape_solidGradientEndColor` instead
74+
75+
* Changed the attribute name `app:shape_gradientType`, please use `app:shape_solidGradientType` instead
76+
77+
* Changed the attribute name `app:shape_centerX`, please use `app:shape_solidGradientCenterX` instead
78+
79+
* Changed the attribute name `app:shape_centerY`, please use `app:shape_solidGradientCenterY` instead
80+
81+
* Changed the attribute name `app:shape_gradientRadius`, please use `app:shape_solidGradientRadius` instead
82+
83+
* Changed the attribute name `app:shape_strokeWidth`, please use `app:shape_strokeSize` instead
84+
85+
* Changed the attribute name `app:shape_dashWidth`, please use `app:shape_strokeDashSize` instead
86+
87+
* Changed the attribute name `app:shape_dashGap`, please use `app:shape_strokeDashGap` instead
88+
89+
* Changed the attribute name `app:shape_innerRadius`, please use `app:shape_ringInnerRadiusSize` instead
90+
91+
* Changed the attribute name `app:shape_innerRadiusRatio`, please use `app:shape_ringInnerRadiusRatio` instead
92+
93+
* Changed the attribute name `app:shape_thickness`, please use `app:shape_ringThicknessSize` instead
94+
95+
* Changed the attribute name `app:shape_thicknessRatio`, please use `app:shape_ringThicknessRatio` instead
96+
97+
* Split
98+
99+
* Split the attribute `app:shape_angle` into `app:shape_solidGradientOrientation` and `app:shape_strokeGradientOrientation`. The previous `app:shape_angle` attribute is equivalent to the current `app:shape_solidGradientOrientation` attribute. You can directly search and replace. Also, the value type has been changed. For specific values, please refer to the following:
100+
101+
```xml
102+
<!-- Draw gradient from left to right (0 degrees) -->
103+
<enum name="leftToRight" value="0" />
104+
<!-- Draw gradient from right to left (180 degrees) -->
105+
<enum name="rightToLeft" value="180" />
106+
<!-- Draw gradient from bottom to top (90 degrees) -->
107+
<enum name="bottomToTop" value="90" />
108+
<!-- Draw gradient from top to bottom (270 degrees) -->
109+
<enum name="topToBottom" value="270" />
110+
111+
<!-- Draw gradient from top left to bottom right (315 degrees) -->
112+
<enum name="topLeftToBottomRight" value="315" />
113+
<!-- Draw gradient from bottom left to top right (45 degrees) -->
114+
<enum name="bottomLeftToTopRight" value="45" />
115+
<!-- Draw gradient from top right to bottom left (225 degrees) -->
116+
<enum name="topRightToBottomLeft" value="225" />
117+
<!-- Draw gradient from bottom right to top left (135 degrees) -->
118+
<enum name="bottomRightToTopLeft" value="135" />
119+
```

‎Adaptive.md‎

Lines changed: 20 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -24,7 +24,7 @@
2424

2525
* 给 `app:shape_solidGradientOrientation` 和 `app:shape_strokeGradientOrientation` 属性补充了几个布局反方向特性适配的属性值
2626

27-
```
27+
```xml
2828
<!-- 从左到右绘制渐变（0 度） -->
2929
<enum name="startToEnd" value="10" />
3030

@@ -98,22 +98,22 @@
9898

9999
* 拆分 `app:shape_angle` 属性，将原有属性拆分为 `app:shape_solidGradientOrientation` 和 `app:shape_strokeGradientOrientation`，之前的 `app:shape_angle` 属性等于现在的 `app:shape_solidGradientOrientation` 属性，可以直接搜索替换，另外还修改了值的类型，具体赋值可以参考以下：
100100

101-
```xml
102-
<!-- 从左到右绘制渐变（0 度） -->
103-
<enum name="leftToRight" value="0" />
104-
<!-- 从右到左绘制渐变（180 度） -->
105-
<enum name="rightToLeft" value="180" />
106-
<!-- 从下到上绘制渐变（90 度） -->
107-
<enum name="bottomToTop" value="90" />
108-
<!-- 从上到下绘制渐变（270 度） -->
109-
<enum name="topToBottom" value="270" />
110-
111-
<!-- 从左上角到右下角绘制渐变（315 度） -->
112-
<enum name="topLeftToBottomRight" value="315" />
113-
<!-- 从左下角到右上角绘制渐变（45 度） -->
114-
<enum name="bottomLeftToTopRight" value="45" />
115-
<!-- 从右上角到左下角绘制渐变（225 度） -->
116-
<enum name="topRightToBottomLeft" value="225" />
117-
<!-- 从右下角到左上角绘制渐变（135 度） -->
118-
<enum name="bottomRightToTopLeft" value="135" />
119-
```
101+
```xml
102+
<!-- 从左到右绘制渐变（0 度） -->
103+
<enum name="leftToRight" value="0" />
104+
<!-- 从右到左绘制渐变（180 度） -->
105+
<enum name="rightToLeft" value="180" />
106+
<!-- 从下到上绘制渐变（90 度） -->
107+
<enum name="bottomToTop" value="90" />
108+
<!-- 从上到下绘制渐变（270 度） -->
109+
<enum name="topToBottom" value="270" />
110+
111+
<!-- 从左上角到右下角绘制渐变（315 度） -->
112+
<enum name="topLeftToBottomRight" value="315" />
113+
<!-- 从左下角到右上角绘制渐变（45 度） -->
114+
<enum name="bottomLeftToTopRight" value="45" />
115+
<!-- 从右上角到左下角绘制渐变（225 度） -->
116+
<enum name="topRightToBottomLeft" value="225" />
117+
<!-- 从右下角到左上角绘制渐变（135 度） -->
118+
<enum name="bottomRightToTopLeft" value="135" />
119+
```

‎HelpDoc-en.md‎

Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
## FAQ
2+
3+
#### Why does my setXxx call not take effect?
4+
5+
* If you are setting attributes for Shape, shadow, or background state selector, you need to call the `intoBackground` method to take effect.
6+
7+
* If you are setting text color or state selector attributes, you need to call the `intoTextColor` method to take effect.
8+
9+
* If you are setting the icon or state selector attributes for **CheckBox** or **RadioButton**, you need to call the `intoButtonDrawable` method to take effect.
10+
11+
#### What if the framework is too intrusive?
12+
13+
* Many people say that the framework is very intrusive after it went online. I must admit this. I have also seen implementations using `LayoutInflater.Factory` or DataBinding, which are less intrusive, but there is a fatal flaw: you cannot preview in the layout editor. Doesn't that suddenly make it less appealing? High intrusiveness certainly has disadvantages but also advantages. We can't just look at the bad side, otherwise, the view is too one-sided. However, its shortcomings are not fatal. For example, if you use a custom View called `XxxTextView`, you definitely can't use **ShapeTextView** anymore. So what should we do in this case? There are roughly two solutions:
14+
15+
* The first is to use the native Shape to implement it, either by defining it in xml or setting it dynamically in code. Everyone should understand this approach, so I won't elaborate. However, there is a problem: the native Shape does not support setting shadows. If you want to use shadows, you have to use the second approach.
16+
17+
* The second is to use the **ShapeDrawable** class provided by the framework and set it dynamically in Java code. The usage is actually very simple: whichever attribute you use in the layout, use the corresponding method in code.
18+
19+
* Another point to note: if you use **GradientDrawable** or **ShapeDrawable** alone in Java code and involve dashed lines or shadows, it has been verified that on some devices it will not take effect unless you turn off hardware acceleration. Of course, **ShapeDrawable** exposes the **intoBackground** method, which will help you determine whether you need to turn off hardware acceleration.
20+
21+
* Currently, no Shape framework can be perfect. It depends on personal choice. Regardless of pros and cons, while enjoying the advantages of the framework, you also need to tolerate its shortcomings.
22+
23+
#### Can Layout clipping sub-View functionality be added?
24+
25+
* I refuse to do this because the positioning of the framework is very clear: it is only to help everyone write less xml. If you ask me to add a clipping function, is that appropriate? No, it's not appropriate. I personally recommend using Google's **CardView** for clipping sub-Views, and if necessary, you can use it together with **ShapeDrawable**.
26+
27+
#### Can ImageView rounded corner clipping be added?
28+
29+
* For rounded corner clipping of the src in ImageView, first, this attribute belongs to the content of the View, while the framework is for setting the background of the View. Second, even if you want to do clipping, the Shape rounded corner attribute is set to the background Drawable of the View. When it comes to the src of ImageView, how do you distinguish between the two? (Should the rounded corner be applied to the background or the src? What if the background's rounded corner is large and the src's is small?) Some people may say, just add a few more attributes, right? Yes, but the framework will become complicated, and most users may not be able to distinguish between them. I don't think it's necessary. The rounded corner function can be uniformly implemented by Glide. If the framework does it again, it will be redundant.
30+
31+
#### Finally, let me share my opinion
32+
33+
* Finally, let me share my opinion. I think making a good framework does not mean implementing every function. It's not that I can't do it, but whether it's necessary. If you do everything, the framework may eventually become a general store, and even the author may not know what the framework is for. For example, when I made the [TitleBar framework](https://github.com/getActivity/TitleBar), many people asked me to add immersive status bar functionality, but I refused and suggested they use a separate immersive framework. First, let me clarify: what I made is a title bar framework, and immersive status bar is a function that should be provided by an immersive framework. If I break the rule and add immersive status bar functionality, later people will ask me to add immersive bottom navigation bar, and then status bar font color change... If I do all these, will you still use such a framework that binds the title bar and immersive together? Should it be called a title bar framework or an immersive framework? What if someone only wants the title bar function but not the immersive function?
34+
35+
* After hearing this, I believe you can understand my thoughts. I put a lot of thought into making the framework. The time spent refactoring code is far more than writing code. The time spent thinking about problems is far more than refactoring code. Making a good framework is not just about writing code. More importantly, I know what everyone wants and what effects you want. At the same time, I will humbly accept all kinds of suggestions, but likewise, I will refuse all unreasonable requests.

0 commit comments

Comments
 (0)