인터넷 개발자로서 안드로이드 앱을 개발하는 사고
결과에 비해 새로운 플랫폼을 개발하는 데 상대적으로 시간이 걸리기 때문에 이 프로젝트는 한동안 정체됐다.내가 우연히 새로운Jetpack Compose toolkit 사용자 인터페이스가 만들어진 것을 발견했을 때 나의 흥미는 다시 높아졌다. 왜냐하면 이 프로젝트는android 개발의 방향을 통찰할 수 있기 때문이다.
나의 대부분의 소프트웨어 개발 경험은 웹 응용 프로그램을 위해 사용자 인터페이스를 구축하는 기술, 프레임워크와 라이브러리에서 비롯되었기 때문에 모바일 응용 프로그램을 구축하는 것은 내가 사용하는 것과 멀지 않다.특정한 플랫폼에서 특정한 도구와 프레임워크 기능을 사용하는 것은 여전히 내가 익숙하지 않은 일이기 때문에 다음은 나의 발견이다.
첫 번째 설치
웹 개발에 비해 현저한 차이점은 적합한 IDE(Android Studio)를 가지고 있다는 것이다.IDE 처리 소프트웨어 개발의 거의 모든 측면, 코드 버전 제어부터 응용 프로그램 생성, 평가, 디버깅까지.그것은 또한 밑바닥 공구를 표준화하여 그것들을 잘 숨겼다.예를 들어, 그것만 유효하다면Gradle이 프로그램을 구축할 때 어떤 명령을 필요로 하는지 알 필요가 없다.프로그램이 작동하도록 하는 절차가 아니라 코드와 기능에 더 많은 관심을 기울이면 장치에 유형적인 내용을 표시하는 시간을 단축할 수 있다.
IDE가 제공하는 모든 유용한 도구가 있으면 첫 번째 프로젝트를 시작하기가 정말 쉽다.현재 Jetpack Compose를 제외한 모든 제품에 적용되며 Jetpack Compose는 알파 상태이므로 프로젝트에 추가 패키지가 필요합니다.다행히도 구글은 매우 간단한guide 해결 방안을 제공하였다.
어떻게 진행하면 그리 번거롭지 않을 것이다
전반적으로 Android Studio를 다운로드하는 데 1~2시간 정도 소요되며 첫 번째 어플리케이션을 한 장치에서 실행하고 필요한 모든 라이브러리(Jetpack Compose 포함)를 준비할 수 있습니다.내가 보기에 IDE가 없는 같은 과정이 하루 종일 걸릴 수도 있다는 것을 감안하면 그리 많은 것은 아니다.나는 또한 IDE가 제공하는 모든 기능에 만족한다. 예를 들어 잘못된 빨간색 표시기, 그리고 코드를 더욱 읽을 수 있도록 하는 각종 자동화 제안이다.
글쓰기 코틀린
새로운 프로그래밍 언어인 Kotlin은 나의 표준 개발 작업 절차의 두 번째 관건적인 차이점이다.Javascript와 Typescript를 보면 큰 차이가 없다.Kotlin은 자바보다 가독성이 뛰어나고 이해하기 쉬워 개발이 더 만족스럽다.
모델 뷰 모델 설계 모델
안드로이드 소프트웨어를 작성하는 일부분으로 View 모델 종류를 작성했는데 이것은 모델 View 디자인 모델의 일부분이다.최근 사용자 인터페이스 응용 프로그램에서 유행하는 것 같다.iOS의 SwiftUI도 MVVM과 VueJS를 사용하고 있으며, Angular는 모두 그 실현에서 데이터와 보기 구성 요소의 분리를 추진한다.MVVM은 크게 다르지 않습니다.
이 모드의 요약은 UI 레이어와 데이터 레이어를 분리하고 ViewModel을 통해 연결하는 것입니다.이것은 내가 습관적으로 하는 방법과 크게 다르지 않지만, 지지적인 요소로 이 점을 실현하면 일을 간소화할 수 있다.
마지막으로 나는 대략적으로 Josip Šalković's article에 근거하여 데이터 부분을 한층 더 분할했다.이것은 룸을 로컬 데이터베이스로 사용할 때 특히 유용하다. 데이터베이스 호출은 실제 논리와 분리되어 처리되고, ViewModel 코드의 등급이 매우 높기 때문이다.
주입기에 의존하다
의존 주입은 리액트에서 많이 사용되지 않지만, 리액트에서도 많이 사용되지 않는다.의존항을 구성 요소 내부에서 정의하는 것이 아니라, 필요할 때 의존항을 유연하게 변경할 수 있도록 입력 매개 변수로 정의할 수 있다는 사상이다.내가 보기에 가장 큰 장점은 테스트를 작성하는 단순성이다. 왜냐하면 주입된 의존항이 긴밀하게 결합된 의존항보다 시뮬레이션하기 쉽기 때문이다.
내 선택은 Hilt 의존 주입 프로그램으로 사용하는 것이다. 이것은android 문서의 조언이기 때문이다.기본 설정은 간단하고 실행하기 쉬우나 칼자루의 자동 기능이 매우 강해 배후의 상황을 이해하기 어렵다.어떤 것들이 완전히 예상대로 일을 하지 않는 한 이것은 큰 문제가 아니다.
예를 들어 의존항이 없는 Repository 클래스가 있기 때문에 일반 클래스로 만들고 싶습니다.내가 프로그램을 구축하기 시작하고 이상한 구축 오류가 발생하기 전에 모든 것이 좋은 것 같았다.빈 주사 설정이 부족했기 때문이라는 것을 발견하는 데 오랜 시간이 걸렸다.
비록 나는 Hilt가 제공하는 단순성을 좋아하지만, 그것은 결국 많은 시간이 걸려야 식별할 수 있는 버그를 촉발할 것이다. 왜냐하면 너무 많은 마법이 막후에서 발생하기 때문이다.이것은 더 많은 일을 수동으로 완성해야 하기 때문에 나는 뚜렷한 결점이 있어도 칼자루를 계속 사용할 것이다.
에어백
놀랍게도 안드로이드 개발자에게 가장 익숙한 부분 중 하나는 Jetpack Compose를 이용한 UI 개발이다.React의 생각은 거의 같다. 모든 UI 구성 요소는 하나의 함수이고, 전체 UI는 이런 작은 UI 구성 요소로 구성된다.안드로이드에는 내부 상태를 처리하는 mutableStateIF 함수도 있습니다.IDE는 @preview 주석이 있는 구성 요소에서 나온 시각적 미리보기도 있는데 마치 이야기책 같다.
@Composable
fun ListItem(
title: String,
subtitle: String
){
val textState = remember { mutableStateOf(TextFieldValue()) }
Column(){
Text(text = title)
Text(text = subtitle)
TextField( value = textState.value, onChangeValue = { textState.value = it } )
}
}
이 모드는 다른 UI 모드에 해당합니다.Jetpack Compose를 제외하고 SwiftUI는 UI를 작성하는 데 매우 유사한 모델을 가지고 있으며, 현재 거의 모든 웹 전단 프레임워크는 같은 모델을 사용하고 있다.나는 React에서 그것을 사용한 지 상당히 오래되었는데, 전방에서 일하는 다른 개발 모델에 비해, 이것은 의심할 여지없이 개발에 커다란 추진을 가져왔다.스프레이 백팩이 아직 완전히 준비되지 않은 것이 틀림없다(그래서 알파 상태)고 할 수 있다. 당연히 느낄 수 있다.
안드로이드를 개발하는 괴벽
스프레이 백팩은 계획대로 진행되지 않은 유일한 부분이 아니다.
Play Store에 애플리케이션 추가
애플리케이션의 첫 번째 버전이 준비되면 Google Play 스토어에서 이를 발표할 시간이 됩니다. 상당히 긴 여정입니다.인터넷 개발자로서 이 소프트웨어는 종종 원래대로 발표되기 때문에 개발이 끝나면 이 소프트웨어를 배치하고 마케팅을 시작할 수 있다.
플레이스토어에서 앱은 사전에 좋은 설명과 캡처, 마케팅 자료가 있어야 하며, 심지어 앱 패키지를 제출하기 전에 대량의 필수 내용을 작성해야 한다.일단 모든 것이 준비되면, 응용 프로그램은 고객에게 제공하기 전에 심사를 진행할 것이다.이것은 전체 업데이트와 버그 복구 과정을 웹 개발과 크게 다르게 할 것이다. 왜냐하면 응용 프로그램에서 버그를 복구하는 데 더 많은 시간이 걸리기 때문이다.
조사 결과
이 경험에서 가장 중요한 발견은 서로 다른 플랫폼을 개발하는 것이 과거처럼 다르지 않다는 것이다.UI와 응용 프로그램 구조를 구축하는 모델은 웹과 본기android에서 모두 비슷해지기 시작한다. 비록 이러한 도구 자체가 서로 다른 기능을 제공할 수 있지만.이것은 개발자의 생활을 더욱 가볍게 할 것이다. 왜냐하면 한 플랫폼에서 온 지식은 적어도 어느 정도에 다른 플랫폼에 사용될 수 있기 때문이다.
나는 또한android 응용 프로그램에서 사용하는 패턴이 나로 하여금 인터넷에서 그것들을 더욱 많이 사용할 수 있게 하고, 특히 React에서 이것은 나에게 실험을 할 수 있는 자유를 주었다.예를 들어, MVVM 디자인 모드는 데이터 레이어와 뷰 레이어를 중간 레이어와 간단하게 분리하여 만들 수 있으며, 중간 레이어는 데이터가 변경될 때 다시 로드되도록 합니다.
플랫폼 간에 비슷한 점이 많지만 모바일 응용 프로그램의 분포는 웹과 크게 다르다.클라이언트와 개발자 사이에 하나의 응용 프로그램 저장 구역을 가지는 것은 결과를 사용자에게 직접 나누어 주는 것과는 전혀 다른 체험이다.이것 또한 여러 개의 클라이언트 버전에서 서비스의 변경을 고려하거나 오류 복구를 나누어 주는 등 해결해야 할 일련의 새로운 도전을 가져왔다.George Orosz's blog post 이런 화제를 잘 건드렸기 때문에 나는 그의 관점을 읽는 것을 강력히 건의한다.
VS코드는 좋은 텍스트 편집기이지만 안드로이드 스튜디오에서 더 많은 IDE급 기능을 놓칠 수 있습니다.그 중 하나는 코드 옆에 이야기책과 유사한 구성 요소 보기입니다.다른 한편, Prettier를 사용하여 저장할 때, 나는 엄격한 자동 포맷에 익숙해졌는데, 이것은 내가 프로그램을 작성할 때 놓친 것이다.
이 여정의 결과를 보려면 Google Play의 CallGates 애플리케이션을 방문하십시오.
Reference
이 문제에 관하여(인터넷 개발자로서 안드로이드 앱을 개발하는 사고), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/akirautio/reflections-on-developing-android-application-as-a-web-developer-p86텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)