Три месяца драйва и сверхурочной работы. Нервное напряжение порой зашкаливало, но оптимизм не иссякал. Мы ставили перед собой непростые задачи и пытались их решить нестандартным способом. И у нас получилось.




Меня зовут Алексей, я расскажу вам о нашем опыте участия в конкурсе ВК по разработке мобильных приложений для платформ Android, iOS и Windows Phone. Думаю, моя статья поможет новичкам трезво оценивать свои силы и знать, что их ожидает.

Условия конкурса, если интересно, здесь, и пара слов о нашем продукте. На конкурс мы решили выйти с проектом «Подсмотрено – город на ладони». У нас было около 50 пабликов «Подсмотрено» в разных городах, но нам хотелось создать что-то, объединяющее все городские новости в одном месте. И мы принялись за работу. Нужно было сделать функциональное мобильное приложение, в котором все события и новости города (агрегирующиеся из Вконтакте) были бы максимально доступны каждому пользователю.

За основной показатель успеха приложения «Подсмотрено» мы взяли реакцию пользователей (Retention) и понимание того, будет ли продукт формировать новую привычку людей пользоваться приложением.

На данный момент:

• Retention 1 дня на уровне 30% (не много, хорошая практика 50%),
• Retention 3 дня – 18%
• Retention 7 дня – 15%

Конечно, хочется более впечатляющих цифр, но для приложения, которому всего 4 месяца, это вполне хорошие результаты.
За эти три месяца, что мы «пилили» проект, естественно, возникали разные сложности. Наши разработчики поделятся с вами полученным опытом решения проблем.

Кейс от iOS разработчика

«Сложностей в работе над «Подсмотрено» возникало достаточно. Вот одна из них. Передо мной была поставлена задача засунуть вертикально скролящийся контент в категории, которые можно переключать скроллом. Не свайпом, а именно скроллом. Сначала было решено использовать UIPageViewController. Внутреннее чутье меня не подвело, через некоторое время появились подвисания при горизонтальной прокрутке. Пришлось переделать на UICollectionView, ячейками которой являются UIScrollView с контентом. Таким образом я добился плавного переключения между категориями, но вертикальный скролл не подавал признаков жизни. Пришлось переписать обработку касаний, чтобы жесты передавались дальше по иерархии.

- (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). Данная архитектура построена на принципах, сформулированных Бобом Мартином. Нет смысла описывать саму архитектуру и преимущества, получаемые при её использовании, на эту тему написано много отличный статей (например: «Архитектура Android-приложений… Правильный путь?», и "Чистая архитектура"), но для понимания того, о чем пойдет речь далее, советую ознакомиться с ними. Сразу перейду к проблеме, возникшей при разработке нашего приложения.

“Подсмотрено — город на ладони” — своего рода площадка для просмотра актуальной информации о конкретном городе. Для того чтобы избавить пользователей от ручного поиска по большому списку городов, нам необходимо определять текущее местоположение пользователя. Сначала я работал по старинке: использовал системный LocationManager, из него получал список провайдеров, а из них определённую локацию. Стандартный способ решения проблемы, думаю, каждый знаком с ним. Всё работало отлично. Но было несколько проблем.

1. В Android API >=23 ввели Runtime Permossions. Это значит, что на девайсах с Android 6.0 нужно в рантайме запрашивать некоторые разрешения, в нашем случае на определение координат. У нас определение текущей локации производится сразу — на первом экране. Мы посчитали, что такой запрос может отпугнуть часть пользователей.

2. LocationManager лежал в слое presentation, что очень сильно противоречит принципам, заложенным в Clean Architecture.

Для решения первой проблемы я прибегнул к сервису от Яндекса: Локатор (https://tech.yandex.ru/locator/). С помощью данного сервиса можно определить текущее местоположение по ближайшим точкам доступа Wi-Fi и мобильным сотам, без использования GPS. Таким образом, мы избавимся от назойливого диалога. Но данный сервис, по различным причинам не всегда выдаёт правильный результат. На сайте самого сервиса написано:

> В некоторых случаях Яндекс.Локатор сообщает о точности 100000 метров, которая означает, что достоверно определить местоположение не удалось. Это происходит, если местоположение определяется не по IP-адресу мобильного устройства, а по IP-адресу какого-либо публичного сервера или прокси-сервера.

В этом случае полагаться на полученный результат мы не можем. Выходит, нам необходимо вернуться обратно к LocationManager. Таким образом алгоритм следующий: Сделали запрос к Яндекс локатору, если он ничего не вернул, либо у точность определённой локации >= 100000 метров, запрашиваем у системного LocationManagerа.

Перейду к решению второй проблемы: вынесем ответственность за выдачу текущей координаты в слой data, так как он отвечает за управление данными в приложении.

Но сначала перейдём в слой domain. Я создал интерфейс LocationService:

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

И использовал его в UseCase:

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 можно легко «заинъектить» в Presenter, с помощью Dagger2, таким образом абстрагироваться от конкретной реализации сервиса.

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. Далее перейдём к системному сервису определения координат. Для него немного сложнее, так как он использует Runtime Permissions, а, следовательно, должен запрашивать разрешения. Я сделал интерфейс:

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

Реализовывать этот интерфейс будем в слое presentation с помощью библиотеки 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 мы последовательно опрашиваем сервисы друг за другом, и если получен ненулевой результат выдаём его, игнорируя оставшиеся сервисы. Таким образом, мы можем использовать неограниченное количество сервисов. Далее, в слое presentation, объединим данные классы в модуле LocationModule, с помощью Dagger2:

@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 в нашем презентере. Таким образом, пусть и частично, но некоторые проблемы с определением местоположения решены. Диалог с запросом местоположения будет появляться намного реже, и, следовательно, отпугнёт намного меньше пользователей. И с точки зрения архитектуры теперь всё намного лучше, слой presentation отвечает за отображение, data за информацию. Данный пример не идеален, но, думаю, позволяет понять общий принцип решения данных проблем в контексте «чистой архитектуры».

Кратко о технологиях

Чтобы было понятнее, вот еще несколько пояснений, какие технологии мы использовали. Серверная часть расположена на двух серверах DigitalOcean с конфигурацией 1 core/1Gb RAM.

Бэкенд написан на PHP7 c использованием фреймворка Yii2.

1 сервер — db-master, скрипт синхронизации с вконтакте.
2 сервер — db-slave, rest api, web клиент.
Web клиент написан с использованием фреймворка AngularJS v1.5.2.
Геолокация определяется при помощи сервиса Geolocator от Yandex.

И под конец немного статистики. На данный момент в системе около 3200 групп (пабликов), синхронизация с Вконтакте осуществляется в несколько потоков. При текущей конфигурации сервера, очередь на обновление всех групп в среднем составляет 6 минут. За последний месяц было загружено около 2 млн новых постов. Обновляем данные постов только при условии, что они не старше 1 месяца и не более 100 последних в группе

И да, мы гордимся тем, что среди почти 130 проектов наш «Подсмотрено» — один из немногих, представленных на 2 платформах.

Благодаря участию в конкурсе мы смогли проверить свои силы и более объективно взглянуть на свой проект. Испытали невероятный азарт и драйв и еще сильнее сплотили команду одной идеей.