android:angle=“270”是从上到下来渲染的

<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:android="http://schemas.android.com/apk/res/android">
  <!-- angle 270 means start from top down -->
  <gradient
      android:angle="270"
      android:startColor="@android:color/black"
      android:endColor="@android:color/white"
      />
</shape>

這樣的話,就會是上面為 "black",下面為 "white" 的 drawable 囉

android:angle网上有各种说法,这里,我说说自己的实验结果,渐变的时候,最原始的,即android:angle=“0”时,是从左到右,按照开始颜色到结束颜色来渲染的,android:angle=“90”是从下到上来渲染的,android:angle=“270”是从上到下来渲染的,android:angle=“180”是从右到左来渲染的,android:angle=“360”和android:angle=“0”是一样的,所以这里应该是这样的,渲染时按照最原始的渲染色板(把控件内部看作一块可以绕中心旋转的板子)围绕控件中心来逆时针旋转相应的度数,即android:angle里面的值就是所需要旋转的角度,只是这个旋转角度必须是45的整数倍

介紹

以下大部分內容為 Android MVP Pattern 之筆記。

MVP 模式的核心思想: MVP 把 Activity 中的 UI 逻辑抽象成 View 接口,把业务逻辑抽象成 Presenter 接口, Model 类还是原来的 Model。

Continue Reading →

Menus - Android Developers Guide

Fundamental type

有一些 menu 行為的轉變

  1. Options menu -> app bar

    • Android 3.0 之後,建議轉用 app bar



  2. Floating context menu -> contextual action mode

    • Long-click: 長按元件後的 UI 變化
    • Android 3.0 之後,建議轉用: contextual action mode

  1. Popup menu
    • 不包含第二項所述, 因長按行為而產生的 floating context menu
    • the popup menu is for extended actions that relate to regions of content in your activity.

Implementation

Continue Reading →

想要在螢幕旋轉的時候,做一些操作,請參考

@Override public void onConfigurationChanged(Configuration newConfig) {
    super.onConfigurationChanged(newConfig);

    // Checks the orientation of the screen

    if (newConfig.orientation == Configuration.ORIENTATION_LANDSCAPE) {
        Toast.makeText(this, "landscape", Toast.LENGTH_SHORT).show();
    } else if (newConfig.orientation == Configuration.ORIENTATION_PORTRAIT){
        Toast.makeText(this, "portrait", Toast.LENGTH_SHORT).show();
    }
}

同時,如果 targetSdkVersion >= 13, 需要在 AndroidManifest.xml 針對此 Activity 加入:

android:configChanges="orientation|screenSize"

另外,如果你有使用 layout/layout-land/ 來切換不同的 layout view, 那請記得在 onConfigurationChanged() 中還要 setContentView(layoutResId);:

@Override public void onConfigurationChanged(Configuration newConfig) {
            super.onConfigurationChanged(newConfig);                
            setContentView(R.layout.main);
    ...
    ...
    ...

    }

其它補充

今天突然在想一個問題:

this.mainObject.getA().getAB().getABA().getABAC().doSomething();

像這樣的 Method chaining / chain of getters 是好的作法嗎?

討論串

Drawback

  • NullPointerException: 這很直觀,如果中間有誰回傳 null 就炸了。
  • Law of Demeter

a.b.Method()違反了此定律,而a.Method()不違反此定律。一個簡單例子是,人可以命令一條狗行走(walk),但是不應該直接指揮狗的腿行走,應該由狗去指揮控制它的腿如何行走。

不過其中一段我蠻贊同的

the law of demeter doesn't apply in purely data/structural (ie "struct like") relationships. IE Student.GetAddress().GetStreetName() is perfectly acceptable.

也就是說,如果這只是一連串的 getters 的話,那沒有什麼問題;但如果涉及到 mutators 如 Student.GetLastTest().ChangeGradeToA(),那就不行了。

the Law only applies when mutators are involved.

Benefit

this.mainObject.getA().getAB().getABA().getABAC().doSomething();

v.s.

A A = this.mainObject.getA();
AB AB = A.getAB();
ABA ABA = AB.getABA();
ABAC ABAC = ABA.getABAC();
ABAC.doSomething();

其它

額外參考: [Android] AppBar, Toolbar 設定大全

Translucent Status Bar

<style name="Theme.MyTheme" parent="Theme.MyTheme.Base">
        <item name="android:windowTranslucentStatus">true</item>
        <item name="android:windowTranslucentNavigation">true</item>
</style>

Fullscreen

<style name="Theme.AppCompat.Light.NoActionBar.FullScreen" parent="@style/Theme.AppCompat.Light">
    <item name="windowNoTitle">true</item>
    <item name="windowActionBar">false</item>
    <item name="android:windowFullscreen">true</item>
    <item name="android:windowContentOverlay">@null</item>
</style>
Copyright © 2013 Andro Chen
Powered by Logdown and Greyshade
Favicon from The Noun Project