Kyle's Life Lab

@Override
	public void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		requestWindowFeature(Window.FEATURE_NO_TITLE);
		setContentView(R.layout.activity_main);

		Log.e("온크리에이트", "입니다.");

		if(getSupportFragmentManager().findFragmentByTag("listfra") == null){
			FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
			ListViewFragment lvf = new ListViewFragment();
			ft.add(R.id.menu, lvf, "listfra");
			ft.addToBackStack(null);
			ft.commit();
			
		}

	}

fragment 코드들을 보다보면 이렇게 onCreate안에 fragment 를 추가해주는 코드들을 볼수 있는데 저렇게 처음부터 null인지 체크를 한다. 이것은 이 액티비티가 처음 실행되었을 때가 아닌 다음번에 실행했을 때를 대비한 코드다. fragment가 이미 생성되어있다면 같은 fragment를 manager에 커밋할필요가 없기때문에 없는 경우에만 프래그먼트를 만들게 한다. 그렇지 않으면 중복해서 만들어서 표시하게된다.

MainActivity.java

package com.example.hellotabfragment;

import java.util.HashMap;

import android.content.Context;
import android.os.Bundle;
import android.support.v4.app.Fragment;
import android.support.v4.app.FragmentActivity;
import android.support.v4.app.FragmentTransaction;
import android.util.Log;
import android.view.View;
import android.widget.TabHost;

import com.example.hellotabfragment.fragment.Fragment1;
import com.example.hellotabfragment.fragment.Fragment2;
import com.example.hellotabfragment.fragment.Fragment3;

/**
 * This demonstrates how you can implement switching between the tabs of a
 * TabHost through fragments.  It uses a trick (see the code below) to allow
 * the tabs to switch between fragments instead of simple views.
 */
public class MainActivity extends FragmentActivity {
    TabHost mTabHost;
    TabManager mTabManager;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_main);
        mTabHost = (TabHost)findViewById(android.R.id.tabhost);//Container for a tabbed window view.
        mTabHost.setup();

        mTabManager = new TabManager(this, mTabHost, R.id.realtabcontent);// tab host와 탭을 눌렀을때 바뀌어야하는 부분의 id
        mTabManager.addTab(mTabHost.newTabSpec("simple").setIndicator("Simple"), Fragment1.class, null);	//새로운 탭을 만든다.
        //tabspec -> A tab has a tab indicator, content, and a tag that is used to keep track of it
        mTabManager.addTab(mTabHost.newTabSpec("contacts").setIndicator("Contacts"), Fragment2.class, null);
        mTabManager.addTab(mTabHost.newTabSpec("custom").setIndicator("Custom"), Fragment3.class, null);


        if (savedInstanceState != null) {
            mTabHost.setCurrentTabByTag(savedInstanceState.getString("tab"));	// 방향 전환 전에 선택된 탭이 있다면 가져와서 설정
        }
    }

    @Override
    protected void onSaveInstanceState(Bundle outState) {
        super.onSaveInstanceState(outState);
        outState.putString("tab", mTabHost.getCurrentTabTag());	// 방향 전환될때 넣어준다.
        Log.e("tab", mTabHost.getCurrentTabTag());
    }

    /**
     * This is a helper class that implements a generic mechanism for
     * associating fragments with the tabs in a tab host.  It relies on a
     * trick.  Normally a tab host has a simple API for supplying a View or
     * Intent that each tab will show.  This is not sufficient for switching
     * between fragments.  So instead we make the content part of the tab host
     * 0dp high (it is not shown) and the TabManager supplies its own dummy
     * view to show as the tab content.  It listens to changes in tabs, and takes
     * care of switch to the correct fragment shown in a separate content area
     * whenever the selected tab changes.
     */
    public static class TabManager implements TabHost.OnTabChangeListener {
        private final FragmentActivity mActivity;	//context
        private final TabHost mTabHost;
        private final int mContainerId;	
        private final HashMap mTabs = new HashMap();	// tag기준으로 tab에대한 정보가 들어있다.
        TabInfo mLastTab;

        static final class TabInfo {
            private final String tag;
            private final Class clss;
            private final Bundle args;
            private Fragment fragment;

            TabInfo(String _tag, Class _class, Bundle _args) {
                tag = _tag;
                clss = _class;
                args = _args;
            }
        }

        static class DummyTabFactory implements TabHost.TabContentFactory{ // Makes the content of a tab when it is selected. 
        	// 굳이 필요 없어 보이는 듯
            private final Context mContext;

            public DummyTabFactory(Context context) {
                mContext = context;
            }

            @Override
            public View createTabContent(String tag) {
                View v = new View(mContext);
                v.setMinimumWidth(0);
                v.setMinimumHeight(0);
                return v;
            }
        }

        public TabManager(FragmentActivity activity, TabHost tabHost, int containerId) {
            mActivity = activity;
            mTabHost = tabHost;
            mContainerId = containerId;
            mTabHost.setOnTabChangedListener(this);
        }

        public void addTab(TabHost.TabSpec tabSpec, Class clss, Bundle args) {	// tab추가하기
            tabSpec.setContent(new DummyTabFactory(mActivity));
            String tag = tabSpec.getTag();

            TabInfo info = new TabInfo(tag, clss, args);	// 그닥 필요없어 보이긴함

            // Check to see if we already have a fragment for this tab, probably
            // from a previously saved state.  If so, deactivate it, because our
            // initial state is that a tab isn't shown.
            info.fragment = mActivity.getSupportFragmentManager().findFragmentByTag(tag);	//tag로 프래그먼트 찾아서 넣어준다.
            if (info.fragment != null && !info.fragment.isDetached()) {	//frament가 null이아니고 떨어져있지 않으면 떼준다.
            	
                FragmentTransaction ft = mActivity.getSupportFragmentManager().beginTransaction();
                ft.detach(info.fragment);
                ft.commit();
            }

            mTabs.put(tag, info);	//자료형에 넣어준다. 이것도 불필요함
            mTabHost.addTab(tabSpec);	// 탭호스트에 실제로 탭을 넣어준다.
        }

        @Override
        public void onTabChanged(String tabId) {
            TabInfo newTab = mTabs.get(tabId);	// 넣어놨던 tabinfo찾아온다.
            if (mLastTab != newTab) {//라스트탭이 뉴탭과 같지 않다면
                FragmentTransaction ft = mActivity.getSupportFragmentManager().beginTransaction();
                if (mLastTab != null) {	//라스트탭이 널이 아니면
                    if (mLastTab.fragment != null) {	//라스트탭의 프래그먼트가 널이 아니면
                        ft.detach(mLastTab.fragment);	//떼어낸다
                    }
                }
                if (newTab != null) {	// 뉴탭이 널이 아니면
                    if (newTab.fragment == null) {	//프래그먼트가 널이면
                        newTab.fragment = Fragment.instantiate(mActivity,
                                newTab.clss.getName(), newTab.args);//새로 만들어준다
                        ft.add(mContainerId, newTab.fragment, newTab.tag);	//추가해준다
                    } else {
                        ft.attach(newTab.fragment);	//널이 아니면 그대로 붙여준다.
                    }
                }

                mLastTab = newTab;	//새로운탭이 라스트탭이 된다.
                ft.commit();
                mActivity.getSupportFragmentManager().executePendingTransactions();
            }
        }
    }
}

개인적인 생각으로 Fragment는 객체화시킬수 있는 서브 액티비티라는 생각이다. 

액티비티자체는 객체화 시킬수 없어 사용에 불편함이 있다. 

그러나 프래그먼트는 객체화가 가능하여 유연성있게 사용할 수 있다. 그리고 단독으로는 사용할 수 없다. 액티비티안에 사용할 수 있다.

액티비티 끼리는 인텐트를 주고받지만 프래그먼트는 argument로 값을 주고 받는다.

그런데 프래그먼트를 생성할때마다 Bundle을 만들어 아규먼트를 전달 받고 전달하는 것은 낭비라는 생각이 들어 메소드를 만든다.

static TextFragment newInstance(String _msg){
		TextFragment tf = new TextFragment();
		Bundle bundle = new Bundle();
		bundle.putString("msg", _msg);
		tf.setArguments(bundle);

		return tf;
	}

	public String getMsg(){
		if(getArguments().getString("msg")!=null){
			return getArguments().getString("msg");
		}
		return "msg";
	}

이런 식으로 메소드를 만들고 실제로 Fragment 객체를 생성할때는 new가 아닌

TextFragment tf = TextFragment.newInstance(((TextView)v).getText().toString());

이런 식으로 메소드를 호출하여 사용한다.

new로 생성하는 것외에 Fragment 에서 자체적으로 지원해주는 메소드도 있다. new로 생성하는 것과 차이는 없지만

인스턴스화가 실패했을 경우 에러 처리를 해준다.

전부터 궁금했던것 Override를 하였을때 부모의 원메소드를 호출할때 super를 사용한다.

그런데 super를 먼저 사용하기도 하고 나중에 사용하기도 한다. 

안드로이드 경우 보통 생명주기에 관한 메소드를 오버라이드 할때 자주 사용하는데 이때에 한해 언제 사용하는게 좋은지 궁금했다. 

안드로이드쪽으로 유명한 블로거 커니님이 관련된 내용의 포스트를 하셔서 자세한 내용을 물어보았다.

http://androidhuman.tistory.com/entry/안드로이드를-위한-자바-오버로딩Overloading-오버라이딩Overriding의-이해

•  커니

  결론부터 말씀드리자면 상황에 따라 다 다릅니다.
  구현에 따라 부모 메서드를 먼저 호출하지 않으면 제대로 동작하지 않는 것도 있을 것이고, 어떤 경우에는 상황에 따라 자식 메서드와 부모 메서드 둘 중 하나만을 호출하도록 할 수도 있습니다. 
  
  간단히 예를 들자면
  
  if(condition){ // 어떤 상황에선
  // 자식 메서드의 구현으로 처리하지만
  }else{ // 그 밖의 상황은
  super.method(); // 부모 메서드의 방식 사용
  }
  
  이렇게 구현될 수도 있겠죠.
  
  액티비티의 Lifecycle 메서드를 오버라이드 할 때, 일반적으로는 순서를 바꿔도 별 상관이 없지만 액티비티 상태 저장/복귀가 일어나는 경우 순서를 바꾸면 오동작할 가능성이 있습니다. 때문에 개인적으로 부모 메서드 호출을 가장 먼저 하는 것을 권장합니다.

  2012/11/06 21:52 [ ADDR : EDIT/ DEL ]

결론은 상황에 따라 다르지만 안드로이드의 경우는 먼저 하는것을 추천해주었다.

일반적인 경우라면 상황에 따라 다른 것이 맞다. 부모메서드가 해야할일이 있다면 super를 부르는 것이 당연하고 그전에 무언가 처리해야할일이 있다면 super를 나중에 부르고 부모가 먼저 해줘야하는 일이 있다면 super를 먼저 부르면 된다.

IntentService
이것은 모든 start요청을 한번에 하나씩 처리하기 위해 worker thread를 사용하는 서비스의 서브클래스이다. 이것은 서비스가 다중 요청들을 동시에 처리해야하는 경우가 아니라면 최적의 선택사항이다. 할 일은 onHandlerIntent()를 구현하는 것이다. 이 메소드는 백그라운드 작업을 할 수 있도록 각각의 시작요청을 위한 인텐트를 수신한다. 

다음 섹션은 이러한 클래스들 중 하나를 사용해서 서비스를 구현하는 방법을 설명한다.

Extending the IntentServie class
대부분의 시작된 서비스들은 동시에 다중 요청(사실상 위험한 다중스레딩 시나리오가 될 수 있다.)을 처리할 필요가 없기 때문에 IntentService 클래스를 사용하여 서비스를 구현하는 것이 아마도 최선일 것이다.

IntentService는 다음과 같은 것을 한다.

1. onStartCommand()에 전달된 모든 인텐트들을 실행하는 어플리케이션의 메인 스레드에서 분리된 디폴트 worker thread를 생성한다.
2. 한번에 하나의 인텐트를 통과시키는 작업 큐를 생성한다. 그러므로 다중 스레딩에 대해 걱정할 필요가 없다.
3. 모든 시작 요청들이 처리된 후에 서비스를 정지시킨다. 그러므로 stopSelf() 메소드를 호출할 필요가 없다.
4. 널을 리턴하는 onBind()의 디폴트 구현을 제공한다.
5. 작업 큐와 그 다음으로 onHandleIntent() 구현에 인텐트를 전송하는 onStartCommand()의 디폴트 구현을 제공한다.

할 일은 클라이언트에 의해 제공된 작업을 하기 위해 onHandleintent()를 구현하는 것이다. ( 어쨋든 서비스를 위해 작은 생성자를 제공할 필요가 있다.)

출처 : 브린과 페이지(http://brinpage.blogspot.kr/2011/11/services.html)

이렇게 LinearLayout으로 감싼 뷰중 하나를 남은 공간에 꽉차게 할때

보통 뷰의 속성에 weight 값을 설정해서 하곤한다. 

이때 아래와 같이 설정해줬다면 width는 0으로 설정해주는 것이 좋다. 

(LinearLayout의 orientation이 vertical인경우에는 height를 0으로 설정)

그 이유는 

weight값은 남은 공간을 채우기 위한 다른 width계산이 필요한데 “wrap_content”을 사용하는것은 시스템은 결국 상관없는 width를 계산하게 되기 때문이다.

한 앱에서 이미 라이브러리화된 곳으로 값을 공유할때 전달인자를 사용하는 것도 가능하지만

SharedPreference를 이용하는 것이 가능하다.

어느정도 결론을 내리긴 했지만 역시나 찝찝하다.

- broadcast 즉 보내는 쪽에서는 어떻게 권한을 실어보내고 받는 쪽은 어떻게 검사를 할까?

- 보내는 쪽에서는 

public abstract void sendBroadcast (Intent intent, String receiverPermission)

이것을 이용하면 될듯 싶은데 Manifest파일에 

<permission android:name="com.test.Permission.send"></permission>

   <uses-permission android:name="com.test.Permission.send"/>

이것도 반드시 작성해야했다.

#. 그런데 sendBroadcast(intent)로 작성하고 Manifest파일에 uses-permission만을 이용해도 가능했다. 그런데 어느 순간부터 또 안된다.

- 받는 쪽에서는 

        <receiver

            android:name="com.example.receiver.TextReceiver"

            android:permission="com.test.Permission.send" >

            <intent-filter>

                <action android:name="com.test.SEND" >

                </action>

                <category android:name="sender" >

                </category>

            </intent-filter>

        </receiver>

이런식으로 정의해주면 된다.

#. 신기한 점은 이 리시버에 퍼미션이 없다면 무조건 통과가 된다.

마치 인텐트의 액션이 아무것도 정의되있지 않다면 모든 인텐트 필터를 통과하는 것처럼 말이다.

단 카테고리는 정확히 일치해야한다.

#. 또한 보내는 쪽에서 sendBroadcast(intent) 메소드를 이용하여 권한없고 ManifestFile에는 위와 같이 적용되어있을때도 리시버가 브로드캐스트를 받는다. 이것을 미루어볼때 굳이 메소드를 이용하지 않고 브로드캐스트를 하면 안드로이드쪽에서 알아서 Manifestfile을 검사하여 권한을 실어 보내는 듯 하다. 그러나 과연 진실은 어디에?

위와 같이 적용해서 사용하기는 했지만 역시 권한을 적용해주는 정확한 방법이 없고 경우의 수도 많아서 조금 혼란스럽다. 다른 블로그에도 정확한 설명이 없다. 레퍼런스에는 단편적인 정보뿐이다.

생각하다보니 리시버와 서비스는 둘다 켜있지 않아도 인텐트를 받아 처리할 수 있다. 이런 면에서 볼때 차이점이 없어 보여 혼동이 되었다. 그러나 생각해보니 리시버에서 받은 인텐트는 그렇게 전달하고 끝이 아니라 관심있는 모든 리시버들에게 줄수 있고 확실히 이런 알림 되는 것들을 받아 간단한 작업을 빠르게 처리하는데 특화되어 있다는게 생각이다. 

서비스와 달리 개발자가 볼수 있는 부분도 onRecieve()메소드 하나로 제한한점이나, 10초안에 처리를 완료하지 않으면 ANR로 자동으로 종료해준다던지 등등 말이다. 실제 레퍼런스에서도 이런 작업을 하기위해 제일 작은 비용을 소모하게 되어 있다고 한다. 

### 더 공부하다보니 확실해졌다. 보내는 쪽의 매니페스트 파일안에는 permission을 정의하고  use-permission이 반드시 있어야하고 받는 쪽에서는 매니페스트파일이나 리시버에 반드시 있어야한다.

- nPush

- Subscribe()시 npushService를 통해서 tagetId를 받는데 자체내에서 생성한다. 한 기기당 고유 ID를 생성하게 되고 그 ID앞에 각각 nhn앱들의 패키지명을 붙여 실제 targetId를 생성한다.

- 자체 생성인데 서비스로 돌리는 이유는 이것이 여러 nhn앱들을 깔아도 실행되는 서비스는 하나로 유지하기 위함이다.

- permission이  protectionLevel:signature로 설정되어있는 것은 이 퍼미션은 한가지의 시그니쳐로 서명된 앱들끼리만 사용할 수 있다는 말이된다. 이미 한가지 서명으로 이 퍼미션을 사용하는 앱이 있다면 다른 서명을 가졌지만 같은 퍼미션을 사용하는 앱은 이 퍼미션을 사용할 수 없게된다. 그러므로 이 퍼미션을 사용하는 시그니쳐로 된 앱들을 다죽여야지만 다른 시그니쳐로 서명된(예로 디버그 시그니쳐) 앱이 이 퍼미션을 사용할 수 있게 된다.

- <intent-filter android:priority="13" > 

priority는 이 인텐트 필터에 대한 인텐트를 받게 된다. 브로드캐스트 리시버의 경우는 우선순위에 따라 차례대로 모든 리시버의 onReceive를 실행하게 되지만 서비스는 최상위 priority를 가진 서비스 하나만 실행하게 된다. 그래서 새로 만든 npush라이브러리를 적용할때 이 priority를 하나씩 증가하게 된다면 nhn앱들중에 이 최신 npush라이브러리를 사용한 어플이 하나만 있어도 모든 nhn앱들이 그것이 적용되는 것이다. 

- android:process="com.nhn.android.npush" 

서비스가 실행될 때의 서비스의 이름이 된다. 그러므로 어느 nhn앱이던지 다른 nhn앱이 실행하고 있는 이 서비스를 찾아갈 수 있게 된다. 이 프로세스이름을 통일해줌으로써 글로벌 서비스가 되는 것이다.  nhn앱마다 npush서비스가 탑재되어있어서 자신이 startService할경우 중복으로 서비스를 실행하는 것이 아니라 안드로이드 시스템자체에서 이미 실행중이라는 것을 알아차리고 기존 서비스에 인텐트만 전달해주게 된다.

- android:exported="true"

다른 어플리케이션에서 이 서비스를 실행시킬수 있게 된다. 이 값은 설정하지 않아도 서비스가  인텐트 필터를 갖는다면 관련된 인턴트는 실행시킬수 있다.

- npush test App으로 npush service를 돌렸을 경우는 어느 서버에 물리느냐에 따라 푸시가 오는지 안오는지 결정된다.

- targetID등을 갖는 것은 Sharedpreference이다. 여러 앱에서 공유해서 사용하게 하기 위함이다.

- 자신이 아닌 다른 앱이 이 서비스를 실행하고 있는 경우에 이 서비스와의 정보교환은 모두 인텐트로 이루어진다.

결국 리시버나 서비스나 이 옵션을 가진 송신자(인텐트)만이 이 리시버나 서비스를 실행시킬수 있게된다. 브로드캐스트 같은 경우는 sendBroadcast(intent, receiverPermission) 여기에서 퍼미션을 설정하여 보내게 되고 서비스는 매니페스트 파일의 use-permission 옵션을 가진 앱에서만 사용이 가능하다.