File()

java.io.File의 length() : 파일의 byte단위 크기를 리턴

import java.io.File;
import java.io.IOException;
public class GetFileSize {
public static void main(String[] args) throws IOException {  
    File file = new File("d:\\example\\image.jpg");

    long bytes = file.length();
    long kilobyte = bytes / 1024;
    long megabyte = kilobyte / 1024;
  
    System.out.println(bytes + " byte"); // 3980059 byte
    System.out.println(kilobyte + " kb"); // 3886 kb
    System.out.println(megabyte + " mb"); // 3 mb
  }
}

MB > KB > Byte

Gradle 빌드 시스템에서의 Configuration on Demand

빌드 프로세스가 특정 작업을 실행할 때 그 작업에 필요한 프로젝트만 구성함. 때문에 multiple modules project에서만 유의미함. Gradle 프로젝트는 기본적으로 모든 서브프로젝트를 구성하지만, configuration on demand를 사용하면 실제로 필요한 서브프로젝트만 구성함. 이를 통해 초기 구성 시간을 단축할 수 있음.

// settings.gradle 파일에서 설정
org.gradle.configureondemand=true

런타임 구성에서의 Configuration on Demand

앱이 실행 중일 때의 configuration on demand는 사용자가 요청할 때만 필요한 리소스나 설정을 로드하는 것을 의미. 이는 성능 최적화와 메모리 사용 효율성을 높이기 위해 사용됨.
e.g. 사용자가 특정 기능을 사용할 때만 해당 기능에 필요한 리소스를 로드하거나 초기화하는 방식.

이 두 가지 맥락 모두 configuration on demand는 필요할 때만 필요한 것을 구성하여 효율성을 높이는 개념을 중심으로 함.

gradle docs : https://docs.gradle.org/7.6/userguide/multi_project_configuration_and_execution.html#sec:configuration_on_demand

buildConfigField, resValue, manifestPlaceholders

There are 3 types of variables in build.gradle : buildConfigField, resValue, manifestPlaceholders.
All of them are defined in Gradle "build" task, so their scope is "build".

Using buildConfigField will generate an actual Java constant in your app's generated BuildConfig class.
So for your example, you would then have something like this:

public static class BuildConfig {
    public static final String BASE_URL = "xxxxxxxxxx";
}

Using resValue will generate a resource of the type you specify into your app's res (resources) directory. So for a string, you'd be able to reference it via XML with @string/base_url or with getResources().getString(R.string.base_url).

resValue는 앱의 빌드 구성 중에서 리소스(문자열, 정수, 색상 등) 값을 동적으로 생성하고 정의할 때 사용되는 gradle 스크립트의 메서드 중 하나. 빌드 타임에 값을 생성하여 리소스 파일에 추가할 수 있음.

Using manifestPlaceholders allows you to add a substitution in AndroidManifest.xml.
So for example, GCM requires you to have a tag with the name set to X.permission.C2D_MESSAGE, where X is your application ID. So if you have multiple build flavors with different application IDs, you can use a manifestPlaceholders tag and then use it in your AndroidManifest.xml where it will be replaced with the correct value, like:

<uses-permission android:name="${applicationId}.permission.C2D_MESSAGE" />

For the record, applicationId is automatically added as a manifest placeholder, so there's no need to define it yourself, but that's just an example.

Basically, it depends on where you need it. If it's needed for an XML resource (a layout, menu, etc.), resValue is what you want. If it's needed to be accessed from Java code directly, buildConfigField will do the trick. For substitutions in the manifest, manifestPlaceholders is what you want.

A : MainActivity
B : DetailActivity

A에서 B로 이동시

B가 종료되고 A로 복귀

minifyEnabled 와 shrinkResources

앱의 빌드 설정 중에서 proguard 및 리소스 축소와 관련된 부분.

용어

code shrinking : 앱 및 라이브러리 종속 항목에서 미사용 클래스, 필드, 메서드, 속성을 감지하여 삭제. 예를 들어 라이브러리 종속 항목에서 몇 개의 API만 사용한다면 축소는 앱이 사용하지 않는 라이브러리 코드를 식별하고 앱에서 그 코드만 삭제할 수 있음.

resource shrinking : 앱 라이브러리 종속 항목의 미사용 리소스를 포함하여 패키징된 앱에서 사용하지 않는 리소스를 삭제함. 리소스 축소는 코드 축소와 함께 사용하여 미사용 코드를 삭제하고 마찬가지로 더 이상 참조되지 않는 리소스도 안전하게 삭제할 수 있음.

obfuscation : 클래스와 멤버 이름을 줄여 DEX 파일 크기를 줄임.

optimization : 코드를 검사하고 다시 작성하여 앱 DEX 파일의 크기를 더 줄임. 예를 들어 주어진 if/else 구문의 else {} 분기가 전혀 사용되지 않음을 R8에서 감지한 경우 R8이 else {} 분기 코드를 삭제함.

적용

1. minifyEnabled true: proguard 도구를 사용하여 코드를 축소(minify)하도록 하는 것. 코드 축소는 사용하지 않는 코드를 제거하여 코드를 최적화하고 난독화하여 앱 크기를 줄이고 보안을 강화하는 데 도움이 됨. (디컴파일을 어렵게 만듬)

2. shrinkResources true: 리소스 축소를 활성화하는 것. 리소스 축소는 사용되지 않는 리소스(이미지, 레이아웃 파일 등)를 제거하여 앱의 크기를 줄이는 데 도움이 됨. 이는 앱을 더 가볍게 만들고 다운로드 및 설치 시간을 단축하는 데 도움이 됨. 리소스 축소는 코드 축소와 함께 사용할 때만 작동함.

앱의 크기를 최적화하고 성능을 향상시키는데 도움, 특히 안드로이드 앱을 배포할 때 필요한 자원을 최소한으로 유지할 수 있음.

단점 (true 선택시)

1. 유지할 코드 충분히 확인시 proguard에 적용 시켜줘야 하는 번거로움
2. 빌드속도가 느려지기 때문에 debug 모두에선 false가 좋음(구글권장)

android developer document

(링크)

android {
    buildTypes {
        release {
            // Enables code shrinking, obfuscation, and optimization for only
            // your project's release build type.
            minifyEnabled true

            // Enables resource shrinking, which is performed by the
            // Android Gradle plugin.
            shrinkResources true

            // Includes the default ProGuard rules files that are packaged with
            // the Android Gradle plugin. To learn more, go to the section about
            // R8 configuration files.
            proguardFiles getDefaultProguardFile(
                    'proguard-android-optimize.txt'),
                    'proguard-rules.pro'
        }
    }
    ...
}

많이쓰는 것들 하나씩 추가예정

LocalDate.now() : 현재 시스템의 기본 시간대(default time zone)에 따라 현재 날짜를 가져옴

기본 시간대 사용: LocalDate.now()는 JVM이 실행 중인 시스템의 기본 시간대 설정을 사용하여 현재 날짜를 가져옴.
로컬 시간대 반영: 시스템의 시간대 설정에 따라 현재 날짜가 결정되므로, 예를 들어 한국 시간대(KST)에서는 한국 기준의 현재 날짜를 반환함.

ZoneId zoneId = ZoneId.of("Asia/Seoul"); // 서울 시간대
LocalDate todayInSeoul = LocalDate.now(zoneId);

In other words the deference between this line

val text = remember { mutableStateOf("") }

and this

val text = remember { "" }

mutableStateOf()

it's an observable that observes the values when underlaying values gets changes and updates the UI. like we use liveData and stateFlows but LiveData also has lifecycle mechanism and almost same goes with StateFlows.

remember{}

It persists the data across the recomposition.
what is recomposition? When the state get changes, the composable that holds that value recomposes itself to give us updated value.
for example: we have a textView(composable) that observes the value, right now which is 1. We press the button and increment the value with 2. What happens here when the value goes from 1 to 2 the textView(composable) recreates(recomposes) itself and shows us the updated value which is 2, this is known as recomposition.

when we use this: val text = remember{ mutableStateOf("") } that's means we are not only observing the data but also persisting the data across the recomposition.

The remember keyword can store a mutable or an immutable object.
If you pass mutableStateOf to remember, any time the value of that object changes, it will force recomposition of the composables that are reading that value.

Row(
    modifier = Modifier
        .fillMaxWidth()
        .padding(bottom = 12.dp) //background 이전 padding > margin
        .clip(RoundedCornerShape(4.dp)) //background 이전 clip해야 모양 유지
        .background(gray10)
        .clickable {
            clickSelectDrinkUnit(item.drinkType, item.drinkUnit)
        }
        .padding(16.dp) //background 다음 padding > 안쪽 padding
}

Row() 전체를 클릭 영역으로 잡고싶으면 .padding(bottom = 12.dp) 보다 아래에 순서를 잡아야함.
위에 위치하면 margin 12.dp 까지 같이 영역이 잡힘.

프로젝트 res/ 디렉터리 내부에서 지원되는 리소스 디렉터리

그러나 원래 파일 이름과 파일 계층 구조에 액세스해야 한다면 res/raw/ 대신 assets/ 디렉터리에 리소스를 저장해야함. assets/ 의 파일에는 리소스 ID가 부여되지 않으므로 AssetManager를 사용해서만 읽을 수 있음

dark 모드용 lottie 를 추가하고 싶을 경우 raw-night 과 같이 qualifier 을 추가할 수 있지만 assets 은 불가능함

String color accent 주는 법

1. SpannableStringBuilder()

  binding.txtTitle.text =
      SpannableStringBuilder()
          .append("해당 공고는")
          .color(ContextCompat.getColor(requireContext(), R.color.secondary_color)) {
              append("개인 정보 보호")
          }
          .append("를 위한 내용을 담고있어")
          .color(ContextCompat.getColor(requireContext(), R.color.secondary_color)) {
              append("본인만 확인할 수 있습니다")
          }

application 보다 content provider가 먼저 onCreate 됨.

ContentProvider는 안드로이드에서 데이터 공유 및 관리를 위한 컴포넌트로, 다른 앱이나 앱 내의 다른 컴포넌트와 데이터를 공유하는 데 사용됨. ContentProvider의 경우, 해당 컴포넌트가 독립적으로 실행되지 않고 다른 앱 또는 컴포넌트와 연동되므로 Context를 얻는 방법에 주의해야 함.

ContentProvider 클래스는 Context를 직접 상속받지 않음. 그러나 getContext() 메서드를 통해 Context에 액세스할 수 있음. 이 메서드는 ContentProvider를 초기화할 때 시스템에 의해 호출되고, 해당 컨텍스트는 ContentProvider의 라이프사이클 동안 유효함.

getContext()를 통해 얻은 Context는 일반적으로 Application 컨텍스트임. 따라서 ContentProvider에서 얻은 Context는 해당 앱 전체에 대한 컨텍스트임.

Called when the application is starting, before any activity, service, or receiver objects(excluding content providers) have been created.

content provider -> initialize(startup) dependencies (xx wrapper initialize) -> base applciation

buildConfigField 는 앱 Build 시에 코드에 문자열을 치환해버림.

buildConfigField를 사용하여 민감한 정보나 중요한 문자열을 코드에 숨기려고 하지만, 이러한 값들은 실제로 앱이 빌드될 때 해당 위치에 직접 삽입되기 때문에 코드를 디컴파일하면 해당 문자열이 그대로 노출됨.

//작성한 코드
String decStr = new AesCrypto(BuildConfig.SOME_KEY).decrypt(encStr); 
//빌드 후 문자열로 치환
String decStr = new AesCrypto("gDE4g5DFghsf5523HDSFdfg").decrypt(encStr); 이렇게 SOME_KEY 의 문자열로 치환되는 겁니다.

dialog dim 처리 하는 법

getDialog().getWindow().setDimAmount(0.7f);
<item name="android:backgroundDimAmount">0.7</item>

A extends BaseDialog를 해도 BaseDialog의 setStyle이 적용되는게 아니라 A의 setStyle이 적용됨. 그리고 xml이 그 위임.

0은 no dimming, 1에 가까울수록 black에 가까움

Values are between 0 and 1. Zero meaning there is no dimming, and 1 meaning 100% black.

fragment에서 viewBidning

viewBinding을 사용하면 binding class의 인스턴스를 사용해 view 참조가 가능함.
fragment는 view보다 수명이 김. 따라서 프래그먼트의 lifecycle에서 뷰가 제거될 때 호출되는 onDestroyView() 콜백 메소드에서 binding class의 인스턴스를 null 값으로 변경하여 참조를 정리해주어야 함.

Fragments outlive their views. 
Make sure you clean up any references to the binding class instance in the fragment's onDestroyView() method.
// 프래그먼트는 뷰보다 오래 지속됩니다. 프래그먼트의 onDestroyView()메서드에서 결합 클래스 인스턴스 참조를 정리해야 합니다.

override fun onDestroyView() {
      super.onDestroyView()
      _binding = null
}

Not All ViewBinding Need Null Setting

항상 null을 사용하여 메모리 해제를 신경쓰지 않아도 됨. activity는 view보다 outlive하지 않음.

private lateinit var binding: ResultProfileBinding

lateinit var 이 변수는 오직 activity가 onCreate() 메서드가 호출될 때만 생성.

The reason is that the Activity will not outlive the ViewBinding. 
The view of the Activity is always available since onCreate() until the end of the Activity Destroy.

The binding is lateinit var binding, is because this variable is not set when the activity is first constructed. It is only constructed during onCreate().

• android documnet

dialog tag의 역할

tag 매개변수는 Android 프래그먼트를 식별하는 데 사용되는 문자열. 프래그먼트를 식별자로 식별하고 관리하기 위해 사용됨.
FragmentTransaction을 사용하여 프래그먼트를 추가할 때 tag를 지정하면 해당 태그를 사용하여 프래그먼트를 식별할 수 있음. 이것은 특히 프래그먼트를 나중에 검색하거나 제거해야 할 때 유용함.

ex) FragmentTransaction을 사용하여 프래그먼트를 추가할 때

MyFragment myFragment = new MyFragment();
FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
ft.add(R.id.fragment_container, myFragment, "myFragmentTag");
ft.commit();
//"myFragmentTag"가 tag

MyFragment myFragment = (MyFragment) getSupportFragmentManager().findFragmentByTag("myFragmentTag");

if (myFragment != null) {
    // 프래그먼트를 찾았으므로 작업 수행
    FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
    ft.remove(myFragment);
    ft.commit();
}

tag에 대한 설명

/**
 * Display the dialog, adding the fragment to the given FragmentManager.  This
 * is a convenience for explicitly creating a transaction, adding the
 * fragment to it with the given tag, and {@link FragmentTransaction#commit() committing} it.
 * This does <em>not</em> add the transaction to the fragment back stack.  When the fragment
 * is dismissed, a new transaction will be executed to remove it from
 * the activity.
 * @param manager The FragmentManager this fragment will be added to.
 * @param tag The tag for this fragment, as per
 * {@link FragmentTransaction#add(Fragment, String) FragmentTransaction.add}.
 */
public void show(@NonNull FragmentManager manager, @Nullable String tag) {
    mDismissed = false;
    mShownByMe = true;
    FragmentTransaction ft = manager.beginTransaction();
    ft.add(this, tag);
    ft.commit();
}

상태바 색상변경

<item name="android:statusBarColor">@android:color/white</item>

상태바 없애기

<item name="android:windowFullscreen">true</item>

java.lang.IllegalStateException: Can't access the Fragment View's LifecycleOwner when getView() is null i.e., before onCreateView() or after onDestroyView()
at androidx.fragment.app.Fragment.getViewLifecycleOwner(Fragment.java:377)
at ....initOnBackPressedCallback

  override fun onAttach(context: Context) {
        super.onAttach(context)
        initOnBackPressedCallback()
    }

left: clipToPadding = "true" right: clipToPadding = "false"

구글 스토어에서 앱을 업데이트시 새로운 인스턴스가 생기는가

새로운 인스턴스가 생성되지 않음.
앱을 업데이트하면 새로운 APK 파일이 기기로 다운로드되고 설치됨. 그러나 사용 중인 앱의 실행 중인 프로세스는 종료되지 않고, 업데이트가 완료된 후에는 새로운 APK 파일의 코드가 실행됨.

앱을 업데이트하면 단순히 앱의 새 버전이 기존의 설치된 앱으로 대체됨. 따라서 앱이 업데이트되더라도 사용 중인 앱의 인스턴스는 종료되지 않고 유지.

onCreateView와 onViewCreated

onCreateView
onCreateView는 Fragment가 처음으로 UI를 그릴 때 호출.
이 메서드에서는 Fragment의 UI를 구성하고 관련된 View를 생성해야 함. 여기서 LayoutInflater를 사용하여 XML 레이아웃을 인플레이트하고, 그 결과로 나온 View를 초기화 및 설정. return 값 View는 Fragment의 UI 요소로 사용됨.

onViewCreated
onViewCreated는 onCreateView에서 반환된 View가 생성된 후에 호출됨.
onCreateView에서 반환된 View에 접근할 수 있으며, 이 시점에서는 View가 이미 생성되었기 때문에 UI에 대한 작업이 가능함.
View에 대한 이벤트 리스너를 설정하거나 추가적인 UI 조작을 할 수 있음.

onCreateView는 UI를 생성하고 초기화하는 역할, onViewCreated는 생성된 UI에 대한 추가적인 작업을 수행함.

git pull 취소하고 되돌리기

(ex.git pull origin main)

commit changes 그대로 남기고 싶을 때

git reset --soft HEAD~1

모두 reset.

git reset --hard ORIG_HEAD

git merge 취소하고 되돌리기

git reset --merge ORIG_HEAD

git commit 취소하고 되돌리기

git reset --hard HEAD

한 단계 앞 commit이나 commit을 실행하기 전 상태로 되돌리는 것이 가능.

git add 취소하고 되돌리기

git reset HEAD

로컬 파일 경로 설정할 때

/Users/parkdanbi/Desktop/project/keystore/release_key.jks

시스템 환경 설정할 때

환경 변수는 운영체제에서 이름(Name)과 값(value)로 관리되는 문자열 정보.
운영체제가 설치될 때 기본적인 내용이 설정되지만, 사용자가 직접 설정하거나 응용프로그램이 설치될 때 자동적으로 변경되기도 함. 자바 진영에서는 OS의 환경변수의 값을 System.getenv( ) 라는 메서드를 통해서 불러올 수 있음.

//String value = Sytstem.getenv(String name); 

System.out.println("전체 OS 환경변수 값 : " + System.getenv());
System.out.println("OS 환경변수 NVM_SYMLINK 값: " + System.getenv("NVM_SYMLINK"));

System.getenv("HOME")

리눅스에서는 System.getenv("HOME") 가 절대경로(/home/user)를 리턴함.
On Linux System.getenv("HOME") return absolute path /home/user, but on Windows return Users\user.

프로젝트 안 릴리즈키를 넣는것이 아니라 안드로이드 폴더에 저장해서 관리할 수 있음.

System.getenv("HOME") + "/.android/keystore/release_key.jks

android에서 data source와 repository를 나누는 기준

역할 및 책임 분리:
데이터 소스 (DataSource): 데이터를 로컬 또는 원격 소스에서 가져오는 역할을 수함. 예를 들어, 로컬 데이터베이스, 네트워크 호출, 캐시 등이 포함될 수 있음.
레포지토리 (Repository): 데이터를 가져와 비즈니스 로직을 처리하고, UI와 통신하는 역할을 수행함. 즉, 데이터의 소스를 추상화하고, 데이터의 변형 및 가공을 담당함.

앱 아키텍처에 따른 분리:
일반적으로 Android 앱에서는 MVVM 또는 Clean Architecture와 같은 아키텍처 패턴을 사용함. 이런 패턴에서는 데이터 소스와 레포지토리가 각자의 책임을 가지며 서로의 구현을 알지 못하는 것이 이상적임.

각각의 책임에 따라 데이터 소스와 레포지토리는 독립적으로 변경될 수 있음. 예를 들어, 데이터 소스를 변경해도 레포지토리의 코드는 변경되지 않아야 함.

// 데이터 소스
interface RemoteDataSource {
    suspend fun fetchData(): Result<Data>
}

// 레포지토리
class DataRepository(private val remoteDataSource: RemoteDataSource) {
    suspend fun getData(): Result<Data> {
        return remoteDataSource.fetchData().map { .. //비즈니스 로직에 맞게 가공
    }
}

이와 같이 RemoteDataSource는 데이터를 가져오는 역할, DataRepository는 데이터를 가져와 비즈니스 로직을 처리하는 역할을 수행할 수 있음.

find, firstOrNull 차이

find와 firstOrNull은 Kotlin 컬렉션에서 요소를 찾는 데 사용되는 메서드. 동작과 반환값에서 차이가 있음.

• find:

  • find 메서드는 컬렉션에서 조건에 맞는 첫 번째 요소를 찾음.
  • 만약 조건에 맞는 요소가 없으면 null을 반환하지 않고 예외를 발생시킴.
  • 따라서 find 메서드는 컬렉션 내에서 조건에 맞는 요소가 반드시 존재함을 가정하고 사용함.
  • 예를 들어, 리스트에서 특정 조건을 만족하는 첫 번째 요소를 찾을 때 사용됨.

• firstOrNull:

  • firstOrNull 메서드는 컬렉션에서 조건에 맞는 첫 번째 요소를 찾음.
  • 조건에 맞는 요소가 없으면 null을 반환. 즉, 요소가 존재하지 않을 때에도 예외를 발생시키지 않음.
  • 따라서 firstOrNull 메서드는 조건에 맞는 요소가 없을 수 있는 상황에서 사용됨.
  • 예를 들어, 리스트에서 특정 조건을 만족하는 첫 번째 요소를 찾을 때 사용될 수 있지만, 요소가 존재하지 않을 수도 있는 경우에도 사용됨.

• first 는 조건에 맞는 요소가 없으면 예외 발생.

activity? vs requireActivity()

activity!!는 액티비티를 직접 가져옴. 액티비티가 null이면 NullPointerException을 발생시킴.

requireActivity()는 프래그먼트가 액티비티에 연결되어 있지 않거나 액티비티가 null이면 IllegalStateException을 발생시키기 때문에 코드 안정성 측면에서 더 안전함. > ? 액티비티가 null이 될 가능성이 있는 경우에는 requireActivity()를 사용하는 것이 권장됨.

Call

public interface Call<T> extends Cloneable {
  /**
   * Synchronously send the request and return its response.
   *
   * @throws IOException if a problem occurred talking to the server.
   * @throws RuntimeException (and subclasses) if an unexpected error occurs creating the request or
   *     decoding the response.
   */
  Response<T> execute() throws IOException;

해당 요청에 대한 응답을 동기적으로 처리하는 데 사용됨.

1. 인터페이스 설명:
   Call는 제네릭한 형태로 정의되어 있음. 는 HTTP 응답에서 기대되는 데이터 형식을 나타냄.

2. 메서드 설명:
   Response execute() throws IOException;: 이 메서드는 HTTP 요청을 동기적으로 보내고, 서버로부터의 응답을 받아옴.
   execute 메서드는 IOException을 던질 수 있음. 이는 서버와의 통신 중에 문제가 발생했을 때 예외가 발생할 수 있음을 나타냄.
   RuntimeException과 그 서브클래스들을 던질 수도 있음. 이는 요청을 생성하거나 응답을 디코딩하는 동안 예상치 못한 오류가 발생했을 때 발생할 수 있음.

3. 요약:
   Call 인터페이스는 Retrofit에서 HTTP 요청을 나타내며, execute 메서드를 사용하여 해당 요청을 동기적으로 보내고 서버로부터의 응답을 처리함 . 이 과정에서 발생하는 예외들에 대한 처리가 내장되어 있음.

1. 가장 최근의 commit 수정

push 전의 commit

git commit --amend

위와 같이 amend 를 이용하면 가장 마지막에 commit 한 내용을 수정할 수 있음.

git commit --amend 를 사용하고 커밋을 수정할 수 있는 창이 뜨면, 수정을 완료한 후 esc -> :wq

2. 더 오래된 commit 수정 or 한 번에 여러 commit 수정

만일 위에서부터 세 번째 커밋을 수정해야 한다면

git rebase -i HEAD~3

수정하고 싶은 커밋 옆의 pick 이라는 문구 > reword 로 바꿔줌.
ex) 두 번째 커밋과 세 번째 커밋을 수정

pick e499d89 Delete CNAME
reword 0c39034 Better README
reword f7fde4a Change the commit message but push the same commit.

esc -> :wq 를 통해 커밋 리스트를 저장을 해주고 나면, 두 개의 커밋을 각각 수정할 수 있는 창이 순서대로 띄워짐.
커밋 수정 후, :wq 를 통해 저장.

3. 이미 커밋을 push 해 remote 에 올린 상황일 때

커밋이 이미 remote 에 적용된 상황이라면, force 를 통해 수정된 커밋을 강제로 push

git push --force 브랜치

💡 Concept :

가변의 state 값을 관찰해서 값의 변화에 따라 따라 UI 나 다른 로직에 대한 관리를 할 수 있음

mutableStateOf

androidx.compose.runtime
Compose UI를 위한 API UI에 특화되어 있음

관찰될 수 있는 MutableState를 생성해주는데, 이 타입으로 된 값이 변경될 때마다 컴포저블이 다시 recompose 되도록 함. 즉, 값에 따라서 Composable UI의 변경을 해주어야 할 때 사용하기 적합함.

mutableStateFlow

private val _state = MutableStateFlow(MyProfileUIState())
    val state: StateFlow<MyProfileUIState> = _state.asStateFlow()

// StateFlow는 MutableStateFlow의 read-only 타입의 부모, state flow 값을 생성하거나 변경할 때 사용하는 것이 mutableStateFlow

Kotlin의 Coroutine Flow API

MutableStateFlow : 변경 가능한 상태를 표현하는 Flow. 여기서는 MyProfileUIState 클래스의 인스턴스를 기본값으로 갖고 있음.

StateFlow: 변경 불가능한 상태를 표현하는 Flow.

MutableStateFlow에서 생성된 StateFlow를 만들기 위해 asStateFlow() 확장 함수를 사용함. 아래는 asStateFlow() 의 대한 설명.

Represents this mutable state flow as a read-only state flow

StateFlow는 업데이트가 가능한 데이터값을 가지는 State라는 것을 가지고, collector에게 emit(전파)하는 인터페이스임. State를 가지고 있다가 변경되면 emit을 해주는 역할을 하는 hot stream. StateFlow는 Complete라는 개념이 없이 계속해서 관찰될 수 있음

_state는 내부적으로 상태를 유지하고 업데이트하는 데 사용되는 MutableStateFlow.
_state를 외부에서 직접 접근하지 않고, 외부에는 state로 노출됨.

enum class values()의 name이란

enum class A {
  JOB_POSTING("jobPosting"), JOB_APPLICATION("jobApplication")
}

이렇게 있으면, name은 exactly as declared in its enum declaration인 JOB_POSTING을 말하는 것.

 val firstNavigationTab = MyProfileTab.values()
            .find { it.name == firstTabName }
            ?: MyProfileTab.PROFILE

name에 대한 설명

 /**
     * Returns the ordinal of this enumeration constant (its position in its enum declaration, where the initial constant
     * is assigned an ordinal of zero).
     */

super.onDismiss(dialog) 의 위치 순서

super.onDismiss(dialog)의 호출 위치는 중요. 이 호출은 부모 클래스인 DialogFragment의 onDismiss 메서드를 호출. 따라서 이 호출을 어디에 위치시키느냐에 따라 다이얼로그의 기본 동작이 언제 수행되는지에 영향을 미침.

보통은 super.onDismiss(dialog)를 메서드의 마지막 부분에 두는 것이 일반적. 만약 super.onDismiss(dialog)를 특정 동작 이전에 호출한다면 다이얼로그가 사라지기 전에 부모 클래스의 동작이 수행되어 원하는 행동대로 되지 않음.

override fun onDismiss(dialog: DialogInterface) {
    // 특정 동작 수행
        viewModel.sendDismissLogger(
            when (dismissType) {
                DismissType.CLOSE -> LogConstant.CLOSE
                DismissType.DIM -> LogConstant.DIM_CLICK
            }
        )

    // 부모 클래스의 동작 호출
    super.onDismiss(dialog)
}

 binding.img.setColorFilter(R.color.secondary100)

이 적용이 안되는 이유.

setColorFilter 메서드의 두 번째 매개변수로 색상을 설정할 , ContextCompat.getColor를 사용하여 리소스 ID 대신 실제 색상 값을 사용해야 함.
현재 코드에서는 리소스 ID를 전달하고 있기 때문에 적절한 색상이 전달되지 않고 다른 색상이 나옴.

 binding.img.setColorFilter(ContextCompat.getColor(requireContext(), R.color.secondary))

kapt

Kotlin Annotation Processing Tool. Kotlin 코드에서 애노테이션 프로세싱을 위한 플러그인.

자바에서는 일반적으로 annotationProcessor를 사용하여 애노테이션 프로세싱을 설정하는 반면, Kotlin에서는 kapt를 사용함. Kotlin 코드에서 사용되는 애노테이션 프로세서를 활성화하고 처리하기 위해 사용됨.

.
Hilt, Room은 자바와 어노테이션 프로세서 기반으로 작성된 library이기 때문에
코틀린에서 힐트 어노테이션 참조해서 작성하는 경우는 자바와 상호운용성을 위해 kapt 가 직접 컴파일타임에 stub이라는 파일을 작성해줌. 이런 것 때문에 빌드할 때 컴파일시간이 늘어나게 되지만 자바 컴파일러가 kapt 가 생성해준 stub 자바 파일을 생성해주기 때문에 코틀린으로 작성한 코드도 해석할 수 있음. 결국 힐트 어노테이션 프로세싱이 가능하게 됨.

따라서 Hilt, Room과 같은 라이브러리를 사용할 때는 Kotlin 프로젝트에서 kapt 플러그인을 사용하여 애노테이션 프로세싱을 활성화해야 함.

SHA-1 인증서 디지털 지문 값 얻기

./gradlew signingReport

setMargin programatically

binding.txtTitle.updateLayoutParams<ViewGroup.MarginLayoutParams> {
    setMargins(0, 0, 0, resources.getDimensionPixelSize(R.dimen.margin_24))
 }

Collecting from the UI

• 정적 타입 언어 : 변수의 데이터 타입이 컴파일 시에 결정. 변수를 선언할 때 해당 변수의 데이터 타입을 명시적으로 지정. 컴파일러는 변수의 타입을 확인하고, 잘못된 타입의 값을 할당하려고 하면 컴파일 오류를 발생시킴

• 동적 타입 언어 : 변수의 데이터 타입이 실행 시간(runtime)에 결정되는 언어. 다시 말해, 변수를 선언할 때 명시적으로 데이터 타입을 지정하지 않고, 변수에 값을 할당할 때 해당 값의 타입에 따라 동적으로 타입이 결정됨. 프로그램을 작성할 때 더 유연하게 코드를 작성할 수 있게 해주지만, 실행 중에 타입 관련 오류가 발생할 가능성을 내포하고 있음.

android:visibility와 tools:visibility

실제 런타임 동작 :
android:visibility : 이 속성은 런타임 동작에 영향을 줌. 해당 뷰의 실제 가시성을 제어.
tools:visibility : 이 속성은 레이아웃 편집기에서만 사용됨. 디자인 타임에만 해당 뷰의 가시성을 제어.

ifEmpty, orEmpty

• ifEmpty : collection이 비어있는지 확인하고, 비어있으면 디폴트 값을 넘겨줌

val list = listOf<Int>()
val result = list.ifEmpty { listOf(1,2,3) }
println(result) // [1,2,3,]

• orEmpty
  • null이나 emptyList가 아닐 경우 : list 그대로 반환
  • null일 경우 : emptyList()
  • emptyList일 경우 : emptyList()

onBackPressed

액티비티에서 사용자가 뒤로 가기 키를 눌렀을때 이를 감지하여 호출되는 메서드.
API 레벨 33부터 더이상 사용되지 않아 deprecated 됨. 대신 OnBackInvokedCallback 또는 androidx.activity.OnBackPressedCallback 를 사용하기를 권고.

FragmentActivity와 AppCompatActivity의 기본 클래스인 ComponentActivity를 사용하면 OnBackPressedDispatcher(getOnBackPressedDispatcher()를 호출하여 가져옴)를 사용하여 뒤로 버튼의 동작을 제어할 수 있음.

 callback = object : OnBackPressedCallback(true) {
            override fun handleOnBackPressed() {
                isEnabled = true
            }
        }

requireActivity().onBackPressedDispatcher.addCallback(viewLifecycleOwner, callback)

versionNameSuffix, applicationIdSuffix

versionNameSuffix : 버전명에 대한 추가적인 식별자를 제공
applicationIdSuffix : 패키지 식별자에 대한 추가적인 식별자를 제공

cp

: 현재 디렉터리에 있는 파일을 원하는 디렉터리에 복사 붙여넣기 하기

cp [복사할 파일] [붙여넣기할 디렉터리]

$ cp file1 dir1

cp ~/Downloads/release_key.jks ~/.android.keystore

FLAG_ACTIVITY_SINGLE_TOP

액티비티 스택에서 최상단에 있는 액티비티와 전환 될 액티비티가 같을 때, 새로운 인스턴스(인텐트)를 생성하지 않고, 스택에 있던 액티비티의 인텐트를 통해 재사용하는 것을 의미.

액티비티를 재사용하는 것이기 때문에, onCreate() 콜백부터 실행되는 것이 아니라 onNewIntent() 콜백을 통해, 기존 액티비티의 intent 정보를 받아 onResume() 콜백으로 호출됨

onNewIntent() -> onResume()

현재 눈에 보이는 액티비티는 이미 액티비티 스택에 적재된 상태이면서, 가장 최상단에 있는 상태(눈에 보이는 상태)임

FLAG_ACTIVITY_CLEAR_TOP

현재 불러올 액티비티가 B인데, 이미 스택에 존재한다면 B를 포함한 모든 액티비티들을 pop해버리고 새로 호출한 B 액티비티를 스택 최상단으로 지정하는 것을 의미

새롭게 인스턴스를 생성하는 것이기 때문에 새 intent를 갖는 액티비티를 생성하게 됨. 그렇기 때문에 라이프 사이클도 onCreate() -> onResume() 로 호출이 됨. 반대로 호출하려는 액티비티가 스택에 없으면 기본적인 intent 동작을 하게됨

onCreate() -> onResume()

Intent.FLAG_ACTIVITY_SINGLE_TOP or Intent.FLAG_ACTIVITY_CLEAR_TOP

둘을 함께 사용하면, 시작하려는 액티비티가 이미 스택에 존재하는 경우 새로운 인스턴스를 생성하지 않고 기존 인스턴스를 재사용하면서, 필요에 따라 해당 액티비티 위에 있는 다른 액티비티들을 제거할 수 있음.

시작하려는 액티비티가 스택 최상단에 있는 경우: FLAG_ACTIVITY_SINGLE_TOP의 효과로 새로운 인스턴스가 생성되지 않고 기존 인스턴스가 재사용됨. FLAG_ACTIVITY_CLEAR_TOP은 아무런 영향을 미치지 않음.

시작하려는 액티비티가 스택 중간에 있는 경우: FLAG_ACTIVITY_CLEAR_TOP의 효과로 해당 액티비티 위에 있는 모든 액티비티가 제거됨. 그리고 FLAG_ACTIVITY_SINGLE_TOP의 효과로 새로운 인스턴스가 생성되지 않고 기존 인스턴스가 재사용됨.

메인(A) -> 편집(B) -> 인증입력(C) -> 인증완료(D) -> 편집(B)으로 이동하는 경우, 
FLAG_ACTIVITY_SINGLE_TOP과 FLAG_ACTIVITY_CLEAR_TOP을 함께 사용하면 기존 편집(B) 위에 있는 C와 D액티비티가 제거되고 기존 편집(B)이 최상단으로 오게됨

메인(A) -> 기존 편집(B)
때문에 기존 편집(B)에서 뒤로가기를 눌렀을시, 메인(A) 화면 노출

메인(A) -> 인증입력(B) -> 인증완료(C) -> 편집(D)으로 이동할 때, 편집(D)에서 뒤로가기를 눌렀을시 메인(A)으로 떨어질 것을 기대할 때

인증입력(B), 인증완료(C) 액티비티를 Manifest의 taskAffinity 에 지정하여 C에서 D로 intent 이동할때 finishAffinity() 를 호출하여 affinity단위로 스택에서 제거함

androidx.appcompat.widget.AppCompatimageView

Android Jetpack 라이브러리의 AppCompatImageView 클래스.
이 클래스는 Android의 기본 ImageView 클래스를 확장하여 하위 호환성을 제공하고 AppCompat 지원 라이브러리와 함께 제공되는 추가 기능을 포함.

AppCompatImageView와 기본 ImageView 비교

gradle과 gradle.kts 차이

module 만들 때 build configuration language에서 Groovy DSL(build.gradle)과 Kotlin DSL(build.gradle.kts)선택할 수 있음

확장자:
gradle: 기본적으로 Groovy 스크립트를 사용.
gradle.kts: Kotlin DSL을 사용.

문법:
gradle: Groovy 문법을 사용.
gradle.kts: Kotlin 문법을 사용.

타입 안정성:
gradle: Groovy는 동적 타입 언어이므로 타입 안정성이 상대적으로 낮음.
gradle.kts: Kotlin은 정적 타입 언어로서 높은 타입 안정성을 제공.

• 정적 타입 언어 : 변수의 데이터 타입이 컴파일 시에 결정. 변수를 선언할 때 해당 변수의 데이터 타입을 명시적으로 지정. 컴파일러는 변수의 타입을 확인하고, 잘못된 타입의 값을 할당하려고 하면 컴파일 오류를 발생시킴

• 동적 타입 언어 : 변수의 데이터 타입이 실행 시간(runtime)에 결정되는 언어. 다시 말해, 변수를 선언할 때 명시적으로 데이터 타입을 지정하지 않고, 변수에 값을 할당할 때 해당 값의 타입에 따라 동적으로 타입이 결정됨. 프로그램을 작성할 때 더 유연하게 코드를 작성할 수 있게 해주지만, 실행 중에 타입 관련 오류가 발생할 가능성을 내포하고 있음.

IDE 지원:
gradle: Groovy는 IntelliJ IDEA, Eclipse 등 다양한 IDE에서 지원되지만 Kotlin DSL에 비해 통합 개발 환경에서 덜 강력한 지원을 받을 수 있음.
gradle.kts: Kotlin은 IntelliJ IDEA와 같은 IDE에서 강력한 지원을 받음. Kotlin DSL은 타입 안정성이 높음.

코드 재사용:
gradle: Groovy의 동적 특성으로 인해 코드 재사용이 어려울 수 있음.
gradle.kts: Kotlin의 정적 타입 특성으로 코드 재사용이 더 쉬울 수 있음.

사실상 Groovy와 Kotlin 언어적인 특징의 차이뿐인가? 차이가 날만한 차이는 없는 듯.

<ConstraintLayout>
    <ImagView..
        id= img_dot
     //>
    
    <TextView..
        id = txt_title
        app:layout_constraintStart_toEndOf="@+id/img_dot"
      //>
</Constraint...>

constratinStart_toEndOf 만 체이닝하면 뒤에 text가 길어지면 잘릴 수 있음.
constraintEnd_toEndOf="parent" 까지 해줘야함.

일반적으로 newInstance 메서드를 사용하여 Fragment를 생성할 때 Fragment 내에서 상수를 정의하는 것이 더 좋은 방법.

1. Fragment가 자체적으로 더 독립적, 재사용성이 높아지기 때문.
2. 여러 Fragment 인스턴스에서 동일한 상수를 공유하려면 Fragment 내에서 해당 상수를 정의하고 사용하는 것이 유지보수 측면에서 효율적.
3. 상수 사용하는 코드가 Fragment 내부에 있으면 해당 Fragment만 수정하면 됨으로 수정 범위 최소화.

pull 했을 시 Not possible to fast-forward, aborting.

Fatal: Not possible to fast-forward, aborting.
fatal: 정방향이 불가능하므로, 중지합니다.

pull하려는 원격저장소의 브랜치와 로컬저장소의 브랜치가 fast-forward 관계가 아닐 때에 발생.
처음에 pull받아서 작업하더라도 팀원이 remote에 업데이트하는 상황도 있음.
원격저장소의 새로운 commit이 존재하는데 git pull을 하지 않은 상태에서 로컬저장소에 새로운 commit을 했다면 해당 에러가 발생함.
git pull을 습관화.

git pull --rebase

이후 conflict 해결 후 git add, git commit, git rebase --continue, push

merge 할 때

git add .
git commit

rebase 할 때

git add .
git rebase --continue
git push -f

git merge 취소

git merge --abort

git rebase 취소

git rebase --abort

flow는 스스로 라이프 사이클을 알지 못하기 때문에 CoroutineScope 생명주기에 따라 맞추어 사용하며 불필요한 메모리나 리소스가 낭비되지 않도록 하는 것이 중요함.

lifecycleScope.launch

private val _stateFlow = MutableStateFlow(0)
val stateFlow get() = _stateFlow

private fun count() {
	viewModelScope.launch(Dispatchers.IO) {
    	repeat(10) {
        	_stateFlow.value = it
                delay(3000)
		 }
	 }
 }
    
    
 lifecycleScope.launch {
 	viewModel.stateFlow.collect {
    		Log.d("TAG", "number : $it")
        }
 }

flow를 이용하여 데이터를 collect 하는 job이 존재함. lifecycleScope 안에서 flow에 대한 collect이 호출됨.
count() 함수를 실행하고 백그라운드로 가거나 앱 종료시.

activity가 finish() 되어 onDestroy가 호출되면 데이터 수집이 중단. onStop이 된 경우에도 여전히 데이터 스트림에 대한 collect이 일어남. 사용자가 앱을 작동하지 않는 상태에서 collect이 발생하는 것은 불필요한 메모리나 리소스가 낭비될 수 있음

private var job : Job? = null

job = lifecycleScope.launch {
            viewModel.stateFlow().collect {
                Log.d("MainActivity","number : $it")
            }
        }



override fun onStop() {
	super.onStop()
	job?.cancel()
}

그래서 onStop에서 job을 cancel해주어야 백그라운드에서 데이터가 수집되는 것을 방지할 수 있음. 잊고 cancel을 해주지 않는 경우 메모리 사용량이 증가할 가능성이 있음. 이를 방지할 수 있는 lifecycleScope.launchWhenStarted와 repeatOnLifecycle이 있음

launchWhenStarted

lifecycleSceop.launchWhenCreated, Started, Resumed scope가 있고 해당 스코프는 when 이후 접미어에 해당하는 생명주기에 맞춰 실행이 되고 생명주기의 상태가 충족이 되지 않으면 정지가 되는 함수

lifecycleScope.launchWhenStarted {
	viewModel.stateFlow.collect {
    	Log.d("TAG,"number : $it")
    }
}

홈버튼을 눌러 onStop() 상태가 되면 생명주기의 상태를 충족시키지 못해 코루틴이 suspend 상태가 됨. 그 후 앱을 다시 진입하면 조건을 다시 충족하기 때문에 데이터 수집을 재개함. 즉 lifecycle이 destroyed 될 때 job이 cancel 될 수 있음

repeatOnLifeCycle

repeatOnLifeCycle은 앞의 스코프와 달리 재구성이 가능함. launchWhenstarted는 백그라운드에서 포그라운드로 진입할 때 일시 중지된 코루틴을 재개한다면 repeatOnLifeCycle은 다시 돌아오면 처음부터 재구성함. 또한, launchWhen 함수는 자동으로 생명주기에 맞추어지지만 생명주기에 맞춰 코루틴을 시작, 취소, 재시작하기 위해서는 repeatOnLifeCycle 확장함수를 사용할 수 있음. 즉, repeatOnLifecycle 은 호출하는 coroutine을 suspend 시키고, lifecycle 이 target state 에서 벗어나면 재시작함. 그리고 Lifecycle 이 destroyed 되면 호출하는 coroutine 을 resume 시킴.

lifecycleScope.launch {
  	repeatOnLifecycle(Lifecycle.State.STARTED) {
    	viewModel.stateFlow.collect {
        	Log.d("TAG", "number : $it")
        }
    }
}