android.R.attr 참조를 이용하여

현재 theme의 리소스 정보 얻어오기..


TypedArray a = getTheme().obtainStyledAttributes(new int[] {  
    android
.R.attr.windowBackground
});
Drawable backgroundDrawable = a.getDrawable(0);
a
.recycle();
TypedArray a = getTheme().obtainStyledAttributes(new int[] {  
    android
.R.attr.colorBackground,
    android
.R.attr.textColorPrimary,
});
int backgroundColor = a.getColor(0, 0);
int textColor = a.getColor(1, 0);
a
.recycle();

Posted by 바나나쥬스

댓글을 달아 주세요

첫번째.


DialogFramgment 를 사용할때 setRetainInstance(true) 를 적용하여 사용하면

orientation 변경등 configuration 이 변경되어 activity 가 재생성이 되었을때 DialogFramgent 가 다시 나타나지 않고 사라지는 문제가 있다. 


http://stackoverflow.com/questions/12433397/android-dialogfragment-disappears-after-orientation-change


이는 아래와 같은 workaround 로 해결 가능하다. 


@Override

public void onDestroyView(){

if (getDialog() != null && getRetainInstance()) {

getDialog().setDismissMessage(null);

}

super.onDestroyView();

}



두번째. 


DialogFragment 가 화면상에 떠있는동안 home 을 눌러 화면에서 사라지게 한다.

그런 상태에서 DialogFragment 의 dismiss 가 호출되면 다음과 같은 에러가 발생한다. 

화면에서 사라지면서 onSaveInstanceSate가 호출된 상태에서 resume 되지 않고 dismiss를 하면 발생하게 된다. 


E/AndroidRuntime(19229): java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState

E/AndroidRuntime(19229): at android.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1323)

E/AndroidRuntime(19229): at android.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1341)

E/AndroidRuntime(19229): at android.app.BackStackRecord.commitInternal(BackStackRecord.java:597)

E/AndroidRuntime(19229): at android.app.BackStackRecord.commit(BackStackRecord.java:575)

E/AndroidRuntime(19229): at android.app.DialogFragment.dismissInternal(DialogFragment.java:292)

E/AndroidRuntime(19229): at android.app.DialogFragment.dismiss(DialogFragment.java:258)


이 경우에는 

dismiss를 호출하지 않고 

dismissAllowingStateLoss() 로 종료해주면 된다. 

개인적으로 dismissAllowingStateLoss() 를 사용하고 싶지 않은데 

dismiss는 어차피 명시적으로 호출해 주는 것이고 확실히 종료시킨다는 의미이므로 써도 상관없을것 같다.


그런데 commit() 도 마찬가지 인데 이에 대한 처리는 좀 신중해야 할것으로 보인다.

참고 : http://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html 




Posted by 바나나쥬스

댓글을 달아 주세요

  • 배경을 nine-patch 를 쓸때는 padding 값 지정은 하지 않도록 한다
    • nine-patch 자체가 padding을 고려하여 만든 이미지
    • padding을 적용하면 nine-patch 의 content영역은 무시하고 padding값 우선 적용됨
  • nine-patch 이미지는 서로 overlay가 되지 않는다
    • layer-list 로 설정된 drawable이 모두 nine-patch 인 경우 서로 overlay가 되지 않고 먼저 설정한 nine-patch의 content 영역에 두번째로 설정된 nine-patch 가 들어가게 되고 두번째로 설정된 nine-patch의 content 영역에 text와 같은 content가 위치하게 된다.
  • Fragment 를 inner class로 정의할때는 무조건 public static 이어야 한다. 


Posted by 바나나쥬스

댓글을 달아 주세요

app이 Theme.Holo.Light.DarkActionBar 테마를 사용하는 경우

기본적으로는 Holo.Light 테마 이지만 ActionBar만 Holo(Dark) 테마가 적용되게 된다. 


따라서 ActionBar위에 붙는 widget들 (ListMenuItemView, IconMenuView, overflow popup등) 은 알아서 처음에 actionbar가 구성될때 Holo(Dark) 테마로 설정되어 검정계통의 스타일을 얻게 된다.

그리고 그외 activity 내에 붙는 widget들은 모두 Holo.Light 테마로 생성되게 된다. 


하지만 widget을 Holo.Light가 아닌 Holo(Dark)로 생성하고 싶다면

이미 잘 알고 있듯이 Theme 를 정의할때 style을 적용해 주면 된다.


<style name="MyTheme" parent="@android:style/Theme.Holo.Light.DarkActionBar">

      <item name="android:checkboxStyle">@android:style/Widget.Holo.CompoundButton.CheckBox</item>

</style>


하지만 이 방법은 app의 모든 CheckBox가 Holo(Dark)로 생성이 된다.


그래서 어떤 CheckBox는 Holo.Light이고 어떤 CheckBox는 Holo(Dark)이고..

이렇게 다르게 생성하려면 어떻게 해야할까??


android 소스를 뒤져서 드뎌 찾아냈다 -ㅅ-!


TypedValue outValue = new TypedValue();          

Resources.Theme currentTheme = getTheme();

currentTheme.resolveAttribute(android.R.attr.actionBarWidgetTheme, outValue, true);

final int targetThemeRes = outValue.resourceId;

ContextThemeWrapper themedContext = new ContextThemeWrapper(this, targetThemeRes);

CheckBox darkCheckBox = new CheckBox(themedContext);


android 소스의 themes.xml을 보면 

actionBarWidgetTheme가 Theme.Holo로 정의되어 있는 것을 볼수 있다. 


<style name="Theme.Holo.Light.DarkActionBar">

        <item name="android:windowContentOverlay">@android:drawable/ab_solid_shadow_holo</item>

        <item name="android:actionBarStyle">@android:style/Widget.Holo.Light.ActionBar.Solid.Inverse</item>

        <item name="actionBarWidgetTheme">@android:style/Theme.Holo</item>

           ......


따라서 android.R.attr.actionBarWidgetTheme 값을 얻어와서 그곳에 적용된 style대로 widget을 생성하는 것이다. 


더 나아가서는 새로 attr정의해서 원하는 style 정의해서 사용하면 더 확장해서 사용할수 있을듯!

아직 테스트해보진 않았지만 -ㅅ-!






Posted by 바나나쥬스

댓글을 달아 주세요

  1. BlogIcon Chan 2013.07.23 12:37  댓글주소  수정/삭제  댓글쓰기

    =_=
    어려워.

  2. BlogIcon 바나나쥬스 2014.05.02 10:49 신고  댓글주소  수정/삭제  댓글쓰기

    지금보니 저 방법 말고 걍 dark 테마로 넣어서 만들면되는데... 아마 attr 쓸려고 저걸 찾았던것 같네;;;

한국어 단어를 한자로 변환하면 대체로 일본에서 사용하는 단어가 되지만

그대로 변환했다가 "응? 무슨 말이지" 하고 

일본에서는 안쓰는 단어인 경우가 있을수 있다 

그런것 그때그때 정리해봄..


예로 

약속은 그대로 한자로 변환하면 約束 (약속)으로 일본에서 사용하는 단어 그대로 됨

하지만 교복같은 경우는 한자그대로 변환하면 校服(교복)이 되는데 일본에서는 

校服(교복)을 사용하지 않고 制服(제복) 으로 사용한다

즉 요런 것들 정리.. 



한국어-일본어


교복 - 制服 (제복)
통금 - 門限

환율 - かわせレート(為替レート)

환전 - 為替ーかわせ

이직 - 転職 (전직) : 직장을 옮김






* 자동차 분류


소형차

- 한국 : 모닝, 스파크 등의 경차

- 일본 : 


중형차

- 한국 :  일반 크기 자동차 -ㅅ-;;

- 일본 :


대형차 

- 한국 : 비싼 자동차 cc 가 큰거

- 일본 : 트럭, 버스

Posted by 바나나쥬스

댓글을 달아 주세요

http://nex-otaku-en.blogspot.kr/2010/12/android-put-listview-in-scrollview.html


listView의 높이를 계산해서 지정해줌으로써 listView내의 scroll은동작안하고 

scrollview의 scroll만 동작하게함


http://nex-otaku-en.blogspot.kr/2010/12/android-put-listview-in-scrollview.html?showComment=1321617812648#c2502974534979822768


이 사람 댓글처럼 

listItem.measure(0, 0);

으로 해주는것이 더잘됨


    

 public static void setListViewHeightBasedOnChildren(ListView listView) {

        ListAdapter listAdapter = listView.getAdapter();

        if (listAdapter == null) {

            // pre-condition

            return;

        }


        int totalHeight = 0;

        for (int i = 0; i < listAdapter.getCount(); i++) {

            View listItem = listAdapter.getView(i, null, listView);

            listItem.measure(0, 0);

            totalHeight += listItem.getMeasuredHeight();

        }


        ViewGroup.LayoutParams params = listView.getLayoutParams();

        params.height = totalHeight + (listView.getDividerHeight() * (listAdapter.getCount() - 1));

        listView.setLayoutParams(params);

        listView.requestLayout();

 }


       

Posted by 바나나쥬스

댓글을 달아 주세요

Fragment에 setRetainInstance(true) 를 설정하면 

onSaveInstanceState(Bundle) 에 설정해준것을 사용하지 않는다 

onActivityCreaded(Bundle) 에서 항상 null을 리턴함


http://stackoverflow.com/questions/9405577/why-isnt-my-fragments-onsaveinstancestate-being-called?answertab=active#tab-top



setRetainInstance(false) 일때 회전시킨경우 

-객체 새로 생성됨

onCreate

onCreateView

onActivityCreated

호출됨


setRetainInstance(true) 일때 회전시킨경우

- 객체 유지함, 따라서 모든 필드값 유지됨

onCreateView

onActivityCreated 

호출됨

- view는 그래도 새로 생성됨



Posted by 바나나쥬스

댓글을 달아 주세요

  1. BlogIcon Chan 2013.07.23 12:35  댓글주소  수정/삭제  댓글쓰기

    헉. Fragment 찾다가 여기로!!!!

Android - Tasks and Back Stack (1) 에 이어 그다음 내용부터 

http://developer.android.com/guide/components/tasks-and-back-stack.html#ManagingTasks


역시나 내맘대로 정리 보는사람 음스므로 음슴체 


<Managing Tasks>


- 이전에 설명했던 android의 task, back stack관리는 대부분의 app에 잘 동작함

- 개발자가 activity들이 back stack에 어떻게 존재하는지 task랑 어떤 연관을 가지고 동작하는지 같은 것에 대해 고민하지 않아도 됨

- 그래도 개발자는 이런 기본적인 동작을 하고 싶지 않을수도 있음 

- 한 activity를 현재 task에 속하게 하지 않고 새로운 task로 시작하게 하고 싶거나

- 이미 생성되어 있는 activity의 instance를 그대로 사용하면서 맨 위로 올리고 싶거나

- task를 떠날때 back stack에서 clear시키고 싶을수 있음

- 이러한 것을 manifest 파일의 <activity> 에서 정의해 줄수 있음


* <activity>에 정의해주는 속성 

- taskAffinity

- launchMode

- allowTaskReparenting

- clearTaskOnLaunch

- alwaysRetainTaskState

- finishOnTaskLaunch


* intent의 flag로 설정해 주는거 (startActivity() 할때)

- FLAG_ACTIVITY_NEW_TASK

- FLAG_ACTIVITY_CLEAR_TOP

- FLAG_ACTIVITY_SINGLE_TOP


<Using the manifest file>

- <activity> 의 속성으로 넣어주는거 하나씩 보겠음

* launchMode

- standard 

   - default임, 앞에서 계속 설명한거와 같은 동작, 새 instance생성해서 task의 top으로 올림

- singleTop 

   - activity가 이미 task의 top에 있으면 새 instance를 생성하지 않고 그 activity의 onNewIntent()를 호출함 

   - top에 없으면 새 instance 생성하여 task의 top으로 올림

   - 예를들면

   - A-B-C-D (D가 top에 있음) 인 task가 있음

   - activity D를 실행하라는 intent가 들어옴

   - activity D의 launchMode가 standard인 경우 activity D의 새 instance를 생성함 따라서 A-B-C-D-D가됨

   - activity D의 launchMode가 singleTop인 경우 activity D는 stack의 top에 있으므로 top에 있는 activity D의 onNewIntent()를 호출함

   - 그래서 stack은 그대로 A-B-C-D 가됨

   - 그런데 activity B를 실행하는 intent가 들어오는 경우

   - activity B의 launchMode가 singleTop 으로 설정되어 있어도 activity B의 새 instance가 생성되고 stack에 추가됨

   - 그래서 stack은 A-B-C-D-B 가됨

- singleTask

   - 시스템은 새 task를 만들고 새로 생성된 activity를 root로 둠 (근데 밑에 그림 보면 root가 아님.. 설명을 위해서인가?)

   - 그런데 다른 task에 activity의 instance가 있으면 새로 instance를 만들지 않고 그 activity의 onNewIntent()를 호출함

   - 그리고 그 activity가 있는 task를 foreground로 가져옴

   - 결국 activity는 instance 1개만 있음

- singleInstance

   - task에 오직 하나의 activity만 가짐

   - 다른 activity들을 task에 두지 않음

   - 그외 singleTask랑 같음


- 밑에 그림으로 singleTask 더 살펴봄

   Figure 4 설명 .

   - Activity Y 가 singleTask로 설정되어있음 

   - Activity 2 가 activity Y를 실행시킴 

   - Activity Y 가 singleTask이므로 이미 있는 activity Y가 속해 있는 task가 foreground로 올라오고 activity Y의 onNewIntent()가 호출됨

     (Activity Y 가 다른 task에없었으면 새로 다른 task에 생성되서 들어가게됨) 


  * (번외) 근데 여기서 activity 2가 activity X를 실행시키면 어떻게 될까??? 

   - activity X는 top이 아닌데 말이쥐

   - 사실 singleTask로 되어있는 activity는 task의 root가 되니까 위 그림과 같이 될수 없는데...어?

   - 직접해볼라니 좀 귀찮아서 일단 구글링 

   - http://stackoverflow.com/questions/6268646/android-question-about-singletask-mode?answertab=active#tab-top 

   - 위 링크에 답변한 사람 dbalaouras 아저씨의 이론대로 설명하면

   - activity X 가 불리면 activity Y는 destroy되고 activity X 가 top으로 옴

   - 위 그림으로 보면 세번째 상태로 바로 간다는 거임 - 그럴거 같음

   - 언젠가 테스트해보겠음.. 귀찮지만...


- 다시 본론으로 

- launchMode 속성은 intent flag값에 의해 overrided 될수 있음 (무시될수 있음)

 * 이부분 테스트해서 정리좀 해야할듯.. 

launchMode설정상태에서 flags넣어 실행하는거 case별로.. 언젠가 -ㅅ-


<Using Intent Flags>

- activity 실행할때 넘겨주는 Intent에 flags를 줄수있음

- FLAG_ACTIVITY_NEW_TASK

   - singleTask와 같음

   - 귀찮지만 다시 설명하면

   - 새로운 task로 activity를 실행시킴

   - 어딘가 activity가 있으면 그 task가 foreground로 나오고 기존의 activity의 onNewIntent()가 호출됨

- FLAG_ACTIVITY_SINGLE_TOP

   - singleTop과 같음

   - activity가 top에 있을 경우만 그 activity의 onNewIntent()가 호출됨, top에 없으면 새로 만듬

- FLAG_ACTIVITY_CLEAR_TOP

   - 실행하려는 activity가 현재 task(current task)에 있으면 새 instance를 생성하지 않고 그 activity위에 있는 activity들을 다 destroy 시키고 실행하려는 activity를 top으로 가져오고 onNewIntent()를 호출함


  *(번외) 그럼 다른 task에 있으면 다르나???? 왜 current task라고 적혀있는거지????? 

   - 이건잠시 보류


   - FLAG_ACTIVITY_CLEAR_TOP flag는 주로 FLAG_ACTIVITY_NEW_TASK랑 같이 쓰임

   - 그러면 기존의 다른 task에 있는 activity를 새 task에 가져올수 있게됨 (이거 해석 다시 해봐야겠다능)

   - 이 플래그로 실행하려는 activity의 launchMode가 standard이면 그 activity도 stack에서 지워지고 새 instance가 생성되어 stack에 들어감

   - 왜냐면 standard는 항상 새로 만들어야 옵션이니까


<Handling affinities>

- affinity는 activity가 어느 task에 속하게 할지 정해줌

- 기본적으로 같은 app의 모든 activity들은 각각의 affinity를 가질수 있음

- 기본적으로 같은 app의 모든 activity들은 같은 task에 속하게됨

- 근데 이 정보를 고칠수 있음

- 다른 app에 있는 activity들이 affinity 를 공유할수 있음

- 그리고 같은 app에 있는 activity들이라도 서로 다른 task에 속할 수 있음

- <activity> 의 taskAffinity 속성값에 정의해줌 
- affinity 동작의 두가지 경우

   * FLAG_ACTIVITY_NEW_TASK flag가 있는 intent로 activity가 실행되는 경우 

      - 기본적으로 새로 생성되는 activity는 startActivity()를 호출한 activity가 속한 task에 속하게 됨

      - 근데 FLAG_ACTIVITY_NEW_TASK flag가 있는 intent로 실행되면 시스템은 새 task에 activity를 포함시킴 (앞에 FLAG_ACTIVITY_NEW_TASK 설명한 그대로임) 

      - 근데 affinity가 정의되어 있으면 같은 affinity를 가진 task를 찾아서 그 task로 들어가게됨 

   * activity가 allowTaskReparenting=true 로 설정되어 있는경우 

      - activity는 시작된 task에서 같은 affinity를 가진 task로 옮겨감

      - 예를들어

      - 여행 app에서 지정된 지역의 날씨를 보여주는 activity가 있는경우 (이 activity에 allowTaskReparenting=true설정)

      - 기본적으로 날씨 activity는 여행 app에 있는 다른 activity들과 같은 affinity를 가짐

      - 여행 app이 아닌 다른 app의 activity에서 날씨 activity를 실행한경우 날씨 activity는 실행시킨 activity의 task에 가게됨

      - 그런데 여행 app이 foreground로 나오면 날씨 activity는 다시 affinty가 같은 여행 app의 task로 돌아감


<Clearing the back stack>

- 사용자가 장시간 task를 떠나 있으면 시스템은 root activity를 제외하고 task의 activity들을 clear시킴

- 사용자가 다시 task로 돌아오면 root activity만 남아있음

- 이러는 이유는 사용자가 오랜 시간이 지난후 돌아왔다는것은 전에 뭘하고 있었는지는 관계없이 다시 새로운 것을 시작하기 위해 온것이기때문

- alwaysRetainTaskState

   - root activity에 true로 설정되어 있으면 task의 오랜 시간지나도 모든 activity를 유지함 

- clearTaskOnLaunch

   - root activity에 true로 설정되어 있으면 사용자가 task를 떠나고 돌아올때마다 task를 clear시킴

   - alwaysRetainTaskState의 반대가됨

   - 사용자가 task에 돌아올때는 항상 초기 상태가 됨

- finishOnTaskLaunch

   - clearTaskOnLaunch 이랑 비슷한데 이건 task 전체에 해당하는게 아니라 하나의 activity에만 해당됨

   - root activity뿐만아니라 어떤 activity이든 사라질수 있게 되는거임

   - true로 설정되어 있으면 activity는 현재 session만을 위해 task에 있게 되는거임 

   - 사용자가 task를 떠났다가 돌아오면 없다능 

 

<Starting a task>

- activity의 intent-filter에 아래와 같이 적어주면 task의 entry point로 설정할수 있음

<activity ... >
    <intent-filter ... >
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
    ...
</activity>

- 위와 같은 intent-filter는 activity 런처에 아이콘과 label로 표현됨

- 사용자는  activity 런처를 통해서 task를 떠나고 task로 돌아오고 할수 있어야 함

- 앞에서 배운 activity launchMode중에 singleTask, singleInstance는 처음 새 task에서 시작됨

- 그래서 이 두 launchMode는 activity가 ACTION_MAIN, CATEGORY_LAUNCHER filter를 가졌을때만 사용해야 함

- 이 filter가 없는 activity A 를 singleTask로 실행시키면 일단 singleTask이므로 새 task로 실행됨

- 그리고 사용자가 홈 버튼을 누름

- activity A가 있는 task는 background로 감 

- 근데 더이상 activity A가 있는 task를 가져올 방법이 없음, 런처가 없으니까

(번외) 근데 이건 activity가 어떻게 런치되는가에 따르니까.. 런처 말고는 실행할 방법이 없는 activity에만 해당된다고 생각

- 사용자가 다시는 activity A 에 돌아오지 못하고 하고 싶은경우에는 finishOnTaskLaunch를 true로 설정하면됨


------------------------------------------------------------------

음 근데 최근엔 recent menu도 있고 한데..

거기에 대한 언급은 하나도 없네 어?

너무 이 기술문서만 믿어도 안될듯 하는 주관적인 내생각 ㅋ



Posted by 바나나쥬스
TAG android

댓글을 달아 주세요

http://developer.android.com/guide/components/tasks-and-back-stack.html


위 내용을 내맘대로 정리

보는사람 음스므로 음슴체


<Tasks and Back Stack>


- application은 여러개의 activity를 가짐 

- activity는 다른 app의 activity를 실행시킬수 있음

- 어떤 하나의 job을 수행했을때 사용자와 상호작용하는 activity들의 모임 -> task

- 이 activity들은 back stack이라 불리는 stack에 오픈된 순서대로 배열됨

- home 화면은 대부분의 task의 start 지점이 됨

- 사용자가 app런처 아이콘 또는 홈화면의 shortcut을 클릭해서 실행하면 그 app의 task가 앞으로 나오게 됨

- app의 task가 최근에 사용된 적이 없으면 새 task가 생성되고 그 app의 main activity가 task의 root가 됨


- 현재 앞에 있는 activity A 가 다른 activity B 를 실행시킴 

- 실행된 activity B는 stack의 top으로 가고 focus를 가지게 됨

- 이전 activity A는 stack에 남아있게 되고 stop됨 

- activity가 stop되면 시스템은 ui 상태를 유지함

- 사용자가 back 버튼을 누르면 stack의 top에 있던 activity B는 pop되고 destroy됨

- 앞에 있던 activity A가 resume되고 ui 상태 복구됨

- task안에 있는 activity들은 결코 재배치 되지 않음

- 오직 stack의 last in, first out의 원칙에 따라 push, pop될뿐임


Figure 1. activity가 back stack에 들어가고 빠지고 하는거 



- 사용자가 계속 back 버튼을 누르면 홈 화면에 갈때까지 stack안에 있는 있는 activity들은 차례로 pop됨

- stack에서 모든 activity가 제거되면 task는 더이상 없는게 됨


- task는 결합된 단위임(뭔소린지 모르겠으니 영어원문 : a cohesive unit)

- 사용자가 다른 새 task를 시작하거나 홈으로 가면 기존에 foreground에 있던 task는 background로 옮겨짐

- background에 있는동안 그 task에 있는 모든 activity들은 당근 stop상태

- back stack은 task들을 온전히 유지시킴

- task는 다른 task가 foreground에 있을 동안 단지 포커스를 잃을뿐


Figure 2. 두개의 task - task B는 foreground 에서 사용자랑 샤바샤바 하고 있고 그동안 task A는 background에서 resume되길 기다릴뿐..


- 사용자가 background에 있는 task를 pick up하면 당연 foreground로 옴

- 예를들어

- 현재 3개의 activity를 가진 task A가 있음

- 사용자가 홈버튼을 누르고 다른 app을 실행시킴

- 시스템은 새로 실행된 app의 새 task B를 시작시킴 

- 다시 홈으로 와서 task A로 실행되어 있는 app을 실행시킴

- 그럼 당근 task A가 foreground로 옴

- 그러니 task A에 있는 3개의 activity는 stack의 top으로 오고 resume됨 (당연 젤 위에 있는 activity만 resume됨)

- 여기서 사용자는 다시 홈으로 가서 task B의 app 을 시작할수 있음 

- 이것이 multi tasking임 


- 여기서 한번더 강조 back stack에 있는 activity들은 재배열 될 수 없음 (즉 중간에 있던 activity가 top으로 온다거나 못함) 

- 사용자가 한 activity를 실행시키면 새 instance가 생성되고 stack의 top으로 들어감

- app의 activity는 여러 시점에서 instance화 될수 있음 (multiple instances)

- 같은 activity가 각각 여러개의 instance로 생성되서 각각 다른 상태로 stack에 쌓일 수 있음

- 그런데 여러 instance로 되게 하기 싫으면 설정 수정하면됨 


Figure 3. 하나의 activity는 여러번 instance화 됨


* activity와 task의 기본 동작 다시 정리 

- activity A가 activity B를 실행시키면 activity A는 stop됨

- 시스템은 stop된 activity A의 상태들(스크롤 포지션이라던가 폼에 입력되어있는 text라던가)을 유지함

- activity B가 앞에 있는 상태에서 사용자가 back버튼을 누르면 activity A가 resume됨

- 사용자가 홈 버튼을 눌러서 task를 빠져나오면 수행되고 있던 activity는 stop되고 task는 background로 감

- 시스템은 task내의 모든 activity들의 상태를 유지함 

- 사용자가 app런처 아이콘 눌러서 다시 실행시키면 그 app의 task는 resume되고 foreground로 옴

- stack의 top에 있던 activity도 resume됨

- 사용자가 back버튼을 누르면 실행되고 있던 activity는 stack에서 pop되고 destroy됨

- 이전의 activity가 resume됨

- activity가 destroy될때는 시스템은 activity의 상태 저장하지 않음

- activity는 다른 task에서 여러번 instance화 될 수 있음 


---------------------------------------------------

Saving Activity State는 넘어감

Managing Tasks랑 나머진 담 포스트에.. 헥헥



Posted by 바나나쥬스
TAG android

댓글을 달아 주세요

http://developer.android.com/tools/building/index.html


android project 는 .apk로 패키징 되는데 

.apk는 

클래스파일을 dalvik byte code로 변환한 .dex 파일과

AndroidManifest.xml 의 바이너리버전

컴파일된 리소스 resources.arsc 

컴파일되지 않은 리소스 파일이 들어있다 


빌드과정은


1. aapt (Asset Packaging Tool)

 - 리소스를 보고 R.java 생성

 - AndroidManifest.xml이나 XML파일들을 컴파일


2. aidl tool 

 - .aidl 파일을 java interfaces 로 만들어줌 


3. java compiler

 - aapt로 생성된 R.java, aidl로 생성된 java interfaces, 그리고 작성한 소스코드를

   컴파일해서 .class 파일로 만들어줌 


4. dex 

 - .class 파일들과 3rd party libraries 클래스파일들을 모두 .dex 파일로 만듬


5. apkbuilder

 - 1번에서 생성된 컴파일된 리소스와 4번에서 생성된 .dex 파일과 그외 리소스들을 패키징함

 - .apk 파일 생성


6. jarsigner 

 - debug 또는 release 용 keystore로 sign

 - sigend .apk가 됨 


7. zipalign (release mode) 

 - 릴리즈 모드로 sign하면 이거 zipalign 해야함



* proguard 는 3번과 4번 사이. 

proguard관련 링크

http://developer.android.com/tools/help/proguard.html

http://www.androidengineer.com/2010/07/optimizing-obfuscating-and-shrinking.html

http://code.google.com/p/maven-android-plugin/wiki/ProGuard

http://proguard.sourceforge.net/



* 여담

ant build 작성은 귀찮아 ㄷㄷ


Posted by 바나나쥬스

댓글을 달아 주세요