[RxAndroid] Basics: Part 1 – (1)

RxJava를 공부하면서 참고한 사이트를 번역(70%) + 나름의 이해한 내용(7%)으로 이루어진 포스팅입니다. 번역하기 애매한 것들이나, 하지 않는 게 더 자연스러울 문장들은 생략하였습니다.

참고한 사이트 : [번역]RxAndroid Basics: Part 1
RxJava with Android -1- RxJava 사용해보기

Welcome friend! So glad to see you! 너는 RxJava에 대해서 그리고, 이것이 Android에서 어떻게 적용되는지 궁금하다. 아마도 너는 이것이 사용되는 것을 몇몇 곳에서 봤겠지만, 너는 여전히 혼란스럽고 설명을 원한다.Well look no further!

내가 처음 RxJava를 접했을 때 나는 대부분 이것에 대해 Cargo coding[코드에 대한 이해없이 복붙]을 했다. 어떤 부분은 이해가 되었지만, 나는 기본 원리들에 대해 깊은 오해를 했다.또한, 나는 도대체 무슨 일이 일어나고 있는 지에 대해서 설명하는 좋은 예시의 부족함에 좌절했다.  RxJava를 완벽하게 이해하기 위해서, 나는 엄청나게 몰두했고, 많은 시도와 오류를 경험해야만 했다.

In an effort to save you, the cherished reader, some leg work, 나는 내가 발견한 것에 기인하여 몇몇의 예시를 서둘러 준비했다.  The hope is these examples will provide you with the necessary knowledge to begin using RxJava in your Android apps.

이 예시들은 완전한 기능을 하는 sample app으로 이곳에서 모두 찾을 수 있다.  각 예시의 처음에, 뒤따르는 code snippets이 있는 명확한 활동을 링크로 걸겠다. 나는 예시를 두 부분으로 나누기로 정했다. 첫번째 부분에서는, 우리는 RxJava의 사용에, 특히 비동기식 data load에, 초점을 맞춘다. 두번째 부분에서는 advanced usage patterns에 대해서 알아본다.

 

Some Concpets

nitty gritty[핵!심!]으로 들어가기에 앞서, 기초적인 개념들부터 시작하자. RxJava는 두가지가 핵심이다: ObservablesObservers. Observables are said to “emit” values. Their counterpart, Observers, watch Observables by “subscribing” to them.Observable들은 값들을 “방출”한다. 그것들에 대응하는 Observer들은 Observable들을 “구독”함으로써 감시한다(지켜본다).

rxJava

Observers는
1. Observable이 값을 방출할 때,
2. 그 Observable이 오류가 발생했다고 할 때,
3. 또는 그 Observable가 더이상 방출할 값이 없다고 할 때,
행동을 취한다. 이 세 가지의 모든 행동들은 Observer interface에서 압축된다. 이에 해당하는 함수들은
onNext(), onError(), and onCompleted() 이다.

위의 내용들을 명심하면서, 몇 개의 예시들을 살펴보자.

Example 1: The Basics

색깔의 목록(list)을(를) 간단하게 보여줄 수 있는 Activity를 만들어보자. 우리는 하나의 값(a list of strings) 을 방출하고, 완료하는 Observable 만들 것이다. 우리는 방출된 값을 목록(list)을(를) 구성하는 데 사용한다. 우리는 이것을 Observable.just() 를 사용해서 한다. This method creates an Observable such that when an Observer subscribes, the onNext() of the Observer is immediately called with the argument provided to Observable.just(). onComplete()Observable이 더 이상 방출할 값이 없기 때문에 불려진다.

ObservableListString listObservable = Observable.just(getColorList());

Note that getColorList() is a non-blocking method call. This may not seem important now, but we’ll come back to it later.

다음으로, 우리는 Observable을 감시하는 Observer를 만든다:

listObservable.subscribe(new ObserverListString() { 

   @Override
   public void onCompleted() { }

   @Override
   public void onError(Throwable e) { } 

   @Override
   public void onNext(ListString colors) {
       mSimpleStringAdapter.setStrings(colors);
  }
});

This is where the magic happens. As mentioned above,  upon subscribing to the Observable with the subscribe() method the following happens immediately, in this order:

Observable을 subscribe()method로 구독하자마자, 아래 내용이 순서대로 즉시 발생한다.

  1. The onNext() method is called and the emitted list of colors is set as the data for the adapter.
  2. Since there is no more data (we only gave our Observable a single value to emit in Observable.just()), the onComplete() callback is called.

나는 용어에 따르면 Observable은 subscription에 달려있음에 대해서 생각하는 것이 유용한 것을 알았다. 사실, Observables는 주로 그들의 subscription에 따른 행동에 의해 정의된다. Let’s take care to remember this, as it will come in handy later. I’m going to state it again since it’s so important:

Observables are primarily defined by their behavior upon subscription.

우리는 onComplete() method를 공백으로 두었기 때문에, 이런 경우에 Observable이 완료되었을 때언제 발생했는지에 대해서는 신경쓰지 않아도 된다. 우리는 onError() method 또한 비어있기 때문에,오류를 받을 방법도 없다.

모든 것이 지나치게(overkill) 보일 수도 있다. We could have just set the color list on our adapter directly. But with this in mind, let’s take a look at something a little more interesting.

Advertisements

[Android] Thread + handler (1)

1. 왜 Thread를 사용해야 하는가?

예를 들자면, 음악을 다운로드 받으면서 웹툰을 보고 싶다. Thread를 사용하지 않으면, 음악을 다운로드 받는 동안 이 작업이 끝날 때까지 기다렸다가 웹툰을 봐야해서 매우 비효율적이게 된다. 간단히 말해서, 다수의 작업을 동시에 진행하기 위해서 사용된다.

2. Main Thread == UI Thread

UIupdate를 할 때는 꼭 Main Thread가 해야 하기 때문에 Main Thread를 UI Thread로 부르기도 한다.

3. Handler는 왜 필요한가?

예를 들어, 인터넷에서 날씨 정보를 가져와서 화면에 나타내고 싶다면, 인터넷에서 정보를 가져오는 데 걸리는 시간을 고려해서 이를 새롭게 생성한 Thread에서 처리하도록 한다. 문제는 이 다음인데, 가져온 정보를 어떻게 UI에 update하느냐 이다. 열심히 일하고 있는(인터넷에서 날씨 정보를 가져오는) Thread에서 작업의 종료를 UI update 를 담당하는 Thread로 알려주면 좋을텐데! Handler를 이용하면 Thread끼리 통신할 수 있다.

4. 정리

THREAD.png

[Android] Android Development for Beginners (1)

 [내용정리]  Android Development for Beginners LESSON 1

  • TextView (View)

tips_text_view.png
참고 : android developers #androidDev #protip

  • ImageView (View)

android:scaleType=”centerCrop”

-orientation : vertical / horizontal
-width , height , weight
android:layout_height of each view to "0dp" (for a vertical layout) or the android:layout_width of each view to "0dp" (for a horizontal layout). Then set the android:layout_weight of each view to "1".

-기준 : <Top, Left>
-attributes의 default 값은 false ;
-centering attributes : layout_centerHorizontal/VerticalRelativeLayout
-그리는 순서에 영향을 받는다Overlapping

  • Padding   VS   layout_marginpadding_margin

 

[Android-Studio] 안드로이드 프로젝트 구조 (1)

1. Android Project Files

Android Studio project files and settings provide project-wide settings that apply across all modules in the project.


 

android_project_structure

  • .idea
    Directory for IntelliJ IDEA settings.
  • app
    Application module directories and files.
  • build
    This directory stores the build output for all project modules.
  • gradle
    Contains the gradler-wrapper files.
  • .gitignore
    Specifies the untracked files that Git should ignore.
  • build.gradle : 빌드 스크립트 파일로, 보통 여기에는 프로젝트 내 모듈들의 빌드 진행시 공통으로 적용해야 하는 설정들을 적어준다.
    Customizable properties for the build system.
    Edit the dafault build settings used by the apllication modules and also set the location of your keystore and key alias[파일. 인터넷 주소 등에 쓰는 가명] so that the build tools can sign your application when building in release mode.
    This file is integral to the project, so maintain it in a source revision control system
  • gradle.properties
    Project-wide(?) Gradle settings.
  • gradlew / gradlew.bat : Gralde wrapper[빌드에서 사용하는 Gralde 툴을 편리하게 사용할 수 있도록 도와주는 일종의 스크립트. 적절한 Gradle 바이너리를 자동으로 다운로드 해주므로, 별도로 Gradle을 설치하지 않아도 빌드를 진행할 수 있도록 해준다.]를 통해 빌드를 진행하기 위한 스크립트이다.
    Gradle startup script for Unix / Windows.
  • local.properties : 빌드를 진행할 때 필요한 환경변수 정보를 저장한다. 안드로이드 SDK의 경로가 여기에 저장된다.
    Customizable computer-specific properties for the build system, such as the path of the SDK installation. Because the content of the file is specific to the local installation of the SDK, the local.properties should not be maintained in a source revision control system.(?)
  • .iml : 안드로이드에서 사용하는 프로젝트 설정 파일이다.
    Module file created by the IntelliJ IDEA to store module info
  • settings.gradle : 빌드와 관련된 환경설정 및 같이 빌드되어야 할 하위 모듈들의 정보를 포함 한다.
    Specifies the sub-projects to build

2. Android Application Modules

Android Application Modules are the modules[어플리케이션이나 라이브러리를 구성하는 최소 단위. 독립적으로 존재할 수 없고, 항상 프로젝트 내에 포함되어야 한다.] that eventually get built into the .apk files based on your build settings. They contain things such as application source code and resource files. Most code and resource files are generated for you by default, while others should be created if required.


The following directories and files comprise an Android apllication module :

android_project_structure2.png

  • build : 빌드 과정에서 생성된 파일(R.java 등) 및 최종 산출물(*.apk) 저장.
  • src : 소스 및 리소스 파일 저장.
    ***main[왜 필요할까 ?]
  • src > main> java
  • src > main> res
    android_project_structure3
  • src > main> AndroidManifest.xml
    This file describes the nature of the application and each of its components.
  • build.gradle : 모듈의 빌드 방법이 정의된 빌드 스크립트. 빌드에 사용할 SDK 버전, 애플리케이션 버전, 사용하는 라이브러리 등 다양한 항목 설정이 가능.
    Customizable properties for the build system.
  • .iml : 안드로이드 스튜디오에서 사용하는 모듈 설정 정보이다.

 

[ArchitecturePattern] #MVC #MVP #MVVM (1)

Model과 View

  • Model
    보통 data 그 자체와 동일시 되지만, 이외의 데이터를 조작할 수 있는 기능이 추가되기도 한다. 구현과 상황에 따라서는 단순히 data source에 접근하는 DAO 역할을 하거나, 파일 시스템 자체가 되거나, 라이브러리 세트가 된다.
  • View
    사용자에게 제공되는 UI Layer. 보통 Web Application 등에서는 View는 HTML/CSS로 렌더링된 화면을 가르킨다.
  • MVC를 비롯한 여러 프레임워크들이 나온 이유는 명확하다. 각 계층의 분리로 재활용성을 높이고 중복을 막자는 것이다. 이 둘의 의존성을 어떻게 제어하느냐에 따라 MVC, MVP, MVVM등으로 나뉘게 된다.

Controller, Presenter, ViewModel ???

  • Controller
    모든 입력은 Controller에서 처리한다. 특정 입력이 들어오면 Controller는 그 입력에 해당하는 Model을 선택하여 처리하게 한다. Controller는 입력에 따라 Model을 업데이트 하고, 결과에 따른 View를 선택한다. Controller는 View를 선택할 수 있기 때문에 여러 개의 View를 관리할 수 있다.일반적으로 View는 Model을 사용하여 업데이트를 하지만, Model을 관리하는 것은 Controller 이므로 사실상 View는 Model을 직접적으로 생성하거나 관리하는 것은 아니다.Controller는 Model을 조적하고 View를 선택하지만 View를 직접 업데이트 하지는 않는다.
    이 경우에는 View와 Model의 관계가 어느정도 있으며, 이 MVC의 문제점은 View와 Model의 의존성을 피할 수가 없다는 것이다. MVC의 좋은 구성은 이둘의 의존성을 낮추는 게 관건이라 할 수 있다.
  • Presenter : View와 Model 사이의 상호작용
    입력처리 담당은 View이다.View가 Event를 Presenter에 전달하면, Event에 맞춰 Presenter는 Model을 조작하고 그 결과를 다시 View에 바인딩하여 View의 요소들이 업데이트 된다.Controller는 단순히 View를 선택하고 Model을 조작한 뒤 실제 화면 갱신은 View와 Model의 상호작용으로 이루어지지만 Presenter를 사용한 MVP에서는 Presenter가 Model을 조작하고 관리하며 변경이 있으면 Model에 따라 View를 업데이트하게 된다.

    View와 Presenter는 1:1 관계로 맺어지며 Presenter는 보통 Model보다는 View에 더 닮은 구조로 디자인된다. MVC와는 다르게 View와 Model의 관계가 전혀 없어지므로 View와 Model의 의존관계가 완전히 사라진다.

     

  • ViewModel : View의 표현을 담당한다
    MVP와 매우 비슷하지만 큰 차이점이라면 비중이 View에 조금 더 치우쳐 있다는 점이다. Presenter는 View에 상당한 의존성이 있었지만, ViewModel은 View와 아무런 관련이 없다.여러 View들은 하나의 ViewModel을 선택하여 바인딩하고 업데이트를 받는다.ViewModel의 디자인은 View보다는 Model에 비슷하게 구성된다. 보통 ViewModel이 변경되면 자동으로 View에 업데이트되는 방식으로 구현된다. ViewModel은 View를 위한 모든 customizing을 제공하는 Model이다.

MVC 패턴은 Web Application에서 다루어보아서 무슨 말인지 이해가 된다. 특히 MVC에서 View와 Model의 의존성 문제에 대해서는 공감한다. 설명만으로는 MVP와 MVVM 패턴을 완전히 이해하기는 어려운 것 같다. 다음번에 이 두 패턴에 관해서 적당한 예시를 들어서 공부하고  포스팅해야 겠다.

참고
1. MVC, MVP and MVVM
2. MVC, MVP, MVVM 의 이해
3. MVVM 패턴에 대해서