-___- @jsinthepark - Tumblr Blog

Single Activity Architecture

2012년부터 본격적으로 안드로이드 개발을 시작하고 가장 많이 공부한 것이 Fragment 에 대한 것이었습니다. 처음 시작하는 안드로이드 개발자라면 그 누구라도 안드로이드 4대 컴퍼넌트에 대해 열심히 공부하겠지만, 제가 처음으로 만든 앱이 폰버전, 태블릿버전 따로 나뉜 프로덕트였던 지라 너무나도 자연스럽고 당연하게 Fragment에 대한 공부에 가장 많은 시간을 할애했죠.

특히나 태블릿에서는 하나의 Activity에 여러 Fragment를 다루는 것을 자주 했었습니다. 큰 틀에서 보면 다양한 디바이스를 지원하는 것이 개발자나 디자이너의 실력 향상에도 매우 좋고 사용자 측면에서도 이만큼 좋은게 없어서 아름다운 일이라고 생각하지만, 이는 많은 지식과 넓은 생각 그리고 많은 시간을 요구로 하는데 우리에게 그런 것들이 있을 수 없기 때문에(특히나 시간은…) 시간이 흐르고 여러가지 프로젝트를 하면서 태블릿에 대한 지원은 점점 더 멀어져 가게 됐습니다. (새 프로젝트 만들면 values-w820dp 이런 큰 기기용 폴더부터 지우게 됨..) 그래서 자연스럽게 하나의 Activity에 두 개 이상의 Fragment를 다루는(ViewPager 빼고)일이 드물어 졌습니다.

점점 Activity는 껍데기 용으로 쓰이는 걸 느끼게 됩니다. 사용자의 요구, 기획적인 요구사항에 의해서 같은 화면을 다른 상황에서 다르게 보여줘야 될 일이 너무나 많기 때문에 Fragment를 안 쓸 수는 없고… 결국 다음과 같은 코드도 조금씩 생기기 시작합니다.

public class UserFragment { public void onViewCreated() { Bundle args = getArgument() args.getLong("id"); args.getLong("name"); args.getLong("profile"); args.getLong("status"); } }

같은 일을 두번하거나 Bundle객체가 두번에 거쳐 전달된다던가 도 문제라고 생각이 들었지만 하나의 도메인에 대한 화면을 구성하기 위해서 위대한 안드로이드 1대 컴퍼넌트가 큰 일안하고 껍데기로서 낭비되는 것이 안쓰러웠습니다. 이외에도 푸쉬나 스키마를 통해서 다수의 Activity를 띄워야 하는 상황, 다양한 화면 Transition에 대한 요구들 등 때문에

화면을 전환을 담당하는 하나의 Activity 와 여러가지 View의 조합으로 어플리케이션을 구성하는 Single Activity Architecture 에 관심을 가지게 됩니다.

Conductor ?

View의 역할에 Fragment를 대입하는 방식으로 작업을 하려다 Single Activity Architecture 를 위한 여러가지 라이브러리 들이 있다는 것을 알게 됐습니다. 그중의 하나가 지금 다룰 Conductor란 것인데요. GoogleSample 에서 이것의 존재를 알게 됩니다. 3자가 작성하긴 했지만 구글에서 제공해주는 샘플도 있겠다 점점 더 흥미로워지고 본격적으로 사용을 해보기 시작합니다.

(! 예제는 대세 Kotlin으로 쓰여집니다.)

routSingle Activity Architecture ?

public class UserActivity ... { public void onCeate() { Intent intent = getIntent(); id = intent.getExtra("id"); name = intent.getExtra("name"); profile = intent.getExtra("profile"); sattus = intent.getExtra("status"); addFragment( UserFragment.newInstance(id, name, profile, status); // or UserFragment.newInstance(intent.getExtras); } } public class UserFragment { public void onViewCreated() { Bundle args = getArgument() args.getLong("id"); args.getLong("name"); args.getLong("profile"); args.getLong("status"); } }

화면을 전환을 담당하는 하나의 Activity 와 여러가지 View의 조합으로 어플리케이션을 구성하는 Single Activity Architecture 에 관심을 가지게 됩니다.

Conductor ?

View의 역할에 Fragment를 대입하는 방식으로 작업을 하려다 Single Activity Architecture 를 위한 여러가지 라이브러리 들이 있다는 것을 알게 됐습니다. 그중의 하나가 지금 다룰 Conductor란 것인데요. GoogleSample에서 이것의 존재를 알게 됩니다. 3자가 작성하긴 했지만 구글에서 제공해주는 샘플도 있겠다 점점 더 흥미로워지고 본격적으로 사용을 해보기 시작합니다.

(! 예제는 대세 Kotlin으로 쓰여집니다.)

class RouterActivity : AppCompatActivity() { lateinit var router : Router override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_router) router = Conductor.attachRouter(this, container, savedInstanceState) if(!(router.hasRootController())) { router.setRoot(RouterTransaction.with(MainController())) } } override fun onBackPressed() { if (!router.handleBack()) { super.onBackPressed() } } }

여러가지 화면을 다루는 Router 용 Activity 구성이 끝났습니다. 쉽게 예를들면 Fragment나 Activity의 대체제로 Controller라는 녀석이 쓰이게 되는데요. 위 코드를 보통 방식으로 치환하면 SplashActivity(LauncherActivity)에서 MainActivity 를 호출하는 것이 되겠습니다.

class MainController : Controller() { override fun onCreateView(inflater: LayoutInflater, container: ViewGroup): View { val view = inflater.inflate(R.layout.controller_main, conatiner, false) view.aButton.setOnClickListener { router.pushContrller(RouterTransaction.with(AController()) } view.bButton.setOnClickListener { router.popContrller(RouterTransaction.with(AController()) } view.cButton.setOnClickListener { getChildRouter(view.conatiner).pushContrller(RouterTransaction.with(CController()) } return view } }

Controller는 Router에 접근해서 다른 Controller를 보여줄 수도 있고(Activity가 다른 Activity를 호출하듯), ViewGroup을 통해 새로운 Router를 만들어서 자식 Controller를 보여줄 수도 있습니다.(Activity에서 Fragment를 보여주듯) 전반적인 메소드 네이밍을 보면 FragmentTransaction 에서 제공하는 add, remove, show 등등등 과 유사한 기능들을 제공하고 있습니다. 결론적으로는 Activity와 Fragment의 특성을 전부 가지고 있는 것이 Controller라고 할 수 있겠습니다.

Activity와 Fragment의 경계를 허물고 화면에 대한 디자인이 나오고 개발을 시작할 때 Activity로 할지 Fragment로 할지 고민하지 않아도 되어서 이것으로 Single Activity Architecture를 구현하면 되겠구나 했습니다만, 제대로 생산성있게 사용할라면 몇가지 공통 메소드 들을 추상화 시키고 써야 할텐데 이렇게 되면 대체 Fragment와 다른 점이 뭔가 싶어집니다. 그동안 개발했던 많은 프로덕트들 거의 전부 BaseFragment, BaseActivity들 만들어서 백버튼에 대한 제어, FragmentTransaction.add, remove, replace, show, hide 등을 추상화해서 사용했는데 굳이 Conductor 내의 라이프사이클, 메소드 등을 공부할 필요가 있는가?

일단 두 가지를 Conductor를 쓰기 위한 합리화로 뽑았는데요. 첫번째는 자유로운 화면 Transition 구현에 대해서 Conductor가 훨씬 쉽다는 점. Conductor에서는 화면 전환에 필요한 클래스를 추상 클래스 ControllerChangeHandler라고 정의하고 있고, 기본적으로 제공되는 ChangeHandler도 엄청 많이 있습니다. 기본적인것 외에 활용가능한 ChanglHandler들

새로운 화면 진입시 아래서 위로, 이전 화면으로 돌아갈시 위에서 아래로 애니메이션되는 Transition 설정 router.pushController(RouterTransaction.with(UserController()) .pushChangeHandler(VerticalChangeHandler()) .popChangeHandler(VerticalChangeHandler()))

두번째는 기존 추상화된 클래스들을 더 깊이있게(상태저장 등) 사용하기 위해 수정해야 하는데 , Conductor에는 이미 구현되어 있는 것들이 많다.

이 두 가지 이유를 들어 새로운 프로젝트에 적용시키고 있는데요. 조금 부정적이지만 아래와 같은 결론도 도출 할 수 있었습니다.

Activity, Fragment 이것들과 관련한 웬만한 이슈들의 해결 방법들은 금방 찾을 수 있고, 어느정도 노하우가 생겨서 안드로이드 4대 컴퍼넌트 안에 속한 이 둘을 사용하는 것에 의구심이 없다면 굳이 Conductor를 사용하지 않아도 된다.

입니다. Conductor 라이브러리 걷고 다시 돌아가는데 많은 시간이 걸리진 않아서 “내가 지금 왜 사서 고생을 하고 있는가, 빨리 걷자” 라고 생각하면서도 이상하게 계속 쓰게 되는데요. 돌이켜보면 제가 가진 부정적인 포인트들이 Conductor 에 대한 것이 아니라 Single Activity Architecture를 향하고 있기 때문인 것 같습니다. 사서 고생이거나 고민중인 포인트 들은 다음과 같습니다.

Theme 지정 - 단일 Activity가 아니라면 styles.xml에 각 Activity마다 필요로 하는 색상값과 같은 화면성격을 기술해 놓으면 쉽게 적용 가능한데, Single Activity Architecture를 적용시키면 하나 하나의 View마다 일일히 theme 설정이 필요함.

StatusBar - 1번과 마찬가지로 각 화면마다 필요한 상태바 관련 설정들을 쉽게 하지 못한다. 색상값은 해결이 가능하다 하더라도 어떤 화면에서는 완전 오버레이된 상태바가 필요하고 어떤 화면은 불투명으로 오버레이된 상태바가 필요할 때, 유연하게 적용시키기 어렵다. (RouterActivity를 완전 오버레이 시켜놓고 각 Controller 에서 대응하는 방법으로 회피 중)

SoftInput - 키보드가 올라옴에 따라 어떤 화면에선 resize 가 요구되고 어떤 화면에선 현재 상태를 유지하는 것이 요구되는 경우도 생길텐데, 이것도 유연하게 대응하기 힘들 듯(대부분의 경우 resize 가 요구되기 때문에 어…음…)

Kotlin - Kotlin을 메인 언어로 사용중인데 android-extensions나 anko등이 Activity,Fragment에서 편리한 메소드들을 제공해주고 있는데, Conductor를 사용하게 되면 그 좋은 메소드들을 사용하는데 제약사항이 생길 수 밖에 없음.

깍두기. Learning curve - 그렇게까지 높다고 생각되진 않지만, 안드로이드 앱 개발에서 가장 중요한 화면을 제어하는 라이브러리 인 만큼 Conductor의 라이프사이클 이나 메소드들을 공부할 필요가 있음

이 정도를 단점으로 꼽고 있는데요. 이 단점들이 Activity의 Task 와 Stack 에 대한 고민을 해소해주고, 화면에 대한 구성을 하나의 개념으로 통일화해서 개발하고, 무분별한 Activity 사용으로 인한 복잡도를 줄여주는 등의 장점들을 상쇄할만큼으로 보이지만, 개인적으로는 충분히 시도해볼만한 가치는 있다라고 판단하고 있습니다.

중요한 것은 개발과 관련된 어떤 언어, 어떤 개념, 어떤 라이브러리 든 장단은 있으니, 맹목적이지 않고 유연한 사고를 하는 것임을 인지하고, 납득가능한 방법이 아닌 회피로직을 만들 때는 “단일” 이란 개념은 생각하지 않도록 해야겠죠.

Conductor와 함께하는 Single Activity Architecture 어플리케이션 개발은 계속 될 것이고, 결과물이 나온 후 회고에 대한 블로그를 남기도록 하겠습니다. 감사합니다.

ps. 요즘 사용중인 BasePage, Controller라는 이름이 낯설고, MVP 패턴 이용중에 네이밍이 좀 겹쳐서 Page로 화면단위 네이밍 중입니다.

Android with Kotlin

새로이 각광받기 시작한 Kotlin 이란 언어를 사용해보며 느꼈던 점들에 대해 공유해봅니다.

KotlinKotlin is a statically typed language that targets the JVM and JavaScript. It is a general-purpose language intended for industry use.

JVM, Javascript 를 대상으로 하는 언어라고 합니다.(기타 Kotlin 에 대한 설명들)

Java 로 안드로이드 개발을 하고 있는 저에게는, Java 가 아닌 다른 언어로 안드로이드 개발을 하는 것이 신기했고 또, 사용하면 할수록 묘한 매력이 있어서 2017년 부터는 Kotlin 위주로 코딩을 하고 있습니다. 물론 저는 Java 로 된 안드로이드 프레임워크, 오픈소스 라이브러리 들을 “응용”하는 수준의 개발자이기 때문에, 아직까지는 자바의 어떤 부분이 안 좋고, 코틀린을 통해서는 어떻게 이런 것들이 해결될 수 있는지 깊게 알지 못합니다. 그래서 사용성, 생산성 위주로 Kotlin 으로 안드로이드 어플리케이션을 개발 했을 때 느꼈던 점들을 공유할까 합니다.

문법적인 부분에서 편해진 부분들이 많이 있는데 이런 부분들을 간단히 살펴보도록 하겠습니다. (Kunny 님 블로그, 권태환 님 블로그 등에 좀 더 자세히 소개 되어 있습니다.)

새로운 액티비티 시작 할 때를 예로들면, Java

Intent intent = new Intent(); intent.putExtra(...); intent.putExtra(...); intent.addFlags(...); startActivity(intent);

Kotlin

startActivity(Intent().apply { putExtra(...) putExtra(...) putExtra(...) addFlags(...) })

보시다 싶이 Kotlin 이 더 간결한 형태를 보입니다. Java 에서도 빌더패턴을 만들어준다면 비슷하게 구현 할 수 있지만, Kotlin 에서는 apply 구문 하나로 어떤 객체라도 내부에 필요한 데이터들을 담을 수 있습니다.

Fragment 에서 Activity 접근에 대한 방어 코드로 Null Check 를 자주 하는 편인데, Java 에서는 이런 부분마다 if 문으로 걸러줘야 했습니다.

if(getActivity() == null) { return; } getActivity().finish(); // or if(getActivity() != null) { getActivity().finish(); }

Kotlin 에서는 금방 끝납니다.

activity?.finish() // ? 가 null check 를 대신해줌 * getActivity() 를 activity 로 표현 가능

let 구문을 사용하면 다음과 같은 형태로도 사용가능합니다.

activity?.let { it.setSupportActionBar(...) it.registerReceiver(...) it.getSupportFragmentManager().beginTransaction(...)

자동 형변환 기능도 맘에 듭니다. Java

Activity activity = getActivity(); if(activity instanceOf StatusBarManager) { ((StatusBarManaget)activity).setStatusBarColor(...);

Kotlin

val activity = activity if(activity is StatusBarManager) activity.setStatusBarColor(...);

Kotlin 문법들을 좀 더 많이 활용해보고 좋은 것들을 뽑아서 최대한 “Java 스럽지 않은” 스타일로 개발 해보려 하고 있습니다.

어플리케이션 개발을 Kotlin 으로…

Kotlin 을 사용하여 비교적 작은 덩치의 앱을 만들었는데요. 이 과정에서 느꼈던 부분들을 공유합니다.(공개용 repository 는 준비중에…)

먼저 기존과는 다른 언어 Kotlin 을 사용함으로서 생긴 문제는 거의 없었습니다. 언어적인 트러블이 거의 없었다는 걸로 보아 러닝커브가 그리 크지 않은 듯 합니다. 만약 러닝커브가 제 생각보다 큰게 일반적인 개발자들의 반응이라면, 언어적인 트러블을 겪기엔 난이도가 그리 높지 않은 앱을 만들었던 듯합니다.

설계패턴적인 부분에선, MVP 패턴을 그동안 계속해서 사용해왔었는데, 덕분에 문법적인 부분을 습득하기 좋았습니다. Kotlin 으로 구현해서 얻는 이득도 많았구요. 툭성에 떄라 구현하는 부분이 나뉘어 있으니 기존에 Java 로 구현된 코드와도 위화감 없이 비교할 수 있었고, 조금 더 구체적으로 View 를 구현하는 Activity/Fragment 에서는 let, apply, null-safe 등의 사용으로 깔끔해졌고. Model 에서는 메소드를 더 간결하게 만들고 콜렉션등을 다룰 때 좋았습니다.(stream api 이용한 Iteration 등), Presenter 에서는 케이스 단위 작업까지 더해서 전체적인 언어적 이점을 활용하기 좋았습니다.

또 유명한 오픈소스 라이브러리들을 아무런 문제없이 이용할 수 있엇습니다. Rx 와 관련해서는 앞으로 어떻게 할까 고민이 생겼는데요. Kotlin 언어에서 자체적으로 지원해주는 것들과 coroutines 를 같이 활용하는것이 Rx를 이용하는 것보다 더 깔끔해질 수 있다면 앞으로는 라이브러리를 사용안해도 될런지 싶습니다.

음… 코드를 보고 싶은데…?

백마디 말보다 소스코드 한 줄이 더 이해가 빠르다고, 소스코드 공유를 통해 좀 더 많은 부분을 공유하고 피드백도 받고 싶습니다. 공개용 Repository 를 조만간 완성해서 Kotlin 과 함께하는 여정을 계속 공유 할 예정입니다.

앞으로도 Kotlin ?

큰 프로젝트에 앞서 자그마한 프로젝트로 Kotlin 을 다뤄 봤는데요. 사실 “Java 도 통달하지 못한 상태” 에서 다른 언어를 사용하는게 맞는건지에 대한 망설임 과 레퍼런스가 적다는 두려움 이 있지만, 칼을 한 번 뽑았으니 무라도 썰어보자는 마음입니다. 지속적인 스터디로 Kotlin 과 함께하려고 합니다 :)

Background Service 에서 키이벤트 발생시키는 건 노답이다.

new Instrumentation().sendSync(KeyEvent);

위 소스를 백그라운드 서비스에서 실행하면 Exception 이 난다.

java.lang.SecurityException: Injecting to another application requires INJECT_EVENTS permission

키 이벤트를 백그라운드 서비스에서 발생시켜서 다른 어플에 효과를 전달? 하려면 시스템 앱 권한이 필요하거나, 루팅 된 폰에서만 동작한단다.

출처 : stackoverflow , androidpub

#android #Keyevent

다양한 형태를 지원하는 리스트 UI, 잘 그리고 계신가요?

다양한 형태가 반복되는 UI를 RecyclerView.Adapter 를 이용해서 깔끔하게 만들고 싶었어요.

대략 1년 반 전, 5.0 롤리팝과 함께 나타난 RecyclerView. ListView 를 이용할 때 아주 기초적이고 정석적인 개념으로 사용되던 ViewHolder pattern 을 반 강제화? 하면서 동시에 성능까지 개선한ListView 의 개량버전.

앱 시장이 활성화되면서 한 가지 타입의 뷰만 반복적으로 보여주는 단순한 구성보다는 다양한 타입의 뷰를 보여주는 앱들이 많아지고 보편화 된 시점에 이것을 구현하기 위한 Adapter.getView 메소드는 혼돈.chaos 가 되었지요. 가독성을 높일만한 나름대로의 시도를 해보고 있을 때, RecyclerView 가 갑툭튀 했고 이걸 이용하면 원하는 만큼의 많은 타입의 뷰를 “가독성 좋게 만들어 볼 수 있겠다” 라는 생각이 들었습니다.

그래서 RecyclerView.Adapter 를 상속 받아 다양한 타입의 뷰를 바인딩 할 수 있게 도와주는 헬퍼 클래스, MultiItemAdapter 라는 것을 만들어 보게 됐습니다. 구 회사 프로덕트에 적용해보기도 하고, 개인 프로젝트에 넣어보기도 하고, 토스랩에서 서비스하고 있는 “잔디”에 녹여내보기도 했는데 나쁘지 않은 느낌이들어 그 과정을 공유하고 많은 분들께 피드백도 받고 싶습니다. 또, 어떻게 더 잘 활용하고 계신지 여쭙고 싶습니다.

RecyclerView.Adapter 의 이해를 위해 단순단순하게 만들어보자

public class BasicAdapter extends RecyclerView.Adapter<BasicAdapter.MyViewHolder> { private List<String> mItems = new ArrayList<>(); @Override public MyViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new MyViewHolder(itemView); } @Override public void onBindViewHolder(MyViewHolder holder, int position) { holder.mTextView.setText(mItems.get(position)); } class MyViewHolder extends RecyclerView.ViewHolder { private TextView mTextView; public MyViewHolder(View itemView) { super(itemView); mTextView = (TextView) itemView.findViewById(android.R.id.text1); } } ...

이런 식으로 구현하면 되는군, 하지만 내가 최종적으로 원하는 건 다양한 ViewHolder 를 다뤄야 되는 건데 ViewHolder 가 많아지는 경우 inner class 는 쓰면 안되겠다! ViewHolder 들은 따로 패키지 만들어서 관리하자. 음 근데 ViewHolder 를 구성하고 난 다음 어떻게 그려지는 지에 대해 궁금하면 다시 어댑터를 찾아가야 되고, 반대로 어댑터에서 ViewHolder 내 구성요소가 어떻게 생겼는지 궁금하면 다시ViewHolder 찾아가서 뒤져봐야되는 군. 이건 비효율 적인 것 같다. ViewHolder 에 뷰를 그리는 메소드를 하나 만들자. 아 기왕이면 추상화된 클래스를 만들어 돌려돌려 쓰자. 하나 더 Generic 을 사용하자.

public abstract class BaseViewHolder<ITEM> extends RecyclerView.ViewHolder { public BaseViewHolder(View itemView) { super(itemView); } public abstract void onBindView(ITEM item); }

뷰를 그리는데 쓰이는 객체는 Generic 을 이용하면 ViewHolder 안에서 그리는 작업 또한 해결이 가능하겠군! 이걸 이용해서 다시 만들어보자.

public class MyViewHolder extends BaseViewHolder<String> { private TextView mTextView; public MyViewHolder(View itemView) { super(itemView); mTextView = (TextView) itemView.findViewById(android.R.id.text1); } @Override public void onBindView(String item) { mTextView.setText(item); } } ... public class BaseAdapter extends RecyclerView.Adapter<MyViewHolder> { private List<String> mItems = new ArrayList<>(); @Override public MyViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new MyViewHolder(itemView); } @Override public void onBindViewHolder(MyViewHolder holder, int position) { holder.onBindView(mItems.get(position)); } public void setItems(List<String> items) { mItems.clear(); mItems.addAll(items); } @Override public int getItemCount() { return mItems.size(); } }

음 원하는 모양새다. 근데 이제 Adapter 에선 ViewHolder 에 들어갈 layout 이 어떤 건지 관심꺼도 되겠네. 게다가 ViewHolder 에서 layout 궁금하면 다시 또 찾아와야 되는게 문제다. 좀 더 명시적인 방법으로 Factory method 로 생성자를 제한해보자. RecyclerView.ViewHolder 는 View 를 가지는 생성자가 강제되니 이렇게 바꾸자.

public static MyViewHolder newInstance(ViewGroup parent) { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new MyViewHolder(itemView); } private MyViewHolder(View itemView) { super(itemView); mTextView = (TextView) itemView.findViewById(android.R.id.text1); }

이렇게 하면 어떤 layout 을 다루고 있는지도 금방 알 수 있겠다. 이 정도만 되도 구색을 다 갖춘듯하니 이 느낌으로 다양한 타입의 뷰들을 다뤄보자.

public class BasicMultiTypeAdapter extends RecyclerView.Adapter<BaseViewHolder> { public static final int VIEW_TYPE_A = 0; public static final int VIEW_TYPE_B = 1; private List<String> mItems = new ArrayList<>(); @Override public BaseViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { if (viewType == VIEW_TYPE_A) { return AViewHolder.newInstance(parent); } else { return BViewHolder.newInstance(parent); } } @Override public void onBindViewHolder(BaseViewHolder holder, int position) { holder.onBindView(mItems.get(position)); } public void setItems(List<String> items) { mItems.clear(); mItems.addAll(items); } @Override public int getItemCount() { return mItems.size(); } @Override public int getItemViewType(int position) { if (position % 2 == 0) { return VIEW_TYPE_A; } else { return VIEW_TYPE_B; } } }

음 깔끔하긴 하다. 근데 getItemViewType 이 스크롤 할 때마다 불릴 텐데, 분기도 많고 연산이 생겼을 때 스크롤 속도에 괜한 영향을 줄 듯? view type 을 차라리 미리 가지고 있게 만들자. 또! 가만보니 한 타입의 객체를 이용해서 다른 스타일로 뷰를 보여줄 뿐이었네. 이것도 여러가지 객체를 담을 수 있게 만들어야지.

뷰를 그릴 대상이 될 객체랑 타입을 가지는 Wrapper class 를 만들어서 해결하자. 이러면Adapter.onBindViewHolder 랑 Adapter.getItemViewType 도 해결이 되겠군.

public abstract class MultiItemAdapter extends RecyclerView.Adapter<BaseViewHolder> { private List<Row<?>> mRows = new ArrayList<>(); @SuppressWarnings("unchecked") @Override public void onBindViewHolder(BaseViewHolder holder, int position) { holder.onBindView(getItem(position)); } @SuppressWarnings("unchecked") public <ITEM> ITEM getItem(int position) { return (ITEM) mRows.get(position).getItem(); } public void setRows(List<Row<?>> mRows) { mRows.clear(); mRows.addAll(mRows); } @Override public int getItemCount() { return mRows.size(); } @Override public int getItemViewType(int position) { return mRows.get(position).getItemViewType(); } public static class Row<ITEM> { private ITEM item; private int itemViewType; private Row(ITEM item, int itemViewType) { this.item = item; this.itemViewType = itemViewType; } public static <T> Row<T> create(T item, int itemViewType) { return new Row<>(item, itemViewType); } public ITEM getItem() { return item; } public int getItemViewType() { return itemViewType; } } }

MultiItemAdapter 완성.

네, 저는 이렇게 만들어서 1년 반 정도 필요한 부분(복잡해 질만한 부분)에 이 클래스를 상속받아 구현했습니다. 사용방법을 예로들어 데이터베이스나 서버로부터 긁어온 아이템들을 타입에 따라 A, B로 나눠서 보워줘야 한다면,

// MutiItemAdapter 구현 public class AdvancedItemAdapter extends MultiItemAdapter { public static final int VIEW_TYPE_A = 0; public static final int VIEW_TYPE_B = 1; @Override public BaseViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { if (viewType == VIEW_TYPE_A) { return AViewHolder.newInstance(parent); } else { return BViewHolder.newInstance(parent); } } } // Activity 나 Fragment 등 view 요소에서 ListAdapter item setting. public void setItems(List<Item> items) { List<MultiItemAdapter.Row<?>> rows = new ArrayList<>(); for (int i = 0; i < items.size(); i++) { Item item = items.get(i); if (item.getType().equals("A")) { rows.add( MultiItemAdapter.Row.create(item, AdvancedItemAdapter.VIEW_TYPE_A)); } else { rows.add( MultiItemAdapter.Row.create(item, AdvancedItemAdapter.VIEW_TYPE_B)); } } mAdvancedItemAdapter.setRows(rows); }

이렇게 해주면 됩니다. 그런데 위 사용방법을 보면 추가적인 새로운 타입(Row)의 List 와 반복문을 돌려야 된다는 것이 단점으로 보이는데요. 그럼 이 클래스를 사용하지 않고 직접 구현한 결과를 좀 볼까요?

public class NormalItemAdapter extends RecyclerView.Adapter<RecyclerView.ViewHolder> { public static final int VIEW_TYPE_A = 0; public static final int VIEW_TYPE_B = 1; private List<Item> mItems = new ArrayList<>(); @Override public RecyclerView.ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { if (viewType == VIEW_TYPE_A) { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new AViewHolder(itemView); } else { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new BViewHolder(itemView); } } @Override public void onBindViewHolder(RecyclerView.ViewHolder holder, int position) { if (holder instanceof AViewHolder) { Item item = getItem(position); ((AViewHolder) holder).getTextView().setText(item.getName()); } else { ((BViewHolder) holder).getTextView().setText("I am B."); } } private Item getItem(int position) { return mItems.get(position); } public void setItems(List<Item> items) { mItems.clear(); mItems.addAll(items); } @Override public int getItemViewType(int position) { if (getItem(position).getType().equals(Item.ITEM_TYPE_A)) { return VIEW_TYPE_A; } else { return VIEW_TYPE_B; } } @Override public int getItemCount() { return mItems.size(); } }

뭐, 나쁘진 않습니다. 이 정도 수준으로 개발이 끝나도 되고 추가적인 확장이 필요하지 않아보인다면 굳이MultiItemAdapter 를 쓸 필요가 없습니다.

중요성을 가지는 리스트 위주의 화면에서 위와 같이 개발된다면 당장 보이는 제 불만은onCreateViewHolder, onBindViewHolder 계속해서 분기가 들어가게 되고 getItemViewType 에서는 계속 해서 List 데이터에 접근해야 한다는 것입니다. 접근 자체가 큰 문제, 큰 영향을 끼치지 않을 정도 규모의 자료구조라면 논외로 치더라도, 뷰 타입이 조금만 늘어나도 onCreateViewHolder,onBindViewHolder 의 덩치는 엄청 커질 겁니다.

예를들면 맨 마지막 아이템 타입이 B 이고 현재 추가 될 아이템 타입이 A인 경우에는 다른 형태의 디바이더를 넣어야 한다던지 하는 추가적인 확장이 이루어져야 한다면 골치가 꽤 아플겁니다. 특히 저는 위 예와 비슷하게 뷰 타입에 따라 각기 다른 아래 위 마진값을 요구받을 때, ViewHolder 마다 이전 데이터를 참고하게 만들고 동적으로 Visibility 처리를 하거나 MarginLayoutParams 를 고치는 것이 비효율적으로 느껴져서height를 주입받는 DividerViewHolder 를 하나 만들어 사용하곤 했습니다. 이렇게 하니 각각의ViewHolder 들이 데이터들에 의존적이지 않게 코딩이 가능했었습니다. 한 가지 더 예를들어 리스트 중간 중간 광고가 보여지게 되고 이 광고 클래스는 완전히 다른 객체로부터 보여줘야 한다 라고 했을 때MultiItemAdapter 를 이용하면 쉽게 해결이 가능합니다.

정작 근 1년간 “잔디”를 만들면서는 자주 쓰진 않았는데, 작년부터 각광받기 시작한 MVP 패턴을 사용할 때View 에서의 로직을 최소화 하려고 한다면 써먹을 수 있는 모델로 적합하지 않나 생각이 들면서 다시 사용하기 시작했습니다. Presenter 에서 Row 를 만들어 던져주면 View 는 그것을 그대로 사용하게 만들 수 있다는 생각이 들었거든요.(아직까지는 비교적 크지 않은 부분에서만 사용하게 되서View(MainThread)에서 Row 를 만들게 코딩해 놓은 컴퍼넌트가 더 많네요 흑흑) 더 복잡한 구조를 갖는 컴퍼넌트를 만들어야 할 때는 비동기 스레드에서 Row 까지 만들어 내보내는 것도 해볼까 하는 생각도 듭니다.

제 눈에만 괜찮은 구조인지, 생각지도 못한 치명적인 단점이 있진 않은지, 구조나 설계 측면에서 안 좋은 점은 있지 않은지, 논리없이 Generic 으로 “퉁” 치고 있는 코드는 아닌지, 여러가지가 많이 궁금합니다 ^^MultiItemAdapter 를 쓴 것과 안 쓴것의 정말 심플한 비교 소스를 열어놓았습니다 MultiItemAdapter또, 여러분들은 어떻게 구현하고 계신지요? 여러분의 관심이 필요합니다 ! :)

TextView 한 라인에 몇 글자가 들어갔는지 확인하는 방법

TextView.getLayout().getLineStart(0) - TextView.getLayout().getLineEnd(0);

Android Image Loading Library Fresco

안드로이드 이미지 로딩 라이브러리 Fresco 소개 및 비교

안드로이드에서 보다 빠르고 간결하게 이미지를 보여주기 위해 오픈소스 라이브러리 Picasso, AUIL 등이 등장했고, Glide 가 나오면서 쉽고 간결하고 빠르게 원하는 이미지를 언제 어디서든 보여 줄 수 있게 되었습니다. 그러나 사람의 욕심은 끝이 없고 그것을 페이스북은 간파한 것인지 많은 개발자들이 디자이너와 기획자의 요구를 웃으면서 받아들일 수 있게 더 편하고 친숙한 사용법을 제시한 라이브러리를 내놓았습니다.

Fresco : http://fresco.recrack.com

심지어 한글문서까지 제공되고 있습니다 ! (이 문서만으로도 Fresco 를 익힐 수 있다는 것은 안 알려줍니다.)

지난 1년간 탄식도 했지만 결국은 감탄을 더 많이하고 만족하며 사용하던 이미지 로딩 라이브러리 Glide(갓). 최근에 이것을 이용해서 예쁜 디자인과 함께 이미지를 요리 할 때 백종원 선생님 만큼의 포스를 못 내는 듯한 느낌이 들었고, 급기야 다른 라이브러리 맛집을 찾아보게 됩니다.

근근히 "Github Trending"에 올라와서 눈독(갤럭시 사용자 아이폰 바라보듯)은 들였지만 저만치 바라보던 Fresco. 과연 어떤 장점이 있는지 Glide 사용성과 비교해보면서 Fresco 의 사용법을 알아보도록 하겠습니다.

시작하기 전에 기본 준비는 해야겠죠?

1. build.gradle dependency 추가

compile 'com.github.bumptech.glide:glide:3.6.1' // Glide compile 'com.facebook.fresco:fresco:0.8.1' // Fresco (문서에는 0.5.0 이지만 GitHub 최신 릴리즈 버전이 0.8.1 입니다.)

2. AndroidManifest.xml 에 uses-permission 추가

<uses-permission android:name="android.permission.INTERNET"/>

1. 이미지를 로딩하고 ImageView 에 붙이는 방법부터 알아봅시다.

Glide:

Glide.with(context) .load(String | File | Integer(resource id) | byte[]) .into(imageView);

코드 한 두 줄로 네크워크, 로컬 파일, 리소스 등등에서 얻어온 이미지를 쉽게 ImageView에 붙일 수 있습니다.

Fresco: 는 먼저 Application class 의 onCreate override 한 후에 Fresco.initialize(context); 구문을 추가해주어야 합니다. (setContentView() 가 호출되기 이전에 한 번만 호출하라고 명시되어 있네요.)

XML 에서는 ImageView 대신 Fresco 의 SimpleDraweeView 를 사용합니다.

<com.facebook.drawee.view.SimpleDraweeView

다음 다시 이미지를 로딩하는 구문으로 돌아와서

SimpleDraweeView draweeView = (SimpleDraweeView) find... draweeView.setImageUri(uri);

Glide 에 비해 취해야 할 행동들이 조금 아니 많이 많은데 결론적으로 SimpleDraweeView 의 setImageUri 를 호출하면 자동으로 이미지가 불려옵니다. 다만 여기서 Uri 를 만들어줘야 하는 비용이 또 생겼네요.

Uri.parse("http:// | Uri.parse("file:// | Uri.parse("asset:// | Uri.parse("res:// 혹은 new Uri.Builder() .scheme("file") // ContentResolver.SCHEME_FILE 또는 com.facebook.common.util.UriUtil.LOCAL_FILE_SCHEME 로 대체 가능 합니다. .path(filePath) .build();

2. 이미지를 로딩 할 때 대기 이미지를 설정해봅시다.

Glide:

Glide.with(context) .load(...) .placeHolder(Integer(resoure id) | Drawable) .into(imageView);

다음 Fresco 는 두 개의 방법이 있습니다.

먼저 XML

<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:fresco="http://schemas.android.com/apk/res-auto" // xml namespace 를 추가해줍니다. ... <com.facebook.drawee.view.SimpleDraweeView fresco:placeholderImage="@drawable/ic_launcher"

다음 Java Code

GenericDraweeHierarchy hierarchy = draweeView.getHierarchy(); hierarchy.setPlaceholderImage(R.drawable.ic_launcher); draweeView.setHierarchy(hierarchy); draweeView.setImageURI(uri);

2-1. 대기 이미지는 FIT_CENTER 로 스케일하고 보여줄 원본 이미지는 FIT_XY 로 스케일해봅시다.

Glide: 딱히 Glide 만 이용해서 할 수 있는 방법이 마땅치 않습니다.

imageView.setScaleType(ImageView.ScaleType.FIT_CENTER); Glide.with(getContext()) .load(url) .placeholder(R.drawable.ic_launcher) .listener(new RequestListener<String, GlideDrawable>() { @Override public boolean onException(Exception e, String model, Target<GlideDrawable> target, boolean isFirstResource) { return false; } @Override public boolean onResourceReady(GlideDrawable resource, String model, Target<GlideDrawable> target, boolean isFromMemoryCache, boolean isFirstResource) { imageView.setScaleType(ImageView.ScaleType.FIT_XY); return false; } }) .into(imageView);

뭔가 억지스러워 보이네요... 다른 방법으로 BitmapTransformation 을 상속받아 구현하는 것 방법이 떠오르네요

Fresco:

<com.facebook.drawee.view.SimpleDraweeView fresco:placeholderImage="@drawable/ic_launcher" fresco:placeholderImageScaleType="fitCenter" fresco:actualImageScaleType="fitXY"

다음 Java Code

GenericDraweeHierarchy hierarchy = draweeView.getHierarchy(); Drawable placeHolder = getContext().getResources().getDrawable(R.drawable.ic_launcer); hierarchy.setPlaceholderImage(placeHolder, ScalingUtils.ScaleType.FIT_CENTER); hierarchy.setActualImageScaleType(ScalingUtils.ScaleType.FIT_XY); draweeView.setHierarchy(hierarchy); draweeView.setImageURI(uri);

여기서 Fresco 의 장점을 만나게됩니다. 내부적으로는 Glide 에서의 처리만큼 비슷한 동작을 하는지, 성능적으로 비슷한지도 꽤 중요하지만 사용성과 가독성 측면, 특히나 XML 에서 정말 가볍게 설정할 수 있는 부분은 너무나도 좋아보입니다.

3. 위에서 보듯 Fresco 의 보여주는 요소들을 다룰때의 장점들을 확인해봅시다.

둥근 이미지나 가장자리가 둥근 이미지를 보여줘 봅시다. Glide : BitmapTransformation 을 상속받는 클래스를 만들어서 직접 Bitmap 을 가공하여야 합니다. 이 때 Xfermode, PoterDuffXfermode, Canvas, Paint 등등 굉장히 많은 정보를 학습하여야 하고 케이스 별로 테스트를 해봐야 하는 리소스가 필요하게 됩니다.(개발자로서 당연한 얘기지만) 이 부분을 구글링을 통해 해결하거나 혹은 android support v4 에 추가된 RoundedBitmapDrawable 를 사용하여야 합니다.

Glide.with(getContext()) .load(url) .asBitmap() .centerCrop() .into(new BitmapImageViewTarget(imageView) { @Override protected void setResource(Bitmap resource) { RoundedBitmapDrawable circularBitmapDrawable = RoundedBitmapDrawableFactory.create(context.getResources(), resource); circularBitmapDrawable.setCircular(true); imageView.setImageDrawable(circularBitmapDrawable); } });

Fresco 에서는 둥근 이미지 보여주기가 너무나도 쉽습니다.

// XML fresco:roundAsCircle="true" // 원형 이미지 fresco:roundAsCircle="false" fresco:roundedCornerRadius="1dp" // 둥근 사각형 이미지 fresco:roundingBorderWidth="2dp" fresco:roundingBorderColor="@color/border_color" // 가장자리 색상, 사이즈 조 // Java code GenericDraweeHierarchy hierarchy = draweeView.getHierarchy(); RoundingParams roundingParams = RoundingParams.asCircle(); // 원형 이미지 RoundingParams roundingParams = RoundingParams.fromCornersRadius(2); // 둥근 사각형 이미지 hierarchy.setRoundingParams(roundingParams);

물론 내부적으로는 android support v4 에 추가된 RoundedBitmapDrawable 과 유사한 Drawable 을 만들어 사용되고 있지만 그것을 개발자가 신경쓰지 않을 수 있으니 정말 좋은 점이라고 보여집니다. GIF 이미지는 둥글게 보여지지 않습니다.

이미지의 외적인 부분을 다루는 것은 Fresco 가 아주 쉽게 해내어 줍니다. 웹에서 자주 보곤하던 이미지를 점진적으로 그려나가는 모습도 Fresco 로 해낼 수 있습니다. ProgressBar, overlay 등등 많은 부분을 취향껏 그려낼 수 있습니다. http://fresco.recrack.com/docs/using-drawees-xml.html <- 더 많은 부분을 확인 할 수 있습니다.

4. Fresco 의 단점같은 특징을 살펴봅시다.

첫번째로 Fresco 의 DraweeView 가 wrap_content 를 지원하지 않기 때문에 요청할 이미지의 사이즈가 절대적으로 필요합니다. 이럴 땐 ImageView 가 그려진 후에 로딩을 시작해서 View 의 크기만큼의 Resource 를 지원해주는 Glide 가 참 좋네요.(Thanks to Steve) 물론 디자인 적으로 적어도 이미지인 부분은 절대적인 수치가 필요하다고 개인적으로 생각하지만 GridView 나 몇 몇 레이아웃에서 match_parent 등이 필요한 경우가 많기 때문에 이 부분은 꽤나 신경쓰입니다. 게다가 원본 이미지가 어느 정도의 사이즈인지 판단이 불가능 한 경우도 있기 때문에 웬만한 경우엔 항상 ResizeOption 이 필요합니다.(Canvas 가 그릴 수 있는 최대치가 넘어버리면 "OpenGLRenderer: Bitmap too large to be uploaded into a texture" Exception 을 내기 때문입니다.)

ResizeOptions options = new ResizeOptions(20, 20); // Canvas 가 그릴 수 있는 최대 사이즈를 구해서 넘겨줘도 됩니다. ImageRequest imageRequest = ImageRequestBuilder.newBuilderWithSource(uri) .setResizeOptions(options) .build(); DraweeController controller = Fresco.newDraweeControllerBuilder() .setImageRequest(imageRequest) .setOldController(draweeView.getController()) .build(); draweeView.setController(controller); // 이런 단점을 조금이라도 보완하기 위해서 일정 비율로 크기를 지정해주는 메소드도 만들어 놓았네요. draweeView.setAspectRatio(1.33f);

두번째로 Fresco 에서 제공하는 CustomView 인 DraweeView 를 대부분의 곳에서 써야(만) 합니다. 이미지 Resource 를 동기적으로 받을 수 있는 방법이 없으며, 비동기적인 방식으로 콜백을 통해 받더라도 Fresco 의 주요 개념인 닫을 수 있는 참조, CloseableReference 를 제때 닫아줘야 하기 때문입니다. 많은 앱들은 Custom ImageView(PhotoView 라던지 PhotoView 라든지) 를 많이 사용할텐데 Fresco 의 주요 개념 중 하나인 ImagePipeLine 과 DataSource 를 이용해서 CustomView 에 Resource 를 붙이는 것이 어렵게 느껴질 수 있을 듯 합니다. 이미지 파이프라인 을 꼼꼼히 살펴보세요 !!

끝으로

Glide 와 Fresco. Glide 는 3.6.1 까지 release 되면서 사용하는 개발자들도 많아지고 솔루션 공유도 잘되고 있기 때문에 또 퍼포먼스 측면에서도 믿음직한 모습을 보입니다. Fresco 는 아직 0.8.1... 그렇지만 개발자의 손을 덜어주는 마법같은 사용성, 직관성, 제한적이긴 하지만 놀라운 퍼포먼스 등이 현재도 마찬가지, 앞으로도 엄청 기대되는 라이브러리 입니다.(Facebook 앱에 사용되고 있다는 사실이 느낌표를 만들어주네요!) 분명한 것은 둘 중에 뭐가 더 낫냐가 아니라 둘 중 어떤게 우리 앱에 맞냐 인 것 같습니다. 위에 나열한 Glide 의 문제점 같지 않은 문제점들에 비슷한 고민을 하고 계시다면 Fresco 로의 이전도 적극 추천합니다!

GCM Registration error

심카드가 없거나 폰 시간이 정상적이지 않으면

옥수는 안 변하는데 내 몸은 왜 이렇게 변하니요

삼탕 후 삼겹 삼각지 명화원은 늘 그랬듯 맛있었고 급으로 간 한남동 삼겹살 집은 뜻 밖으로 맛있었군

Android SDK Sample 파해치기 - ActionBarCompat-ListPopupMenuSample

Android SDK Sample 들 중 배우기 좋은게 생각보다 많아서

조금씩 들여다 보기로 함.

ActionBarCompat-ListPopupMenuSample 경로 : android-sdk\samples\android-19\ui 이다 android-studio 나 intellij로 Gradle Poject 임포트하면 에러가 날것이다. 안드로이드 스튜디오나 인텔리제이가 최신 버전이고 Gradle PlugIn이 최신버전이라는 가정하에 해당 프로젝트의 gradle\gradle-wrapper.properties 를 고쳐주어야한다.

(ActionBarCompat-ListPopupMenu\ gradle\gradle-wrapper.properties)

distributionUrl=http\://services.gradle.org/distributions/gradle-1.x-bin.zip 아마 gradle-1.x-bin.zip으로 되어 있을 텐데 gradle-1.10-all.zip 로 수정. 또 해당 어플리케이션 모듈

(ActionBarCompat-ListPopupMenu\ ActionBarCompat-ListPopupMenuSample)

에 build.gradle 파일도 수정해야한다.

buildscript { repositories { mavenCentral() }

dependencies { classpath 'com.android.tools.build:gradle:0.x.+' } }

gralde:0.x.+ -> gradle:0.8.+ 수정이 끝나고 다시 임포트 시켜주면 정상적으로 임포트 될 것.

리스트를 뿌려주고 리스트에 있는 설정버튼을 누르면 팝업메뉴가 뜨는 샘플. 쌩 Activity와 ListFragment로 구성 API 17부터(내 기억에..)추가된 android.support.v7 에 PopupMenu.class 를 이용한다. PopupMenu 에 menu를 inflate 하는 방법. 이런게 생겼는지도 몰랐네 ㅎㅎ.. 꽤 심플하고 대부분 아는 내용이지만 참고할만한 코딩스타일이 좀 있는듯.

Web - 실시간으로 UI 수정을 확인해보자(Yeoman)

1. Node.js 를 설치한다. (http://nodejs.org/)

2. yeaoman 을 설치한다. console 창을 열고 "npm install -g yo" 기다리면 설치가 끝난다. webapp이라는 generator가 필요하다. "npm install -g generator-webapp" 3. 설치가 끝나면 Web용 Project를 하나 생성한다. (원래 프로젝트가 있었다면 해당 경로로 이동) console 창을 열고 "yo webapp" 이것저것 설치를 한다. 기다린다. 설치가 끝나면 "grunt server" Alo Alo 화면이 뜨면 설치성공

4. Gruntfile.js 를 수정해야한다. 현재 grunt server가 기본적으로 제공되는 sample인 app/index.html을 가르키고 있다. Line.19 - grunt.initConfig({ yeoman:{ //app:'app'; app:'프로젝트 경로'; dist: 'dist'; } } Line. 29 - watch 부분 javascript경로, css 경로, html 경로, img 경로 수정 필요

Line.61 - connect 부분 hostname 수정 ex)'192.168.1.11'

5. console 창 열고 "grunt server" 웬 폴더구조 같은게 나올 것이다. 여기서 보고싶은 페이지 선택. Gruntfile.js 아래 쪽 살펴보면 기본 페이지 설정도 가능한거 같은데 시간도 없고 귀찮으니 패스 이제 css나 이것저것 수정해보자. ctrl+s(저장)을 누를 때마다 페이지가 바로바로 변경되는 것을 확인 할 수 있다. 모바일에서도 같은 대역대(공유기 와이파이이용 등등, 혹은 port가 열려있다거나)라면 바로바로 확인 가능하다.

참고 - https://developers.google.com/chrome/mobile/docs/webview/workflow

웹앱 만들 때 편하라고 구글에서 가이드 만들어 준듯 매우 좋다. 인텔리제이 Live Edit 플러그인 이라던지 브라켓 Live Edit 등등 보다 훨씬 더 좋다. 모바일에서도 실시간 확인 가능한게 진짜 짱인듯.

Listview with Multiple Item

리스트뷰에서 여러개의 item을 붙일 때

adpater는 항상 listview에 set되기 전에 여러개의 item을

사용할 준비를 해놓아야 한다.

ex)

x)listview.setAdapter(adapter);

adapter.setViewTypeCount(3);

o)adapter.setViewTypeCount(3);

listview.setAdapter(adapter);

ps. 멀티아이템 뿐만아니라 footerView, headerView... etc

이용할 때도 listview에 set되기 전에 모든 준비가 되어있어야한다.

Android FragmentTransaction And ViewPagerAdapter

FragmentTransaction.add -> Fragment.onAttach

FragmentTransaction.attach -> Fragment.onCreate(start lifecycle)

FragmentTransaction.detach -> Fragment.onPause

FragmentTransaction remove -> Fragment.onDetach

ViewPager 이용시 PagerAdapter는 Item을 메모리에서 제거 하지 않는다.

페이지의 갯수를 알거고 또 적을 때, 큰 작업이 아닐 경우에 사용하는 것이

이득.

이미지 갤러리 용 또는 큰 작업이 이루어지는 Item이 많은 경우

StatePagerAdapter 이용

안드로이드 최고의 라이브러리 Volley

https://gist.github.com/benelog/5981448

한글로 설명 되있는 걸 여태 왜 못본걸까?

안드로이드 키스토어 sha1 가져오기

매 번 구글링하기 귀찮아서

keytool -list -v -keystore 키스토어명 -alias "Alias" -storepass "KeyStore Password" -keypass "Key Password"

포스트 10개

#10 posts #tumblr milestone

Fragment 내부 Fragment

어쩔수없이... Fragment내에 내부 Fragment가 존재해야하고 내부 Fragment가 FragmentManager를 통해 add혹은 replace되야 한다면

"부모(상위) Fragment가 detach 될 때 자식(하위) Fragment를 꼭 컨트롤 해줘야한다." 자식 Fragment를생명주기를 탈수 있게끔 컨트롤 해줘야한다. 그렇지 않으면 계속 살아있게(?) 되고 어떠한 생명주기도 타지 못하게 된다.

이유는 모든 Fragment는 Activity에서 관리하기 때문

Trending Blogs

Recently Viewed Blogs

-___-