// 1. 위치관리자 객체 생성
LocationManager lm = (LocationManager)getSystemService(Context.LOCATION_SERVICE);
// 2. 위치제공자 모두 가져오기
List<String> list = lm.getAllProviders();
for (int i = 0; i < list.size(); i++) {
// 위치제공자
list.get(i);
// 해당 제공자 사용가능 boolean
lm.isProviderEnabled(list.get(i));
}
/**안드로이드 위치 제공자 관련 상수**/
public static final String GPS_PROVIDER = "gps"
public static final String NETWORK_PROVIDER = "network"
public static final String PASSIVE_PROVIDER = "passive"
2. Criteria
// 1. 위치관리자 객체 생성
LocationManager locationManager = (LocationManager)getSystemService(Context.LOCATION_SERVICE);
//2. Criteria 객체 생성(프로바이더의 상세 속성 옵션)
Criteria criteria = new Criteria();
criteria.set(Criteria.ACCURACY_FINE); //위도와 경도에 정확도(정밀도) 설정
criteria.setAccuracy(Criteria.ACCURACY_FINE);
criteria.setPowerRequirement(Criteria.POWER_HIGH);
criteria.setAltitudeRequired(false);
criteria.setSpeedRequired(true);
criteria.setCostAllowed(true);
criteria.setBearingRequired(false);
//3. criteria의 옵션에 해당하는, 현재 위치값을 가져오기 위한 프로바이더
private String bestProvide = locationManager.getBestProvider(criteria, true);
4. 위치 정보 취득시의 콜백 - onLocationChanged
//GPS Update 시간은 1초 이상, 반경은 10m 이상이 좋음
//(GPS 송수신하는데 준비 과정에서만 약 1초가 소요 된다고 함)
if(!locationManager.isProviderEnabled(provider)
&&locationManager.getLastKnownLocation(provider)!=null) {
locationManager.requestLocationUpdates(provider, 1000, 10, this);
}else{
criteria.setAccuracy(Criteria.ACCURACY_COARSE);
provider = locationManager.getBestProvider(criteria, true);
locationManager.requestLocationUpdates(provider, 1000, 10, this);
}
@Override
public void onLocationChanged(Location location) {
// GPS 변경에 따른 코딩 구현.
}
-한두명이 아닌, 여러명이 공통 개발을 할 때, 각자의 담당하는 바를 간섭하지 않고 개발하기란(without stepping on each other's toes) 어렵다. 그래서 이를 방지하고자 이런 모듈들로 나눠서 만들 수 밖에 없다는 의미.
(2) maintainability 유지보수성
- 만약 monolithic application, 즉 하나의 거대한 아키텍쳐를 가진 앱을 마주하게 된다면? 안드로이드 개발자가 수십 수백개의 레이어들을 마주하게 되고 이를 파악하고 분석하는 것은 매우 어려운 일이다. 대신에, 만약 이 레이아웃들을 각 특징(feature)에 기반하여 그룹화 한다면, 용도의 파악이 용이진다. 또한 굉장히 길고 이상한 이름(weird name)으로 목록이 생기지 않는다.
(3)Faster compilation 빠른 컴파일
- 왼쪽은 monolithic application의 예, 오른쪽은 modulaized application된 예다. 만약 '(designer_news_)comment.xml'라는 파일을 1개 수정했다고 가정 했을때, 컴파일시 커버 범위는 다음과 같다.
(4)Faster CI(Continuous Integration) 빠른 지속적 통합
- 만약 다음과 같은 모듈 구조를 가진 앱이 있다고 가정하자.
- 이 중에서 module5를 수정 한다고 했을때, 변화가 올바른지 확인하기 위해서 테스트를 해야하는 부분은 오로지, module5가 depend 하고 있는 app부분만 확인하면 된다. 따라서 테스트를 할 때, 연관되지 않은 다른 부분들을 실행할 필요가 없다.
- 이에 대해서 '우리는 incremental CI이 없다!'라고 말할 수 있다. 그래서 AndroidX 개발에서 의존성 그래프에 대한 플러그인, 파일들이 변화된 위치와 해당 파일들이 포함된 모듈이 무엇인지에 대한 Git History를 알 수 있도록 하는 플러그인들을 작성했다. 그리고 영향받은 모듈들에 대한 모든 테스트를 실행하였다. 해당 작업에 대한 링크는 다음과 같다. http://goo.gle/androidx-dependency-tracker
(5)Good for business
- APK 사이즈가 작아지는 장점이 있다. Play store의 통계에 따르면, APK 사이즈에 따라 사람들이 설치를 시작하고 중단하는 비율이 다음과 같다. 즉 앱의 사이즈가 작으면 보다 많은 이용자를 끌어들일 수 있다.
- 또한 PM이 "내가 정말 멋진 라이브러리를 찾아가지고 왔어!"라고 아이디어를 들고 와도, 이것이 좋은지 안좋은지 싸울 필요가 없다. 다이나믹하게 개발하고 A/B 테스트를 진행하면 됨.
androidx.lifecycle:lifecycle-*:2.2.0-alpha03부터는 ViewModelProviders.of()로 초기화하던 방식이 deprecated되었다. (아래 링크 참조)
ViewModelProviders.of()has been deprecated. You can pass aFragmentorFragmentActivityto the new ViewModelProvider(ViewModelStoreOwner) constructor to achieve the same functionality. (aosp/1009889)
먼저, 다음과 같은 커스텀ViewModel 클래스가 있다고 할 때, (JAVA 방식)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import androidx.lifecycle.MutableLiveData;
import androidx.lifecycle.ViewModel;
publicclass TestViewModel extends ViewModel {
private MutableLiveData<String> test =new MutableLiveData<>();