고 투 더 멘토

스토어 계정 만료 시
- 앱다운로드 불가
- 새로운 앱과 업데이트 게시 불가
- 사용중이던 앱의 사용은 문제 없음
스토어계정 멤버쉽 갱싱 시
- 무료앱은 24시간내에 스토어에 다시 게시 되어 검색이 가능해짐
- 유료앱은 AppStoreConnect에서 "유료 응용프로그램 계약서"를 작성하면 사용가능
- 재배포 할필요 없음.

엔터프라이즈 계정 만료시
- 앱다운로드 불가
- 이미 설치된 앱도 사용불가

엔터프라이즈 인증서 만료 시 
- OCSP Server를 통해 인증을 진행하는데 캐시기간(일주일정도)동안은 
사용이 가능할 수 있으나 이 기간이 지나면 앱 사용이 불가해짐.
- 인증서는 3년간 유효 하나 "프로비저닝 프로파일"이 1년주기로 만료되기 때문에 매년 배포해야 함
- 인증서로 프로파일을 만들고 앱에 포함 때문에 프로파일이 만료되기 전에 만료되지 않은 인증서로 
프로파일을 갱신하여 배포해야 함.

안드로이드 오레오(O)부터 뱃지카운트 표시방법을 정리 해 보겠다.

뱃지를 표시할 채널을 추가해야 한다.

String CHANNEL_ID = "badge_channel";

@TargetApi(Build.VERSION_CODES.O)
void createNotificationChannel() {
    NotificationManager nm = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
    NotificationChannel notificationChannel = new NotificationChannel(CHANNEL_ID, "notificationName", NotificationManager.IMPORTANCE_DEFAULT);
    nm.createNotificationChannel(notificationChannel);
}

임의 뱃지카운트를 아이콘에 추가하려면 

NotificationCompat.Builder notificationBuilder = new NotificationCompat.Builder(this, CHANNEL_ID)
        .setContentTitle("New Messages")
        .setContentText("You've received 3 new messages.")
        .setSmallIcon(android.R.drawable.ic_notification_clear_all)
        .setNumber(10);

NotificationManager nm = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
nm.notify(1001, notificationBuilder.build());

뱆지카운트를 초기화 하려면

NotificationManager nm = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
nm.cancelAll();

오레오 이전버전은 오픈소스 ShortcutBadger의 사용을 권장한다.

implementation "me.leolin:ShortcutBadger:1.1.22@aar"

log를 가로채서 보여주면 되는데 누군가 이미 만들었다.

스토에도 게시가 되어 있으니 감사하게 사용하면 되겠다.

https://github.com/plusCubed/matlog

RxJava의 가장 훌룡한 사용예에 해당하는 네트웍통신 예제로서 Retrofit만한게 없을것 같아 정리해 보겠다.

GitHub의 https://api.github.com/users/{사용자계정}/repos를 샘플로 진행하겠다.

내 계정으로 부터 위 통신을 수행하면 다음과 같은 응답이 내려온다

[
  {
    "id": 34425769,
    "node_id": "MDEwOlJlcG9zaXRvcnkzNDQyNTc2OQ==",
    "name": "JSWheelView",
    "full_name": "samse/JSWheelView",
    "private": false,
    "owner": {
      "login": "samse",
      "id": 3222919,
      "node_id": "MDQ6VXNlcjMyMjI5MTk=",
      "avatar_url": "https://avatars.githubusercontent.com/u/3222919?v=4",
      "gravatar_id": "",
      "url": "https://api.github.com/users/samse",
      "html_url": "https://github.com/samse",
      "followers_url": "https://api.github.com/users/samse/followers",
      "following_url": "https://api.github.com/users/samse/following{/other_user}",
      "gists_url": "https://api.github.com/users/samse/gists{/gist_id}",
      "starred_url": "https://api.github.com/users/samse/starred{/owner}{/repo}",
      "subscriptions_url": "https://api.github.com/users/samse/subscriptions",
      "organizations_url": "https://api.github.com/users/samse/orgs",
      "repos_url": "https://api.github.com/users/samse/repos",
      "events_url": "https://api.github.com/users/samse/events{/privacy}",
      "received_events_url": "https://api.github.com/users/samse/received_events",
      "type": "User",
      "site_admin": false
    },
    "html_url": "https://github.com/samse/JSWheelView",
    "description": "Wheel Control View",
    "fork": true,
    "url": "https://api.github.com/repos/samse/JSWheelView",
    "forks_url": "https://api.github.com/repos/samse/JSWheelView/forks",
    "keys_url": "https://api.github.com/repos/samse/JSWheelView/keys{/key_id}",
    "collaborators_url": "https://api.github.com/repos/samse/JSWheelView/collaborators{/collaborator}",
    "teams_url": "https://api.github.com/repos/samse/JSWheelView/teams",
    "hooks_url": "https://api.github.com/repos/samse/JSWheelView/hooks",
    "issue_events_url": "https://api.github.com/repos/samse/JSWheelView/issues/events{/number}",
    "events_url": "https://api.github.com/repos/samse/JSWheelView/events",
    "assignees_url": "https://api.github.com/repos/samse/JSWheelView/assignees{/user}",
    "branches_url": "https://api.github.com/repos/samse/JSWheelView/branches{/branch}",
    "tags_url": "https://api.github.com/repos/samse/JSWheelView/tags",
    "blobs_url": "https://api.github.com/repos/samse/JSWheelView/git/blobs{/sha}",
    "git_tags_url": "https://api.github.com/repos/samse/JSWheelView/git/tags{/sha}",
    "git_refs_url": "https://api.github.com/repos/samse/JSWheelView/git/refs{/sha}",
    "trees_url": "https://api.github.com/repos/samse/JSWheelView/git/trees{/sha}",
    "statuses_url": "https://api.github.com/repos/samse/JSWheelView/statuses/{sha}",
    "languages_url": "https://api.github.com/repos/samse/JSWheelView/languages",
    "stargazers_url": "https://api.github.com/repos/samse/JSWheelView/stargazers",
    "contributors_url": "https://api.github.com/repos/samse/JSWheelView/contributors",
    "subscribers_url": "https://api.github.com/repos/samse/JSWheelView/subscribers",
    "subscription_url": "https://api.github.com/repos/samse/JSWheelView/subscription",
    "commits_url": "https://api.github.com/repos/samse/JSWheelView/commits{/sha}",
    "git_commits_url": "https://api.github.com/repos/samse/JSWheelView/git/commits{/sha}",
    "comments_url": "https://api.github.com/repos/samse/JSWheelView/comments{/number}",
    "issue_comment_url": "https://api.github.com/repos/samse/JSWheelView/issues/comments{/number}",
    "contents_url": "https://api.github.com/repos/samse/JSWheelView/contents/{+path}",
    "compare_url": "https://api.github.com/repos/samse/JSWheelView/compare/{base}...{head}",
    "merges_url": "https://api.github.com/repos/samse/JSWheelView/merges",
    "archive_url": "https://api.github.com/repos/samse/JSWheelView/{archive_format}{/ref}",
    "downloads_url": "https://api.github.com/repos/samse/JSWheelView/downloads",
    "issues_url": "https://api.github.com/repos/samse/JSWheelView/issues{/number}",
    "pulls_url": "https://api.github.com/repos/samse/JSWheelView/pulls{/number}",
    "milestones_url": "https://api.github.com/repos/samse/JSWheelView/milestones{/number}",
    "notifications_url": "https://api.github.com/repos/samse/JSWheelView/notifications{?since,all,participating}",
    "labels_url": "https://api.github.com/repos/samse/JSWheelView/labels{/name}",
    "releases_url": "https://api.github.com/repos/samse/JSWheelView/releases{/id}",
    "deployments_url": "https://api.github.com/repos/samse/JSWheelView/deployments",
    "created_at": "2015-04-23T01:15:40Z",
    "updated_at": "2015-04-23T01:15:41Z",
    "pushed_at": "2015-04-01T05:44:23Z",
    "git_url": "git://github.com/samse/JSWheelView.git",
    "ssh_url": "git@github.com:samse/JSWheelView.git",
    "clone_url": "https://github.com/samse/JSWheelView.git",
    "svn_url": "https://github.com/samse/JSWheelView",
    "homepage": null,
    "size": 244,
    "stargazers_count": 0,
    "watchers_count": 0,
    "language": "Objective-C",
    "has_issues": false,
    "has_projects": true,
    "has_downloads": true,
    "has_wiki": true,
    "has_pages": false,
    "forks_count": 0,
    "mirror_url": null,
    "archived": false,
    "disabled": false,
    "open_issues_count": 0,

위 응답을 기준으로 data class를 먼저 정의한다.

data class Owner(val userId: String, val avatar_url: String, val url: String, val htmlUrl: String, val repos_url: String)
data class Repo(val name: String, val full_name: String, val private: Boolean, val owner: Owner, val htmlUrl: String,
val description: String)

인터페이스를 정의한다.

여기서는 같은 일을 하는 일반 Call<T>와 Observable<T>를 반환하는 두가지를 비교하기 위해 정의하였다.

interface GitHubService {
    @GET("users/{user}/repos")
    fun listRepos(@Path("user") user: String): Call<List<Repo>>
    @GET("users/{user}/repos")
    fun listReposRx(@Path("user") user: String): Observable<List<Repo>>

}

Retrofit 객체를 빌드한다.

RxJava2CallAdapterFactory를 추가하여 Observable를 반환할 수 있도록 한다.

    var retrofit: Retrofit? = Retrofit.Builder()
        .baseUrl("https://api.github.com/")
        .addConverterFactory(GsonConverterFactory.create())
        .addCallAdapterFactory(RxJava2CallAdapterFactory.create())
//        .client(createClient())
        .build()

일반 Call<T> 호출의 예

val service: GitHubService? = retrofit?.create(GitHubService::class.java)
service?.apply {
    val call: Call<List<Repo>> = listRepos("samse")
    call.enqueue(object : Callback<List<Repo>> {
        override fun onResponse(call: Call<List<Repo>>, response: Response<List<Repo>>) {
            println("###################################")
            println("ret ${response.body()}")
            println("###################################")
        }

        override fun onFailure(call: Call<List<Repo>>, t: Throwable) {
            t.printStackTrace()
        }
    })
}

RxJava Observable<T> 호출의 예

val service: GitHubService? = retrofit?.create(GitHubService::class.java)
service?.apply {
    listReposRx("samse")
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe ({ repos ->
            println("###################################")
            println("Repo count=${repos.size}")
            for (v in repos) {
                println("  $v")
            }
            println("###################################")
        }, { error ->
            println(error)
        })
}

Retrofit이 네트웍통신에 대한 모든 방식을 지원하고 귀찮은 예외처리까지 해주는 데다가 RxJava도 가능하니 이를 통해서 좀더 깔끔하고 가독성 좋은 코드를 생산할 수 있겠다.

Retrofit은 Interceptor를 통신 중간에 추가해 넣어서 송/수신 구간에 끼어 들어서 헤더에 정보를 추가하거나 통신로깅을 수행하는 등의 작업을 가능하게 해준다.

아래는 송신패킷에 임의의 헤더값을 추가해주는 Interceptor의 예이다.

class HttpLoggingInterceptor: Interceptor {
    override fun intercept(chain: Interceptor.Chain): okhttp3.Response = with(chain) {
        val newRequest = request().newBuilder()
            .addHeader("X-New-UA", "My custom header")
            .build()
        proceed(newRequest)
    }
}

이렇게 정의한 Interceptor는 Retrofit를 build할때 추가해준다.

var retrofit: Retrofit? = Retrofit.Builder()
    .baseUrl("https://api.github.com/")
    .addConverterFactory(GsonConverterFactory.create())
    .addCallAdapterFactory(RxJava2CallAdapterFactory.create())
    .client(createClient())
    .build()

fun createClient(): OkHttpClient {
    return OkHttpClient.Builder()
        .addInterceptor(HttpLoggingInterceptor())
        .build()
}

Retrofit

Volley같은 네트웍통신의 다양한 예외케이스들을 처리해주면서 사용하기도 편리하게 해주는 라이브러리중에 아주 유명한 Retrofit라이브러리의 사용법에 대해 정리한다.

1. build.gradle에 dependency추가

implementation 'com.squareup.retrofit2:retrofit:2.9.0'
implementation 'com.squareup.retrofit2:converter-gson:2.9.0'


2. manifest에 permission 추가

<uses-permission android:name="android.permission.INTERNET" />

3. 서버주소가 HTTPS가 아니라 HTTP주소를 사용한다면 application tag에 usesCleartextTraffic true

<application
  android:name="ApplicationName"
  ...
  android:usesCleartextTraffic="true"
  />

4. interface 추가

public interface PostServiceApi {
   @GET("/posts")
   Call<List<POSTDATA>> getPost(@Query("userId") String id);
}

5. Data model 정의

public class POSTDATA {
   @SerializedName("userId")
   private int userId;

   @SerializedName("title")
   private String title;

   @SerializedName("content")
   private String content;

   int getUserId() {
      return userId;
   }

   void setUserId(String userId) {
      this.userId = userId;
   }

   String getTitle() {
      return title;
   }

   ...

}

6. 호출 및 응답처리

Retrofit retrofit = new Retrofit.Builder()
   .baseUrl("http://www.myservice.com/posts")
   .addConverterFactory(GsonConverterFactory.create())
   .build();


PostServiceAPI postApi = retrofit.create(PostServiceAPI.class);

postApi.getPost("100").enqueue(new Callback<List<POSTDATA>>() {
   @Override
   public void onResponse(Call<List<POSTDATA>> call, Response<List<POSTDATA>> response) {
      if (response.isSuccessful()) {
         Log.e( TAG, "타이틀" : response.title());
      }
   }
   @Override
   public void onFailure(Call<List><POSTDATA>> call, Throwable t) {
      t.printStackTrace();
   }
});

참고
Request유형별 정의방법 안내 : https://jaejong.tistory.com/38

DataStore는 SharedPreferences를 대체하기 위해서 고안되었다.
SharedPreferences를 대체해야 겠다는 생각을 구글개발자들은 왜 했을까?

1. SharedPreferences는 UIThread에서 호출이 가능한데 기본적으로 disk I/O operation이기 때문에 UITHread에 대해 block을 유발하게 된다. 때에 따라서는 이점이 anr을 유발할수도 있다.
2. 런타임 파싱에러를 발생시킬 수 있다.

이런 문제점이 마음에 들지 않았던 어느 개발자가 DataStore를 만들었다.

DataStore는 두가지 구현을 제공하는데 모두 파일로 저장하고 Dispatchers.IO에서 동작한다.

1. Preference DataStore는 SharedPreference와 유사하고 key/value쌍으로 저장한다.
2. Proto DataStore는 Protocol buffer로 스키마를 정의하고 강력한 데이타타입체크를 지원한다. protocol buffer는 더 빠르고 작고 단

순하며 다른 XML같은 포맷보다 덜 모호하다. protocol buffer 정의하고 시리얼화 매커니즘을 추가로 배워야 하지만 강력한 타입스키마체크라는 장점때문에 충분히 배울 가치가 있다고 본다.

Room이라는 또 다른 Store를 제공하는 라이브러리가 있으며 DataStore가 작고 단순한 데이터셋을 지원하는 반면 Room은 부분업데이트나 참조무결성을 지원한다.  정확하게 어떤 다른 특성이 있는지는 더 조사해 보아야 겠다.

// Preferences DataStore 사용시
implementation "androidx.datastore:datastore-preferences:1.0.0-alpha01"

// Proto DataStore 사용시
implementation  "androidx.datastore:datastore-core:1.0.0-alpha01"

Proto DataStore를 사용하고자 한다면 스키마를 proto file로 /app/src/main/proto 폴더에 저장한다. 스키마정의 링크에서 자세한 정의 방법을 더 숙지해야 한다.

syntax = "proto3";

option java_package = "<your package name here>";
option java_multiple_files = true;

message Settings {
  int my_counter = 1;
}

DataStore 생성

Preference DataStore 생성

// with Preferences DataStore
val dataStore: DataStore<Preferences> = context.createDataStore(
    name = "settings"
)

Proto DataStore 생성

protobuff file명과 Serializer의 구현체를 제공해야 한다. 

object SettingsSerializer : Serializer<Settings> {
    override fun readFrom(input: InputStream): Settings {
        try {
            return Settings.parseFrom(input)
        } catch (exception: InvalidProtocolBufferException) {
            throw CorruptionException("Cannot read proto.", exception)
        }
    }

    override fun writeTo(t: Settings, output: OutputStream) = t.writeTo(output)
}


// with Proto DataStore
val settingsDataStore: DataStore<Settings> = context.createDataStore(
    fileName = "settings.pb",
    serializer = SettingsSerializer
)

DataStore 읽기

Preference DataStore 읽기

val MY_COUNTER = preferencesKey<Int>("my_counter")
val myCounterFlow: Flow<Int> = dataStore.data
     .map { currentPreferences ->
        // Unlike Proto DataStore, there's no type safety here.
        currentPreferences[MY_COUNTER] ?: 0   
   }

Proto DataStore 읽기

val myCounterFlow: Flow<Int> = settingsDataStore.data
    .map { settings ->
        // The myCounter property is generated for you from your proto schema!
        settings.myCounter 
    }

DataStore 쓰기

Preference DataStore 쓰기

suspend fun incrementCounter() {
    dataStore.edit { settings ->
        // We can safely increment our counter without losing data due to races!
        val currentCounterValue = settings[MY_COUNTER] ?: 0
        settings[MY_COUNTER] = currentCounterValue + 1
    }
}

Proto DataStore 쓰기

suspend fun incrementCounter() {
    settingsDataStore.updateData { currentSettings ->
        // We can safely increment our counter without losing data due to races!
        currentSettings.toBuilder()
            .setMyCounter(currentSettings.myCounter + 1)
            .build()
    }
}

Data를 Modeling할때 DataStore를 사용해서 해보는것도 좋은 경험이 될것 같다.

언제 해볼 수 있을지 모르겠지만 .. ㅠㅜ 

ViewModel
- 액티비티, 프래그먼트의 복잡한 라이프사이클과 무관하게 데이터를 보관해줌
- 네트웍이나 저장소등의 레포지트리를 통해서 데이터를 수집
- ViewModel을 사용하는 액티비티나 프래그먼트에서는 ovserve를 사용하여 데이터가 변경될때 이벤트를 받을 수 있으며 이 때 화면에 데이터를 바인딩하면 된다.

Java

public class MyViewModel extends ViewModel {  
    private MutableLiveData<List<User>> users;  
    public LiveData<List<User>> getUsers {  
        if (users == null) {  
            users = new MutableLiveData<List<User>>();  
            loadUsers();  
        }  
        return users;  
    }  

    private void loadUsers() {  
        // load from local storage or network  
    }  
}  

Kotlin

class MyViewModel : ViewModel() {  
    private val users: MutableLiveData<List<User>> by lazy {  
        MutableLiveData<List<User>>().also {  
            loadUsers()  
        }  
    }  
    fun getUsers() : LiveData<List<User>> {  
        return users  
    }  

    private fun loadUsers {  
        // load from local storage or network  
    }  
}

ViewModel 사용

Java  
public class MyActivity extends AppCompatActivity {  
    public void onCreate(Bundle savedInstanceState) {  
        MyViewModel model = new ViewModelProvider(this).get(MyViewModel.class);  
        model.getUsers().observe(this, users -> {  
            // update UI  
        });  
    }  
}  

Kotlin  
class MyActivity : AppCompatActivity() {  
    override fun onCreate(savedInstanceState: Bundle?) {  
        val model = MyViewModel by viewModels()  
        model.getUsers().observe(this, Observer<List<User>> { users ->   
            // update UI  
        })  
    }  
}

MyActivity가 단말을 가로로 돌려서 종료되거나 시스템이 강제로 종료시키는 등의 상황이 발생하더라고 MyActivity가 다시 생성될 때 이전의 MyViewModel의 인스턴스를 유지한다.


ViewModel은 View나 Activity, Fragment같은 Lifecycle객체 등을 포함하는 클래스를 참조하면 메모리릭이 발생할 수 있다.
만일 ViewModel이 Context가 필요한 경우가 있다면 AndroidViewModel을 상속한 후 Application객체를 생성자에 포함시키는 방법을 추천한다.

앞서 안드로이드에서 Coroutine과 CompletableFuture를 알아 보았다.

제목에서 보면 알수 있듯이 개발자들은 지속적으로 게을러지기 위해 노력하고 있다는것을 알 수 있다.

비동기 호출도 가장 적은 타이핑을 목표로 하고 있다.

비동기 처리를 하는 가장 고전적인 방법은 콜백함수를 인자로 하여 처리과 완료되면 콜백으로 처리결과를 전달하여 다음 단계로 넘어가도록 하는 방법이 되겠다.

알다시피 이는 콜백지옥을 수반하게 되며 이게 싫었던 개발자는 Rx나 CompletableFuture같은것들을 고안하고 사용하기 시작한다.

그것도 싫었던 그들은 Coroutine같은것을 다시한번 고안해 냈으며 마치 동기호출을 하는 코드처럼 비동기코드를 짜기 시작했다.

안드로이드에서는 Coutine으로 아래와 같이 마치 동기호출처럼 비동기 함수들을 호출할 수 있다.

suspend iWantEatRamyeon(money) {
  try {
    val ramyeon = buyRamyeon(money)
    val pot = getPot()
    val cookedRamyeon = doBoilPot(ramyeon, pot)
    val ramyeonInDish = moveToDish(cookedRamyeon)
    eatIt(ramyeonInDish)
  } catch (e: Exception) {
    // 실패케이스 처리
  }
}

iOS에서는 swift 5에서 아래와 같이 사용 가능하다.

func iWantEatRamyoen(money) async {
    val ramyeon = await buyRamyeon(money: money)
    val pot = await getPot()
    val cookedRamyeon = await doBoilPot(ramyeon:ramyeon, pot: pot)
    val ramyeonInDish = await moveToDish(ramyeon: cookieRamyeon)
    eat(ramyeon: remyeonInDish)
    print("Server response: \(response)")
}

async 메서드에서 비동기메서드로 호출하려면 메서드 정의시 아래와 같이 정의해야 한다.

func buyRamyeon(money: money) async -> Ramyeon {
	// get a ramyeon 
	var ramyeon = getRamyeon()
	return ramyeon
}

DispatchQueue와 블럭코딩을 이용하여 위와 동일한 로직을 작성해보자.

그러면 위 코드가 얼마나 코딩량을 줄여주는지 알게 될것이다.

개발자는 게을러져야 하나보다... 머리는 빼고...

사용자의 단말을 특정하기 위해서 예전부터 사용해오던 것들은 점차적으로 구글이 보안을 강화하는 정책으로 변경되면서 사용이 불가하게 변화하고 있다.

deviceId, imei, meid, ANDROID_ID, SERIAL, MAC address 등이 많이 사용되어 왔는데

대부분 deprecated되었고 ANDROID_ID는 기기 재설정시 변경되고 SERIAL은 Android10부터 'unknown'을 반환한다.

2021년 현재는 SSAID가 대체재로서 사용 가능하다.

동일단말에서 같은 개발자의 키스토어로 빌드된 앱들 끼리는 같은 SSAID를 사용할 수 있다. 

아래 코드는 안드로이드 버번과 상관없이 항상 유니크한 아이디를 반환해주는 메서드이다.

    private fun getUniqueDeviceIdentifier(): String? {
        val telephonyManager: TelephonyManager = getSystemService(Context.TELEPHONY_SERVICE) as TelephonyManager
        var uniqueId: String? = null
        try {
            telephonyManager.deviceId?.let {
                uniqueId = it
            }
            if (uniqueId==null && Build.VERSION.SDK_INT > Build.VERSION_CODES.O) {
                telephonyManager.imei?.let { uniqueId = it }
                if (uniqueId==null) {
                    telephonyManager.meid?.let { uniqueId = it }
                }
            }
        } catch(e: Exception) {}

        if (uniqueId==null) {
            uniqueId = Build.SERIAL
        }
        if (uniqueId==null || uniqueId=="unknown") {
            val wifiManager: WifiManager = getSystemService(Context.WIFI_SERVICE) as WifiManager
            val wifiInfo = wifiManager.connectionInfo
            uniqueId = wifiInfo.macAddress
        }
        if (uniqueId==null || uniqueId=="02:00:00:00:00:00") {
            uniqueId = Settings.Secure.getString(contentResolver, Settings.Secure.ANDROID_ID)
        }
        return uniqueId
    }

비동기로 파일을 다운로드 후 해당 파일을 로드하는 로직을 코루틴으로 작성하면 아래와 비슷한 로직으로 구성이 될것이다.

CoroutineScope(Dispatchers.IO).launch { // CoroutineScope를 IO스레드에서 launch
    if (downloadAsync(filePath, fileUrl)) { // 다운로드 코루틴메서드 다른 쓰레드에 영향을 주지 않는다.
        loadFromLocal(file, loadListener)  // 다운로드가 성공하면 다운로드된 파일을 로드한다.
    }
}


downloadAsync가 파일을 다운로드하는 코루틴 메서드로 suspend키워드와 coroutineScope을 지정하여 
다른 스레드에 영향을 주지 않고 동작하게 한다.

suspend fun downloadAsync(filePath: String, fileUrl: String): Boolean = coroutineScope {
    if (L.DBG) {
        Log.v(TAG, "downloadAsync : $filePath, $fileUrl")
    }
    return@coroutineScope download(filePath, fileUrl)
}

이걸 CompletableFuture에서 사용하고자 한다면 아래와 같은 형태가 될것이다.

if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.N) {
downloadAsync2(filePath, fileUrl)
        .thenAccept { r ->
            if (r) {
                loadFromLocal(file, loadListener)
            }
        }
}

downloadAsync2는 CompletableFuture를 반환하며 thenAccept로 콜백을 받아서 처리할 수 있다.

@RequiresApi(Build.VERSION_CODES.N)
fun downloadAsync2(filePath: String, fileUrl: String): CompletableFuture<Boolean> {
    return CompletableFuture.supplyAsync {
        return@supplyAsync download(filePath, fileUrl)
    }
}

두가지 코드는 완전히 동일하게 동작한다.
어떤게 더 좋아 보이는가??
난 개인적으로 코루틴이 나아 보인다.
왜냐하면 CompletableFuture의 경우 안드로이드 N부터 지원하는데다 코루틴이 좀더 사용이 쉽다.