'네이티브 앱이 뭐에요?' 기초적인 코딩(플러터) 궁금증 모음

세빈·2022년 1월 10일
flutter
2

[Flutter] 개발과 디자인

목록 보기
4/5
post-thumbnail

직접 그린 홍삼캔디다. 귀여운..

어느 날 생각한 건데 나는 '네이티브 앱'과 같은 기초적인 용어에 대해 정확한 답을 정의하지 못하고 있었다.
그걸 반성하는 차원에서 글로 정리하는 나의 궁금증들- (특히 플러터와 관련된.)

계속 추가하는 중.

목차 🚙

1. 네이티브 앱? 모바일웹앱? 하이브리드앱?

2. API?

3. [플러터] dispose(), 생명주기?

4. [플러터] Stateless/ful Widget?

5. [플러터] final? const?

1. 네이티브 앱? 모바일웹앱? 하이브리드앱?

출처: https://m.blog.naver.com/acornedu/221012420292

1)네이티브 앱

우리가 흔히 말하는 ' 어플리케이션 '이다. 모바일 기기에 최적화 된 언어로 개발된 앱으로, 안드로이드 SDK를 이용해 Java로 만드는 앱과 iOS 기반 SDK를 이용해 Swift로 만드는 대부분의 앱이 여기에 속한다.

2)모바일 웹앱

모바일웹과 네이티브앱을 결합한 형태로, 모바일웹의 특징을 가지면서 네이티브앱의 장점을 갖고 있다. 모바일웹 보다는 조금 더 모바일에 최적화 된 앱을 의미한다. 웹앱도 모바일웹처럼 모바일 브라우저에서 실행되지만, 풀 브라우저 방식이 아닌 단일 페이지 방식으로 화면을 진화해 속도가 빠르다.

*모바일웹이란?
모바일에서 PC용 사이트의 데스크탑 브라우저에서 실행되는 기능(글자폰트와 이미지, 터치 아이콘, 플래시 등)을 모바일에 맞추어 표현한 사이트를 의미합니다. 쉽게 말해, PC용 홈페이지를 모바일 스크린의 크기에 맞춰 줄여 놓은 것이라고 생각하시면 됩니다.

3)하이브리드 앱

하이브리드 앱은 '네이티브앱 + 웹앱' 이라고 생각하면 쉽다. 일반적으론 네이티브웹에 웹view를 띄워 웹앱을 실행시키는 것이 보편적이며 양쪽의 API 를 모두 사용할 수 있는것이 큰 장점이다.

장단점 정리

네이티브 앱모바일 웹앱하이브리드 앱
성능이 가장 높다.웹사이트를 보는 것이기에 따로 설치할 필요가 없다.네이티브 API, 브라우저 API를 이용한 다양한 개발이 가능하다.
네이티브 API를 호출하여 사용하기 때문에 플랫폼과 밀착되어 있다.모든 기기, 브라우저에서 접근 가능하다.웹개발 기술을 사용해 앱 개발이 가능하다.
해당 언어에 익숙하다면 좀 더 쉽게 접근 가능하다.유지보수가 용이하다.한 번의 개발로 다수의 플랫폼에 대응할 수 있다.
-> 아래부터는 단점--
플랫폼에 한정적이다.플랫폼 API(카메라 등)를 사용할 수 없고 브라우저 API만 가능하다.네이티브 기능에 접근하려면 결국엔 네이티브 개발 지식이 필요하다.
플랫폼에서 요구하는 언어에 제약적이다.(해당 언어+플랫폼의 API 다루는데 익숙해져야 한다.)친화적인 터치 앱을 개발하기 까다롭다.웹뷰에서 앱을 실행하기 때문에 앱의 성능=브라우저의 성능이 된다.
-네이티브, 하이브리드 앱보다 실행이 까다롭다. (브라우저를 열고 검색해야 함.)UI 프레임워크 도구를 사용하지 않는다면 개발자가 UI제작까지 해야 한다.

2. API?

출처 1, 출처 2


그림이 좀 요상하긴 한데 정확하다

API는 프로그램들의 상호작용을 돕는 매개체로 볼 수 있다.

API는 어떤 서버의 특정한 부분에 접속해서 그 안에 있는 데이터와 서비스를 이용할 수 있게 해주는 소프트웨어 도구입니다. API를 이용하면 두 개의 소프트웨어가 서로 통신을 주고받을 수 있으며, 이는 우리가 모바일을 이용해서 하는 모든 행동들의 기반을 이루고 있다고 할 수 있습니다.

1)API의 역할

  • 서버와 DB에 대한 출입구 : 모든 사람이 DB에 접근하면 안 된다. 따라서 우리가 가진 서버와 DB간 출입구 역할을 하여 허용된 사람에게만 접근성을 부여해 준다.

  • 애플리케이션과 기기 간 원활한 통신 : 데이터를 원활히 주고받을 수 있도록 돕는다.

  • 모든 접속을 표준화한다. : 기계/운영체제와 상관없이 누구나 동일한 액세스를 얻을 수 있다. 쉽게 말해 범용 플러그처럼 작동한다.

2)API의 유형

  • private API : 내부 API로, 회사 개발자가 내부적으로 발행하여 제 3자에게 노출되지 않는다. 자체 제품과 서비스를 개선하기 위함.

  • public API : 개방형 API로, 모두에게 공개된다.

  • partner API : 기업이 데이터 공유에 동의하는 특정인만 사용 가능하다. 비즈니스 관계에서 사용되고, 종종 파트너 회사 간에 소프트웨어 통합을 위해 사용된다.

3)API의 장점

  • private API를 이용할 경우 개발자들이 애플리케이션 코드를 작성하는 방법을 표준화함으로써 간소화되고 빠른 프로세스 처리가 가능하다.
  • SW 통합 시에 개발자들 간 협업이 용이하다.
  • Public API와 Partner API를 사용하면, 기업은 타사 데이터를 활용해 브랜드 인지도를 높일 수 있다. 또한 고객 DB를 확장해 전환율도 높일 수 있다.

4)API의 구조

SOAP는 프로토콜, REST는 아키텍처 스타일이다.
SOAP는 서비스 인터페이스를 통해서, REST는 URI를 이용해 서버에 접근한다.

  • REST API : Representational State Transfer. 네트워크를 통해서 컴퓨터들끼리 통신할 수 있게 해주는 아키텍처 스타일이다. 인터넷 식별자(URI)와 HTTP 프로토콜을 기반으로 하여 단순하다. 데이터 포맷은 브라우저 간 호환성이 좋은 JSON을 사용한다.
    클라이언트와 서버 사이에서 통신할 수 있게 하고, 아키텍처를 만들 수 있게 한다. 즉, REST방식의 API라면, 클라이언트-서버 모델로 구축되었다는 것을 의미한다.
    웹에 최적화되어 있고, 데이터 포맷이 JSON이기 때문에 성능과 확장성이 뛰어나고, 브라우저 간 호환성이 좋다.

  • SOAP API : Simple Objecy Access Protocol. 그 자체로 프로토콜이고, REST보다 더 많은 표준이 정해져 있어 조금 더 복잡하다. 보안, 트랜잭션 등을 준수해야 하는 조직에게는 적합한 방식이 될 수 있다. 웹 서비스 시나리오에 적용하기엔 좋지 않고, 기업용 애플리케이션 작업에 좀 더 이상적이다.
    보안 수준이 엄격하다. SSL을 지원, WS-Security라는 자체 표준 보안 기능도 가지고 있다. 따라서 은행용 앱이나 메시징 앱 등에 선호된다. 성공/반복 실행 로직이 규정되어 있어, SOAP API를 통해 통신하면 처음부터 끝까지 신뢰성을 제공한다. ACID를 준수하기 때문에 데이터의 변형을 줄여주고, DB와의 상호작용에 대해 사전에 정확하게 정의하기 때문에 데이터의 무결성을 지켜준다. 금융 정보 등의 민감한 데이터를 주고받을 때 일반적으로 많이 사용된다.

SOAP는 서버와 매우 긴밀하게 연결되기 때문에 그 통신 방식이 매우 엄격하며, 그래서 수정이나 업데이트를 하는 것이 보다 더 어렵다. REST 방식의 API에서는 클라이언트에서 해당 API가 필요하지 않지만, SOAP 방식의 API에서는 상호작용을 시작할 때조차도 클라이언트에서 API에 관한 모든 정보들을 필요로 한다.

5) SOAP vs REST

웹서비스에서는 REST API를 택하는 경우가 많고, 기업용 애플리케이션인 경우에는 많은 리소스, 엄격한 보안, 여러 요구 사항의 만족을 위해 SOAP를 택하는 경우가 많다!

3. [플러터] dispose(), 생명주기?

출처: 플러터 StatefulWidget 생명주기 (감사하게도 정말 자세히 설명되어 있다.)

StatelessWiget은 생명주기가 없고, State 객체를 생성하는 StatefulWidget만 생명주기를 가진다.

// 예) StatefulWidget의 initState에서 스트림을 사용하는 경우, 
// streamController에 할당된 메모리를 닫기 위해.
@override
void dispose() {
    cameraController?.dispose();
    bannerAd?.dispose();
    timer.cancel();
    suepr.dispose();
}

컨트롤러 객체가 제거될 때 변수에 할당된 메모리를 해제하기 위해 사용하는 메소드다.
트리에서 State 객체가 영구적으로 제거될 때 호출된다. 영구적으로 제거되었기 때문에 build()가 다시 호출되지 않는다. 이미 State 객체가 폐기되었기 때문에 dispose()에서 setState()를 호출하면 안 된다.

4. [플러터] Stateless/ful Widget?

출처: 플러터 StatelessWidget
플러터는 모든 UI를 위젯으로 처리한다. 플러터는 크게 두 가지 위젯을 가진다.

1) StatelessWidget (이하 stless)

상태(State)를 가지지 않는 위젯이다. stless위젯은 build() 함수를 통해 만들어진다. 상태 변화를 감지하지 않기 때문에 화면 구성 시 최초 한 번만 build()를 호출한 후 다시 호출하지 않는다.

따라서 '어떤 버튼을 누를 시 텍스트가 변경되는 동작' 구현에는 적합하지 않다. 텍스트의 상태 변화를 알지 못하기 때문이다.
Text위젯이 갱신되려면 build()를 다시 해야 하는데, 그러지 못해서 화면 상에는 변화가 없다.

따라서 stless는 상태 변경이 불필요한 화면 구성에 사용하기 적합하다.

2) StatefulWidget (이하 stful)

State 객체를 가진다. 거의 대부분의 stful위젯은 createState()를 통해 State 객체를 만드는 작업만 한다. 이 변경 가능한 특징을 갖고 있는 State 객체가 상태 변경 처리를 할 수 있다.

setState() 함수는 build() 함수를 재호출한다. 따라서 변경된 상태를 위젯에 반영해 화면이 갱신된다.

3) State의 특징

  1. 위젯이 빌드 완료된 후 읽을 수 있다. 따라서 build() 호출 전 State 설정이 돼야 한다.
  2. 위젯이 유효한 동안에 State는 변경될 수 있다.
    State는 생성되면 BuildContext에 연결된다.
  • BuildContext : 위젯 트리에서 위젯의 위치에 대한 참조. 하나의 BuildContext는 하나의 위젯만 가진다.
  • Widget Tree : 위젯은 트리 구조로 구성된다.

    모든 네모 박스가 다 위젯이다. 부모 위젯, 자식 위젯 개념도 있다.

4) 플러터의 세 가지 트리

  1. 위젯: 요소의 구성(Configuration)을 기술, 처리한다.
  2. 요소: 트리의 특정 위치에서 위젯을 인스턴스화 한다.
  3. 렌더 객체: 크기, 레이아웃 등을 다루고 렌더링을 처리한다.
  • 한 컬러 = 한 BuildContext
  • 컬러 속 흰 박스 = 위젯이 배치된 상태(인스턴스화) = 요소

5) 인스턴스화?

BuildContext에 위젯이 배치된다는 것.
State가 생성되면 BuildContext에 연결되기 때문에! State 생성 시 요소(Element)가 만들어진다는 말과 같다.

즉, State 생성 > 트리의 특정 위치를 참조하는 BuildContext 존재 > 해당 BuildContext에 연결 > 연결된 각 BuildContext에 위젯 배치(인스턴스화) > 요소(Element) 생성

5. [플러터] final? const?

출처

1. 공통점

한 번 설정한 값을 변경할 수 없다. 다른 값으로 변경하려고 시도하면 컴파일 오류가 발생한다.

2. 차이점

const : 컴파일 타임에서 상수를 정의할 수 있다. 즉, const로 정의한 상수는 런타임에서는 정의되는 값을 설정할 수 없다.
예를 들어, DateTime.now()는 런타임에서 호출될 때마다 결과 값이 다르기 때문에 const로 설정할 수 없다.

final : 런타임에서 결정되는 값도 설정할 수 있다.

final List<String> languages = []; //final: 값 추가 가능
const List<String> companies = []; //const: 값 추가 불가
languages.add('dart');
/* 둘 다 새로운 배열로 변경하는 건 불가능
// compile error
companies.add('Google');
languages = ['Java'];
*/

즉, final로 선언된 변수는 해당 변수에 새로운 값이 설정되는 것은 불가능하지만, 객체나 배열에 값을 추가하는 행위에 대해서는 관여하지 않는다.

3. final 장점

예기치 못한 상황에서 값이 변경되어 발생하는 문제를 해결 가능하다. 멀티 스레딩을 지원하는 경우에는 별도의 예외 처리 없이 간결한 코드를 작성할 수 있다.

4. 그런데 왜 const를 써야 할까?

요약하면, const가 더 불변의 정도가 강하다.

const는 app의 lifecycle에서 절대 변치 않음을 의미하기 때문에 색상, 글자 크기 등이 고정일 때 그 변수의 앞에 const를 붙여주어야 flutter 의 build method가 그 부분을 rebuild 하지 않게 되어 app의 속도가 빨라진다.

final도 고정 상수이긴 하지만, 상황에 따라 변할 수 있는 (주로 constructor에서 설정되는) 변수 앞에 주로 선언해 줘야 한다.

final은 widget이 생성되는 시점마다는 변경될 수 있지만, 한 번 생성된 위젯 내에서의 const 상수는 변경할 수 없다.

StatelessWidget이 그 대표적인 예다. 자체적으로 상태를 가지지 않기 때문에 '다른 속성을 가지는 StatelessWidget'으로 바꾸려면 constructor에 새로운 property 값을 전달하면서 새로운 위젯을 만들어야 한다. 이때 사용되는 것이 const variable이다. StatelessWidget의 모든 property는 const variable이다.

profile
세빈
코딩도 하고, 디자인도 합니다. 디자인이 좀 더 좋은 건 안비밀
이전 포스트

플러터 기초 참고 사이트

다음 포스트

왜 8 Point 그리드를 맞춰야 하죠?

2개의 댓글

comment-user-thumbnail
김하연학부생
2022년 1월 27일

최고시다

1개의 답글