• Предустановка отечественного ПО или кто теперь следит за нами?
    +6
    Привет. Судя по всему детектирование трекеров на этом сайте работает довольно поверхностно. Например, видно, что 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 МБ. Лекция Яндекса
    +1
    Да, гугл не дает расслабиться :)
    Но в первую очередь хочется, чтобы это был напоминание разработчикам, что с ростом технологий не все девайсы превращаются во второй пиксель, и всегда надо думать о производительности на слабых устройствах.
    Но вообще да, это безусловно новая фрагментация, которая заставляет думать о том, что с ней делать. К счастью, время на эти раздумья еще много.
  • Android Go — будущий миллиард устройств и лимит в 50 МБ. Лекция Яндекса
    0
    Android Go явно не займет большой % рынка в ближайшем будущем и слишком большой когда-либо. Так что переживут :)
    Или выпустят какой-нибудь Flutter Go, хотя это будет сильно непросто, если он не будет встроен прямо в фреймворк.
  • Android Go — будущий миллиард устройств и лимит в 50 МБ. Лекция Яндекса
    0
    Очень правильные слова. Поэтому мы и тратим определенные силы на то, чтобы пользователь видел наше приложение и на Android Go. Но для полноценного хорошего экспериенса нужно все же отдельное приложение.
    Отдельное приложение требует много времени на разработку, тестирование и поддержку. Пока нет гарантии, что Android Go займет хотя бы 5% рынка, бизнес не пойдет на это. Ведь эти же ресурсы можно пустить на проекты, которые могут с большей вероятностью принести лояльных пользователей :)
  • Android Go — будущий миллиард устройств и лимит в 50 МБ. Лекция Яндекса
    0
    Я не увидел проблемы в таком ограничении.

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

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

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

    Рекламно-трекинговые библиотеки занимают совсем мало, поверьте. Да и в принципе никаких таких особых библиотек нет. AppMetrica да Ads SDK.
  • Android Go — будущий миллиард устройств и лимит в 50 МБ. Лекция Яндекса
    +3
    Реальные. Если делать новое приложение, как и делает гугл.
    Засунуть огромное приложение, которое вообще не задумывалось под такую специфику, — это да, весело :)

    Но как я сказал, это веселье все равно дешевле, чем поддержка второго приложения. А пока Android Go не распространится широко, поддержка второго приложения может не оправдаться, так что ждем.
  • Итоги Школы и все материалы по архитектуре клиент-серверных приложений
    0
    Нет, к сожалению, мы столкнулись с некими техническими затруднениями :)
  • Итоги Школы и все материалы по архитектуре клиент-серверных приложений
    +1
    Повторения конкретного этого курса не планируется. Но группы GDG других городов, насколько я знаю, собирались устроить школы по Android. Информацию о других группах GDG вы можете найти по ссылке.
  • Итоги отбора в школу Android-разработчиков в Казани
    0
    Это не сексизм :)
    Тестовое задание отправили в общем 5 девушек, из них две прошли, одна отказалась в связи с тем, что не может приехать на такой срок в другой город (справедливости ради надо сказать и ее имя — Светлана Шишкина).

    P.S. Честно говоря, сам замечал такую тенденцию, что Android не пользуется популярностью среди представительниц прекрасного пола :)
  • Бесплатная школа для Android-разработчиков в Казани
    0
    e-Legion регулярно проводит такие школы в Санкт-Петербурге, в других городах конкретных планов у нас пока нет. Но в некоторых городах GDG сообщества собирались проводить такие школы. Советую найти GDG (Google Developers Group) сообщество в вашем городе и следить за новостями.
  • Бесплатная школа для Android-разработчиков в Казани
    0
    Мы учли все пожелания и предыдущий опыт, поэтому все будет примерно так, как вы говорите :)
    Программа курса идет последовательно, шаг за шагом рассматривая все актуальные вопросы архитектуры и построения приложений. Точно также мы будем создавать приложение и постепенно улучшать его, добавляя новые паттерны, тесты и прочее. Единственное — мы не рассматриваем UI-часть приложения (вьюшки, анимации, принципы Material Design и прочее) — это уже придется самому добивать :)
    Школа идет не с азов, так как идея провести такую школу появилась после StudyJams, который мы ранее провели в Казани, где нас просили провести что-то похожее, но на более высоком уровне.
  • Бесплатная школа для Android-разработчиков в Казани
    0
    Знание и умение использовать базовые классы Android: активити, фрагменты, вьюшки, бд + серверные запросы. Все, что отражено в тестовом задании по сути. Можно считать, что нам минимальные требования — это человек, достаточно активно изучающий разработку под Android 2-4 месяца.
  • Бесплатная школа для Android-разработчиков в Казани
    0
    Обучение только офлайн, но мы подумаем о возможности записи лекций. Каждое занятие рассчитано примерно на 40 минут теории и 80 минут практики. Теория будет на лекциях в виде презентаций, возможно, мы сделаем и полноценное теоретическое описание и выложим его. Но это пока не обещаю :)
  • Расширяемый код Android-приложений с MVP
    0
    Презентер всегда должен резолвить интерфейс, иначе это не MVP. Без интерфейса невозможно мокировать для тестов.

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

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

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

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

    А как называть, если паттерн Model-View-Presenter?
  • Построение Android приложений шаг за шагом, часть первая
    +3
    Спасибо, очень хорошая статья, достаточно детально описано. Конечно, проблема MVP в том, что каждый понимает его по-своему (есть куча реализаций этого паттерна), предложенная схема в принципе одна из самых распространненых. Надеюсь, что вторая часть (особенно про тестирование будет также интересна).

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

    P.S. Есть канал по паттернам, где 90% обсуждений посвящено MVP, можно присоединяться :)
  • Что нам стоит полином Жегалкина построить…
    +2
    А еще главное, что для многих функций это единственное представление имеет сложность O(2^n), в отличии, например, от BDD. Собственно, алгоритм в статье для построения имеет такую же сложность, что ограничивает его применение контрольными для студентов.
  • Intro to RxJava
    –1
    Спасибо, действительно, стоило на этом подзадержаться. Обязательно передам ваши ссылки :)
  • Android архитектура клиент-серверного приложения
    0
    Вот запрос.
    @GET("/places/coords_to_places_ru.json")
    Call<List<Airport>> airports(@Query("coords") String gps);
    

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

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

    Схема с Rx примерно такая (могу немного ошибаться, так как с Rx-проектами не работал особо) — получаем Observable, потом в flatMap сохраняем данные (или повторяем запрос, если ошибка) и прокидываем Observable в UI.
  • Android архитектура клиент-серверного приложения
    0
    Я последний раз работал с 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)?

    Если рассматривать их отдельно, то никак. А если в контексте разработки приложения, то связь самая прямая. Не очень-то возможно работать с сетью без асинхронности / многопоточности.
  • Android архитектура клиент-серверного приложения
    0
    Мы вообще переходим на такой подход, что в БД храним чистый json, который приходит с сервера (то есть один столбец строковый в бд), а при создании объекта получаем эту строку и через Gson конвертируем. Получается вот такая немного странная сериализация. Намного удобнее, на самом деле. В этом случае нельзя сказать, что БД нам для чего-то необходима.

    P.S. Упс, не совсем в ту ветку добавил коммент)
  • Android архитектура клиент-серверного приложения
    0
    В общем, да, я с вами согласен. БДшки на самом деле потихоньку могут становится архаизмом в данных случаях, учитывая постоянно растущую мощность устройств, сейчас уже не страшно хранить все в памяти или в кэше.
    Из плюсов все-таки можно считать, что бд обеспечивает большую стабильность.
  • Android архитектура клиент-серверного приложения
    +1
    Честно скажу, что не работал с кэшированием в http, так что дальше могу ошибаться. Насколько я понимаю, кэширование тоже выполняется локально в файлах или как-то еще. Скорость, конечно, повыше чем из бд, но не настолько, чтобы это было явным преимуществом. Но если мы говорим о структурированных данных разного типа из разных запросов, то без бд тут не обойтись. Да и когда у нас в приложении 50 разных запросов, использовать кэш для всех тоже вряд ли разумно. Кроме того, может случиться так, что кэш очистится (если закрыл приложение и не использовал его какое-то время), запустил приложение, а сервер лежит. С бд не попадем в такую ситуацию.
    Впрочем да, я с вам согласен частично, в каких-то приложениях достаточно будет такого кэширование, но все же такая архитектура менее расширяема, и при росте приложения ее будет сложно поддерживать.
  • Android архитектура клиент-серверного приложения
    +1
    Я склонен считать, что всегда есть смысл хранить данные локально. Что будет, если у вас сервер вдруг отвалится? Никакое кэширование в HTTP уже не поможет. И приложение несколько даже не будет открываться.
    Все равно не понимаю вашу нелюбовь к локальной базе :) Занимает не так много места, а дает возможность постоянно быстро получать данные из разных мест без всяких запросов и прочем. Не вижу недостатков в таком подходе, а преимущества, как мне кажется, очевидны.
  • Android архитектура клиент-серверного приложения
    +1
    Не знаю, правильно ли вас понял, но пример для б) я приводил в самом начале, с запросом в Activity. Там запрос выполнится, но при преждевременной смерти Activity, результат просто потеряется.
    По сути база данных нужна для нескольких кейсов:
    1) Даже если мы всегда ходим за данными на бэкенд, то все равно в один прекрасный момент интернет может пропасть, и нам придется работать локально.
    2) Мы работаем с какой-то сложной структурой данных, и нужно использовать данные от предыдущих запросов (даже из апи примера в статье, получили список аэропортов, потом нужно получить список популярных направлений с учетом этих аэропортов [может, бред говорю, не изучал это апи]. Как их хранить? Напрямую в памяти как-то не очень хорошо. Кэширование запроса тоже не подходит. Вот и используем БД.)
  • Android архитектура клиент-серверного приложения
    0
    У нас в легионе внутренняя библиотека для SQLite, которая этот ад сильно уменьшает. Ну и иногда используем Realm, недавно начали.
  • Android архитектура клиент-серверного приложения
    0
    Да, с реалмом вопрос хороший, и в принципе любой bus с этим может справиться, хотя они не добавляют плюсов к карме в архитектуру. Обычно в сочетании с Realm мы используем Rx, и уже соответственно, средства Rx для таких оповещений.
    Я не то чтобы сильный фанат реалма на самом деле, его использовал лишь для примера, что можно легко перейти к другой БД.
    Хорошо, я всерьез подумаю о том, чтобы в ближайший месяц максимально разобраться с Rx и что-то такое написать :) Хотя не исключено, что это сделает еще кто-нибудь :)
  • Android архитектура клиент-серверного приложения
    +1
    В лоадере мы только загружаем и сохраняем данные. Если они нам требуются дальше, то, разумеется, мы не ходим каждый раз на сервер, а берем из базы. Например, мы можем на сплеше один раз загрузить все данные в лоадерах и сохранить их в базу (при этом можно вообще всегда возвращать null — это будет лишь означать то, что загрузка данного лоадера завершена, и можно загружать следующий — при последовательных запросах), а после работать только локально.
    Если кратко — то лоадеры отдают нам данные один раз и долго, а из базы мы можем их вытащить всегда и сразу.
  • Android архитектура клиент-серверного приложения
    +1
    Я допускаю, что и об архитектуре с Rx могу написать, но не обещаю :)
    Но на самом деле, мы в легионе используем для Rx похожую модель. Такое же использование лоадеров, чтобы система заботилась + всякие фишки и операторы от Rx, довольно неплохо получается. Вот только мне она не очень нравится (сильно больше классов выходит), а ничего получше я пока не придумал. Вот если появятся хорошие идеи, то можно и статью написать.
  • Библиотека Fresco от Facebook
    +1
    Тема особо не раскрыта, точнее, не раскрыта совсем. У них хорошая документация, можно было бы и добавить что-то в статью. А вообще, это библиотека очень мощная, как и всегда у фейсбука) Но при этом такая мощь бывает нужна нечасто, подавляющему большинство проектов с лихвой хватит Picasso / Glide / UIL.
  • Kotlin для Android
    0
    Да, есть такой момент. Впрочем, все это может быть переработано еще)
    Насчет переиспользования есть кое-что — сам не пробовал, но похоже. Это с xml, а с DSL — создаем функции, которые будут возвращать часть UI (например, поле ввода с кнопкой) один раз и используем везде.
  • Kotlin для Android
    0
    Хорошие вопросы)
    Во-первых, замечу еще такую вещь, что при открытии файла xml разметки во вкладке Code есть возможность конвертации в Koan DSL. Однако работает пока далеко не очень)

    Теперь по вопросам:
    1) Насколько я знаю, стили, описанные в xml, использовать нельзя. Это в принципе логично, все пишем в DSL (однако с dimen такое не катит, под разные размеры экрана придется в xml писать).
    В общем, можно это делать с помощью функции style. Если стили где-то храним, то делаем примерно такое:
    private fun editTextStyle(editText: EditText) {
        editText.textSize = 18f
        editText.textColor = Color.RED
    }
    
    //=>
    
    relativeLayout {
        editText {
            style { editTextStyle(this) }
        }.layoutParams { centerInParent(); }
    }
    


    2) Custom view — легко, нужно просто знать. Пишем такую функцию (допустим, класс называется MyView):
    fun ViewManager.myView(init: MyView.() -> Unit = {}) =
            __dslAddView({ MyView(it) }, init, this)
    

    И можем спокойно использовать:
    relativeLayout {
        myView {
            //...
        }
    }
    


    3) Еще проще:
    val size = dip(getResources().getDimension(R.dimen.my_dimen))
    


    4) Тоже достаточно просто, создаем две разметки и в рантайме проверяем, какая ориентация:
    private fun portrait() {
        linearLayout {
        }
    }
        
    private fun landscape() {
        relativeLayout {
        }
    }
    
    //=>
    
    if (getResources().getConfiguration().orientation == Configuration.ORIENTATION_LANDSCAPE) {
        landscape()
    }
    else {
        portrait()
    }
    
  • Kotlin для Android
    0
    Опять-таки дело не в этом. Я не зря привел такой пример:
    private var mHelloWorldTextView : TextView = //???
    

    Переменную mHelloWorldTextView нужно чем-то инициализировать. А в данном случае (без Delegates) можно инициализировать только null. Тогда тип mHelloWorldTextView уже будет не TextView, а TextView?, что не хочется.
    Пример предназначен только для этого.

    Впрочем, Kotlin Android Extensions решает все проблемы.
  • Kotlin для Android
    0
    Да, это очень сильная вещь, я забыл упомянуть о ней.
  • Kotlin для Android
    0
    Вы не совсем правильно поняли. Конструкция
    by Delegates.notNull()
    нужна чтобы поле mHelloWorldTextView имело тип TextView, а не TextView?, чтобы не было всяких операторов типа "?." и "!!.".

    Для справки (на всякий случай) — объект типа TextView не может принимать значение null. Для null есть типы с "?" в конце — TextView?.. Это во всем котлине. Если объект имеет тип "?", то к его полям нельзя обращаться непосредственно через "." — код просто не скомпилируется. Для этого есть операторы "?." и "!!." (сложно представить, как можно было додуматься до такого оператора:))
  • Wyvern: новый универсальный язык программирования, спонсируемый АНБ
    +4
    Судя по примерам с гита, просто поменяли синтаксис java.
  • Проект dot42 переходит на новый формат (C# 2 Java)
    +1
    Насколько я понял, просто убрана конвертация байт-кода в dex. Поэтому я и спросил — если бы они выполняли компиляцию C# кода сразу в dex, то было бы неприятно.
  • Проект dot42 переходит на новый формат (C# 2 Java)
    +3
    Учитывая то, что dalvik теперь остается только для поддержки совместимости, возникает вопрос: актуальна ли статья?
  • Стартап шаг за шагом: будущее онлайн-образования
    0
    Полностью согласен.
    Обучение в стиле игры может быть полезно детям, которые просто не могут сконцентрироваться на серьезных вещах долго, но даже их нельзя слишком сильно приучать к этому. Хотя, возможно, жизнь меняется
    Лучше всего не учиться и играть, а учиться и думать, каждый раз искать, где можно использовать тот или иной факт, в общем практика. Тогда и скучно не будет, и пользы больше.
  • 10 главных выводов, которые я сделал за Год Изучения Продуктивности
    –1
    Больно уж бессвязная статья. И рекомендации странные:
    Например, в вашей работе скорее всего есть всего несколько задач, которые приносят 80-90% пользы

    А кто будет остальные 10-20% делать?

    Все эти блестящие рекомендации и наблюдения можно выразить одним предложением: прочитай вот эти 10 советов, придумай что-то сам и выбери, какие тебе подходят.