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

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

P.S. Упс, не совсем в ту ветку добавил коммент)

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

В общем, да, я с вами согласен. БДшки на самом деле потихоньку могут становится архаизмом в данных случаях, учитывая постоянно растущую мощность устройств, сейчас уже не страшно хранить все в памяти или в кэше.
Из плюсов все-таки можно считать, что бд обеспечивает большую стабильность.

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

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

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

Я склонен считать, что всегда есть смысл хранить данные локально. Что будет, если у вас сервер вдруг отвалится? Никакое кэширование в HTTP уже не поможет. И приложение несколько даже не будет открываться.
Все равно не понимаю вашу нелюбовь к локальной базе :) Занимает не так много места, а дает возможность постоянно быстро получать данные из разных мест без всяких запросов и прочем. Не вижу недостатков в таком подходе, а преимущества, как мне кажется, очевидны.

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

Не знаю, правильно ли вас понял, но пример для б) я приводил в самом начале, с запросом в Activity. Там запрос выполнится, но при преждевременной смерти Activity, результат просто потеряется.
По сути база данных нужна для нескольких кейсов:
1) Даже если мы всегда ходим за данными на бэкенд, то все равно в один прекрасный момент интернет может пропасть, и нам придется работать локально.
2) Мы работаем с какой-то сложной структурой данных, и нужно использовать данные от предыдущих запросов (даже из апи примера в статье, получили список аэропортов, потом нужно получить список популярных направлений с учетом этих аэропортов [может, бред говорю, не изучал это апи]. Как их хранить? Напрямую в памяти как-то не очень хорошо. Кэширование запроса тоже не подходит. Вот и используем БД.)

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

У нас в легионе внутренняя библиотека для SQLite, которая этот ад сильно уменьшает. Ну и иногда используем Realm, недавно начали.

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

Да, с реалмом вопрос хороший, и в принципе любой bus с этим может справиться, хотя они не добавляют плюсов к карме в архитектуру. Обычно в сочетании с Realm мы используем Rx, и уже соответственно, средства Rx для таких оповещений.
Я не то чтобы сильный фанат реалма на самом деле, его использовал лишь для примера, что можно легко перейти к другой БД.
Хорошо, я всерьез подумаю о том, чтобы в ближайший месяц максимально разобраться с Rx и что-то такое написать :) Хотя не исключено, что это сделает еще кто-нибудь :)

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

В лоадере мы только загружаем и сохраняем данные. Если они нам требуются дальше, то, разумеется, мы не ходим каждый раз на сервер, а берем из базы. Например, мы можем на сплеше один раз загрузить все данные в лоадерах и сохранить их в базу (при этом можно вообще всегда возвращать null — это будет лишь означать то, что загрузка данного лоадера завершена, и можно загружать следующий — при последовательных запросах), а после работать только локально.
Если кратко — то лоадеры отдают нам данные один раз и долго, а из базы мы можем их вытащить всегда и сразу.

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

Я допускаю, что и об архитектуре с Rx могу написать, но не обещаю :)
Но на самом деле, мы в легионе используем для Rx похожую модель. Такое же использование лоадеров, чтобы система заботилась + всякие фишки и операторы от Rx, довольно неплохо получается. Вот только мне она не очень нравится (сильно больше классов выходит), а ничего получше я пока не придумал. Вот если появятся хорошие идеи, то можно и статью написать.

Библиотека Fresco от Facebook

Тема особо не раскрыта, точнее, не раскрыта совсем. У них хорошая документация, можно было бы и добавить что-то в статью. А вообще, это библиотека очень мощная, как и всегда у фейсбука) Но при этом такая мощь бывает нужна нечасто, подавляющему большинство проектов с лихвой хватит Picasso / Glide / UIL.

Kotlin для Android

Да, есть такой момент. Впрочем, все это может быть переработано еще)
Насчет переиспользования есть кое-что — сам не пробовал, но похоже. Это с xml, а с DSL — создаем функции, которые будут возвращать часть UI (например, поле ввода с кнопкой) один раз и используем везде.

Kotlin для Android

Хорошие вопросы)
Во-первых, замечу еще такую вещь, что при открытии файла 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

Опять-таки дело не в этом. Я не зря привел такой пример:

private var mHelloWorldTextView : TextView = //???

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

Впрочем, Kotlin Android Extensions решает все проблемы.

Kotlin для Android

Да, это очень сильная вещь, я забыл упомянуть о ней.

Kotlin для Android

Вы не совсем правильно поняли. Конструкция

by Delegates.notNull()

нужна чтобы поле mHelloWorldTextView имело тип TextView, а не TextView?, чтобы не было всяких операторов типа "?." и "!!.".

Для справки (на всякий случай) — объект типа TextView не может принимать значение null. Для null есть типы с "?" в конце — TextView?.. Это во всем котлине. Если объект имеет тип "?", то к его полям нельзя обращаться непосредственно через "." — код просто не скомпилируется. Для этого есть операторы "?." и "!!." (сложно представить, как можно было додуматься до такого оператора:))

Wyvern: новый универсальный язык программирования, спонсируемый АНБ

Судя по примерам с гита, просто поменяли синтаксис java.

Проект dot42 переходит на новый формат (C# 2 Java)

Насколько я понял, просто убрана конвертация байт-кода в dex. Поэтому я и спросил — если бы они выполняли компиляцию C# кода сразу в dex, то было бы неприятно.

Проект dot42 переходит на новый формат (C# 2 Java)

Учитывая то, что dalvik теперь остается только для поддержки совместимости, возникает вопрос: актуальна ли статья?

Стартап шаг за шагом: будущее онлайн-образования

Полностью согласен.
Обучение в стиле игры может быть полезно детям, которые просто не могут сконцентрироваться на серьезных вещах долго, но даже их нельзя слишком сильно приучать к этому. Хотя, возможно, жизнь меняется
Лучше всего не учиться и играть, а учиться и думать, каждый раз искать, где можно использовать тот или иной факт, в общем практика. Тогда и скучно не будет, и пользы больше.

10 главных выводов, которые я сделал за Год Изучения Продуктивности

Больно уж бессвязная статья. И рекомендации странные:

Например, в вашей работе скорее всего есть всего несколько задач, которые приносят 80-90% пользы

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

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