And "roid"

안드로이드는 프로그래밍 스킬 + 디자인 패턴까지 배울 수 있는 만병 통치약이다. 삼성 최초의 안드로이드 디바이스 P1 개발을 시작으로 IPC, RIL, Framework, 보안 모듈, Application 경험은 하였지만, 사실 기억이 잘 안 난다. 트러블 슈팅을 어떻게 해야 할지에 대한 감만 남은 상태. 




Framework 아랫단(프레임웍 커널, IPC, RIL, 등)은 대부분 C/C++로 구성되어 있고, 삼성/LG와 같은 대기업 소속 연구원이 아니면 접해보기 어렵다. 시대가 변해도 바뀌지 않는 ARM architecture 기반의 Instruction set과 CP(모뎀칩)에 S/W가 쌓이기에 별다른 것은 없겠지만 최신 트렌드를 따라가기 위해 Application에 집중하기로 한다. 거대한 Android에서 사실 개인이 한 분야만 해도 따라가기 힘든데, Android/iOS, Embedded, WEB(Node.js, React)을 병행해야 하는 개발자에게는 버겁다. 간단히 말하면 능력이 안된다는 말. 유순하게 표현하면 능력 밖, 좋게 포장하면 전문성을 위한 포기 정도로 보면 되겠다. 현실을 그렇더라도 염세주의는 좋아하지 않으니 시작과 끝은 Android Application으로 하자.





한 3년간은 iOS를 하느라 Android 지식이 옛날 지식밖에 없어서 새로운 게 뭐가 있을지 조금 둘러보게 되었다.



Material Component

머티리얼 디자인은 나온 지 꽤 오래되었지만 대부분 사용하지 않는 듯하다.




Transformation

Top App Bar

Text Field

Tabs

Fonts

Floating Action Button

Chips

Cards

Buttons

Button Navigation

Bottom App Bar




다시 기본기를 다져야겠다.



Fragment, NDK

안드로이드 화면 한 장 한 장은 Activity라는 단위로 구성된다. 물론, 하나의 화면을 꼭 하나의 Activity로 구성할 필요는 없다. SlotView 형식으로 하나의 Activitiy 에 여러 화면을 올려도 되고, setContentView를 이용한 xml 구성이 아닌 코드로 구성해도 된다. 혹은 엔진을 얹여 해당 framework을 이용해도 되겠다. 그러나 기본적인 앱은 안드로이드가 제공하는 기본을 따르는 것이 좋고, 예전에는 Activity에 Relative Layout이나 FrameLayout을 기본으로 한 xml을 썼다면, 지금은 Fragment로 구성한다는 것을 알면 된다. 그렇다. Fragment는 Fragment가 있기 이전 Activity 전환 시 생기는 깜빡임 현상을 줄이기 위해 만든 slotView에서 발전하여 안드로이드가 공식 지원하는 레이아웃이 되겠다. 그리고 기기별로 따로 코드로 따로 구성해 주어야 했던 힘듦도 사라졌다. 태블릿에서는 Fragment를 2개 보여주고, 폰에서는 1개만 보여주고 화면 전환이 가능하도록 하였다. 여기서 말하는 레이아웃은 안드로이드에서 말하는 레이아웃이 아닌 어도비 포토샵의 레이아웃으로 보면 되겠다. 갈아 끼우는... 중첩은 되지 않는 replace로 바꿔야 한다.




1.0 이전은 Eclipse에 비해 못쓸 수준이던 Android Studio도 많은 버전업을 거치면서 gradle, cmake, NDK 및 여러 예제가 포함되었다. gradle은 Ant, Maven 보다 향상된 자동화 도구인데 정말 작년부터는 gradle이 모두를 대체한다고 봐도 무방할 정도로 편리하고 안정적이 되었다. cmake는 다양한 플랫폼에 빌드용 project 파일을 만들어주는 녀석이다. 버추어 버신, 아니 달빅, 아니 L, 아니... 안드로이드 프레임웍에서는 문제없지만 C/C++은 기본적으로 UNIX만을 위해, 또는 각자의 머신에 종속되어 있던 태생이 있으므로 cmake를 결합하여야 한다. 안드로이드 프레임웍과 애플리케이션도 혼자 짜면 자바를 이용 안 해도 되겠지만 이미 만든 프로그램도 많고, C/C++은 강력하기에 그것들을 연결한 NDK도 필수. 이제 레퍼런스 보면서 API 찾아서 잘 쓰면 된다.




Fragment로 구성된 앱의 기본 구조를 살펴보자.




엔트리 포인트는 AndroidManifext.xml이다.

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




해당 엔트리 포인트에서

setContentView(R.layout.activity_entry_point);

xml 레이아웃을 세팅한다.




세팅된 레이아웃에서 

<include layout="@layout/content_entry_point" />

다른 레이아웃을 불러오고




해당 레이아웃에서 Fragment를 설정한다. 연결된 JAVA 파일을 설정해 준다는 뜻

<fragment xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/fragment"
android:name="com.hajunho.odroid.odroidcontroller.EntryPointFragment"
android:layout_width="match_parent"
android:layout_height="match_parent"
app:layout_behavior="@string/appbar_scrolling_view_behavior"
tools:layout="@layout/fragment_entry_point" />




해당 파일에서는 다시 xml를 불러와 펼쳐준다.

public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
return inflater.inflate(R.layout.fragment_entry_point, container, false);
}




복잡하게 연결하지 않더라도 Fragment를 상속받은 블라블라Fragment를 만들고

instance블라블라Fragment = new instance블라블라Fragment();

getSupportFragmentManager().beginTransaction().add(R.id.container, instance블라블라Fragment).commit();




붙이는 container는 간단한 FrameLayout으로 구성하면 되겠다.

<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/container"
android:layout_width="match_parent"
android:layout_height="match_parent">
</FrameLayout>




NDK는 Android Studio가 버전업을 하면서 기초 코드가 작성된 상태로 나오고 내부에서 자동 빌드가 가능했다. C 파일이 내부에서 있어서 변형하면 바로 적용이 되었다. 따로 컴파일해서 so 파일 만들고 연결 브릿지 만들지 않아도 되니 무지하게 편했다 ㅠㅠ 대기업 선행 개발의 삽질을 안해도 되니 이제 플랫폼이 나오면 성숙되기를 기다렸다가 들어가는게 좋을 것 같다. (물론, 돈과는 멀어지겠지)



Dagger2 Fragment 

요새 유행하는 "위존성 주입"을 위한 Fragment를 만들어 보았다. 의존성 주입은 같은 코드를 계속 적어야만 하는 번거러움을 없애고자 기존 모듈에 @블라블라 와 같은 annotation 만 적으면 다른 곳에서 @ annotation을 이용하여 모듈처럼 불러 쓸 수 있게 만든 것이다. 사실 싱글톤으로 만들고 생성 코드를 Factory나 Builder 패턴을 이용해서 만들어 두면 되는데, 유행은 따라야 편해보이고 어려운 개념을 많이 쓸 수록 연봉은 올라간다. 보일러 플레이트 코드를 줄이는 방법이 Dagger2 밖에 없으랴? 간단히 라이브러리로 만들면 될 것을 ^^;;




우선, app 바로 밑에 있는 build.gradle에 다운로드 코드, 아니 디펜던시 코드를 추가한다.

dependencies {

api 'com.google.dagger:dagger:2.15'
annotationProcessor 'com.google.dagger:dagger-compiler:2.15'
api 'com.google.dagger:dagger-android:2.15'
api 'com.google.dagger:dagger-android-support:2.15'
annotationProcessor 'com.google.dagger:dagger-android-processor:2.15'
api 'com.android.support:multidex:1.0.3'

.

.

.

이제 

import dagger.android.support.DaggerFragment;

만 해주면 DaggerFragment를 이용할 수 있다.




public class MainFragment extends DaggerFragment {
}




https://www.androidhuman.com/life/2016/06/06/dagger2_resources/
Dagger2 학습에 필요한 참고자료

#Android and #Koltin

www.androidhuman.com


여기서 youtube 강의는 dagger가 뭔지 한번에 알 수 있게 해 주었다. 인터넷에서 찾은 머티리얼 디자인 예제 소스도 Dagger2를 이용하여 구현되어 있었다.



Image Loading Library

메모리가 작은 안드로이드에서 가장 골칫 거리는 Image Loader였다. 초창기 버전의 유니버셜 이미지 로더는 이제 다른 프로젝트에 가려지게 된 것 같다.

http://gun0912.tistory.com/17
[안드로이드/Android]유용한 라이브러리 - Glide (이미지 로딩 라이브러리)

우리가 ImageView에 사진을 띄우고자 하는 경우는 여러가지 입니다. 1. 안드로이드 앱 안의 drawable폴더의 리소스를 보여주는 경우 2 .안드로이드 디바이스 안에 저장되어있는 사진을 보여주는 경우(갤러리 혹은..

gun0912.tistory.com





잠깐만 둘러보아도 많은 것이 변형되었지만 1주일간 이것저것 만들다 보니 딱히 크게 변화된 사항도 또 없는 것 같다. 어차피 자바라는 프로그래밍 언어 테두리에서 벗어나지 않아서 그런가?



코틀린

모르는 프로그래밍 언어다. 새로운 언어가 있다고 해서 우선 repository를 찾았다.




https://github.com/JetBrains/kotlin
JetBrains/kotlin

kotlin - The Kotlin Programming Language

github.com


소스 받아서 확장자부터 보았다. cpp, hpp, c, h 파일은 없고, java와 kt가 대부분.

자바로 만들어졌구나, 그래서 이런 생각이 들었다.

자바에서 더 추상화한 언어라면 더 적은 코드로 원하는 것을 구현할 수 있겠네? 그 대신 앱의 복잡도가 증가할수록 트러블 슈팅은 더 어려워지겠네? 어라? 인텔리 J 만든 JetBrain사에서 만들었구나. 새로운 언어에 대한 도전으로 Android Studio를 이용해서 접근하는구나... 어차피 오라클 때문에 JDK가 아닌 OpenJDK로 간 구글도 JAVA보다는 코틀린을 밀테니 아랫단에서 C++코드로 구현해서 상위단으로 올린 Android API는 코틀린에서 다 지원하겠네? JNI, NDK만 되면 C++ 코드도 다 쓸 수 있으니 향 후 에는 결국 코틀린으로 가긴 하겠다는 생각. 왜냐면 모바일은 포토샵이나 AutoCAD 같은 거물급 앱은 없어서 킬러앱이 프레임웍의 방향성을 좌지우지 하지는 못하기 때문이다.




https://try.kotlinlang.org/#/Examples/Hello,%20world!/Simplest%20version/Simplest%20version.kt
Try Kotlin

Try Kotlin right in the browser.

try.kotlinlang.org





코드를 좀 보았다. 결국 양자 컴퓨터 이전의 컴퓨터 언어는 다 거기서 거기구나 괜히 더 햇갈리기만 하겠구나... 라는 생각이 들었다.




결국, 언어에 대한 입맛보다는 해당 프로젝트를 어떤 언어로 구현하기로 결정했고 다른 프로그래머들과 어떤 언어로 소통할지 정해지는 프로젝트가 더 중요하다는 생각이 들었다.




Android/iOS 두 가지 지원 때문에 폰갭이 나왔었고, XML, XAML 개념, 그리고 React native까지...

그러나 두 회사가 하나의 회사는 아니기에 결국 Native 앱은 Native로 만들어야 한다는... 뭐 FACEBOOK이 Google이나 Apple에게 압력을 줄 정도면 모르겠지만.




일전에 안드로이드 폰을 통일한 삼성이 따로 삼성 앱스토어를 만들고 기본 배포하려고 할 때 구글에서 인증을 해주지 않겠다는 협박을 했었다. 세상은 그렇다. 코볼 엔지니어가 아직 나보다 더 많은 연봉을 받는 이 시대에 굳이 유행을 따를 필요는 있으랴?




Android는 아직 자바로 충분하다. 그러나 분명 나중에는 버릴 것 같다. 애플도 SWIFT 공식 언어를 내고 아직까지 Objective-C를 지원하고 있다. 둘 다 사용해보니 마이그레이션 되는 코드도 있고, 안 되는 코드도 분명 있더라. 그러나 기본 기능은 확실히 SWIFT로 다 만들 수 있다. 코틀린도 그런 것 같다. iOS 앱은 마이그레이션 하다가 swift 코드와 objective-c 코드가 공존하게 되었는데 알 수 없는 링크 에러 때문에 더 진행하지 못하는 부분이 있었다. 물론, 프레임웍까지 디버깅하거나 ICE 물려서 더 아래단까지 보고 누구 잘잘못 따질 시간적, 경제적 비용, 권한도 없다.




Android는 자바에서 코틀린으로 바뀌겠지만 한방에 마이그레이션 될리는 절대, 절대 없다. 구글이 꽤 큰 프로젝트들에 대한 소스 접근 권한이 있어서 대부분 테스트 해 보지도 못할 테고 한 명이 짠 것도 아니어서 완벽한 이론에 기초될 리도 없다. 물론, 같은 목적과 수준의 앱이라면 구글이 마이그레이션을 장려하거나 그 앱의 편을 조용히 들어줄 것이다.(검색이 더 잘되게 한다던가 -> 페이스북에서 페이스북 동영상은 youtube 링크보다 10배 더 많이 퍼지게 해 놓은 것이랑 같은...)




개인적인 생각이지만,

너무 계속해서 새로운 언어가 나오다 보니, 이제 기본기는 C++로 회귀할까 생각 중이다. 필요한 프로젝트가 C++ 이 아니더라도 프로젝트 완성하는 데는 큰 어려움이 없으니까 말이다. 상위단에서 구현되는 새로운 개념을 LOW LEVEL 언어로 구현하면 "정수"를 알 수 있기도 하고 말이다.




시간을 어디 배분하느냐의 차이겠다. 남는 시간에 오버워치를 할 것 인가... 좀 더 NERD 하게 될 것인가.