Android/App개발2019.06.10 14:15

대거2를 적용하는 3 가지 방법이 있다.

 

1번은 Component, Module, Scope으로 직접 모두 기술하는 방법이고

2번은 DispatchingAndroidInjector로 제공하는 방법

3번은 안드로이드에서 제공하는 기반클래스(DaggerActivity, DaggerFragment, ...)로 제공하는 방법이 있다.

 

여기서는 1번 방식으로 작업하는 방식을 설명한다.

여러가지 구성을 하는 방법이 있겠지만 내가 작업한 방식을 설명한다. 틀린 부분이 있다면 누구든 지적을 해주었으면 한다.

 

안드로이드에서 대거는 전역 및 로컬범위로 다양하게 scope을 지정하여 객체를 주입할 수 있다.

Application레벨은 보통 전역 객체를 Activity레벨은 로컬객체를 주입한다.

 

전역에서 GuiManager를 로컬에서 ItemAdapter를 주입할것이다. 

 

Module을 정의한다.

 

in AppModule.java

 

@Module

public class AppModule {

  private MyApplication mApp;

  public AppModule(MyApplication app) { mApp = app; }

  

  @Provides

  @Singletone

  GuiManager provideGuiManager() { return new GuiManager(); }

}

 

MyApplication을 멤버로 가지고 있으며 Scope을 Singletone으로 GuiManager를 주입하기 위한 Provider를 구현한다.

provide를 prefix로 하여 메서드를 정의하며 해당 클래스의 인스턴스를 생성하여 반환한다.

 

Component를 구현한다.

 

in AppComponent

 

@Singletone

@Component(modules = { AppModule.class }

public interface AppComponent {

  void inject(MyApplication app);

  void inject(MainActivity activity);

}

 

Application에서 GuiManager를 주입하는 예이다.

in MyApplication.java

 

public class MyApplication extends Application {

 

  AppComponent mComponent;

 

  @Inject

  protected GuiManager mGuiManager;

 

  @Override

  public void onCreate() {

    super.onCreate();

    mComponent = DaggerAppComponent.builder().appModule(new AppModule()).build();

    mComponent.inject(this);

  }

 

  public AppComponent getComponent() {

    return mComponent;

  }

 

대거는 주석을 기반으로 코드를 생성하며 Dagger를 prefix로하여 Component builder로 객체를 생성할 수 있다. 이렇게 만들어진 ㅡㅐ여component의 inject()를 호출하면 Module에서 provide prefix로 노출한 객체들이 바인딩되어 진다. 

 

이번에는 액티비티 스콥의 주입예이다. ItemAdapter를 MainActivity에서 주입하여 사용할것이다.

 

ActivityModule을 정의한다.

 

@Module

public class ActivityModule {

  private Activity mActivity;

  public ActivityModule(Activity activity) {
    mActivity = activity; 

  }

  

  @Provides @ActivityScope

  Activity activity() { return mActivity; }

 

  @Provides @ActivityScope

  ItemAdapter provideItemAdapter() {

    return new itemAdapter();

  }

}

 

provide prefix로 itemAdapter를 노출하고 있다.

ActivityComponent를 구현한다.

 

@ActivityScope

@Component(dependencies={AppComponent.class}, modules={ActivityModule.class})

public interface ActivityComponent {

  void inject(Activity activity);

}

 

dependencies를 추가하였다. AppComponent를 정의하여 GuiManager도 사용이 가능하다.

MainActivity에서 주입을 시전한다.

 

public class MainActivity extends AppCompatActivity {

  @Inject

  GuiManager guiManager;

  @Inject

  ItemAdapter itemAdapter;

 

  @Override

  public void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    setContentView(R.layout.activity_main);

 

    ((MyApplication)getApplication()).getComponent().inject(this);

    DaggerActivityComponent activityComponent = DaggerActivityComponent.builder().appComponent(new AppComponent()).build();

    activityComponent.inject(this);

 

    guiManager.showAlert("hi!");

    itemAdapter.setDataSource(new MySource()); 

  }

  ...

}

 

MyApplication의 getComponent()를 가져와서 inject함으로써 GuiManager가 주입되었고 DaggerActivityComponent를 build하여 ItemAdapter를 주입하였다.

이 후 guiManager.showAlert("hi")나 itemAdapter.setDataSource(new MySource()) 같이 주입된 객체를 사용할 수 있다.

guiManager는 singletone의 스콥을 가지며 itemAdapter는 ActivityScope을 가진다.

 

ActivityScope이 무엇인가 싶을텐데.. 아래와 같이 정의된다.

 

@Scope

@Retention(RUNTIME)

public @interface ActivityScope {}

 

Scope을 하나 정의했는데 저리하면 액티비티에 종속되는 범위를 갖는 스콥 아노테이션이 만들어진다. 아노테이션 세계는 참..

 

의존성을 여러개로 나누어서도 관리할 수 있다. 모듈과 콤포넌트를 용도에 맞게 구성하여 사용하면 된다.

이번에는 UserData를 주입하기 위한 예제를 살펴보겠다.

 

@Module

public class UserModule {

  private Activity mActivity;

  public UserModule(Activity act) { mActivity = act; }

 

  @Provides @ActivityScope

  Activity activity() { return mActivity; }

 

  @Provides @ActivityScope

  UserData provideUserData() { reutrn new UserData(); }

}

UserData를 주입하기 위해 provideUserData메서드가 정의되었다.

 

@ActivityScope

@Component(dependencies={AppComponent.class}, modules={ActivityModule.class, UserModule.class})

public interface UserComponent {

  void inject(Activity activity);

}

 

AppComponent, ActivityModule등의 의존성도 포함하고 있으며 주입을 위해 inject가 정의되어 있다.

이 모듈을 사용하기 위해 SubActivity는 다음과 같이 구현된다.

 

public class SubActivity extends Activity {

  @Inject

  ItemAdapter itemAdapter;

  @Inject

  UserData userData;

 

  @Override

  public onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    DaggerActivityComonent.builder().appComponent((MyApplication)getApplication()).getComponent()).build().inject(this);

    DaggerUserData.builder().appComponent((MyApplication)getApplication()).getComponent()).build().inject(this);

  }

  ...

}

 

itemAdapter를 사용하기 위해 DaggerActivityComponent.builder()를 사용했고 userData를 사용하기 위해 DaggerUserData.builder()를 사용했다.

 

이와 같이 전역 및 지역적으로 객체를 주입해서 사용하는 일반적인 방법을 알아 보았다.

 

이 방법은 GuiManager, ItemAdapter, UserData등에 대해 모두 정확히 알고 있어야 하며 코드도 많다. 이 보다 적은 코드로도 적용이 가능한데 위에서 말한대로 두가지 방법이 더 있다. 이 에 대해서는 추가로 공부하여 정리하도록 할것이다.

 

 

 

Posted by 삼스
Android/App개발2019.06.10 11:03

Dagger and android

 

https://dagger.dev/android

 

Dagger2 다른 의존성주입 프레임웍들에 비해 주요장점중에 하나는 엄격하게 만들어졌다는것이며 이는 안드로이드앱에서도 사용될 있음을 의미한다. 하지만 대거를 안드로이드 앱에서 사용하기 위해서는 고려할것들이 있다.

 

안드로이드가 자바로 작성이 되지만 스타일면에서 다르다. 보통 이런 차이점은 모바일의 성능고려를 수용하기 위해 존재한다.

하지만 많은 패턴들이 이와는 반대인 경우가 많다. Effective Java 많은 어드바이스들이 안드로이드에 적절하게 적용가능하다.

 

이런 목표를 달성하기 위해 대거는 컴파일된 바이트코드를 후처리하기 위해 프로가드에 의존한다. 이는 대거가 코드를 서버와 안드로이드 둘다 자연스럽게 코드를 만들어낼 있게 한다. 서로 다른 툴체인과 바이트코드를 만들어냄에도 불구하고

대거는 이른 보장하기 위해 프로가드 최적화에 호환되는 코드를 만들어낸다.

따라서 대거는 프로가드를 사용해야 한다.

 

Recommended ProGuard Settings

 

dagger.android

 

대거를 사용하는 안드로이드앱을 작성하는 가장 어려움중에 하나는 액티비티나 프래그먼트같은 안드로이드 프래임웍 클래스들이 OS 의해서 인스턴스화되지만 대거는 삽입된 모든 객체를 생성할 있는 경우 가장 잘동작한다는것이다. 대신에 생명주기 메서드내에서 멤버주입을 수행해야 한다. 이는 많은 클래스들이 다음의 형태와 같다는것을 의미한다.

 

public class FrombulationActivity extends Activity {

  @Inject Frombulator frombulator;

 

  @Override

  public void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    // 작업을 먼저 하지 않으면 frombulator null일것이다.

    ((SomeApplicationBaseType) getContext().getApplicationContext())

        .getApplicationComponent()

        .newActivityComponentBuilder()

        .activity(this)

        .build()

        .inject(this);

    // ... now you can write the exciting code

  }

}

 

이는 몇가지 문제가 있다.

 

  1. 복사붙이기가 나중에 리팩터링하기 힘들다. 많은 개바자들이 그렇게들 하는데 일부만 멀하는지 이해한다.
  2. 근본적으로 이는 타입요청 주입이다. 이는 인젝터가 타입을 알아야 한다. 각각 타입이 아니라 인터페이스를 통해 이른 해결한다 해도 이는 의존성주입의 핵심원리를 깬다. 클래스는 어떻게 주입되는지 아무것도 몰라야 한다.

 

dagger.android 클래스들은 패턴을 단순화하기 위한 하나의 접근법을 제공한다.

 

 

Injecting Activity objects

 

  1. 애플리케이션 구성요소에 AndroidInjectionModule 설치해서 이러한 기본 유형에 필요한 모든 바인딩을 사용할수 있도록 하라.
  2. AndroidInjector<YoutActivity> 구현하는 @Subcomponent작성을 시작해라.  AndroidInjector.Factory<YourActivity> 확장한 @Subcomponent.Factory 있다.

 

@Subcomponent(modules = ...)

public interface YourActivitySubcomponent extends AndroidInjector<YourActivity> {

  @Subcomponent.Factory

  public interface Factory extends AndroidInjector.Factory<YourActivity> {}

}

 

3. 서브콤포넌트를 정의하고 나서 모듈을 정의하여 콤포넌트 구조를 추가해라. 모듈은 서브콤포넌트 팩토리를 바인딩하여 애플리케이션에 주입할 콤포넌트를 추가한다.

 

@Module(subcomponents = YourActivitySubcomponent.class)

abstract class YourActivityModule {

  @Binds

  @IntoMap

  @ClassKey(YourActivity.class)

  abstract AndroidInjector.Factory<?>

      bindYourActivityInjectorFactory(YourActivitySubcomponent.Factory factory);

}

 

@Component(modules = {..., YourActivityModule.class})

interface YourApplicationComponent {}

 

2단계에서와 달리 서브콤포넌트와 팩토리가 메서드나 수퍼타입을 갖고 있지 않은 경우 @ContributesAndroidInjector 사용할 있다. 2, 3단계대신에 abstract모듈 메세드를 @ContributesAndroidInjector 함께 추가하여 당신의 액티비티를 반환할 있다. 그리고 서브콤포넌트에 설치하고자 하는 모듈을 기술하라.

서브콤포넌트가 스콥이 필요하면 스콥주석을 사용할수 있다

 

 

@ActivityScope

@ContributesAndroidInjector(modules = { /* modules to install into the subcomponent */ })

abstract YourActivity contributeYourActivityInjector();

 

4. 이제 당신의 애플리케이션에 HasActivityInjector 구현하고 @Inject  DispatchingAndroidInjector<Activity> 지정하여 activityInjector()로부터 반환한다. 

 

public class YourApplication extends Application implements HasActivityInjector {

  @Inject DispatchingAndroidInjector<Activity> dispatchingActivityInjector;

 

  @Override

  public void onCreate() {

    super.onCreate();

    DaggerYourApplicationComponent.create()

        .inject(this);

  }

 

  @Override

  public AndroidInjector<Activity> activityInjector() {

    return dispatchingActivityInjector;

  }

}

 

5. 마지막으로 Activity.onCreate()메서드에서 AndroidInjection.inject(this) super.onCreate()호출전에 호출한다.

 

public class YourActivity extends Activity {

  public void onCreate(Bundle savedInstanceState) {

    AndroidInjection.inject(this);

    super.onCreate(savedInstanceState);

  }

}

 

 

어떻게 동작하나?

 

AndroidInjection.inject() Application으로부터 DispatchingAndroidInjector<Activity> 얻고 inject(Activity) 액티비티에 전달된다. 

DispatchingAndroidInjector 당신의 액티비티의 클래스(YourActivitySubcomponent.Factory) 위해 AndroidInjector.Factory 찾고, AndroidInjector(YourActivitySubComponent) 생성하고, inject(yourActivity) 당신의 액티비티를 전달한다.

 

프래그먼트 객체의 주입

 

프래그먼트를 주입하는것은 액티비티를 주입하는것 만큼 단순하다. 같은 방식으로 서브콤포넌트를 정의하고 HasActivityInjector HasFragmentInjector 변경하면 된다.

 

onCreate()에서 액티비티를 주입하는것 대신에 onAttach(..)에서 주입하면 된다.

 

액티비티에 정의된 모듈과 달리, 프래그먼트에 모듈을 설치할 위치를 선택할수 있다. 당신의 프래그먼트콤포넌트를 다른 프래그먼트 콤포넌트, 액티비티 콤포넌트 또는 애플리케이션 콤포넌트의 서브콤포넌트로 만들수 있다. 이는 당신의 프래그먼트를 필요로 하는 다른 바인딩에 의존한다. 콤포넌트의 위치를 결정하고 나서 대응되는 타입의 HasFragmentInjector 구현한다. 예를 들어 당신의 프래그먼트가 YourActivitySubcomponent에서 바인딩이 필요하면 다음과 같이 코딩할것이다.

 

public class YourActivity extends Activity

    implements HasFragmentInjector {

  @Inject DispatchingAndroidInjector<Fragment> fragmentInjector;

 

  @Override

  public void onCreate(Bundle savedInstanceState) {

    AndroidInjection.inject(this);

    super.onCreate(savedInstanceState);

    // ...

  }

 

  @Override

  public AndroidInjector<Fragment> fragmentInjector() {

    return fragmentInjector;

  }

}

 

public class YourFragment extends Fragment {

  @Inject SomeDependency someDep;

 

  @Override

  public void onAttach(Activity activity) {

    AndroidInjection.inject(this);

    super.onAttach(activity);

    // ...

  }

}

 

@Subcomponent(modules = ...)

public interface YourFragmentSubcomponent extends AndroidInjector<YourFragment> {

  @Subcomponent.Factory

  public interface Factory extends AndroidInjector.Factory<YourFragment> {}

}

 

@Module(subcomponents = YourFragmentSubcomponent.class)

abstract class YourFragmentModule {

  @Binds

  @IntoMap

  @ClassKey(YourFragment.class)

  abstract AndroidInjector.Factory<?>

      bindYourFragmentInjectorFactory(YourFragmentSubcomponent.Factory factory);

}

 

@Subcomponent(modules = { YourFragmentModule.class, ... }

public interface YourActivityOrYourApplicationComponent { ... }

 

 

Base Framework Types

 

DispatchingAndroidInjector 런타임에 해당클래스가 전용 AndroidInjector.Factory 찾기 때문에 기반클래스는 AndroidInjection.inject() 호출하고 HasActivityInjector/HasFragmentInjector/등을 구현해야 한다. 모든 서브클래스들이 해야 하는 일은 대응되는 @Subcomponent 바인딩해야 하는것이다. 대거는 복잡한 클래스구조가 없다면 DaggerActivity DaggerFragment같은 몇가지 기반클래스를 제공한다. 대거는 같은 목적으로 DaggerApplication 제공한다. 당신이 해야 일은 이를 확장하고 applicationInjector()메서드를 오버라이드하여 application 주입하는 콤포넌트를 반환한다.

 

다음 타입들 또한 제공된다

 

  • DaggerService DaggerIntentService
  • DaggerBroadcastReceiver
  • DaggerContentProvider

 

DaggerBroadcastReceiver AndroidManifest.xml 등록되어 있어야 한다. 

코드로 BroadcastReceiver 생성되면 대신에 생성자주입을 선호합니다.

 

지원라이브러리는 dagger.android.support 패키지이다

 

Build.gradle 다음을 추가해야 한다.

 

dependencies {

  compile 'com.google.dagger:dagger-android:2.x'

  compile 'com.google.dagger:dagger-android-support:2.x' // if you use the support libraries

  annotationProcessor 'com.google.dagger:dagger-android-processor:2.x'

}

 

 

When to inject

 

생성자 주입은 가능하면 선호된다. javac 셋팅되기전에 필드가 참조되지 않아서 널포인트를 피할수 있도록 해주기 때문에 선호된다.

멤버주입이 필요한 경우(위에서 언급된) 가능하면 빨리 주입하는것이 선호된다. DaggerActivity super.onCreate() 호출되기 전에 AndroidInjection.inject() 바로 호출하기 때문에 선호된다. 프래그먼트의 경우는 onAttach()에서 한다.

 

super.onCreate()보다 전에 AndroidInjection.inject() 먼저 호출하는것이 중요하다. 반대로 하면 컴파일에러가 발생한다.

 

Posted by 삼스
Android/App개발2019.06.05 16:44

https://dagger.dev/users-guide

 

Dagger FactoryFactory 클래스를 대체한다. 보일러플레이트를 배제한 의존성주입을 구현한다. 이는 쓸모없는 오버엔지니어링을 방지하고 의미 있는 클래스에 집중할수 있게 한다. 의존성을 정의하고 어떻게 구성되는지 기술하면 된다.

 

테스트 아주 유용할뿐 아니라 재사용 가능하고 모듈의 변경이 가능하다. AuthenticationModule 여러 앱에서 사용 가능하고 DebugLoggingModule ProdLoggingModule 상황에 맞게 구성하여 사용할 있다.

 

Dagger2 최초료 풀스택 코드생성방식으로 구현되었다. 

 

커피메이커 샘플(https://github.com/google/dagger/tree/master/examples/simple/src/main/java/coffee) 대거를 설명하겠다.

 

대거는 당신의 클래스들과 이에 관련된 의존성을 정의하는 것으로 구성이 된다. Javax.inject.Inject 어노테이션으로 생성자와 필드를 지정한다.

 

클래스 생성자에 @Inject 사용하면 대거가 클래스인스턴스를 만들때 사용한다. 새로운 인스턴스를 요청하면 요구되는 파라메터들을 얻어내어 생성자를 만든다.

 

class Thermosiphon implements Pump {

  private final Heater heater;

 

  @Inject

  Thermosiphon(Heater heater) {

    this.heater = heater;

  }

 

  ...

}

 

대거는 필드를 바로 주입할수 있다. 다음 샘플은 두개의 필드를 얻어낸다.

 

class CoffeeMaker {

  @Inject Heater heater;

  @Inject Pump pump;

 

  ...

}

 

클래스가 @Inject 필드는 있는데 생성자가 @Inject 없다면 대거는 필요하면 필드를 주입하게 되겠지만 새로운 인스턴스를 생성하지는 않을 것이다.  인자가 없는 생성자를 추가해서 대거가 인스턴스를 생성할 있게 해주어야 한다.

 

메서드 주입도 지원하는데 생성자나 필드주입이 선호된다.

 

@Inject아너테이션이 없는클래스는 대거가 생성할 없다.

 

기본적으로 위에서 기술한 타입의 인스턴스를 생성함으로써 의존성을 만족시킨다. CoffeeMaker 요청하면  new CoffeeMaker() 인스턴스를 만들고 필드에 주입하도록 설정한다.

 

@Inject 항상 동작하지는 않는다.

  • Interface 생성될수 없다.
  • 3rd party 클래스는 어도테이션할수 없다.
  • 설정가능한 객체는 반드시 설정하여 사용해야 한다.

 

@Providers 어노테이션은 메서드에 의존성을 부여한다. 해당 메서드의 반환타입이 의존성객체이다.

 

예를 들어 provideHeader() Header 필요할대 마다 호출된다.

 

@Module

class DripCoffeeModule {

  @Provides static Heater provideHeater() {

    return new ElectricHeater();

  }

 

  @Provides static Pump providePump(Thermosiphon pump) {

    return pump;

  }

}

 

 

@Inject @Provides 어노테이트된 클래스는 의존성에 따른 객체 그래프를 만든다. main메서드나 안드로이드의 Application 그래프의 루트로 사용될수 있다.

 

대거2에서 의존성은 다음 샘플처럼 인수가 없고 원하는 형식을 반환하는 메서드가 있는 인터페이스로 정의되며 @Component주석과 모듈유형을 매개변수로 전달한다. 그러면 명세에 따라 코드가 생성된다.

 

@Component(modules = DripCoffeeModule.class)

interface CoffeeShop {

  CoffeeMaker maker();

}

 

프리픽스로 Dagger 붙은 동일한 이름의 클래스가 생성되며 builder().build()메서드로 인스턴스를 얻는다.

 

CoffeeShop coffeeShop = DaggerCoffeeShop.builder()

    .dripCoffeeModule(new DripCoffeeModule())

    .build();

 

콤포넌트가 최상위타입이 아니면 생성된 콤포넌트 이름은 타입의 이름을 포함하여 밑줄로 구분하여 이름이 정해진다.

 

class Foo {

  static class Bar {

    @Component

    interface BazComponent {}

  }

}

 

경우 DaggerFoo_Bar_BazComponent

 

접근가능한 생성자를 갖는 모듈은 builder 생략될 있다. 

모든 @Provides메서드가 static이면 인스턴스의 구현이 필요없다. 때도 create()메서드로 builder없이 생성이 가능하다.

 

CoffeeShop coffeeShop = DaggerCoffeeShop.create();

 

커피앱에서 대거가 생성한 구현체가 주입된 CoffeeShop객체를 사용하는 예이다.

 

public class CoffeeApp {

  public static void main(String[] args) {

    CoffeeShop coffeeShop = DaggerCoffeeShop.create();

    coffeeShop.maker().brew();

  }

}

 

샘플은 콤포넌트를 어떻게 생성하는지에 대한 몇가지 방법을 설명한다. 다른 바인딩방법을 알아보자

 

다음은 의존성으로 사용 가능하며 구성된 콤포넌트를 생성하는데 사용될 있다.

 

  • @Component.modules 의해 직접 참조되거나 @Module.includes 통해 참조죄는 @Module내에 @Provides메서드로 선언된 모듈
  • scope 지정되지 않는 @Inject생성자가 있는 타입이거나 콤포넌트 scope 일치하는 @Scope 주석이 있는 타입
  • 콤포넌트 의존성의 콤포넌트 제공 메서드
  • 콤포넌트 자체
  • 임의의 포함된 서브콤포넌트의 규정되지 않는 빌더
  • Provider 또는. Lazy wrapper 
  • Lazy Provider( Provider<Lazy<CoffeeMaker>>)
  • 모든 타입의 memberInjector

 

 

@Singletone주석을 갖는 @Provides 단일인스턴스를 사용한다.

 

@Provides @Singleton static Heater provideHeater() {

  return new ElectricHeater();

}

 

싱글톤을 사용할떄는 멀티스레드에 대해 대비해야 한다.

 

@Singleton

class CoffeeMaker {

  ...

}

 

대거2 콤포넌트 구현 범위를 연관시키기 때문에 이를 선언해야 한다. @Singletone @RequestScoped바인딩을 동일한 콤포넌트에 포함하는것은 의미가 없다. 수명주기가 다르기 때문인데 유의하여 콤포넌트 인터페이스 정의 범위 주석을 적용해야 한다.

 

@Component(modules = DripCoffeeModule.class)

@Singleton

interface CoffeeShop {

  CoffeeMaker maker();

}

 

콤포넌트는 여러 범위 주석을 적용할 있다. 

 

 

간혹 @Inject 생성되는 클래스가 @Provides메서드로 인스턴스로 만드는데 회수를 제한하고자 할수 있다. 하지만 모든 개개의 콤포넌트나 서브콤포넌트에서 사용되는 인스턴스가 동일한지 보장할 필요 없다. 이는 안드로이드 같은 메모리가 비용이 비싼 경우 유용하다.

 

경우 @Reusable 범위를 사용할 있다. @Reusable 사용되면 다른 범위와 다르게 모든 단일 콤포넌트에 연관되지 않는다 대신에 바인딩을 실제로 사용하는 콤포넌트들은 캐시하거나 객체를 생성한다.

 

이는 콤포넌트에 @Reusable 바인딘된 모듈을 정의하고 서브콤포넌트만 실제 해당 바인딩을 사용한다면 서브콤포넌트는 해당 바인딩을 캐시하게 된다. 조상을 공유하지 않는 두개의 서브콤포넌트가 바인딩 한다면 각각 따로 캐시할것이다. 조상이 이미 객체를 캐시한 경우 서브컴포넌트는 재사용한다.

 

콤포넌트가 바인딩을 한번만 호출한다는 보장이 안되므로 변경가능한 객체를 반환하는 바인딩에 @Reusable 적용하거나 동일 인스턴트를 참조하는것은 위험하다. 할당 횟수와 상관없는 불변객체에 대해 사용하는것이 안전하다.

 

@Reusable // It doesn't matter how many scoopers we use, but don't waste them.

class CoffeeScooper {

  @Inject CoffeeScooper() {}

}

 

@Module

class CashRegisterModule {

  @Provides

  @Reusable // DON'T DO THIS! You do care which register you put your cash in.

            // Use a specific scope instead.

  static CashRegister badIdeaCashRegister() {

    return new CashRegister();

  }

}

 

@Reusable // DON'T DO THIS! You really do want a new filter each time, so this

          // should be unscoped.

class CoffeeFilter {

  @Inject CoffeeFilter() {}

}

 

Lazy injections

 

지연된 주입이 가능하다. 샘플 참조.

 

class GrindingCoffeeMaker {

  @Inject Lazy<Grinder> lazyGrinder;

 

  public void brew() {

    while (needsGrinding()) {

      // Grinder created once on first call to .get() and cached.

      lazyGrinder.get().grind();

    }

  }

}

 

Provider Injections

 

여러개의 인스턴스가 필요한 경우가 있을 것이다. 경우 사용이 가능하다.

 

class BigCoffeeMaker {

  @Inject Provider<Filter> filterProvider;

 

  public void brew(int numberOfPots) {

  ...

    for (int p = 0; p < numberOfPots; p++) {

      maker.addFilter(filterProvider.get()); //new filter every time.

      maker.addCoffee(...);

      maker.percolate();

      ...

    }

  }

}

 

 

Qualifier

 

같은 클래스의 다른 인스턴스가 필요한 경우가 있다. 경우 qualifier주석을 사용할 있다. 

 

@Qualifier

@Documented

@Retention(RUNTIME)

public @interface Named {

  String value() default "";

}

 

자신만의 qualifier 만들거나 그냥 @Named 사용할수 있다. 필드와 관심있는 파라메터에 모두 사용가능하다.

 

class ExpensiveCoffeeMaker {

  @Inject @Named("water") Heater waterHeater;

  @Inject @Named("hot plate") Heater hotPlateHeater;

  ...

}

 

대응되는 @Provides메서드가 제공되어야 한다.

 

@Provides @Named("hot plate") static Heater provideHotPlateHeater() {

  return new ElectricHeater(70);

}

 

@Provides @Named("water") static Heater provideWaterHeater() {

  return new ElectricHeater(93);

}

 

 

Optional bindings

 

콤포넌트에 포함되지 않음에도 디펜던시를 추가하고 싶다면 @BindsOptionalOf 사용할 있다.

 

@BindsOptionalOf abstract CoffeeCozy optionalCozy();

 

이는 @Inject생성자와 멤버 그리고 @Provides메서드는 Optional<CoffeeCozy>객체에 의존한다. 콤포넌트에  CoffeeCozy 바인딩되어 있으면 Optional 존재하고 없으면 존재하지 않을것이다.

 

다음중 하나를 주입할수 있다.

 

  • Optional<CoffeeCozy> : CoffeeCozy 바인딩에 @Nullable 없다면(아래 참조)
  • Optional<Provider<CoffeeCozy>>
  • Optional<Lzay<CoffeeCozy>
  • Optional<Provider<Lazy<CoffeeCozy>>>

 

Provider, Lazy 또는 Lazy Provider 주입할수 있지만 유용하지는 않다.

 

CoffeeCozy바인딩이 있고 바인딩이 @Nullable이면 Optional<CoffeeCozy>에서 컴파일에러가 발생한다. 왜냐하면 Optional null일수 없기 때문이다. Provider Lazy get 메서드에서 항상 null 반환할 있기 때문에 항상 다른 값이 주입될 있다.

 

콤퍼넌트에 optional 바인딩이 없어도 서브콤포넌트에 있을 있다. 서브콤포넌트에 기저타입의 바인딩이 있다면

 

 

Binding Instances

 

종종 콤포넌트를 빌드하는 시점에 유효한 데이터를 가질수 있다. 예를 들어 커맨드라인 인자를 필요로 하는 앱이 있는 경우 콤포넌트에 인자를 전달하고자 할것이다.

 

단일 인자로 이름을 받고 @UserName문자열로 주입하고자 한다면 콤포넌트 생성시 값을 전달하기 위해 @BindsInstance 주석을 추가할수 있다.

 

@Component(modules = AppModule.class)

interface AppComponent {

  App app();

 

  @Component.Builder

  interface Builder {

    @BindsInstance Builder userName(@UserName String userName);

    AppComponent build();

  }

}

 

위와 같이 정의하고 앱에서는 아래와 같이 사용한다.

 

public static void main(String[] args) {

  if (args.length > 1) { exit(1); }

  App app = DaggerAppComponent

      .builder()

      .userName(args[0])

      .build()

      .app();

  app.run();

}

 

콤포넌트에 주입되는 @UserName 문자열은 메서드가 호출될 빌더에 제공되는 인스턴스에 사용하게 될것이다. 콤포넌트를 빌드하기 전에 모든 @BindsInstance메서드들이 반드시 호출되어야 하면 null 아닌값이 전달되어야 한다(@Nullable 바인딩의 경우 제외).

 

@BindsInstance메서드가 @Nullable 경우 바인딩은 @Provides메서드의 경우처럼 nullable 간주된다. @Nullable 해야 하며 떄는 바인딩에 null 허용된다. Builder 유저는 호출을 생략할수 있으며 경우 콤포넌트는 null 다루어진다.

 

@BindsInstance메서드는 @Module 생성자 인자로 작성되어야 하고 해당 값이 바로 제공되어져야 한다.

 

Compile-time Validation

 

대거 아노테이션 프로세서는 업격해서 유효하지 않거나 완성되지 않는 바인딩에 대해 컴파일에러를 발생한다. 예를 들면 다음 예는 Executor 위한 바인딩이 누락상태의 모듈을 콤포넌트에 인스톨하고 있다.

 

@Module

class DripCoffeeModule {

  @Provides static Heater provideHeater(Executor executor) {

    return new CpuHeater(executor);

  }

}

 

컴파일하면 javac 바인딩 누락으로 반려하게 된다.

 

[ERROR] COMPILATION ERROR :

[ERROR] error: java.util.concurrent.Executor cannot be provided without an @Provides-annotated method.

 

콤포넌트내의 아무 모듈에든 executor 위한 @Provides 주석을 추가해서 문제를 해결할 있다. @Inject, @Module그리고 @Provides주석이 각각 유효하면 @Component단계에서 바인딩간의 관계에 대한 모든 유효성검사가 발생한다. 대거1 모듈단계에서 유효성이 업격하게 책임지없다면 대거2 단계는 생략한다.

 

Compile time Code Generation

 

대거는 컴파일 CoffeeMaker_Factory.java CoffeeMaker_MembersInjector.java같은 이름의 파일들을 만들어 낸다. 파일들은 대거 구현의 디테일이다. 이들을 바로 사용할일은 없으며 디버깅은 해볼수 있겠다.코딩 참조할만한 코드들은 콤포넌트에 프리픽스로 Dagger 붙이것들이다.

 

Using Dagger In Your Build

 

Dagger-2.x.jar 런타임에 필요하다.  dagger-compiler-2.x.jar 코드자동생성을 위해 요하다. 자새한것은 다음 링크 참조 https://github.com/google/dagger/blob/master/README.md#installation

 

Posted by 삼스
Android/App개발2019.06.04 14:02

https://github.com/google/dagger

 

google/dagger

A fast dependency injector for Android and Java. Contribute to google/dagger development by creating an account on GitHub.

github.com

의존성주입 라이브러리인 Dagger2를 알아보기 전에 Dagger1을 먼저 알아보자


2012년에 자바로 의존성을 주입하는 아이디어를 좋아한 스퀘어 개발자 몇명이 만들었다. 결국 어노테이션 기반의 코드생성과 guice와 비슷한 api를 갖지만 더 유연하고 빠르게 만들었다.
Dagger의 동작방식은 주입하고자 하는 모든 의존성을 위한 프로바이더를 포함하는 모듈들을 정의하여 객체그래프에 모듈을 로딩하고 결국 필요한 타겟에 내용을 주입하는 방식이다. 충분히 단순한구조(구현은 단순하지 않음)는 개발자가 코드를 분리할 수 있게 도움을 주고 클래스 상단에 객체를 생성하는 보기싫은 코드들을 라이브러리가 생성하는 인젝터들에 옮겨준다.
하지만 이런 잇점과 동시에 빠른 풀리퀘스트(하나 혹은 둘)를 해결하지 못하는 문제가 있다. 이는 기본아키텍쳑와 관련되어 있다.

- 런타임에 그래프 구성 : 성능에 악영향. 
- 리플랙션(예:Class.forName()) : 읽기 힘든 자동생성 코드와 프로가드의 악몽 발생
- 보기 싫은 자동생성코드 : 팩토리로 부터 수동 생성한 경우와 비교하여 아주 보기 싫음

결국 이런 이유로 수많은 이슈들이 트래킹되었고 이 이슈들은 Dagger2에서 해결하는것으로 이슈가 클로즈 되었다.

Dagger2

스퀘어의 원작자와 구글의 코어라이브러리 팀이 Dagger의 다음 이터레이션을 가져왔다.
약속대로 여러 이슈들이 해결되어 새버전이 배포되었다.

- 리프랙션 없음 : 프로가드 지옥도 해결
- 런타입 그래프구성 없음 : 성능 향상
- 추적가능 : 더 좋은 코드와 리플랙션 제거로 인해 더 읽이 쉽고 따라하기 쉬워짐.

Module

Dagger2에서 가장 변경이 없는것이 모듈이다. 주입하고자 하는 의존성의 프로바이더 메서드를 정의하면 된다. 

SharedPreference가 필요하다고 외쳐보자!

@Module 
public class ApplicationModule { 
    private Application mApp; 
    public ApplicationModule(Application app) { 
        mApp = app; 
    } 
    @Provides
    @Singleton
    SharedPreferences provideSharedPrefs() { 
        return PreferenceManager.getDefaultSharedPreferences(mApp); 
    } 
}

Component

Dagger를 아는 사람은 모듈에서 ingect = {} 가 사라진것을 알수 있다. Dagger2는 콤포넌트가 이를 대체한다.

@Singleton 
@Component(modules = {ApplicationModule.class}) 
public interface ApplicationComponent { 
    void inject(DemoApplication app); 
    void inject(MainActivity activity); 
}

주입하고자 하는 타겟들을 정의하면 되며 만일 누락되면 "cannot find method" 컴파일에러가 날것이다.

Application

다음은 콤포넌트를 담을 컨테이너이다.
응용 프로그램에 따라 더 복잡한 방법으로 구성 요소를 저장할 수도 있지만이 예제에서는 응용 프로그램 클래스에 저장된 단일 구성 요소로 충분하다.

public class DemoApplication extends Application { 
    private ApplicationComponent mComponent; 
    @Override 
    public void onCreate() { 
        super.onCreate(); 
        mComponent = DaggerApplicationComponent.builder() 
                    .applicationModule(new ApplicationModule(this))
                    .build(); 
    } 
    public ApplicationComponent getComponent() { 
        return mComponent; 
    } 
}

특별한것이 없다 해당 콤포넌트를 build하고 인스턴스화 해서 저장한다.
위 코드에서 이해가 안되는 부분이 있을수 있는데 DaggerApplicationComponent가 어디서 나왔냐 하는것일것이다. 이는 Dagger%COMPONENT_NAME%형식으로 명명되어 자동생성된 클래스이다. 컴파일러가 자동으로 만들어준다. 

Injection

마지막으로 위에서 설정한 인젝션 설정을 SharedPreference에 접근하고자 하는 액티비티내에서 사용하게 된다.

public class MainActivity extends Activity { 
    @Inject SharedPreferences mSharedPrefs; 
    @Override 
    public void onCreate(Bundle savedInstanceState) { 
        super.onCreate(savedInstanceState); 
        ((DemoApplication) getApplication())
                    .getComponent()
                    .inject(this); 
        mSharedPrefs.edit()
                    .putString("status", "success!")
                    .apply(); 
    } 
}

예상한데로 @Inject어노테이션은 변경되지 않았고 인젝션내에서만 일부 변경이 있다.  

Named Injection


동일 타입의 여러 객체가 필요한 경우 예를 들어 SharedPreference를 용도가 다르거나 다른파일을 지정하는 등의 경우 어떻게 할것인가?
이 경우 이름을 부여할 수 있다. @Named 어노테이션을 추가하는것만으로 가능하다.

@Provides 
@Named("default") 
SharedPreferences provideDefaultSharedPrefs() { … } 

@Provides 
@Named("secret") 
SharedPreferences provideSecretSharedPrefs() { … }

주입 대상에서도 동일하게..

@Inject @Named("default") SharedPreferences mDefaultSharedPrefs; @Inject @Named("secret") SharedPreferences mSecretSharedPrefs;


Lazy Injection

성능을 고려하면 지연된 주입이 반드시 필요하다 모든 의존성을 앱실행 초기에 하면 앱이 늦게 시작될테니까. 이를 위해 지연된 주입을 지 원한다.

@Inject Lazy mLazySharedPrefs; 
void onSaveBtnClicked() { 
    mLazySharedPrefs.get()
                .edit().putString("status", "lazy...")
                .apply(); 
}

위와 같이 정의 두면 호출전까지 주입이 되지 않는다. 이 후에는 주입된 상태를 유지한다.

Provider Injection

팩토리 패턴이 가능하다. 객체를 주입하지 않고 여러 인스턴스를 만들어야 하는 경우... 이 경우 Provider가 가능하다.

@Inject 
Provider mEntryProvider; 
Entry entry1 = mEntryProvider.get(); 
Entry entry2 = mEntryProvider.get();

프로바이더가 Entry객체의 두가지 인스턴스를 만든다. 인스턴스가 모듈에서 어떠게 생성될지는 알아서...

짜증나게 하는 지점!

inject() 메서드는 강력한 타입체크를 수행한다. 이는 디버깅에 유리하지만 베이스클래스로부터 주입하는 경우 복잡하게 한다.
직관적으로 베이스클래스를 대상으로 하는 inject()메서드를 만들것이다 하지만 이는 서브클래스에 대해서는 동작하지 않는다.

해결책은 멀까? 

방법#1 은 베이스클래스에 abstract 메서드를 정의하는것이다. 

@Override 
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState); 
    injectComponent(((DemoApplication) getApplication())
                .getComponent()); 

protected void injectComponent(ApplicationComponent component);

그리고 서브클래스에서 구현한다.

@Override
protected void injectComponent(ApplicationComponent component) { 
    component.inject(this); 
}

방법#2 는 리플랙션을 사용하는것이다. 이는 당신이 다루고자 하는 타입에 해 당하는 inject()메서드를 찾는것으로 귀결된다.

먼저 당신이 정의한 콤포넌트의 모든 메서드들을 타입별로 캐시한다.

// Keep the returned cache in some helper. 
Map<Class, Method> buildCache() { 
    Map<Class, Method> cache = new HashMap<>(); 
    for (Method m : ApplicationComponent.class.getDeclaredMethods()) { 
        Class[] types = m.getParameterTypes(); 
        if (types.length == 1) { 
            cache.put(types[0], m); 
        } 
    } 
    return cache; 
}

그리고 주입시에 getClass()로 캐시로부터 꺼내고 invoke를 호출한다.

// Use for injecting targets of any type. void inject(ApplicationComponent component, Object target) { 
    Method m = cache.get(target.getClass()); 
    if (m != null) { 
        m.invoke(component, target); 
    } 
}

기본클래스에서 모든 설정을 숨기거나 이것을 수행하는 코드를 다루는 누군가에게는 유용할것이다.

짜증2 는 콤포는트 구현이 재빌드를 요구하고 클래스가 사라질때는 컴파일에러가 발생한다는 것이다. 심간한 불편함은 아니지만 프로젝트 구성 초기에는 좀 귀찮을 수 있다.

원문 : https://blog.gouline.net/dagger-2-even-sharper-less-square-b52101863542

 

Dagger 2: Even Sharper, Less Square

It was only a matter of time before version 2.0 of the well-known dependency injection library Dagger hit production and that seemed like…

blog.gouline.net

한글로 된 잘 정리된 문서

https://medium.com/@jason_kim/tasting-dagger-2-on-android-%EB%B2%88%EC%97%AD-632e727a7998

Posted by 삼스
iOS2019.05.21 12:36

Cookie?
쿠키는 브라우저세계에서 주로 세션관리, 사용자 프리퍼런스와 상태등을 주로 다루며 일반적이고 널리 사용된다.
서버에서 제공하는 작은 속성데이터이다. 웹브라우저에서 저장되며 서버에 요청시 공유된다.

쿠키구조
적은양의 데이터이지만 구조적이고 속성들은 쿠키의 동작을 정의한다. RFC6265, RFC2109

쿠키와 모바일앱
쿠키는 웹세계에서 사용되며 대부분 모바일개발자는 다룰필요가 없다. REST API 로 서버에 데이터를 요청한다. 대부분의 유스케이스와 앱에 맞다. 하지만 간혹 경계가 모호해지는 경우가 있다. 쿠키를 조작해야 하고 모바일앱은 이를 잘 수행한다.
SSO를 예를 들면 여러 시스템에서 세션을 공유해야 할것이다. 이때 쿠키가 이 목표를 달성할수 있게 해준다.

iOS에서 쿠키 다루기
NSHTTPCookie, NSHTTPCookieStorage라는 아주 잘 설계된 클래스 2개가 제공된다.

NSHTTPCookie클래스는 쿠키 데이터 클래스이며 필수 파라메터가 있다. name, value, domain or originalurl, path이다, 모두 제공되지 않으면 nil리턴된다.

NSMutableDictionary* cookieProperties = [NSMutableDictionary dictionary];

//set rest of the properties
[cookieProperties setObject:@"MyCookie" forKey:NSHTTPCookieName];
[cookieProperties setObject:@"cookie12345ytehdsfksdf" forKey:NSHTTPCookieValue];
[cookieProperties setObject:@"/" forKey:NSHTTPCookiePath];
[cookieProperties setObject:@".example.com" forKey:NSHTTPCookieDomain];
//create a NSDate for some future time
NSDate* expiryDate = [[NSDate date] dateByAddingTimeInterval:2629743];
[cookieProperties setObject:expiryDate forKey:NSHTTPCookieExpires];
[cookieProperties setObject:@"TRUE" forKey:NSHTTPCookieSecure];

NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];

HttpOnly같은 속성은 쿠키에서 중요하며 딕셔너리로 셋팅할수 없다. 위와 같은 방식의 쿠키생성은 유용하지 않은것 같다. 

권장되는 방식은 다음과 같다.

NSHTTPCookie에 더 훌룡한 API가 제공되는데 http response 문자열을 모두 덤프할 수 있고 HttpOnly를 포함해서 모든 필요한 속성이 셋팅된 완전한 쿠키를 리턴한다.

NSArray* httpCookies = [NSHTTPCookie cookiesWithResponseHeaderFields:[httpresponse allHeaderFields] forURL:url];

서버응답인 http response에는 키/밸류 쌍인 "Set-Cookie"로 일반적으로 넘어온다. 위 API는 쿠키문자열을 response로부터 취해서 cookie를 만든다. 여기서 URL이 중요하면서도 유용한다. 앞서 얘기한데로 쿠키는 필수파라메터로 name, domain, value, path가 있다고 했다. 하지만 RFC문서에는 Domain은 옵션이다 이는 빈도매인이 있을 수 있다는 것이다. NSHttpCookie클래스에는 originURL을 셋팅할수 없다. 딕셔너리로 쿠키를 생성하는 방법은 완전히 쓸모가 없다. 하지만 이 방법은 쿠키문자열에 domain이 없으면 originURL을 채우고 유효한 쿠키를 제공한다. 이에 더해 서버에서 전달한 추가적인 정보를 알아서 셋팅해준다. 이 방법이 경험적으로 쿠키를 만드는 가장 좋은 방법이다.

쿠키 저장
NSHTTPCookieStorage가 쿠키를 저장해준다.

[[NSHTTPCookieStorage sharedHTTPCookieStorage] setCookie:cookie];

여기서 가장 중요한 특성은 iOS가 네트웍 요청에 도메인이 매칭된다면 자동으로 추가해준다는 것이다. 예를 들어 domain이 ".example.com"인 쿠키가 저장되어 있고 "www.test.example.com"으로 요청을 하게된다면 추가코드없이 자동으로 추가된다.

NSURLSession요청은 URL이 domain이 매칭되면 요청에 쿠키를 셋한다.  webview의 경우 아래와 같이 초기로드를 위해 저장소에서 액세스하여 쿠키를 추가 할 수 있다

NSURLRequest* request; //your request
[request setAllHTTPHeaderFields:[NSHTTPCookie requestHeaderFieldsWithCookies:[NSHTTPCookieStorage sharedHTTPCookieStorage].cookies]];
[request HTTPShouldHandleCookies];

Posted by 삼스
iOS2019.05.10 16:47

이게 개념이 잡히지 않으면 개발환경 설정 시 마다 고생하기 마련이다.

이참에 정리를 좀 하자.

 

일단 기본적으로 애플은 앱실행권한을 관리를 하고 있다. 이 권한이 획득되지 못하면 앱이 실행이 될수 없다.

그러기 위해서는 애플로부터 인증서를 발급받아야 한다. 그리고 단말에서 실행을 하려면 프로비저닝이 단말에 설치가 되어야 한다.

프로비저닝은 단말과 애플인증서의 연결해주는 역할을 하며 권한을 획득하여 얻어지면 앱이 실행이 된다.

 

이 과정은

1. 애플인증서 생성

2. 프로비저닝 생성

3. 빌드 및 실행

이 되는데 하나하나씩 정리해 보자

 

1. 애플인증서 생성

개발자 PC에 키체인앱은 개인키와 공개키를 가지고 있다 이를 기반으로 먼저 CSR(Certificate Signing Request)을 먼저 만들어야 한다.

(1) 키체인 앱 실행

(2) 키체인접근 > 인증서 지원 > 인증기관에서 인증서 요청 선택

(3) 개발자의 이메일주소와 이름을 입력

(4) 요청항목의 "디스크에 저장됨" 선택

(5) 계속을 누르면 CertificateSigningRequest.certSigningRequest 파일이 저장된다.

 

저장된 CSR파일을 애플개발자 콘솔에 인증서 추가 화면에서 등록한다.

(1) https://developer.apple.com/ 접속 및 로그인

(2) Certificates, Identifiers and Profile > Certificates > Development 이동

(3) 추가버튼 누르고 iOS App Development선택하고 화면 안내에 따라 CSR파일 등록 

(4) 등록 완료되면 인증서 파일 다운로드

 

동일한 방법으로 Production의 AppStore and Ad Hoc선택하여 배포용도 등록

 

2. 프로비저닝 생성

프로비저닝은 앱아이디별로 생성이 가능하며 앱아이디를 먼저 등록해주어야 한다.

등록된 앱아이디로 Provision Profiles 화면에서 안내에 따라 개발과 배포용을 등록한 후 프로비저닝 파일을 다운로드 한다.

이 때 개발용의 경우 설치를 허용할 단말을 선택할 수 있는데 이 화면에서 선택한 단말들만 해당 프로비저닝으로 설치및 실행이 가능하다.

 

위 과정을 거치면 

1. 개발자의 공개키와 개인키

2. 애플이 인증한 인증서

3. 디바이스에 설치 가능한 프로비저닝

 

위 3가지로 빌드를 하면 .app파일이 생성되며 2가지로 구성된다.

1. 실제로 사용될 프로비저닝 프로파일 : 빌드시 사용된 프로비저닝이다.

2. _CodeSignature 폴더 : CodeResources 파일을 담고 있고 모든 파일의 암호화 해시정보를 갖고 있다.

 

AdHoc버전의 앱은 디바이스에 설치되어 실행될때 

 

1. .app에 포함된 프로비저닝 프로파일이 애플인증서로 서명되었는지 확인

2. CodeResources참조하여 모든 파일의 해시를 확인하여 무결성 체크

3. 디바이스에 프로비저닝 프로파일이 있는지 확인

 

위 과정을 거쳐서 실행된다.

 

엔터프라이즈배포의 경우는 애플은 그 회사를 신뢰하고 별도의 확인과정을 거치지 않고 바로 실행되게 해준다.

 

앱스토어배포의 경우는 그 어떤 디바이스에서도 실행될수 없다. 오로지 애플에 제출용으로만 사용이 가능하며 애플이 리뷰후 다시 사인하여 배포한다.

 

팁!)

새로운 팀원이나 다른 PC에 개발환경을 설정할 때 매번 애플인증서를 만들수는 없다.

이 때는 이미 등록된 인증서와 해당 인증서를 등록한 개발자의 키파일을 전달 받아서 설치해주어야 한다. 그러지 않으면 인증서의 출처를 확인하지 못하여 정상적으로 빌드가 안되는것 같다. 이 부분에 대해서는 정확히 아는 사람이 설명을 좀 해주었으면 ....

 



Posted by 삼스
iOS2018.08.04 13:17


애플의 인앱결재의 자동결재를 정리한다.


종류는 다음과 같다.


  • 소비형 : 한번 사면 바로 소모됨
  • 비소비형 : 한번사면 평생 유효
  • 자동갱신형 : 주기적으로 재구매(결재)가 자동으로 이루어짐
  • 비갱신형 : 기간 만료되면 다시 구매를 해야 함.

자동갱신

애플에서는 해당 구매의 만료일 10일전에 결재인프라를 먼저 확인한다. 이 때 카드정보등이 유효하지 않으면 메일등을 보내서 갱신을 유도한다.

하루전에는 실제로 결재를 시도한다. 이 때 결재가 실패할 수 있다. 

두가지가 있을 수 있다.


  • 결제정보의 일시적인 오류
  • 정기결제기능을 off

위 상황에서는 결재가 실패하게 되며 사용자가 결재정보를 유효하게 갱신하거나 정기결재기능을 다시 on하게 되면 애플에서는 구매를 수행하게 된다. 이 때 부득이 지연이 발생한다.


앱을 서비스 하는 입장에서는 이런 지연이 발생 한경우를 파악하여 적절히 사용자에게 안내를 해야 불온한 의도를 가진 사용자들의 공격을 막아낼 수 있을 것이다.


재결제내역 확인

앱과 서버가 모두 수행하는것이 좋으며 일반적으로 서버에서 하는것이 좀더 안전하다. 왜 더 안전한지에 대한 설명은 찾아볼 수 없으나 예상으로는 앱은 해킹이 가능하기 때문으로 추정해본다. 


앱 기동시에는 addTransactionObserver를 호출하면 된다. 이 때 재구매건이 있으면 paymentQueue에 결제건이 들어오게 된다. 이 결재건을 사용자가 직접 구매했을 때 와 동일하게 처리하면 된다.


서버에서는 만료일이 가까워진 결재건에 대해서 original 결재정보로 apple서버에 조회하여 마지막 영수증정보과 최종 영수증 정보가 다르면 리뉴얼 된것으로 파악하면 된다.


영수증정보의 갱신

영수증정보는 동일계정으로 로그인 된 다른 단말에서 재구매가 일어나도 앱 기동시마다 영수증정보를 최신으로 유지하기 때문에 동기화가 가능하다.


현재 구매상태인지 여부 확인

최초 결제의 영수증의 transactionId가 originalTransactionId가 되며 이 후 재결제가 일어나면 새로운 영수증이 발급되며 이 때 transactionId도 갱신이 된다. 하지만 originalTransactionId는 최초의 값이 유지된다.

따라서 영수증 목록에서 originalTransactionId로 필터링 후 expireDate가 아직 미래인 영수증이 있다면 아직 구매중인것으로 판단하면 된다.


구매취소 여부 확인

영수증에 Cancelation Date가 있다면 구독취소한것으로 판단하면 된다고 한다. Cancelation필드가 있으면 ExpireDate와 관계없이 취소된 구독이다.



결재내역 복원하기





Posted by 삼스
iOS2018.02.13 15:51


iOS7이전에는 자바스크립트와 무언가 작용을 하려면 UIWebView의 stringByEvaluatingJavaScriptFormString:를 사용해야 했다. 이는 웹뷰의 자바스크립트 런타임에서만 가능했다. 이는 싱글스레드인 환경의 제약이 있다.


JavaScriptCore는 Objective-C에서 자바스크립트의 풀런타임환경에 접근이 가능하게 한다. 문법확인, 스크립트실행과 변수 접근, 콜백수신  그리고 Objective-C 객체의 공유등으로 광범위한 상호작용이 가능하다.


JSVirtualMachine클래스로 불리는 가상머신에서 실행된다. 이는 여러개의 VM을 통해 멀티스레드 자바스크립팅이 가능하다는 것이다. JSVirtualMachine 각각은 여러개의 JSContext를 가질 수 있다. JSContext는 자바스크립트 런타입환경에 말하고 몇가지 기능을 제공한다. 이 중 두가지는 글로벌객체에 접근하는것과 스크립트를 실행할 수 있다는 것이다.


글로벌 영역에 정의된 변수에 대한 접근은 키로 바로 접근이 가능하다. 


    JSContext *context = [[JSContext alloc] initWithVirtualMachine:[[JSVirtualMachine alloc] init]];
    context[@"a"] = @5;
    JSValue *aValue = context[@"a"];
    double a = [aValue toDouble];
    NSLog(@"%.0f", a);

함수호출은 다음과 같다


[context evaluateScript:@”var square = function(x) {return x*x;}”]; 

JSValue *squareFunction = context[@”square”]; 

NSLog(@”%@”, squareFunction); 

JSValue *aSquared = [squareFunction callWithArguments:@[context[@”a”]]]; 

NSLog(@”a^2: %@”, aSquared); 

JSValue *nineSquared = [squareFunction callWithArguments:@[@9]]; 

NSLog(@”9^2: %@”, nineSquared);


evaluateScript로 스크립트 코드를 로드하고 callWithArguments로 스크립트내의 함수를 호출한다. 호출된 결과는 JSValue로 반환된다.

스크립트코드는 블럭코드형태로도 가능하다.



    context[@"factorial"] = ^(int x) {
        int factorial = 1;
        for (; x > 1; x--) {
            factorial *= x;
        }
        return factorial;
    };
    [context evaluateScript:@"var fiveFactorial = factorial(5);"];
    JSValue *fiveFactorial = context[@"fiveFactorial"];
    NSLog(@"5! = %@", fiveFactorial);
스크립트와 objective c간의 타입관계는 다음과 같다.

//   Objective-C type  |   JavaScript type
// --------------------+---------------------
//         nil         |     undefined
//        NSNull       |        null
//       NSString      |       string
//       NSNumber      |   number, boolean
//     NSDictionary    |   Object object
//       NSArray       |    Array object
//        NSDate       |     Date object
//       NSBlock       |   Function object
//          id         |   Wrapper object
//        Class        | Constructor object
스크립트NSNumber와 NSBlocks 타입은 mutable이 아니다 즉 한쪽에서 변경했다고 다른쪽에서 반영이 되지 않는다. id와 Class는 mutable이다. 
임의 오브젝트나 클래스가 자바스크립트에 브릿지될 수 있다. 
NSNull, NSString, NSNumber, NSDictionary, NSArray 또는 NSDate는 관련 클래스 계층을 JavaScript 실행 컨텍스트로 가져 와서 동등한 클래스 및 프로토 타입을 생성하는 JavaScriptCore를 생성하려고 한다.

JSExport protocol로 자바스크립트에 커스텀클래스의 일부를 노출할 수 있다. 래퍼객체는 다른곳에 생성될것이다. 그리하여 한개의 객체가 양쪽의 실행컨텍스트에 공유될 수 있다.

다음이 그 예이다.

    @protocol ThingJSExports <JSExport>
    @property (nonatomic, copy) NSString *name;
    @end

    @interface Thing : NSObject <ThingJSExports>
    @property (nonatomic, copy) NSString *name;
    @property (nonatomic) NSInteger number;
    @end

    @implementation Thing
    - (NSString *)description {
        return [NSString stringWithFormat:@"%@: %d", self.name, self.number];
    }
    @end

JSExport를 상속하여 ThingJSExports를 선언함으로써 자바스크립트에 노출할 수 있다. 이제 objective-c객체의 정보를 변경하면 자바스크립트에 그 값이 반영이 될것이다. 그 반대로 마찬가지.
다음은 id와 class를 브릿지한 예이다.


다음은 id와 class를 브릿지한 예이다.    Thing *thing = [[Thing alloc] init];
    thing.name = @"Alfred";
    thing.number = 3;
    context[@"thing"] = thing;
    JSValue *thingValue = context[@"thing"];

context[@"thing"] = [Thing class];

NSString *thingScript =

@"var t = new thing();"

"t.name = 'yslee';"

"t.number = 10;"

[context eveluateScript:thingScript];








Posted by 삼스
iOS2018.02.13 15:01


iOS에도 이런게 나왔을 줄이야..


안드로이드 하이브리드 개발자들은 알고 있겠지만 addJavascriptInterface를 통해서 자바스크립트에 java object를 바인딩이 가능하다.

이를 통해 하이브리드를 통해서 동기화 호출도 가능하다.

하지만 iOS는 불가했었다.

cordova도 NSURLProtocol을 통해서 하이브리드를 지원하는데 역시 동기화 호출을 불가하다.

하지만 불가능하지는 않다. 다른 방법으로 가능한 방법이 있으며 이를 통해서 실제 동기화 호출을 구현하기도 하였다.


그런데 iOS7부터 지원하는 JavaScriptCore프레임웍으로 가능한것 같다.


http://www.dbotha.com/2014/11/19/using-javascript-core-for-game-scripting-on-ios/ 를 참조하였다.


게임스크립팅 엔진을 javascriptcore로 변경하는것에 대한 글이다.


일반적인 게임튜터리얼의 스크립트는 아래와 같다.


/* tutorial1.js */
showText("Hello World!", /*x:*/ 160, /*y:*/ 100);
wait(5); // sleep 5 seconds
hideText()

showText("Tap the screen to continue", 160, 100);
waitForTap(); // pause execution until the user taps the UI
hideText();

showText("Match three coloured blocks to win!", 160, 100);
waitForLevelEnd(); // pause execution until a level end event occurs
hideText();

loadLevel("level2.map")

예제에서 보듯이 어떤 레벨에 도달할때까지 스크립트실행을 중지하는것이 좋다. 위에서 wait()함수에 대해 의문을 품게 될것이다. 싱글스레드의 자바스크립트 엔진에서는 의도한대로 작동을 기대하기 어렵다. 완전히 스레드가 멈추게 될것이므로..

JSVirtualMachine은 어떻게 실행을 중단할까?


스크립팅엔진자체에 대해 먼저 더 알아보자.


자바스크립트에 접근가능하도록 작성된 스위프트 프로토콜 메서드들을 보자


/* ScriptEngine.swift */
@objc protocol ScriptingEngineExports : JSExport {
    func wait(duration: Double)
    func waitForTap()
    func waitForLevelEnd()
    func loadLevel(mapName: String)
    func showText(text: String, _ x: Double, _ y: Double)
    func hideText()
}


금방 구현가능하고 앞서 기술한 튜터리얼 스크립트에 매우 가깝게 매칭된다.


이번엔 스크립팅 엔진을 살펴보자.


/* ScriptEngine.swift */
@objc class ScriptEngine : NSObject, ScriptEngineExports {
    var context: JSContext!
    let engineQueue = dispatch_queue_create(
            "script_engine", DISPATCH_QUEUE_SERIAL)
    
    override init() {
        super.init()
        
        dispatch_async(engineQueue) {
            self.context = JSContext()
            self.context.setObject(self, forKeyedSubscript: "$")
            self.context.evaluateScript(
                "function wait(duration) {$.wait(duration);}" + 
                "function waitForTap() {$.waitForTap();}" +
                "function waitForLevelEnd(){$.waitForLevelEnd();}" +
                "function print(text) {$.print(text);}" + 
                "function println(text) {$.print(text);}" + 
                "function loadLevel(name) {$.loadLevel(name);}")
        }
    }
    
    /* to be continued... */ 
}

engineQueue은 JSContext를 사용하기 위한 dispatch_queue이다. 이는 메인스레드와 분리하여 스크립트의 콜백을 스위프트가 받을 수 있도록 한다.

여기서 중요한것은 JSContext가 메인스레드에서 분리되어서 인스턴스화되었다는 것이다. 이는 메인스레드가 블럭되는것을 방지한다.


ScriptEngine 객체 인스턴스는 $변수를 통해서 접근이 가능하다.  evaluateScript가 호출되어 스크립트에 억세스 할 수 있는 ScriptEngineExports의 기능을 노출한다. 스위프트의 함수를 호출함으로 인해 ScriptEngine의 메서드가 호출된다.


실행중인 스크립트를 로드하는것은 간단하다. 



/* ScriptEngine.swift */
var currentScriptName: String?

func runScript(scriptName: String) {
    var ext = scriptName.pathExtension
    var fileName = scriptName.substringToIndex(
        advance(scriptName.startIndex, 
                scriptName.utf16Count - ext.utf16Count - 1))
    
    if fileExtension.utf16Count == 0 {
        fileName = scriptName
        ext = "js"
    }
    
    let url = NSBundle.mainBundle()
        .URLForResource(fileName, withExtension: ext)
    let scriptCode = String(contentsOfURL: url!, 
                            encoding: NSUTF8StringEncoding, 
                            error: nil)!

    self.currentScriptName = fileName + "." + fileExtension

    dispatch_async(engineQueue) {
        self.context.evaluateScript(scriptCode)
        return
    }
}

다음과 같이 실행이 가능하다.


let scriptEngine = ScriptEngine()
scriptEngine.runScript("tutorial1")

이제 어떻게 다양한 Wait()함수를 실행할 수 있는지 살펴보자


/* ScriptEngine.swift */
func wait(duration: Double) {
    NSThread.sleepForTimeInterval(duration)
}

이 wait함수는 engineQueue에 의해 관리되는 분리된 스레드에서 호출될것이 보장된다. 그래서 sleepForTimeInterval은 메인스레드가 아니라 이 스레드에서 동작할것이다. 자바스크립트는 실행이 잠시 중단될것이다.


다음은 좀 복잡한 대기로직들이다.


/* ScriptEngine.swift */
let tapCondition = NSCondition()
let levelEndCondition = NSCondition()
var seenTap = false
var seenLevelEnd = false

func waitForCondition(condition: NSCondition, 
        inout predicate: Bool) {
    condition.lock()
    while (!predicate) { // loop to protect against spurious wakes
        condition.wait()
    }
    predicate = false
    condition.unlock()
}

func notifyCondition(condition: NSCondition) {
    condition.lock()
    condition.signal()
    condition.unlock()
}

func waitForTap() {
    waitForCondition(tapCondition, &seenTap)
}

func notifyTap() {
    notifyCondition(tapCondition)
}

func waitForLevelEnd() {
    waitForCondition(levelEndCondition, &seenLevelEnd)
}

func notifyLevelEnd() {
    notifyCondition(levelEndCondition)
}

waitForTap()과 waitForLevelEnd()는 자바스크립에서 대응되는 함수가 호출되었을때 인스턴스 메서드로 노출된다. waitForCondition(condition:predicate:)는 해당 컨디션이 시그널될때까지 스레드를 블럭한다. notifyTap(), notifyLevelEnd()는 해당 컨티션발생시 시그널되고 engineQueue스레드를 깨워서 자바스크립트가 다시 살아나게 한다. 이 메서드들은 게임엔진에서 해당 이벤트가 발생하였을때 호출해야 한다.


이제 남은 노출된 함수는 구현하기에 따라 다르며 여기서는 다음과 같이 구현하였다.


/* ScriptEngine.swift */
func postNotification(type: GameNotification, 
        var userInfo: [NSObject : AnyObject]?) {
    
    if userInfo == nil {
        userInfo = [NSObject : AnyObject]()
    }
    
    userInfo![kGameNotificationUserInfoCurrentScriptName] 
        =  self.currentScriptName
    
    dispatch_async(dispatch_get_main_queue(), {
        NSNotificationCenter.defaultCenter()
            .postNotificationName(
                type.name(), object: self, userInfo: userInfo)
    })
}

func loadLevel(levelName: String) {
    postNotification(GameNotification.LoadLevel, 
        userInfo: [kGameNotificationUserInfoLevelName: levelName])
}

func showText(text: String, _ x: Double, _ y: Double) {
    postNotification(GameNotification.ShowText, 
        userInfo: [kGameNotificationUserInfoText: text, 
                   kGameNotificationUserInfoTextX: x, 
                   kGameNotificationUserInfoTextY: y])
}

func hideText() {
    postNotification(GameNotification.HideText, nil)
}


Posted by 삼스
iOS2018.01.16 11:19


CoreLocation framework에서 현재 위치의 위/경도 좌표를 얻을 수 있고 위/경도 좌표로 주소정보를 얻을 수 있다.



    _locationManager = [[CLLocationManager alloc] init];

// 사용중에만 유효하도록 

    if ([_locationManager respondsToSelector:@selector(requestWhenInUseAuthorization)]) {

        [_locationManager requestWhenInUseAuthorization];

    }

// 위치정보 와치 시작

    [_locationManager startUpdatingLocation];

    NSLog(@"%f/%f", _locationManager.location.coordinate.latitude, _locationManager.location.coordinate.longitude);

    

// 위/경도 정보로 주소 얻기

    CLLocation *location = [[CLLocation alloc] initWithLatitude:_locationManager.location.coordinate.latitude longitude:_locationManager.location.coordinate.longitude];

    NSLocale *locale = [[NSLocale alloc] initWithLocaleIdentifier:@"ko-kr"];

    CLGeocoder *geocoder = [[CLGeocoder alloc] init];

    [geocoder reverseGeocodeLocation:location preferredLocale:locale completionHandler:^(NSArray<CLPlacemark *> * _Nullable placemarks, NSError * _Nullable error) {

        NSLog(@"%@", [[[placemarks objectAtIndex:0] addressDictionary] objectForKey:@"FormattedAddressLines"]);

    }];



Posted by 삼스