Денис Загаевский

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

Ну а ты его(текст) просеттил? tools:text - только для режима просмотра.

Этот метод определен в наследнике. И, естественно, базовый класс не имеет к нему доступа.

Context это активити в данном случае. Можешь заменить на this. Кроме того, неизвестно, как долго эта либа держит контекст, возможна утечка памяти. Можешь заменить на getApplicationContext() - application это максимально долго живущий контекст приложения.

Если на устройстве - то из всего этого только SQLite. +storIO.
На сервере вообще без разницы, с какой больше работал. Для общения API.

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

А, собственно, зачем тут стримы? Map::putAll чем не угодил?

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

Нет, конечно. Мар это это контейнер пар ключ-значение. Ключ на то и ключ, что он уникальный.

Берете Crashlytics от Fabric. Логгируете всё, что угодно. Бест практис, так сказать.

Думаю, qt не идиоты писали, и там, таки, виртуальный деструктор, как и положено у классов, предназначенных для наследования. Всё будет нормально.

Именно int, double, float, char, byte, long, short - никак. Несмотря на то, что в джаве ООП, эти типы не являются объектами. Они не наследуются от Object'a, у них нет общего предка. Поэтому для них не работают дженерики.
Можно использовать boxed-типы Integer, Double, Float, etc. Тогда можно обобщить тип очереди в духе

class Queue <T> {
    private T[] q;
   ...
}
...
Queue<Integer> = new Queue<>();

cуществуют вспомогательные библиотеки v7 которые обеспечивают обратную совместимость в плоть до 7й версии API. Т.е. я могу создавать приложения 27 версии, использовать библиотеку v7 и все мои приложения будут работать до 7й версии API?

Уже нет

Some of the Support Library packages have package names to indicate the minimum level of the API they originally supported, using a v# notation, such as the support-v4 package. Starting with Support Library version 26.0.0 (released in July 2017), the minimum supported API level has changed to Android 4.0 (API level 14) for all support library packages. For this reason, when working with any recent release of the support library, you should not assume that the the v# package notation indicates a minimum API support level. This change in recent releases also means that library packages with the v4 and v7 are essentially equivalent in the minimum level of API they support. For example, the support-v4 and the support-v7 package both support a minimum API level of 14, for releases of the Support Library from 26.0.0 and higher.

Но это не столь критично, потому что ниже четвёрки сейчас поддерживать что-то не особо имеет смысл.
Тем не менее, библиотека поддержки нужна для облегчения работы. Чаще всего на практике её используют. В ней куча полезных виджетов и других классов(например, фрагменты нужно использовать именно из неё, из пакета android.support.v4.app.
values-*, drawable-* и так далее тоже используют, это бывает полезно.

Потому что на новых андроидах нельзя отдавать file:/// URI, который ты получаешь. Нужно использовать FileProvider.