1. 프로세스(process)란?

프로세스(process)는 단순히 실행 중인 프로그램이라고 할 수 있다. 즉, 사용자가 작성한 프로그램이 운영체제에 의해 메모리 공간을 할당받아 실행 중인 것을 말한다. 프로세스는 프로그램에 사용되는 데이터와 메모리 등의 자원 그리고 스레드(thread)로 구성된다.

2. 스레드(thread)란?

스레드(thread)는 프로세스(process) 내에서 실제로 작업을 수행하는 주체를 의미한다. 모든 프로세스에는 한 개 이상의 스레드가 존재하여 작업을 수행한다. 또한, 두 개 이상의 스레드를 가지는 프로세스를 멀티 스레드 프로세스라고 한다.

🤷 스레드(thread)를 사용하는 이유?

안드로이드의 UI 작업은 메인 스레드에서만 이루어져야 한다. 하지만 만약 서버 통신이나 DB 작업같이 무거운 작업을 메인 스레드에서 작업하게 된다면 UI 작업이 멈추게 되고 그러면 모든 UI 이벤트가 작동하지 않고 애플리케이션이 중단된 것처럼 보이게 된다. 이러한 오류를 방지하기 위해 서버 통신이나, DB 작업과 같은 작업을 하는 워커 스레드가 필요하다.

📌 Looper, Handler 그게 뭔데?

1. Looper란?

하나의 스레드(thread)는 오직 하나의 Looper를 가진다. Looper는 MessageQueue를 가지고 있는데, 이 MessageQueue는 해당 스레드가 처리해야하는 동작들이 메시지 형태로 저장된다. 그리고 저장된 메시지를 꺼내서 적절한 Handler로 전달하는 역할을 한다.

메시지(Message)란 무엇일까?

메시지(Message)는 스레드 통신에서 Handler에 데이터를 보내기 위한 클래스이다. MessageQueue 에는 메시지들이 큐 형태로 저장되어있고, Looper가 메시지들을 차례대로 처리한다.

Message객체는 내용물이 Runnable객체나 Message객체 두 가지 종류로 이루어져있다. Runnable객체는 Handler에 메시지를 전달하지 않고 run()을 통해 Runnable 작업을 바로 시작한다. Message객체는 내부에 명시되어있는 Handler의 handleMessage()를 수행하여 처리한다.

2. Handler란?

Handler는 특정 메시지를 Looper의 MessageQueue에 추가하거나, 특정 메시지를 꺼내어 전달하면 이를 처리하는 역할을 한다. 쉽게 말하면 Looper와 MessageQueue의 중간다리 역할을 한다.

메시지를 전달하는 경우

sendMessage() 메서드를 통해 메시지 큐에 Message객체를 전달한다. post() 메서드를 통해 Runnable객체를 전달한다.

메시지를 전달받는 경우

Runnable객체라면 run() 메서드를 호출해서 작업을 실행한다. Message 객체라면 handleMessage() 메서드를 호출해서 메시지를 전달받는다.

🌊 동작 흐름 살펴보기

1. 워커 스레드에서 Hanlder의 sendMessage()를 통해 메인 스레드의 Looper의 MessageQueue에 메시지를 전달한다.
2. 메인 스레드의 Looper는 MessageQueue의 메시지 하나를 Handler에 전달한다.
3. Handler에서 handleMessage()를 통해 메시지를 처리한다.

💻 Thread를 사용해보자

1. Handler

// 메시지를 전달받는 경우
class MyHandler : Handler() {
    override fun handleMessage(msg: Message) {
        super.handleMessage(msg)
        // 다른 Thread에서 받아온 message 처리 구문 작성
    }
}

// 메시지를 전달하는 경우
val handler = Handler()

handler.post {
    // 해당 handler와 연결된 thread에 전달할 runnable 객체 내부 코드 작성
}

// 해당 handler와 연결된 thread에 message 객체 전달
handler.sendMessage(message)

2. Looper

class MainActivity : AppCompatActivity() {

    private lateinit var handler: Handler

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val myThread = Thread {
            Looper.prepare() // Looper 준비
            handler = Handler() // myThread의 handler 생성
            Looper.loop() // Looper 시작(동작)
        }
        myThread.start() // myThread 시작
    }

    override fun onDestroy() {
        super.onDestroy()
        handler.looper.quit() // Looper 종료

        // handler.looper.quitSafely() - MessageQueue의 모든 작업 수행 후 Looper 종료
    }
}

위와 같이 수동으로 Looper객체를 생성하는 번거로움을 피하기 위해, 안드로이드에서는 Thread를 상속한 Handler클래스인 HandlerThread 클래스를 제공한다. HandlerThread는 내부에서 Looper.prepare(), Looper.loop()를 수행해준다.

class MainActivity : AppCompatActivity() {

    private lateinit var handlerThread: HandlerThread

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        handlerThread = HandlerThread("thread_name")
        handlerThread.start() // HandlerThread 시작 및 looper 시작
    }

    override fun onDestroy() {
        super.onDestroy()
        handlerThread.quit() // HandlerThread looper 종료
    }
}

참고한 블로그 https://velog.io/@haero_kim/Android-Looper-Handler-%EA%B8%B0%EC%B4%88-%EA%B0%9C%EB%85%90 https://jungwoon.github.io/android/2019/09/25/Handler-Looper.html https://hungseong.tistory.com/26

소프트웨어 개발 아키텍처 패턴중 하나인 MVVM 아키텍처 패턴에서 파생된 개념으로 View와 Model 사이에서 매개체 역할을 하고, View의 데이터를 관리하는 역할을 한다.

AAC ViewModel 이란?

Anroid Architecture ViewModel의 약자로, 생명주기를 고려하여 UI와 관련된 데이터들을 저장하고 관리하는 역할을 하는 Android Jetpack의 구성요소이다.

ViewModel이 필요한 이유?

UI 컨트롤러의 데이터를 캡슐화하여 구성이 변경되어도 데이터를 유지하고, 과도한 책임을 분담하여 유지보수, 재사용성, 테스트 등을 용이하게 만들어 준다.

ViewModel의 생명주기

ViewModel은 Activity처럼 생명주기를 가지고 있다. ViewModel의 생명주기는 Activity가 생성될 때 시작 되고 Activity가 종료될 때 함께 종료된다.

생명주기가 Activity에 비해 단순하기 때문에 앱이 갑자기 전화가 걸려오거나, 화면 회전이 발생하는 경우에도 데이터를 보존할 수 있다.

ViewModel 요청 과정

Activity나 Fragment 같은 UI 컨트롤러에서 ViewModel을 사용하기 위해서는 ViewModelProvider를 통해 ViewModel과 Activity, Fragment를 연결 해줘야한다. 만약 ViewModel 인스턴스가 이전의 요청으로 생성되어 있다면 ViewModelProvier는 ViewModelStoreOwner를 참조해 ViewModelStore에 생성되어 있는 ViewModel 인스턴스를 반환한다. ViewModel 인스턴스가 생성되어 있지 않다면, ViewModelProvider.Factory를 통해 ViewModel 인스턴스를 생성한 후 ViewModelStore에 저장하고 생성된 ViewModel 인스턴스를 반환한다.

ViewModel 사용법

먼저 AAC ViewModel을 상속받는 ViewModel 클래스를 생성한다.

class MainViewModel : ViewModel() {
    ...
}

이렇게 생성한 ViewModel을 사용하기 위해서는 2가지 방법이 있다.

1. ViewModelProvider 사용

첫번째는 위에서 설명한 ViewModelProvider를 이용한 초기화 방법이다.

class MainActivity : AppCompatActivity() {
    // by lzay 사용
    private val viewModel1: MainViewModel by lazy { 
        ViewModelProvider(this).get(MainViewModel::class.java)
    }
    // lateinit var 사용
    private lateinit var viewModel2: MainViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        viewModel2 = ViewModelProvider(this).get(MainViewModel::class.java)
    }
}

2. by viewModels() 사용

2번째는 AndroidX의 KTX 모듈을 사용한 초기화 방법이다.

먼저 모듈 수준의 build.gradle에 아래 코드를 추가한다.

dependencies {
    // activity
    implementation 'androidx.activity:activity-ktx:{version}'
    // fragment
    implementation 'androidx.fragment:fragment-ktx:{version}'
}

그 후 Activity나 Fragment에 아래 코드를 사용하여 초기화 한다.

class MainActivity : AppCompatActivity() {
    private val viewModel: MainViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        ...
    }
}

+ Fragment에서 Activity와 공유하는 ViewModel을 방법

class MainFragment : Fragment() {
    private val viewModel: MainViewModel by activityViewModels()

       override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View {
        ...
    }
}

MVVM ViewModel vs AAC ViewModel

MVVM ViewModel과 AAC ViewModel의 차이를 모르는 사람들이 많다. MVVM에서의 ViewModel은 View에 필요한 데이터를 관리하여 바인딩 해주고, 비즈니스 로직을 담당해 데이터를 처리하는 개념이고, AAC에서의 ViewModel은 Android의 수명 주기를 고려하여 UI 관련 데이터를 저장하고 관리하는 개념이다.

따라서 MVVM ViewModel과 AAC ViewModel은 다른 개념이고 AAC ViewModel을 사용했다고 해서 MVVM 패턴으로서의 ViewModel을 사용했다고 말할 수 없다.

하지만 AAC ViewModel과 Observable한 LiveData, StateFlow을 사용해서 데이터를 바인딩 해준다면 MVVM의 ViewModel로써 사용할 수 있다.

결론을 말하자면, AAC ViewModel을 사용했다고 해서 MVVM ViewModel을 구현했다고 할 수 없고, AAC ViewModel과 LiveData 등으로 데이터를 바인딩한다면 MVVM의 ViewModel로써의 AAC ViewModel을 사용할 수 있다.

액티비티에서 xml에 있는 뷰를 수정하기 위해서는 뷰의 id와 변수를 연결해주어야 하는데 그 때 findViewById 를 사용하여 연결한다.

class MainActivity : AppCompatActivity() {
     override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val button1 = findViewById<Button>(R.id.btn1)
        val button2 = findViewById<Button>(R.id.btn2)
    }
}

findViewById의 문제점

• 존재하지 않는 View의 id를 가져올 경우 Null Exception이 발생한다.
• View의 타입과 findViewById의 타입이 다를 경우 Type Exception이 발생한다.
• View가 많아지면 코드가 많아지고 더러워진다.

viewBinding은 이러한 findViewById 의 문제를 해결할 수 있다.

viewBinding 이란?

viewBinding은 findViewById 와 같은 역할을 하지만 여러가지 장점이 있다.

viewBinding의 장점

• 잘못된 view의 id를 가지고 오지 않아 null-safety 하다.
• type을 지정해줄 필요가 없어 type-safety 하다.
• 바인딩 클래스를 모듈에서 자동으로 생성해주기 때문에 바로 참조할 수 있다.
• 상대적으로 속도가 빠르다

viewBinding 사용법

1. build.gralde 추가

viewBinding 을 사용하기 위해서는 먼저 모듈 단위의 build.gradle 에 아래 코드를 추가해준다.

android {
    ...
    // android 3.6 ~ 4.0
    viewBinding {
        enable = true
    }

   // android 4.0 ~
   buildFeatures {
           viewBinding = true
   }
}

2. Activity & Fragment에 binding 선언

// Activity
private lateinit var binding: ActivityMainBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding.root)
    }
}

// Fragement

override fun onCreateView(
    inflater: LayoutInflater, container: ViewGroup?,
    savedInstanceState: Bundle?
): View? {
    val binding = FragmentMainBinding.inflate(inflater, container, false)

    return binding.root
}

3. 사용하기

<LinearLayout ... >
        <TextView android:id="@+id/tv_name" />
        <ImageView android:cropToPadding="true" />
        <Button android:id="@+id/btn_login"
            android:background="@drawable/rounded_button" />
    </LinearLayout>

위와 같은 xml이 있을 때 아래와 같이 사용할 수 있다.

binding.tvName.text = "안녕하세요"
binding.btnLogin.setOnClickListener { ... }

dataBinding 이란?

Android Jetpack의 라이브러리중 하나로 xml에 데이터를 binding해서 사용할 수 있게 해준다.

dataBinding의 장점

• Activity에서 View로 접근할 필요없이 연결된 데이터가 변경되면 자동으로 view가 업데이트 된다.

dataBinding 사용법

1. build.gralde 추가

android {
    ...
    // android 3.6 ~ 4.0
    dataBinding {
        enable = true
    }

   // android 4.0 ~
   buildFeatures {
           dataBinding = true
   }
}

2. layout 파일 수정

<layout ... >

    <data>
        <variable
            name="vm"
            type="com.example.databinding.MainViewModel" />
    </data>

    <LinearLayout ... >
        ...
    </LinearLayout>
</layout>

기존 xml에 dataBinding을 할 수 있도록 <layout> 태그로 감싸고 <data> 태그에 <variable>을 추가하여 데이터를 연결해준다.

name : 레이아웃에서 사용할 변수의 이름 type : 사용할 변수의 타입

3. Activity & Fragment에 binding 선언

// Activity
private lateinit var binding: ActivityMainBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = DataBindingUtil.setContentView(this, R.layout.activity_main)
    }
}

// Fragement

override fun onCreateView(
    inflater: LayoutInflater, container: ViewGroup?,
    savedInstanceState: Bundle?
): View? {
    val binding = DataBindingUtil.inflate(inflater, R.layout.fragment_main, container, false)

    return binding.root
}

4. 사용하기

<layout ... >

    <data>
        <variable
            name="vm"
            type="com.example.databinding.MainViewModel" />
    </data>

    <LinearLayout ... >
        <TextView android:id="@+id/tv_name" 
            android:text=@{vm.text}/>
        <Button android:id="@+id/btn_login"
            android:onClick=@{vm.onClickBtn()}
            android:background="@drawable/rounded_button" />
    </LinearLayout>
</layout>

위와 같이 layout에 값을 바로 입력할 수 있다. @{} 의 중괄호 안에 name 에 지정했던 변수명을 사용하여 type 에 있는 값을 사용할 수 있다.

데이터 바인딩은 주로 viewModel, liveData와 함께 사용한다.

소프트웨어 디자인에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책. 어플리케이션이나 시스템을 디자인할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 패턴. 간단히 말해서 효율적인 코드를 만들기 위한 설계 방법 이라고 말할 수 있다.

디자인 패턴의 장점

• 정형화된 패턴이므로 개발자간의 의사소통이 수월해짐
• 이미 검증된 패턴이므로 문제가 발생할 일이 적음
• 올바른 설계를 빠르게 만들 수 있음
• 더 효율적이고 빠르게 코드를 만들 수 있음

디자인 패턴의 종류

• 생성 패턴 (Creational Patterns)
• 구조 패턴 (Structural Patterns)
• 행위 패턴 (Behavioral Patterns)

디자인 패턴은 크게 이 세가지로 분류할 수 있다.

생성 패턴

객체 생성과 관련된 패턴

객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다.

• 추상팩토리 패턴 (Abstract Factory)
• 빌더 패턴 (Builder)
• 팩토리 메서드 패턴 (Factory Method)
• 프로토타입 패턴 (Prototype)
• 싱글톤 패턴 (Singleton)

구조 패턴

클래스나 객체를 조합해 더 큰 구조를 만드는 패턴

예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴이다.

• *어댑터 패턴 (Adapter) *
• 브리지 패턴 (Brige)
• 컴퍼지트 패턴 (Composite)
• 데커레이터 패턴 (Facade)
• 퍼사드 패턴 (Facade)
• 플라이웨이트 패턴 (Flyweight)
• 프록시 패턴 (Proxy)

행위 패턴

객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴

한 객체가 혼자 수행할 수 없는 작업을 여러개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는것에 중점을 두는 방식이다.

• 책임 연쇄 패턴 (Chain of Responsibility)
• 커맨드 패턴 (Command)
• 인터프리터 패턴 (Interpreter)
• 이터레이터 패턴 (Iterator)
• 미디에이터 패턴 (Mediator)
• 메멘토 패턴 (Memento)
• 옵저버 패턴 (Observer)
• 스테이트 패턴 (State)
• 스트래티지 패턴 (Strategy)
• 탬플릿 메서드 패턴 (Template Method)
• 비지터 패턴 (Visitor)

아키텍처 패턴이란?

아키텍처 패턴은 디자인 패턴과 유사하지마 범위가 더 넓고, 소프트웨어 공학의 다양한 문제를 해결한다.

디자인 패턴과의 차이점?

디자인 패턴은 특정 문제를 해결하기 위한 방법이고, 아키텍처 패턴은 전체적인 소프트웨어에서 발생한 문제를 해결하기 위한 방법이다.

아키텍처 패턴을 사용하는 이유?

어플리케이션을 개발할 수록 코드는 길어지고 의존성은 더욱 강해지기 때문에 앱을 유지보수하기 점점 어려워진다. 이러한 문제를 해결하기 위해 아키텍처 패턴을 사용한다.

아키텍처 패턴의 종류

• MVC (Model - View - Controller)
• MVP (Model - View - Presenter)
• MVVM (Model - View - ViewModel)
• MVI (Model - View - Intent)

MVC

프로그램을 각각의 역할에 따라 Model, View, Controller로 나누어 설계한 아키텍처 패턴

• Model 어플리케이션에서 사용되는 데이터와 그 데이터를 처리
• View 사용자에게 보여지는 UI
• Controller 사용자의 입력을 받고 처리

동작 순서

1. 사용자의 Action이 Controller로 전달된다.
2. Controller는 사용자의 Action을 확인하고, Model을 업데이트한다.
3. Controller는 Model을 나타내줄 View를 선택한다.
4. View는 Model을 이용하여 UI를 업데이트한다.

특징

• Controller가 여러개의 View를 선택할 수 있는 1:N 구조
• Controller는 View를 선택할 뿐 직접 업데이트 하지 않음 (View는 Controller를 알지 못 함)

  장점

• 가장 단순한 아키텍처 패턴

  단점

• View와 Model 간의 의존성이 높음 -> 어플리케이션이 커질수록 복잡해지고 유지보수가 어려움

MVP

MVC에서 파생된 Model, View 사이의 의존성이 없는 아키텍처 패턴

• Model 어플리케이션에서 사용되는 데이터와 그 데이터를 처리
• View 사용자에게 보여지는 UI
• Presenter View에서 요청한 정보로 Model을 가공하여 View에 전달 Model과 View 사이의 매개체

동작 순서

1. 사용자의 Action이 View에 전달된다.
2. View는 데이터를 Presenter에 요청한다.
3. Presenter는 Model에게 데이터를 요청한다.
4. Model은 Presenter에서 요청받은 데이터를 응답한다.
5. Presenter는 View에게 데이터를 응답한다.
6. View는 Presenter가 응답한 데이터를 이용하여 UI를 업데이트한다.

   특징

• Presenter는 View와 Model의 인스턴스를 가지고 있어 둘 사이의 매개체 역할을 한다.

  장점

• Model과 View 사이의 의존성이 없음

  단점

• View와 Presenter 사이의 의존성이 커짐

MVVM

MVC에서 파생된 Model과 View, Controller와 View 사이의 의존성을 고려하여 각 구성 요소가 독립적으로 작성되고 테스트될 수 있도록 설계된 아키텍처 패턴

• Model 어플리케이션에서 사용되는 데이터와 그 데이터를 처리
• View 사용자에게 보여지는 UI
• ViewModel View를 나타내 주기 위한 Model이자 View를 나타내기 위한 데이터를 처리

동작 순서

1. 사용자의 Action이 View에 전달된다.
2. View에 Action이 들어오면 Command 패턴으로 ViewModel에 입력을 전달한다.
3. View Model은 Model에게 데이터를 요청한다.
4. Model은 View Model에게 요청받은 데이터를 응답한다.
5. View Model은 응답 받은 데이터를 가공하여 저장한다.
6. View는 View Model과 Data Binding하여 UI를 업데이트한다.

   특징

• Command 패턴과 Data Binding을 이용하여 View와 ViewModel 사이의 의존성을 없앰
• ViewModel과 View는 1:N 관계

  장점

• Model과 View 사이의 의존성이 없음
• View와 ViewModel 사이의 의존성이 없음
• 중복되는 코드를 모듈화 할 수 있음

  단점

• ViewModel 설계가 쉽지 않음

MVI

Cycle.js 프레임워크의 단방향성과 Cycle Nature에서 영감받아서 탄생한 아키텍처 패턴

• Model 상태, MVI의 모델은 아키텍처의 다른 레이어와의 단방향 데이터 흐름을 보장하기 위해 변경이 불가능함
• View 사용자에게 보여지는 UI
• Intent 사용자 또는 앱내 발생하는 Action, 앱의 상태를 바꾸라는 요청

동작 순서

1. Intent로 사용자의 Action을 가져온다.
2. Intent는 Model에서 처리해야 하는 동작을 제공한다.
3. Model은 Intent로 부터 Action을 가져온다.
4. Model이 View에 표시할 모델을 생성한다.
5. View는 Model로 부터 새로운 모델을 가져와 UI를 업데이트한다.

   장점

• 데이터가 단방향으로 순환
• View의 생명주기 동안 일관성 있는 상태를 가짐

  단점

• 러닝 커브가 높음

이번 해커톤의 팀은 4~6명에서 한 팀으로 구성되야했다. 나는 팀 구성을 Android 개발자 1명 iOS 개발자 1명 서버 개발자 1명 디자이너 1명 이렇게 구상했다. 내 전공은 안드로이드이기 때문에 iOS 개발자 석호, 서버 개발자 종윤, 디자이너 경민이와 한 팀을 구성했다. 팀명 : 우아한 남매들

💡 아이디어 회의

이번 해커톤의 주제는 신입생들을 위한 소프트웨어 개발 이었다. 우리 팀은 신입생들이 우리 학교에 있는 건물의 위치나 학교에 대한 정보, 기숙사에 대한 정보를 알려줄 수 있는 AI 챗봇이 있었으면 좋겠다고 생각했고, 신입생들이 전공이나 학교 생활에 대한 질문을 선배들에게 자유롭게 물어볼 수 있는 앱이 있었으면 좋겠다고 생각했다. 그래서 인공지능 챗봇과 학교 Q&A를 할 수 있는 앱인 대소톡을 기획하게 되었다.

💻 개발

나는 디자인이 완성 될 때까지 안드로이드 앱 아키텍처를 어떻게 할 지 고민했다. 이번 해커톤의 평가 기준에 코드도 있었기 때문에 클린아키텍처와 MVVM 패턴으로 개발해야겠다고 생각했다. AI 챗봇은 Naver Clova Studio API을 사용해 우리 학교에 대한 1000개의 질문과 답변을 학습시켜서 대소고 챗봇을 개발하였다. 이거 학습시키는데 죽는줄 알았다. 학교 Q&A 기능은 간단한 CRUD이고, 멘투멘을 개발할 때 사용한 기술들이어서 어렵지 않게 개발했다. 야식으로 읍천리 샌드위치와 아이스티를 줘서 맛있게 먹었다😁 대소톡 메인화면 완성! 저 메인화면 구현하는데 죽는줄 알았다.. 3시간 삽질함ㅜㅜ

자세한 코드는 아래의 링크에 있습니다.

깃허브 링크 : https://github.com/Woowa-Siblings/DGSWchat-Android

🏆 우승

이번 해커톤의 결과는...? 🎉 대상을 받았다!! 솔직히 예상은 하고있었다. 해커톤에서 상을 받은건 처음이라서 기분이 너무 좋았다😆 상금으로 요기요 쿠폰 10만원을 받아서 나중에 팀원들과 회식해야지~

😄 느낀 점

저번에 참여한 하이톤은 첫 해커톤이라서 시간도 부족하고 당황해서 상은 못 탔지만 하이톤 때 한 경험이 아이디어 구상이나, 디자인, 협업 등 이번 교내 해커톤을 할 때 많은 도움이 되었다. 항상 해커톤을 하면서 느낀 건데 새로운 기술이나 안 써본 기술들을 사용하기 정말 좋은 기회인 것 같다. 해커톤은 새로운 팀원들과 새로운 아이디어로 협업을 하면서 개발할 수 있는 경험을 할 수 있어서 좋은 것같다. 앞으로도 해커톤이나 대회를 참여할 기회가 생긴다면 무조건 참여해야겠다고 생각했다.

1. 교육봉사 동아리 두카미

학교에서 가입한 첫 동아리. 나는 가르치고 알려주는 것을 좋아하고 그러면서 나도 다시 한 번 공부할 수 있기 때문에 그 점이 좋아서 두카미에 지원하였다. 두카미에서 친구들을 많이 사귀고 친해져서 좋았다😀

2. 코드업

당시에 친구들 대부분이 게임을 했었는데 나는 그 시간에 코드업 문제를 풀어서 C언어 실력을 향상시켰다. 다른 친구들도 그 때 코드업 문제를 많이 풀었으면 친구들 실력이 조금은 올라가지 않았을까?

4월

1. 💻 맥북

학교에서 나눠준 그램으로 안드로이드를 공부하려니 너무 느리고 애뮬레이터도 실행되지 않아서 아빠카드로 맥북 FLEX. 맥북 사고 삶이 행복해짐😆

2. 중학생 교육

두카미에서 진행한 중학생들 교육! 처음 해보는 교육이어서 긴장도 되고 기대도 됬다. 교육 하면서 에러도 많이 발생하고 여러 문제가 많았지만 해결하면서 뿌듯함도 느끼고 중학생 친구들이 잘 따라와줘서 재미있었다.

5월

1. 체육대회

체육 대회 진짜 재밌었다!!😆 각 반마다 부스도 운영해서 맛있는 음식도 먹고 보드게임도 했다. 또 물놀이도 해서 더운 여름에 시원하게 젖었다💦

2. STA+C 2022

친구들과 함께 참여한 첫 대회! 본선까지 올라가진 못 했지만 대회를 맛 볼 수 있는 좋은 기회였다.

3. 대구청소년디딤센터

두카미에서 대구청소년디딤센터에 코딩봉사를 하러 갔다. 7월까지 격주로 아두이노를 이용하여 디딤센터 친구들에게 봉사를 했다 좋은 경험이 될 것 같아서 참여했지만 생각보다 힘들었다ㅠㅠ 선생님이 우리 수업할 때 어떤 느낌인지 알 수 있는 기회가 되었다.

6월

1. 부산 롯데월드

학교에서 부산에 새로 생긴 롯데월드로 놀러 갔다😀 친구들과 사진도 많이 찍고 좋은 추억을 만들었다.

7월

1. 2022년 교내 해커톤

학교에서 진행한 여름해커톤! 우리팀은 웹개발을 해서 안드로이드 개발자인 나는 할게 없었지만 혼자 공부하면서 많은 걸 배웠다. 선배님들의 버스로 해커톤 동상을 수상했다😄

2. 노벨 엔지리어링 해커톤

대구 과학관에서 진행한 해커톤이다. 책을 읽고 책에서 나온 문제점을 소프트웨어를 이용하여 해결하는 해커톤이다. 나는 소설 보물섬에서 주인공 아저씨가 구조 되기 전까지 안전하게 보낼 수 있도록 온도와 습도를 알려주는 친구를 열심히 뚝딱뚝딱 만들었지만 수상은 하지 못했다😢

3. 기말고사

대소고라서 시험보다는 전공공부에 집중했다. 일주일 정도 시험 준비 하고 시험을 쳤는데 1학기 전교 2등을 했다! 2학기도 공부 안 해서 1학년 전교 7등으로 떨어짐

4. B1ND 인턴

기존의 동아리인 두카미는 교육봉사 동아리라서 개발을 할 기회가 적었다. 그래서 나의 개발 실력을 키우고 친구들과 협업 경험을 키우기 위해 바인드팀에 지원을 했다. 기술 면접과 임원 면접을 보고 바인드 안드로이드팀의 인턴으로 합격했다!

5. 🥳 학교 축제

1학기 마무리 축제! 나도 축제를 즐기기 위해 참여했다. 친구들과 기숙사에서 하루종일 연습했던** 톰보이, **쉬어 무대!! 전교생이 함께 즐겨서 좋았고 무대도 성공적으로 끝내서 뿌듯했다😆

8월

1. 나르샤 프로젝트

바인드 팀원들과 나르샤 프로젝트를 함께 하게 되었다. 우리는 프로젝트 주제로 멘토멘티 서비스인 멘투멘으로 정하였다. 개발을 하는 첫 프로젝트라서 기대도 엄청 되었고 실력을 키울 생각에 신이 났다.

9월

1. ⚾️ 라이온즈 파크

학교에서 다 같이 야구를 보러 갔다. 야구를 처음 보는거라서 재밌을지 걱정을 했는데 응원을 하다보니 신나서 나중에 보니 엄청 집중해서 보고있었다ㅋㅋ

2. 해양 수련원

2박 3일동안 해양 수련원을 갔다. 여러가지 체험을 하고 재미있는 활동도 많이 해서 수련원같은 느낌이 안 들었다. 장기자랑도 해서 친구들과 준비한 춤도 추고 교관님들도 공연을 준비해주셔서 즐거웠다😄 교관쌤이 예뻐서 눈호강 했다.

10월

1. 멘투멘 프로젝트

학교마치면 멘투멘 개발하고...개발하고...개ㅂ..ㅏ.ㄹ

11월

1. ict 융합 엑스포

나르샤 프로젝트로 시작한 멘투멘을 ict 융합 엑스포에 전시했다. 팀원 친구들 모두 열심히 참여해줘서 고마웠다. 다양한 기업분들이 오셔서 조언도 해주시고 피드백도 해주시고 칭찬도 해주셔서 도움이 많이 되었다. 이번 기회를 통해 다양한 사람들의 의견을 많이 들을 수 있어서 좋았고 나의 부족함점이 무엇인지 알 수 있는 기회가 되었다. 외국인 분들도 오셔서 다음번에 준비할 때는 영어 공부도 해야겠다고 생각했다☺️

2. 🍊제주도

떠나요~ 제주도~ ✈️ 학교에서 제주도로 3박 4일 여행을 갔다😆

1일차

첫번째로 방문한 곳은 제주도 카카오 본사! 카카오의 역사와 제주 카카오 오피스를 둘러봤다. 공기도 너무 좋았고 경치도 좋아서 카카오에 취업하고 싶어졌다ㅋㅋㅋ

숙소는 침대도 있고 넓어서 친구들이랑 밤 늦게까지 놀았다😆

2일차

즐겁게 루지를 타고~🏎️ 친구들이랑 사진도 찍고📷 머리에 감귤도 올렸다🍊

3일차

좋아하는 녹차를 엄청 많이 사서 기분이 좋았다🍵 요트를 타고 시원한 바람을 맞으면서 힐링을 했다💨

4일차

노형수퍼마켓. 나는 노형수퍼마켓이 진짜 수퍼마켓인지 알고있었다ㅋㅋㅋㅋㅋㅋ 여기는 생각보다 할 건 없었고 사진만 찍고 나왔다.

3. 판교 카카오엔터프라이즈

진로시간에 ppt 잘만들어서 가게 된 카카오😀 카카오의 문화를 알게 되어서 좋았고 카카오 개발자분들의 얘기를 들을 수 있어서 도움이 되었다. 카카오는 파면 팔수록 매력적인 곳 같다.

12월

첫 눈.

학교에 내린 첫 눈❄️ 등교 하자마자 너무 신나서 눈사람을 만들어버렸다ㅎ⛄️ ⬆️ 눈 맞아서 기분 좋음

4대 컴포넌트는 안드로이드 앱의 필수적인 기본 구성 요소입니다. 4대 컴포넌트는 액티비티(Activity), 서비스(Service), 방송 수신자(Broadcast Receiver), 콘텐츠 제공자(Content Provider)가 있습니다.

텍스트각 컴포넌트는 하나의 독립적인 형태로 존재하고, 고유의 기능을 수행하고, 인텐트(Intent)를 통해 서로 상호작용한다.

1. 액티비티(Activity)

• 액티비티(Activity)는 사용자가 애플리케이션(Application)과 상호작용하며 실제로 사용자에게 보이는 화면을 의미한다.
• 애플리케이션(Application)에 화면이 하나도 없으면, 사용자와 상호작용을 할 수 없으므로 적어도 하나의 액티비티는 반드시 필요하다.
• 인텐트(Intent)를 통해 다른 애플리케이션(Application)의 액티비티(Activity)를 불러올 수 있다.
• 하나 이상의 View 또는 ViewGroup을 가져야 한다. 여기서 View는 화면에서 눈에 보이는 것들, 예를 들어 텍스트, 버튼, 이미지 등을 의미하며, ViewGroup은 레이아웃을 의미한다고 볼 수 있다.

  2.서비스(Service)

• 서비스(Service)는 액티비티(Activity)와 반대로 직접적으로 상호작용하지 않는 요소이다.
• 백그라운드(Background)에서 어떠한 작업을 처리하기 위해 사용된다.
• 애플리케이션(Application)이 종료되어도 백그라운드(Background)에서 동작하는 컴포넌트이다.
• 타이머나, 음악 앱 같은 경우에, 앱을 실행시킨후 앱을 꺼도 계속 작동되므로 서비스 기능이다.

  3.방송 수신자(BroadCast Receiver)

• 안드로이드 OS로부터 발생하는 이벤트 정보를 받고 대응하는 컴포넌트이다.
• 대부분 UI를 가지지 않으며, 수신기를 통해 디바이스 상황을 감시하다가 이벤트가 발생하면 해당 이벤트에 맞게 정의한 작업들을 수행하는 역할을 한다. 디바이스에서 발생하는 중요한 이벤트를 앱(Application)에 알려준다.
• 대표적인 예로 배터리 부족, 문자 수신, 전화 수신과 같은 정보를 받아서 이를 처리할 때 동작한다.

  4.콘텐츠 제공자(Content Provider)

• 콘텐츠 제공자는 데이터를 관리하고 다른 앱(Application)의 데이터를 제공하는데 사용되는 컴포넌트이다.
• 데이터를 저장하고, 불러와서 사용할 수 있는 시스템들을 의미한다.
• 파일 시스템이나 SQLiteDB, 기타 저장소 위치에서 앱이 접근 가능한 저장소의 데이터를 읽거나 쓸 수 있다.
• 작은 데이터들은 인텐트(Intent)로 애플리케이션(Application)끼리 데이터를 서로 공유가 가능하지만 콘텐츠 제공자(Content Provider)는 음악 또는 사진 파일 등과 같이 용량이 큰 데이터들을 공유하는데 적합하다.
• 대표적인 사례로 인스타그램 앱에서 갤러리 앱에 접근하여 사진 파일을 가져오거나 지도 앱에서 자신의 현재 위치를 가져오는 등이 대표적 사례라고 볼 수 있다.
• 콘텐츠 제공자를 이용하기 위해서는 권한을 획득해야 한다. 이러한 정보들은 민감한 정보들이기 때문에 보통 맨 처음에 앱을 설치하면 바로 권한 요청이 뜨는데, 보안적인 이슈를 고려해서이다.

인텐트(Intent)

• 애플리케이션 컴포넌트간에 작업 수행을 위한 정보를 전달하는 역할을 하며 통신수단이다.
• 서로 독립적으로 동작하는 4가지 커포넌트들 간의 상호 통신을 위한 장치이다.
• 컴포넌트에 액션(Action), 데이터(Data)등을 전달한다.
• 인텐트를 통해 다른 애플리케이션의 컴포넌트를 활성화시킬 수 있다.