Pull to refresh
31
Karma
0
Rating
Василов Артур @Arturka

Пользователь

Предустановка отечественного ПО или кто теперь следит за нами?

Привет. Судя по всему детектирование трекеров на этом сайте работает довольно поверхностно. Например, видно, что facebook share sdk детектируется по широкому network rule, а flurry по наличию com.flurry. в прокте.

Мы несколько раз перепроверили приложение Яндекс и Яндекс Браузер по коду и по ./gradlew dependencies. У нас подключены только следующие библиотеки:
AppMetrica
Yandex Ads
Facebook login (для социальной авторизации) / facebook audience network sdk (для улучшения рекламы)

Остальные, которые детектит данный сайт, были найдены по коду, но они не подключены и не используются в приложении Яндекс и Яндекс Браузере. Такое возможно, так как некоторые библиотеки являются адаптерами и ссылаются на другие популярные трекеры и используют их, если они подключены (и не используют, если нет).

Например, facebook ads ссылается на flurry:
com.facebook.ads.internal.adapters.q
  com.flurry.android.ads.FlurryAdNative c

Или вот так:
com.facebook.ads.AdNetwork -> com.facebook.ads.AdNetwork:
    com.facebook.ads.AdNetwork AN -> AN
    com.facebook.ads.AdNetwork ADMOB -> ADMOB
    com.facebook.ads.AdNetwork FLURRY -> FLURRY

Аналогично он же ссылается и на inmobi. Но эти SDK НЕ подключены и НЕ используются.
За другие приложения сказать не могу, но судя по всему и по ним нет оснований полностью доверять.

P.S. Мы всегда против лишних библиотек и особенно трекеров. Если внезапно найдете такие в приложении Яндекс и в Браузере, приходите ко мне — будем рады выпилить. Но мы и сами стремимся поддерживать приложения здоровыми.

Android Go — будущий миллиард устройств и лимит в 50 МБ. Лекция Яндекса

Да, гугл не дает расслабиться :)
Но в первую очередь хочется, чтобы это был напоминание разработчикам, что с ростом технологий не все девайсы превращаются во второй пиксель, и всегда надо думать о производительности на слабых устройствах.
Но вообще да, это безусловно новая фрагментация, которая заставляет думать о том, что с ней делать. К счастью, время на эти раздумья еще много.

Android Go — будущий миллиард устройств и лимит в 50 МБ. Лекция Яндекса

Android Go явно не займет большой % рынка в ближайшем будущем и слишком большой когда-либо. Так что переживут :)
Или выпустят какой-нибудь Flutter Go, хотя это будет сильно непросто, если он не будет встроен прямо в фреймворк.

Android Go — будущий миллиард устройств и лимит в 50 МБ. Лекция Яндекса

Очень правильные слова. Поэтому мы и тратим определенные силы на то, чтобы пользователь видел наше приложение и на Android Go. Но для полноценного хорошего экспериенса нужно все же отдельное приложение.
Отдельное приложение требует много времени на разработку, тестирование и поддержку. Пока нет гарантии, что Android Go займет хотя бы 5% рынка, бизнес не пойдет на это. Ведь эти же ресурсы можно пустить на проекты, которые могут с большей вероятностью принести лояльных пользователей :)

Android Go — будущий миллиард устройств и лимит в 50 МБ. Лекция Яндекса

Я не увидел проблемы в таком ограничении.

Hello World занимает 50% уже сразу. Добавьте пару картинок и развлечение обеспечено :)

В нашем случае это картинки, это Алиса (+ нативная библиотека спичкита), тонна поискового функционала и еще куча различных сервисов. Суммарное количество только нашего Java-кода (без библиотек) — это порядка 500k строк (и да, не рекламно-трекингового). И вот с такими показателями ограничения уже непростые.

Возможно потому что я не использую 40 мб рекламно-трекинговых библиотек, как делает яндекс.

Рекламно-трекинговые библиотеки занимают совсем мало, поверьте. Да и в принципе никаких таких особых библиотек нет. AppMetrica да Ads SDK.

Android Go — будущий миллиард устройств и лимит в 50 МБ. Лекция Яндекса

Реальные. Если делать новое приложение, как и делает гугл.
Засунуть огромное приложение, которое вообще не задумывалось под такую специфику, — это да, весело :)

Но как я сказал, это веселье все равно дешевле, чем поддержка второго приложения. А пока Android Go не распространится широко, поддержка второго приложения может не оправдаться, так что ждем.

Итоги Школы и все материалы по архитектуре клиент-серверных приложений

Нет, к сожалению, мы столкнулись с некими техническими затруднениями :)

Итоги Школы и все материалы по архитектуре клиент-серверных приложений

Повторения конкретного этого курса не планируется. Но группы GDG других городов, насколько я знаю, собирались устроить школы по Android. Информацию о других группах GDG вы можете найти по ссылке.

Итоги отбора в школу Android-разработчиков в Казани

Это не сексизм :)
Тестовое задание отправили в общем 5 девушек, из них две прошли, одна отказалась в связи с тем, что не может приехать на такой срок в другой город (справедливости ради надо сказать и ее имя — Светлана Шишкина).

P.S. Честно говоря, сам замечал такую тенденцию, что Android не пользуется популярностью среди представительниц прекрасного пола :)

Бесплатная школа для Android-разработчиков в Казани

e-Legion регулярно проводит такие школы в Санкт-Петербурге, в других городах конкретных планов у нас пока нет. Но в некоторых городах GDG сообщества собирались проводить такие школы. Советую найти GDG (Google Developers Group) сообщество в вашем городе и следить за новостями.

Бесплатная школа для Android-разработчиков в Казани

Мы учли все пожелания и предыдущий опыт, поэтому все будет примерно так, как вы говорите :)
Программа курса идет последовательно, шаг за шагом рассматривая все актуальные вопросы архитектуры и построения приложений. Точно также мы будем создавать приложение и постепенно улучшать его, добавляя новые паттерны, тесты и прочее. Единственное — мы не рассматриваем UI-часть приложения (вьюшки, анимации, принципы Material Design и прочее) — это уже придется самому добивать :)
Школа идет не с азов, так как идея провести такую школу появилась после StudyJams, который мы ранее провели в Казани, где нас просили провести что-то похожее, но на более высоком уровне.

Бесплатная школа для Android-разработчиков в Казани

Знание и умение использовать базовые классы Android: активити, фрагменты, вьюшки, бд + серверные запросы. Все, что отражено в тестовом задании по сути. Можно считать, что нам минимальные требования — это человек, достаточно активно изучающий разработку под Android 2-4 месяца.

Бесплатная школа для Android-разработчиков в Казани

Обучение только офлайн, но мы подумаем о возможности записи лекций. Каждое занятие рассчитано примерно на 40 минут теории и 80 минут практики. Теория будет на лекциях в виде презентаций, возможно, мы сделаем и полноценное теоретическое описание и выложим его. Но это пока не обещаю :)

Расширяемый код Android-приложений с MVP

Презентер всегда должен резолвить интерфейс, иначе это не MVP. Без интерфейса невозможно мокировать для тестов.

Почему это? Во-первых, презентер редко используется как объект, который необходимо мокать, так как он обычно является простой логической обёрткой без андроидных классов. Ну и если надо мокать презентер, то мокито никто не отменял. Я лично вообще не вижу смысла в интерфейсах для презентера.

что точно не имеет права находиться в UI потоке.

Не такое однозначное мнение. Чтение из БД небольшого объёма данных не окажет значимого влияния на перфоманс. А вот асинктаск как раз проблема более серьезная.

Ну а больше всего меня бесит наличие классов MainView и CounterView. В андроиде под вью понимается UI-йный компонент.

А как называть, если паттерн Model-View-Presenter?

Построение Android приложений шаг за шагом, часть первая

Спасибо, очень хорошая статья, достаточно детально описано. Конечно, проблема MVP в том, что каждый понимает его по-своему (есть куча реализаций этого паттерна), предложенная схема в принципе одна из самых распространненых. Надеюсь, что вторая часть (особенно про тестирование будет также интересна).

Немного замечаний: не совсем понимаю выделение в интерфейс базового презентера — ведь как интерфейс он нигде не используется. Базовый класс презентера — это да, общая функциональность. А вот интерфейс — просто лишний.
И насчет извечной боли — как и утечек избежать, и запрос нормально сделать, тут есть спорные моменты. При вызове onStop у вас подписка отписывается, запрос отменяется. Отсюда следует, что при поворотах и прочем менеджить переподпиской придется самому. Альтернатива — использовать презентер для взаимодействия с лоадерами или с сервисом, но тут свои минусы: в таком случае презентер уже будет знать о классах андроида. Впрочем, тестированию это особо не мешает.

P.S. Есть канал по паттернам, где 90% обсуждений посвящено MVP, можно присоединяться :)

Что нам стоит полином Жегалкина построить…

А еще главное, что для многих функций это единственное представление имеет сложность O(2^n), в отличии, например, от BDD. Собственно, алгоритм в статье для построения имеет такую же сложность, что ограничивает его применение контрольными для студентов.

Intro to RxJava

Спасибо, действительно, стоило на этом подзадержаться. Обязательно передам ваши ссылки :)

Android архитектура клиент-серверного приложения

Вот запрос.
@GET("/places/coords_to_places_ru.json")
Call<List<Airport>> airports(@Query("coords") String gps);

MainActivity — это UI часть.
ApiFactory — общий класс для всех запросов. Больше он не трогается.
Зависимости считать кодом тоже как-то странно.
Можете как-нибудь сравнить это с кодом, который писался раньше плюс ручной парсинг json-а.

Android архитектура клиент-серверного приложения

Например отображать сначала сохраненные данные, проверить необходимость обновления, запустить загрузку новых данных и отобразить.

Такой подход можно использовать независимо от того, что вы используете для получения данных с бэкенда. Здесь важно лишь то, является ли критичным показ актуальных данных, или можно сначала показать старые. У нас общая политика обычно такая — всегда сначала ходим на бэкенд, а уже потом достаем из кэша, в случае ошибки. Обычно стараемся подгружать данные за экран-два до того, как они понадобятся, так что такой подход тоже неплох.

Схема с Rx примерно такая (могу немного ошибаться, так как с Rx-проектами не работал особо) — получаем Observable, потом в flatMap сохраняем данные (или повторяем запрос, если ошибка) и прокидываем Observable в UI.

Android архитектура клиент-серверного приложения

Я последний раз работал с Android API 4.0.2, но бубнов не помю.

AsyncTask-и никак не связаны с жизненным циклом Activity / Fragment. Со всеми вытекающими проблемами при уничтожении Activity / закрытии приложения.
HTTP Apache Client — прекрасная библиотека, используемая в куче Java проектов. В энтерпрайзе полно.

Библиотека отличная, без сомнений. Проблема в том, что в Android SDK включена не сама библиотека как зависимость, а ее самая начальная beta-версия. Сейчас в API 23 те, кто хочет продолжать использовать Apache, уже подключают саму библиотеку.
Разве HttpUrlConnection не часть Java API? (JavaDoc).

Да, здесь я погрешил против истины. В свое оправдание могу сказать, что Google все равно переработал этот класс.
А как связана многопоточность(асинхронность) и работа с сетью (HttpUrlConnection)?

Если рассматривать их отдельно, то никак. А если в контексте разработки приложения, то связь самая прямая. Не очень-то возможно работать с сетью без асинхронности / многопоточности.

Information

Rating
Does not participate
Location
Казань, Татарстан, Россия
Works in
Date of birth
Registered
Activity