MVVM의 이해와 사용, 라이브 데이터,viewmoel의 소개
6231 단어 안드로이드 진급
1. mvvm의 간단한 소개
MVVM은 주목점 분리를 강화하는 체계 구조 모델 중 하나로 사용자 인터페이스 논리를 업무(또는 백엔드) 논리에서 분리할 수 있다. 그의 목표(MVC 등 다른 목표)는'UI 코드를 단순화하고 더 많은 업무 논리와 관련되지 않도록 함으로써 개발자가 더욱 잘 제어하고 관리할 수 있도록 하기 위한 것이다'.
MVVM은 주로 다음과 같은 몇 가지 차원이 있다. 1. 모델층 모델층은 사용자 프로그램의 데이터와 업무 논리를 나타낸다. 이 층의 추천 실현 전략 중 하나는 데이터의 변화를 관측하고 전달하여 View모델이나 다른 관찰자/소비자로부터 완전히 결합시키는 것이다.
2. ViewModel 층 ViewModel은 모델(데이터 층)과 상호작용을 하고 ViewMode는 View에서 관찰할 수 있다.ViewModel은 모델에 이벤트를 전달하기 위해 뷰에 선택적으로 갈고리를 제공할 수 있습니다.이 층의 중요한 실현 전략은 모델과View를 분리하는 것이다. 즉 View모델은 누구와 상호작용하는 보기를 의식하지 말아야 한다는 것이다.
3. View층 이 모드의 보기 역할은 ViewMode를 관찰하거나 구독하며 데이터 b의 변화를 관찰하여 데이터를 얻어 UI 요소를 업데이트하는 데 편리하도록 한다.
viewmodel
1、LiveData
위에서 말한 바와 같이 LiveData는 새로 도입된 구성 요소 구조 중의 하나이고 LiveData는 관찰할 수 있는 데이터 소유자이다.따라서 애플리케이션의 구성 요소가 LiveData 객체의 변경 사항을 관찰할 수 있으므로 이들 간에 명확하고 엄격한 의존 관계를 만들 필요가 없습니다.이는 라이브데이터 대상 사용자와 라이브데이터 대상 생산자를 완전히 분리하는 것이다.
이외에도 LiveData는 응용 프로그램 구성 요소(이벤트, 세션, 서비스)의 생명주기 상태를 준수하고 구성 요소의 생명주기 관리에 들어가 LiveData 대상의 메모리 유출을 확보하는 데 큰 장점이 있다.
2. ViewModel ViewModel도 새로 도입된 체계 구조 구성 요소 중의 하나이다.구조 구성 요소는 UI/View를 위한 데이터를 준비하는 View 모델이라는 새로운 종류를 제공합니다.
ViewModel은 MVVM 모드의 ViewModel에 좋은 기본 클래스를 제공합니다. ViewModel (하위 클래스인 안드로이드 ViewModel) 의 확장 클래스는 설정이 변경되는 동안 자동으로 데이터를 보존하기 때문입니다.어울리다
변경 사항을 설정하면 이 ViewModel의 모든 데이터를 다음 활동 (activity) 이나 세션 (fragment) 실례에 바로 사용할 수 있습니다.
viewmodel 생명주기는view 구성 요소의 생명주기에 따라 삭제되며 메모리 유출이 없습니다.ViewModel 클래스는 UI 관련 데이터를 감지할 수 있는 방식으로 저장하고 관리하는 데 사용되며, ViewModel에서 데이터는 액티브 configuration이 바뀌어도 가로로 화면을 전환할 때 살아남는다.
데이터베이스 구조는 흔히 인터페이스 컨트롤러와 일일이 대응할 수 없기 때문에 데이터 대상이view에 대응하는 컨트롤러를 다시 정의해야 한다.ViewModel의 직책은 모델 대상을 입력을 표시하고 받아들일 수 있는 인터페이스 데이터 대상으로 봉인하는 것이다.
결합view와 모델 사이,viewmodel은 중간 조율로 데이터 조작의 직책을 분리하여ViewModel에 주고 네트워크 요청과 데이터베이스 조작은viewmodel에 맡긴다.
쉽게 말하면 View 모델은 바로 View와 모델의 연결기이고 View와 모델은 View 모델을 통해 양방향 연결을 실현한다.데이터베이스 구조는 흔히 인터페이스 컨트롤러와 일일이 대응할 수 없기 때문에 데이터 대상이view에 대응하는 컨트롤러를 다시 정의해야 한다.ViewModel의 직책은 모델 대상을 입력을 표시하고 받아들일 수 있는 인터페이스 데이터 대상으로 봉인하는 것이다.
3,viewmodel 작용;
1) 데이터 지속성
ViewModel 생명주기는 전체 activity 생명주기를 관통하는 것으로 Activity가 회전으로 인한 재창설을 포함하여 Activity가 진정한 의미에서 소각된 후에야 끝난다.기왕 이렇게 된 이상 데이터를 저장하는 데 쓰면 더할 나위 없이 좋다.
public class MyViewModel extends ViewModel {
private MutableLiveData> users;
public LiveData> getUsers() {
if (users == null) {
users = new MutableLiveData>();
loadUsers();
}
return users;
}
private void loadUsers() {
// do async operation to fetch users
}
}
public class MyActivity extends AppCompatActivity {
public void onCreate(Bundle savedInstanceState) {
MyViewModel model = ViewModelProviders.of(this).get(MyViewModel.class);
model.getUsers().observe(this, users -> {
// update UI
});
}
}
2) 비동기식 콜백 문제
일반적으로 우리 앱은 인터페이스를 바꾸어 서버 데이터를 요청하는 등 빈번한 비동기 요청 데이터를 필요로 한다.물론 이 요청들의 리셋은 상당히 시간이 걸린다. 이전에 우리는Activity나fragment에서 이 리셋을 받았다.그래서 Activity가 소각된 후에 인터페이스 요청이 되돌아오는 등 잠재적인 메모리 유출 상황을 고려해야 한다.이런 문제들을 처리하는 것은 우리에게 매우 많은 복잡한 일을 증가시킬 것이다.하지만 이제 ViewModel을 이용하여 데이터 리셋을 처리하면 이 문제점을 완벽하게 해결할 수 있습니다.
3. UI controller 부담 분담
최초의 MVC부터 현재 유행하는 MVP, MVVM까지 직책을 명확히 하고 UI controller 부담을 분리하는 것이 목적이다.UI controller, 예를 들어Activity,Fragment는 전시 데이터를 렌더링하고 사용자의 행동에 응답하며 시스템의 일부 상호작용을 처리하는 데 사용된다.만약 다시 그에게 네트워크나 데이터베이스 데이터를 불러오는 것을 책임지라고 요구한다면, 그것은 그를 비대하고 관리하기 어려워 보일 것이다.그래서 간결하고 상쾌하며 매끄럽기 위해 우리는 데이터 조작의 직책을 View 모델에게 분리할 수 있다.
4. Fragments 간 데이터 공유
예를 들어Activity에 여러 개의fragment가 있는데 이fragment 사이에는 어떤 상호작용이 필요하다.나의 이전 방법은 인터페이스 리셋이고Activity에서 통일적으로 관리해야 하며 피할 수 없는fragment 간에 서로 상대방의 인용을 가지고 있어야 한다.자세히 생각해 보면 이것은 매우 비상하는 일이다. 결합도가 높다는 것은 말할 것도 없고, 대량의 용착 판단이 필요하다. (예를 들어 상대방의fragment가 아직 살아 있는지 없는지)그렇다면 ViewModel을 사용하는 것은 어떨까(홈페이지 예): (activity와 그 내부의 fragment는 하나의 ViewModel을 공용할 수 있다)
public class SharedViewModel extends ViewModel {
private final MutableLiveData- selected = new MutableLiveData
- ();
public void select(Item item) {
selected.setValue(item);
}
public LiveData
- getSelected() {
return selected;
}
}
public class MasterFragment extends Fragment {
private SharedViewModel model;
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
itemSelector.setOnClickListener(item -> {
model.select(item);
});
}
}
public class DetailFragment extends Fragment {
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
SharedViewModel model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
model.getSelected().observe(this, { item ->
// Update the UI.
});
}
}
이러한 이점을 자세히 살펴보면 다음과 같습니다.
1. Activity는 아무것도 할 필요가 없다. 심지어 이번 상호작용을 모르고 완벽하게 결합한다.
2. Fragment는 ViewModel과 상호작용만 하면 상대방의 Fragment 상태가 심지어 존재하는지 알 필요가 없고 인용을 가지고 있을 필요가 없다.모든 것은 상대방이 Fragment를 소각할 때 그 어떠한 업무에도 영향을 주지 않는다.
3. Fragment의 생명주기는 서로 영향을 주지 않으며 심지어fragment가 다른 것으로 바뀌어도 이 시스템의 운영에 영향을 주지 않는다.
주의하다
홈페이지에는 커다란 빨간색 느낌표로 Caution: A View Model must never reference a view, Lifecycle, or any class that may hold a reference to the
activity context.ViewModel의 생명주기가 activity와 길어질 수 있기 때문에 메모리 유출을 피하기 위해 Google은 ViewModel에서 Context나 activity 또는view의 인용을 금지합니다.
안드로이드 View 모델 클래스를 발견할 수 있습니다. 내부에 Application Context가 유지되어 있습니다. 이 클래스를 사용하려면
public class AndroidViewModel extends ViewModel {
@SuppressLint("StaticFieldLeak")
private Application mApplication;
public AndroidViewModel(@NonNull Application application) {
mApplication = application;
}
/**
* Return the application.
*/
@NonNull
public T getApplication() {
//noinspection unchecked
return (T) mApplication;
}
}
좋은 웹페이지 즐겨찾기
