코딩하는 두꺼비

학교에선 Github을 사용하다가 회사를 다니며 Gitlab을 쓰다보니 PR과 MR 단어를 같이 쓰지만 무엇이 다른지 정확히 모르고 사용하고 있었다. 또한 Git-Flow를 공부하다가 이 내용에 대해서 정확히 짚고 나가는 것이 좋다는 생각이 들었다.

그래서 이에 대해 알아보니 일단 결론적으론 브랜치를 합치는 작업에서 Github진영에서는 Pull Request라 하고 Gitlab진영에서는 Merge Request라고 부르는 같은 동의어와 같은 것임을 알게 되었다.

간단히 설명하자면 Github에서는 내가 작업한 브랜치를 Master의 입장에서 Pull하는 것이기에 Pull Request라 하는 것이고 Gitlab에서는 내가 작업한 브랜치 입장에서 Master에 Merge하는 것이기에 Merge Request라 하는 것이였다.

좀 자세히 알아보자면

Pull Request는 첫 액션이 Pull을 하는 것이기에 PR이 된 것이다.

Merge Request는 마지막 액션이 Merge를 하는 것이기에 MR로 부른다.

사실상 같은 용어들이므로 자신이 쓰는 서비스에 맞게 용어를 사용하면 될 것 같다!!

참고

https://stackoverflow.com/questions/7273434/is-it-possible-to-create-merge-requests-in-pure-git-from-the-command-line?noredirect=1&lq=1

https://prosaist0131.tistory.com/entry/MR%EA%B3%BC-PR%EC%9D%98-%EC%B0%A8%EC%9D%B4

처음에 Git-Flow라는 단어를 들었을 떈 그냥 단순히 브랜치의 흐름? 같은 것이라고 생각을 했었다.

비슷하지만 그런 것이 아니라 Git-Flow는 대표적인 Git 브랜칭 전략이다.

Git-Flow는 Vincent Driessen이라는 분이 처음 개발한 깃 브랜칭 모델이다.

1년여간 이 분이 이러한 브랜칭 모델을 사용했고 그에 대한 이야기를 적어놓았던 글이 화제가 되어 현재 많은 개발자들이 이 모델을 많이 사용하고 있다.

Git-Flow에 대해 간략한게 설명해보자면 이 모델은 5가지 브랜치를 사용하는 모델이다.

Master(Main) - 제품으로 출시되는 Branch, Production의 개념을 내포하고 있다.

Develop - 다음 출시 버전을 개발하는 Branch

Feature - 기능을 개발하는 Branch, 주로 이 브랜치에서 개발을 한다.

Release - 이번 출시 버전을 준비하는 Branch, QA를 진행하는 브랜치이다.

Hotfix - 출시 버전에서 발생한 버그를 수정하는 Branch

Git-Flow를 사용해서 개발하는 순서는 보통 아래와 같이 이루어진다.

• 처음에 Master(Main)와 Develop 생성
• 새로운 추가 작업은 Develop에서 Feature Branch 생성
• Feature는 Develop으로 Merge(이때 Develop이 최신 상태인지 확인해야함)
• QA를 위해서 Develop에서 Release Branch 생성
• QA에서 발생한 버그는 Release에서 수정
• QA가 끝나면 Release에서 Develop / Master(Main)으로 각각 Merge
• Hotfix는 Master에서 시작하여 수정 후 Master / Develop에 Merge

Git-Flow가 유용하긴 하지만 너무 많은 브랜치를 사용하는 점, 그에 따라 안쓰는 브랜치가 생기고 브랜치 마다 포지션이 애매해질 수 있기 때문에 이러한 점을 보완해 좀 더 간소화 된 브랜칭 전략이 나왔는데 그것이 GitHub-Flow이다.

GitHub-Flow란 Git-Flow가 복잡하기에 이를 좀 더 간소화시킨 방식으로 Scott chacon이 Github에서 좀 더 편리하게 사용하기 위해 만든 브랜칭 전략이다.

자동화 개념이 포함되어 있으며 Master(Main) Brnach에 대한 role만 정확하다면 나머지 Branch들에는 관여를 하지 않는다. 그리고 Pull Request 기능의 사용을 권장한다.

사용법 및 특징을 정리해보면

1. Master Branch의 어느것이든 배포가 가능하다.

• master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치
• 이 브랜치에 대해서는 엄격한 role과 함께 사용한다
• merge하기 전에 충분히 테스트를 해야한다. 테스트는 로컬에서 하는 것이 아니라 브랜치를 push 하고 Jenkins로 테스트 한다

2. 새로운 일을 시작하기 위해 Branch를 Master에서 딴다면 이름은 어떤 작업인지 명확하게 명시한다.

• 브랜치는 항상 master 브랜치에서 만든다
• Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않음
• 새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자
• 커밋메시지를 명확하게 작성하자

3. Local Branch에 수시로 커밋하고 이 내용을 원격 Branch에 수시로 Push한다.

• Git-flow와 상반되는 방식
• 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
• 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다

4. 피드백이나 도움이 필요할 때 혹은 자신의 Branch가 merge할 준비가 되었다면, PR을 생성하여 공유한다.

• pull request는 코드 리뷰를 도와주는 시스템
• 이것을 이용해 자신의 코드를 공유하고, 리뷰받자
• merge 준비가 완료되었다면 master 브랜치로 반영을 요구하자

5. PR 리뷰 후에는 다른 사람의 동의를 얻고 Master에 Merge한다.

• 곧장 product로 반영이될 기능이므로, 이해관계가 연결된 사람들과 충분한 논의 이후 반영하도록 한다
• 물론 CI도 통과해야한다!

6. Master Branch로 Merge나 Push가 이루어지면 즉시 배포해야한다.

• GitHub-flow의 핵심
• master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다

마지막으로 GitLab-Flow란 GitLab에서 Git-Flow를 간소화하여 만든 브랜칭 전략이다.

또한 Github-flow는 너무나도 간단하여 배포, 환경 구성, 릴리즈, 통합에 대한 이슈를 남겨둔 것이 많았다.

그것을 보완하기 위해 GitLab에서 관련 내용들을 추가적인 가이드를 제공하여 전략을 만들었다.

아래는 GitLab-Flow의 특징이다.

Production branch with GitLab flow

Github-Flow에서는 매번 Merge후에 배포를 하라고 하지만 iOS앱 등 배포 시기를 맞추지 못하는 서비스 등 이 특징을 매번 적용하기 힘든 경우가 있다.

이러한 경우들을 해결하기 위해 production 브런치가 존재하여 커밋한 내용들을 일방적으로 배포하는 형태를 만들었다. GitHub에서 브런치 하나를 더 구성하여 사용하는 이것도 조금은 간단한 구성이다.
이렇게 구성하면 배포 자동화가 되어있지않은 구성에서 어떻게 배포를 진행할 것인가에 대한 내용을 담았다. 물론 이걸로 부족하여 다음의 것도 추가되었다.

Environment branches with GitLab flow

master와 production 사이에 pre-production을 두어 개발한 내용을 곧장 반영하지 않고 시간을 두고 반영을 하는 것을 말한다. Staging을위한 공간인 pre-production에 MR을 Master에서 보낸다. 이와 같은 형식은 downstream flow의 방식을 취하게 되며 hotfix발생시 master에서 feature 브랜치를 만들어 수정 후 Master에 MR을 보낸다. feature 브랜치를 바로 삭제하지 않고 Master에서의 자동 테스트를 통과를 확인하고 삭제한다.

Release branches with GitLab flow

release한 브런치를 두고서 보안상 문제가 발생한 것이나 백 포트를 위해서 작업을 할 경우, cherry-pick을 이용해서 작업을 진행할 수 도 있다.(2-3 stable이나 2-4 stable등의 브랜치를 만들어서 작업) 아니면 해당 릴리즈에서 발생하는 버그들을 묶어서 수정하는 방식으로 작업한다. 일반적으로 말하는 ‘upstream first’ 정책이다. 같은 버그를 수정하는 경우를 방지하기 위해 태그를 달아서 패치 버전을 관리해주는 것이 좋다.

Merge/pull requests with GitLab flow

Pull request를 사용하는 방법이다. GitHub Flow에서 하는 방법과 동일하다.(Github에서는 pull request이고 GitLab에서는 Merge request임)

보호되고 있는 Long-live branch는 maintainer만 merge할 수 있도록 해야한다. Merge후에는 feature 브랜치는 삭제해주도록 한다.

Issues with GitLab flow

Issue 트러커와 연결하여 사용하는 것을 말한다. 긴 시간 동안 작업을 할 경우, 이슈를 생성하여 작업을 진행하는 것으로 브랜치 이름에는 이슈번호를 적어 작업 중인 이슈가 어떤 것인지를 명확하게 해주는 것이 필요하다.
작업이 끝나거나 코드 공유가 필요한 시점이면 Merge/pull requsts를 보낸다.

이 글을 작성하면서 가장 많은 도움을 받았던 블로그이다. 특히 GitLab 관련해서 일어 번역을 해주셔서 편하게 공부할 수 있었다.. 또한 장단점 정리가 깔끔했다.

https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/

위의 브랜칭 전략들을 공부하면서 정말 정답은 없다고 느꼈다. 우아한 형제들 블로그에서는 Github-flow를 사용하다가 오히려 Git-flow로 넘어가는 등 자신이 하고 있는 프로젝트나 팀 상황에 맞게 브랜칭 전략을 잘 수립해야 될 것 같다.

아래의 공식 사이트 등을 통해 좀 더 자세히 공부할 수 있다~

참고

https://docs.gitlab.com/ee/topics/gitlab_flow.html

https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/

https://guides.github.com/introduction/flow/

https://hellowoori.tistory.com/56

https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/

https://scottchacon.com/2011/08/31/github-flow.html

https://nvie.com/posts/a-successful-git-branching-model/

https://techblog.woowahan.com/2553/

https://muscardinus.tistory.com/223

항상 자바를 공부하다 보면 항상 헷갈리는 부분이 ==과 eqauls의 차이에 대한 것이다.

매번 찾아보지만 또 까먹은 김에 아예 글을 작성하게 되었다.

간단하게 결론부터 이야기 하자면 ==의 경우 주소값(Call by Reference)까지 비교하는 연산자이고 equals의 경우 값(Call by Value)만 비교하는 메소드이다.

예를 들어

String str1 = "abc";
Stirng str2 = new String("abc");

이 두개의 값을 비교해보자

str1의 경우 리터럴을 사용하여 선언하였기에 string constant pool이라는 영역에 존재하게 되고

str2의 경우 new를 통해 String을 생성했기에 Heap 영역에 존재하게 됩니다.

따라서 당연히 두 값의 주소값은 달라질 것이기에 아래와 같은 결과가 나오게 됩니다.

str1 == str2;		// false!!
str1.equals(str2);	// true!!

따라서 평상시 자바에서 String을 비교할때에는 equals를 사용해야한다!!

참고

https://coding-factory.tistory.com/536

회사에서 일을 하면서 hosts파일을 설정할 일이 생겼다. 정확히 어떤 일을 하는 파일인지 모르고 있었기에 이번 기회에 공부하게 되었다.

Hosts란?

호스트 이름에 대응하는 IP주소가 저장되어 있어서 DNS에서 주소를 제공받지 않아도 서버의 위치를 찾게 해주는 파일이다.

예를 들어 www.naver.com에 접속을 하게 된다면 외부 DNS서버를 통해 IP가 제공되고 그 IP주소에 우리가 접속을 하게되는 것이다. 만약 호스트 파일에 IP주소와 도메인을 적어놨다면 따로 DNS서버를 거치지 않고 바로 그 IP주소에 접속하게된다.

정리하자면

▶ 호스트파일의 역할

 - 호스트 이름에 대응하는 IP 주소가 저장되어 있어서 도메인 이름 시스템(DNS)에서 주소 정보를 제공받지 않고도 서버의 위치를 찾게 해준다.

▶ 호스트 파일 사용 장점

 - 인터넷 속도 향상

 - 리소스 사용을 줄임

 - 보안 문제 예방적 대처

▶ 호스트 파일 사용 단점

 - 사이트 방문이 차단될 수 있다

 - 페이지 내에서 부분 차단된 경우 디자인, 속도 문제

▶ 호스트 파일 저장 위치

 C:\windows\system32\drivers\etc\hosts

▶ 호스트 파일 작성 원칙

- 샵 기호(#)로 시작하는 줄(line)은 주석문, 개별 줄(line) 앞이나 호스트 이름 다음에 작성

- 각 항목은 한 줄(line)로 작성

- 항목은 IP 주소 + 호스트 이름 순서로 제한

- 호스트 이름과 IP 주소의 간격은 최소한 1칸을 띄움

- 호스트 이름 부분에 'IP 주소' 등록 제한 : 호스트의 IP 주소 검색이 목적. IP 주소를 이미 찾은 상태

- 호스트 이름의 글자수는 255자로 제한

- 프로토콜 형식 'http:', 와일드카드 문자 '*', 주소 맨끝에 사선기호 '/' 사용 제한

IP나 도메인 등 좀 더 자세하게 알고 싶다면 아래 내가 참고한 블로그에 들어가서 깊게 공부해보자!

참고

https://way-be-developer.tistory.com/86

https://goddaehee.tistory.com/90

회사에서 공부를 하다가 NAT이라는 용어가 나와서 들어는 봤지만 헷갈리는 단어라 다시 공부를 하게 되었다.

NAT이란 위키에 따르면

네트워크 주소 변환(영어: network address translation, 줄여서 NAT)은 컴퓨터 네트워킹에서 쓰이는 용어로서, IP 패킷의 TCP/UDP 포트 숫자와 소스 및 목적지의 IP 주소 등을 재기록하면서 라우터를 통해 네트워크 트래픽을 주고 받는 기술을 말한다. 패킷에 변화가 생기기 때문에 IP나 TCP/UDP의 체크섬(checksum)도 다시 계산되어 재기록해야 한다. NAT를 이용하는 이유는 대개 사설 네트워크에 속한 여러 개의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위함이다. 많은 네트워크 관리자들이 NAT를 편리한 기법이라고 보고 널리 사용하고 있다. NAT가 호스트 간의 통신에 있어서 복잡성을 증가시킬 수 있으므로 네트워크 성능에 영향을 줄 수 있는 것은 당연하다.

라고 한다..

말이 좀 어렵게 되어 있지만 간단하게 생각하면 우리가 가정집에서 사용하는 공유기에서 사용하는 여러기기가 있다면 각 기기마다 사설 IP 주소를 만들어주는 것이다. 그리고 우리가 인터넷을 사용할때에는 이러한 개인 IP 주소들을 공인 IP주소로 변환하여 인터넷에 접속을 하게된다.

위의 이미지를 보면 아마 쉽게 이해가 될것이다..

우리가 NAT을 사용하는 이유에는 두가지 정도가 있다.

첫번째는 공인 IPv4주소를 절약하기 위해서이다.

인터넷상의 공인 IP주소는 유한할 수 밖에 없다. 현재 IPv4의 경우 2의32승의 갯수만을 사용할 수 있으니 이러한 문제를 해결하기 위해서 NAT을 사용해 하나의 공유기에서 여러기기를 연결시키고 이를 통해 공인 IP 주소의 낭비를 줄이는 것이다.

두번째는 보안의 목적이다.

공개된 인터넷망에 사설 내부 IP가 노출된다면 개인PC로의 직접적인 접속 등 보안 사고가 발생할 수 있다. 따라서 NAT과 함께 방화벽을 사용함으로써 외부로의 공격을 예방 혹은 방어할 수 있다.

NAT의 동작원리나 자세한 사항은 참고자료에 있으니 나중에 공부할때 활용하면 좋을 것 같다!

참고

https://www.stevenjlee.net/2020/07/11/%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-nat-network-address-translation-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%A3%BC%EC%86%8C-%EB%B3%80%ED%99%98/

https://m.blog.naver.com/sehyunfa/221684093830

https://wiki.teltonika-networks.com/view/Network_Address_Translation

https://ko.wikipedia.org/wiki/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC_%EC%A3%BC%EC%86%8C_%EB%B3%80%ED%99%98

참고한 블로그: kiwinam.com/posts/25/android-toolbar-add-button/

그전 자바로 프로젝트를 할 때 팀원이 이미 액션바 xml등 모든 세팅을 다 해줬기 때문에 혼자서 개발을 해보았다.

어떻게 해야하는 지 막막했는데 위의 블로그를 보고 쉽게 이해할  수 있었다.

1. 기존 액션바를 지우고(보통 기본 설정) 액션바를 적용하고자 하는 레이아웃에 툴바를 넣어준다.

res/values/styles.xml의 style태그를 아래와 같이 수정해 기본 액션바를 설정해준다.

<style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar">

res/layout루트 아래 xml파일 중 툴바를 넣을 액티비티에 툴바를 넣어준다.

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout
    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:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <androidx.appcompat.widget.Toolbar
        android:id="@+id/toolbar"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:background="@color/colorPrimary"
        android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"
        app:popupTheme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"
        tools:ignore="MissingConstraints" />

</androidx.constraintlayout.widget.ConstraintLayout>

블로그에서는 android.support.v7.widget.Toolbar로 태그 설정이 되어 있었는데 구버전이라 그런 것 같아 나는 신버전인 androidx로 다시 설정해주었다.

2. Menu.xml을 만들어 액션바 틀을 만들어준다.

res/menu에 mainmenu.xml파일을 만들어 주었다.

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    >
    <item
        android:id="@+id/menu_search"
        android:title="search"
        android:icon="@drawable/baseline_search_white_24dp"
        app:showAsAction="always"
        />
    <group>
        <item
            android:id="@+id/menu_account"
            android:title="account"
            />
        <item
            android:id="@+id/menu_logout"
            android:title="logout"
            />
    </group>
</menu>

각 icon들은 머티리얼 사이트에서 가져오거나 이미 가지고 있는 파일을 활용하면 된다.

3. 액티비티에서 툴바를 설정해준다.

package com.example.desktop.mymo

import android.content.Intent
import androidx.appcompat.app.AppCompatActivity
import android.os.Bundle
import android.view.Menu
import android.view.MenuItem
import android.view.View
import com.google.android.material.snackbar.Snackbar
import kotlinx.android.synthetic.main.activity_main.*

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        
        setSupportActionBar(toolbar)	//툴바 사용 설정

        supportActionBar!!.setDisplayHomeAsUpEnabled(true)	//왼쪽 버튼 사용설정(기본은 뒤로가기)
        supportActionBar!!.setHomeAsUpIndicator(R.drawable.baseline_menu_white_24dp)	//왼쪽 버튼 메뉴로 아이콘 변경
        supportActionBar!!.setDisplayShowTitleEnabled(true)		//타이틀 보이게 설정
    }

    override fun onCreateOptionsMenu(menu: Menu?): Boolean {
        menuInflater.inflate(R.menu.mainmenu, menu)		//작성한 메뉴파일 설정
        return true
    }

    override fun onOptionsItemSelected(item: MenuItem): Boolean {

        when(item!!.itemId){
            android.R.id.home->{	//각 버튼 마다 스낵바 메세지로 기능 구현
                Snackbar.make(toolbar,"Menu pressed",Snackbar.LENGTH_SHORT).show()
            }
            R.id.menu_search->{
                Snackbar.make(toolbar,"Search Menu pressed",Snackbar.LENGTH_SHORT).show()
            }
            R.id.menu_account->{
                Snackbar.make(toolbar,"Account Menu pressed",Snackbar.LENGTH_SHORT).show()
            }
            R.id.menu_logout->{
                Snackbar.make(toolbar,"Logout Menu pressed",Snackbar.LENGTH_SHORT).show()
            }
        }

        return super.onOptionsItemSelected(item)
    }

}

마지막으로 툴바를 사용할 액티비티에 위와 같이 코드를 구성해주면 된다.

FAB 기능과 필요없는 코드들은 걷어내고 추가해야할 부분만 코드를 업로드함

material.io/resources/icons/?style=baseline

머티리얼 아이콘 사이트에 들어가면 안드로이드 개발에 필요한 대부분의 아이콘을 svg, png 그리고 dp별로 다운로드 받을 수 있다.

검은색, 흰색도 정할 수 있고 간단한 add 아이콘부터 시작해서 다양한 아이콘들이 있어서 혼자 개발을 할때 편하게 사용할 수 있다.

귀찮게 직접 아이콘을 만들지 말고 다운받아 사용해보자!

이와 같이 원하느 아이콘을 검색하고 설정에 맞게 다운이 가능하다.

앱 액션바의 기본 색상을 변경하고 싶었는데 변경 방법이 기억 안나 툴바를 제작할 뻔했다.

하지만 잘 찾아보니 colors.xml에 있는 색상을 변경하고 그것을 styles.xml에 적용하면 되는 것이였다.

<resources>
    <color name="colorPrimary">#07f5de</color>
    <color name="colorPrimaryDark">#00e8d1</color>
    <color name="colorAccent">#03DAC5</color>
</resources>

액션바 - 상태바 - 버튼색순으로 배치되어 있다.

<resources>
    <!-- Base application theme. -->
    <style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
        <!-- Customize your theme here. -->
        <item name="colorPrimary">@color/colorPrimary</item>
        <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
        <item name="colorAccent">@color/colorAccent</item>
    </style>

</resources>

각 아이템에 맞는 색상을 집어 넣어 주면 된다.

위의 세가지 외에 다른 요소들도 각각 색깔을 지정해 줄 수 있는 데 밑의 블로그를 보고 많은 공부가 되었다.

iw90.tistory.com/108

예전에 자바로 구현해보았던 부분이지만 다시 만들어보니 생각보다 시간이 좀 걸렸다..

1. build.gradle의 dependencies에 코드를 추가한다.

dependencies {

    implementation 'com.google.android.material:material:1.2.1'

}

2. Floating Action Button을 추가하고자 하는 xml의 버튼 디자인 중 해당 버튼을 찾아 추가해준다.

<com.google.android.material.floatingactionbutton.FloatingActionButton
        android:id="@+id/fab"
        android:layout_width="60dp"
        android:layout_height="60dp"
        app:fabCustomSize="60dp"
        android:clickable="true"
        android:focusable="true"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintHorizontal_bias="0.919"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintVertical_bias="0.937"
        app:srcCompat="@drawable/add" />

여기서 보통은 백그라운드 이미지가 제대로 중앙에 오지 않을 것이다. 이때!

app:fabCustomSize="60dp"

width와 height 크기에 맞추어 위의 dp를 조절해 코드를 추가해주면 해결이 된다ㅎㅎ

3. 버튼을 추가한 xml을 사용하는 액티비티로 가서 새로운 액티비티를 열어주는 버튼 클릭 리스너 코드를 추가한다.

package com.example.desktop.mymo

import android.content.Intent
import androidx.appcompat.app.AppCompatActivity
import android.os.Bundle
import android.view.View
import com.google.android.material.snackbar.Snackbar

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val fab: View = findViewById(R.id.fab)		// 버튼 객체 생성
        fab.setOnClickListener {					// 클릭 리스너 생성
            val intent = Intent(this, EditActivity::class.java)	//인텐트 생성
            startActivity(intent)				//새로운 액티비티 시작
        }
    }
}

위의 과정을 거치면

위와 같은 FAB를 만들 수 있다.

다음 번엔 버튼 색깔 및 버튼 눌렀을 때 여러개의 버튼이 나오는 방법에 대해 공부를 해봐야겠다..

예전에 안드로이드 스튜디오를 처음 사용할때도 찾아봤던 내용이다. 맨날 헷갈려서 이번에는 기록해보려고 한다.

처음 시작할 경우 앱의 액션바가 보이지 않는 경우가 있다.

그때는 xml에 들어가 눈모양에서 "Show System UI"를 클릭해주면 나온다ㅎㅎ