「スパイ」-VK Mobile Challengeのアイデアから実際の製品への道

3か月のドライブと残業。 神経緊張は時々屋根を通りましたが、楽観主義は尽きませんでした。 私たちは困難なタスクを設定し、非標準的な方法でそれらを解決しようとしました。 そしてそれをやった。









私の名前はアレクセイです。Android、iOS、およびWindows Phoneプラットフォーム向けのモバイルアプリケーション開発のためのVKコンテストでの経験をお話しします。 私の記事は初心者が自分の強みをひたすら評価し、何が待っているかを知るのに役立つと思います。



競争条件は、もし興味があれば、 ここにあり、私たちの製品に関するいくつかの言葉があります。 私たちは「Spied on-あなたの手のひらの都市」というプロジェクトでコンテストに参加することにしました。 さまざまな都市で約50のポッドキャストがありましたが、すべての都市のニュースを1か所にまとめたものを作成したかったのです。 そして、私たちは仕事に取り掛かりました。 （Vkontakteから集約された）都市のすべてのイベントとニュースに各ユーザーが最大限にアクセスできる機能的なモバイルアプリケーションを作成する必要がありました。



「覗き見」アプリケーションの成功の主な指標として、ユーザーの反応（保持）と、製品がアプリケーションを使用する人々の新しい習慣を形成するかどうかを理解しました。



現時点では：

• 30％で1日間保持（それほど多くはなく、50％が良い習慣）
• 保持3日-18％
• 保持7日-15％

もちろん、もっと印象的な数字が欲しいのですが、わずか4か月前のアプリケーションの場合、これらは非常に良い結果です。

プロジェクトを「見た」3ヶ月の間に、当然ながら、さまざまな困難が生じました。 当社の開発者は、問題解決の経験をあなたと共有します。

iOS開発者からのケース

「Peeked」の作業にはかなりの困難がありました。 ここにそれらの1つがあります。 私の仕事は、スクロールによって切り替えることができるカテゴリにコンテンツを垂直にスクロールすることでした。 スワイプではなく、スクロールで。 最初は、UIPageViewControllerを使用することが決定されました。 私の内なる本能は私を失望させませんでした。しばらくすると、水平にスクロールするときにハングしました。 セルがコンテンツを持つUIScrollViewであるUICollectionViewでやり直す必要がありました。 したがって、カテゴリ間のスムーズな切り替えを達成しましたが、垂直スクロールには生命の兆候はありませんでした。 ジェスチャが階層を通過するように、タッチの処理を書き直す必要がありました。

- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event { if (!_isHorizontalScroll && !_isMultitouch) { CGPoint point = [[touches anyObject] locationInView:self]; if (fabs(_originalPoint.x - point.x) > kThresholdX && fabs(_originalPoint.y - point.y) < kThresholdY) { _isHorizontalScroll = YES; [_currentChild touchesCancelled:[event touchesForView:self] withEvent:event]; } } if (_isHorizontalScroll){ [super touchesMoved:touches withEvent:event]; }else{ [_currentChild touchesMoved:touches withEvent:event]; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Androidデベロッパーからのケース

アプリケーションのアーキテクチャを選択するとき、Clean Architecture（https://github.com/android10/Android-CleanArchitecture）に決めました。 このアーキテクチャは、Bob Martinが策定した原則に基づいて構築されています。 アーキテクチャ自体とそれを使用することで得られる利点を説明する意味はありません。このトピックについては多くの優れた記事が書かれています（たとえば、 「Androidアプリケーションのアーキテクチャ...正しい方法？」 、「 クリーンアーキテクチャ 」）。さらに、それらに精通することをお勧めします。 アプリケーションの開発中に発生した問題に直行します。



「覗かれている-あなたの手のひらの都市」は、特定の都市に関する関連情報を表示するための一種のプラットフォームです。 多数の都市での手動検索からユーザーを救うために、ユーザーの現在の場所を特定する必要があります。 最初は昔ながらの方法で作業しました。システムLocationManagerを使用し、そこからプロバイダーのリストを取得し、そこから特定の場所を取得しました。 問題を解決する標準的な方法は、誰もがそれに慣れていると思います。 すべてが完璧に機能しました。 しかし、いくつかの問題がありました。



1. Android API> = 23では、ランタイムパーモションが導入されました。 つまり、Android 6.0を搭載したデバイスでは、実行時にいくつかの権限を要求する必要があります。この場合、座標を決定する必要があります。 最初の画面で、現在の場所をすぐに特定します。 このようなリクエストは一部のユーザーを脅かす可能性があると考えました。



2. LocationManagerはプレゼンテーション層にありましたが、これはClean Architectureで規定されている原則とはまったく逆です。



最初の問題を解決するために、Yandexのサービス（Latitude（https://tech.yandex.ru/locator/））に頼りました。 このサービスを使用すると、GPSを使用せずに、最も近いWi-Fiアクセスポイントとモバイルセルによって現在地を特定できます。 したがって、迷惑な対話を取り除きます。 しかし、このサービスはさまざまな理由で、常に正しい結果をもたらすとは限りません。 サービス自体のWebサイトには次のように書かれています。



>場合によっては、Yandex.Locatorは100,000メートルの精度を報告します。これは、場所を確実に特定することができなかったことを意味します。 これは、モバイルデバイスのIPアドレスではなく、パブリックサーバーまたはプロキシサーバーのIPアドレスによって場所が決定される場合に発生します。



この場合、得られた結果に頼ることはできません。 LocationManagerに戻る必要があることがわかりました。 したがって、アルゴリズムは次のようになります。Yandexロケーターにリクエストを送信しました。何も返されなかった場合、または特定の場所の精度が100000メートル以上の場合、システムLocationManagerにリクエストします。



次に、2番目の問題の解決に進みます。アプリケーション内のデータの管理を担当するため、データレイヤーに送信される現在の座標を担当します。



しかし、最初に、ドメイン層に行きましょう。 LocationServiceインターフェースを作成しました：

 public interface LocationService { Observable<LocationEntity> getCurrentLocation(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ユースケースでそれを使用しました：

 public class GetCurrentLocationUseCase extends UseCase<LocationEntity> { public static final String CASE_NAME = "get_current_location"; private final LocationService mLocationService; @Inject public GetCurrentLocationUseCase(LocationService locationService, ThreadExecutor threadExecutor, PostExecutionThread postExecutionThread) { super(threadExecutor, postExecutionThread); mLocationService = locationService; } @Override protected Observable<LocationEntity> buildUseCaseObservable() { return mLocationService.getCurrentLocation(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、このUseCaseは、Dagger2を使用してPresenterに簡単に「注入」でき、サービスの特定の実装から抽象化できます。

 public class YandexLocationService implements LocationService, Constants { public static final int MAX_PRECISION = 100000; private final YandexLocatorService mYandexLocatorService; @Inject public YandexLocationService() { RestAdapter restAdapter = new RestAdapter.Builder() .setEndpoint(BASE_URL_LOCATOR) .setLogLevel(RETROFIT_LOG_LEVEL) .build(); mYandexLocatorService = restAdapter.create(YandexLocatorService.class); } @Override public Observable<LocationEntity> getCurrentLocation() { return getCurrentLocationByIp() .timeout(DEFAULT_TIMEOUT, TimeUnit.SECONDS) .filter(yandexLocation -> yandexLocation.getPrecision() < MAX_PRECISION) .map(LocationTransformer::transformToLocationEntity); } public Observable<YandexLocation> getCurrentLocationByIp() { return mYandexLocatorService.getLocation(getLocatorRequestObject()); } public YandexRequest getLocatorRequestObject() { return new YandexRequest(new Common(LOCATOR_VERSION, LOCATOR_API_KEY)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、座標はIPアドレスによってのみ決定されます。 ここでは、座標を精度の低い（> = 100000）でフィルター処理し、結果のYandexLocationエンティティをLocationEntityに変換します。 次に、座標を決定するためのシステムサービスに進みます。 彼はランタイムパーミッションを使用するため、パーミッションを要求する必要があるため、彼にとってはもう少し複雑です。 インターフェースを作成しました：

 public interface PermissionsRequester { Observable<Boolean> request(String... permissions); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RxPermissionsライブラリを使用して、プレゼンテーションレイヤーにこのインターフェイスを実装します。

 public class PermissionsRequesterImpl implements PermissionsRequester { private final RxPermissions mRxPermissions; public PermissionsRequesterImpl(Context context) { mRxPermissions = RxPermissions.getInstance(context); } @Override public Observable<Boolean> request(String... permissions) { return mRxPermissions.request(permissions); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、このインターフェイスを簡単に使用できます。

 public class SystemLocationService implements LocationService { private final LocationManager mLocationManager; private final PermissionsRequester mPermissionsRequester; @Inject public SystemLocationService(LocationManager locationManager, PermissionsRequester permissionsRequester) { mLocationManager = locationManager; mPermissionsRequester = permissionsRequester; } @Override public Observable<LocationEntity> getCurrentLocation() { return getCurrentGpsLocation() .map(LocationTransformer::transformToLocationEntity); } public Observable<Location> getCurrentGpsLocation() { return mPermissionsRequester .request(Manifest.permission.ACCESS_COARSE_LOCATION, Manifest.permission.ACCESS_FINE_LOCATION) .flatMap(granted -> granted ? findLastLocation() : Observable.error(new RuntimeException())); } private Observable<Location> findLastLocation() { return Observable.create(new Observable.OnSubscribe<Location>() { @Override public void call(Subscriber<? super Location> subscriber) { Location lastLocation = null; List<String> providers = mLocationManager.getAllProviders(); if (providers != null && !providers.isEmpty()) { for (String provider : providers) { if (mLocationManager.isProviderEnabled(provider)) { Location auxLocation = mLocationManager.getLastKnownLocation(provider); if (auxLocation != null) { if (lastLocation == null) { lastLocation = auxLocation; } else if (auxLocation.getTime() > lastLocation.getTime()) { lastLocation = auxLocation; } } } } } subscriber.onNext(lastLocation); subscriber.onCompleted(); } }); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そこで、2つのサービスを作成しました。 ただし、両方を使用する必要があります。 この問題を解決するには？ CompositeLocationServiceを作成しました。これは、LocationServiceインターフェイスのいくつかの実装を受け取り、特定の場所を受け取るまでそれぞれを開始します。

 public class CompositeLocationService implements LocationService { public static final int DEFAULT_TIMEOUT = 30; private final LocationService[] mLocationServices; @Inject public CompositeLocationService(LocationService... services) { if (services == null || services.length == 0) { throw new CompositeLocationEmptyException(); } mLocationServices = services; } @Override public Observable<LocationEntity> getCurrentLocation() { return Observable.concat( Observable.from(mLocationServices) .map(locationService -> locationService .getCurrentLocation() .onErrorReturn(throwable -> null) .timeout(DEFAULT_TIMEOUT, TimeUnit.SECONDS, Observable.empty()) ) ) .first(location -> location != null); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

getCurrentLocationメソッドでは、サービスを次々に調べ、ゼロ以外の結果が得られた場合、残りのサービスを無視してそれを発行します。 したがって、無制限の数のサービスを使用できます。 次に、プレゼンテーションレイヤーで、Dagger2を使用してLocationModuleモジュールでこれらのクラスを結合します。

 @Module public class LocationModule { final PubApplication mPubApplication; public LocationModule(PubApplication pubApplication) { mPubApplication = pubApplication; } @Provides @Singleton Context providesApplicationContext() { return mPubApplication; } @Provides @Singleton LocationManager providesLocationManager() { return (LocationManager) mPubApplication.getSystemService(Context.LOCATION_SERVICE); } @Provides @Singleton PermissionsRequester providesRxPermissions(Context context) { return new PermissionsRequesterImpl(context); } @Provides @Singleton YandexLocationService provideYandexLocationService() { return new YandexLocationService(); } @Provides @Singleton SystemLocationService provideSystemLocationService(LocationManager locationManager, PermissionsRequester permissionsRequester) { return new SystemLocationService(locationManager, permissionsRequester); } @Provides @Singleton LocationService provideLocationService(YandexLocationService yandexLocationService, SystemLocationService systemLocationService) { return new CompositeLocationService(yandexLocationService, systemLocationService); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべて準備完了です！ これで、プレゼンターでGetCurrentLocationUseCaseを安全に使用できます。 したがって、部分的にではありますが、場所に関するいくつかの問題は解決されています。 ロケーションリクエストダイアログはそれほど頻繁に表示されないため、怖がってしまうユーザーは少なくなります。 また、アーキテクチャの観点から見ると、すべてがより良くなり、プレゼンテーション層は情報のデータを表示する責任があります。 この例は理想的ではありませんが、「クリーンアーキテクチャ」のコンテキストでこれらの問題を解決する一般的な原理を理解できると思います。

技術概要

わかりやすくするために、ここで使用したテクノロジの説明をいくつか示します。 サーバー部分は、1コア/ 1Gb RAMの構成を持つ2つのDigitalOceanサーバーにあります。



バックエンドはYii2フレームワークを使用してPHP7で記述されています。



1サーバー-db-master、VKontakteとの同期スクリプト。

2サーバー-db-slave、REST API、Webクライアント。

Webクライアントは、AngularJS v1.5.2フレームワークを使用して記述されています。

ジオロケーションは、YandexのGeolocatorサービスを使用して決定されます。



そして最後に、いくつかの統計。 現在、システムには約3200のグループ（パブリック）があり、Vkontakteとの同期はいくつかのストリームで実行されます。 現在のサーバー構成では、すべてのグループを更新するためのキューは平均6分です。 過去1か月で、約200万の新しい投稿がダウンロードされました。 投稿のデータを更新するのは、グループ内で最後に1か月以上、最後に100を超えないという条件のみです



はい、私たちは約130のプロジェクトの中で、「覗き見」が2つのプラットフォームで提供される数少ないプロジェクトの1つであることを誇りに思っています。



コンテストに参加したおかげで、私たちの強みをテストし、プロジェクトをより客観的に見ることができました。 彼らは信じられないほどの興奮とドライブを経験し、1つのアイデアでチームをさらに結集させました。