stoptalking

в секции импорта указанного кода отсутствует класс R. Ваш КО

"так как если бы были ошибки, не открывало бы и на других телефонах" - ага, ага :D фабрик вам в помощь

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

если у вас есть прожекты/гитхаб сложнее, чем стандартные ресайклеры/фонарики/прочая хрень, то дополнительных вопросов может и не быть. В остальном зависит от собесера (как тут уже было сказано) - один спросит про связь между фрагментом и активей, второй про rxjava, третий про string1 == string2, четвертый про ad hoc полиморфизм, пятый про ковариантный сабтайпинг, шестой попросит стек написать на бумажке по-быстрому. Ведро это вся жава, фреймворк + дополнительный инструментарий. Про графы вас вряд ли спрашивать будут

imageView.setImageResource(Integer.parseInt(adapter.IMAGES[position]));

вы пытаетесь стринг вида "blablablaover9000symbols" спарсить в инт, поэтому у вас все крашится.

public static int parseInt(String s) throws NumberFormatException {
    return parseInt(s,10);
}

Вместо setImageRecource используйте пикассо и в активе, как вы это делаете в адаптере

Layout Transitions

Очевидно, мапить ответы с вопросами локально/удаленно. На очередном вопросе чекать ответы мапнутые с интересующими предыдущими вопросами

самый простой способ

<Framelayout ...>
    
    <ImageView src="somewhat" layout_width="match_parent" layout_height="somewhat"/>

    <...Toolbar fitsSystemWindows="true"/>

</Framelayout>

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

<item name="android:windowTranslucentStatus">true</item>

для иконки - Toolbar::setNavigationIcon()
для меню - Toolbar::inflateMenu()

Если у вас все уезжает на одном экране, а на другом не уезжает, значит вы сверстали криво. Например, задавали ширину в дп без привязки к родительским контейнерам. Констрейнт позволяет флэттернить иерархию и не писать овер9000 вложенных контейнеров, но вам все равно придется пересматривать то что сверстано.

Во-первых String[] icons = {123,123} - это ошибка компиляции. Вы объявляете массив стрингов, и пытаетесь заполнить его интами.

Во-вторых вот в этом коде

for(int i = 0; i < arr4.length(); i++) {
    String icons = arr4.getJSONObject(i).getString("icons");
    list4.add(icons);
}

поменяйте getString на getInt (или как там у вас называется метод, который превращает JsonPrimitive в инт). Ну и меняйте везде String на инт. Зачем вы создаете список, заполняете его, а потом героически преобразуете в массив?

int[] arr = new int[arr4.length];
for (...) {
    arr[i] = arr4[i]....
}

adapter = new BlaBlaAdapter(... arr);

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

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

Возможно повторюсь, но ваш вопрос звучит как-то так : "Если подойти к строительству домов с точки зрения физика-ядерщика, то как нужно строить дом?". Для того, чтобы строить дом нужно подходить к его строительству с точки зрения строителя. Физик скорее всего все зафакапит потому что он собсно физик, а не строитель. Кодинг - сугубо исполнительская тема, она к предпринимательству отношения не имеет. Да, есть позиции лидов, продактов, сто и т.д., но там уже не кодинг строго говоря. Если отбросить это все, то:

1) это джунское рассуждение, стеки всегда будут меняться. Умение эффективно изучать новые стеки - одна из задач и издержек работы программиста. Бизнесу не важно что там под капотом ровно до того момента, пока это не начало бажить/глитчить/тормозить/крашиться

2) непонимание того как работает то, что вы вставляете, приводит к проблемам из пункта 1)

3) ну в принципе для начала да, было бы не плохо освоить хотя бы один фреймворк

4) абстрактные знания ооп и чтение каких-то книжек никому не нужны (в том числе и вам). Нужен опыт использования ооп в боевых прожектах. Если вы просто что-то прочитали и что-то выучили, на практике вы это скорее всего применить не сможете

5) опциональны, как правило развиваются по мере получения опыта. На уровень сильного фронта бекендер врядли выйдет, тупо не хватит времени. Но не исключаю наличие подобных связанных сфер, где практически нет динамики, а потому есть шанс успеть "заботать" и получить достаточный опыт и в том и в другом. Ну либо нужна очень специфичная личность кодера (одержимость), который в таком раскладе ни разу не предприниматель (нет времени предпринимательствовать, вышел новый фреймворк, fap fap fap)

6) коммуникативные навыки важны в любой профессии. Опять же, позиционируя себя как кодер, вы скорее всего не сможете развить коммуникацию до уровня годного продажника - для этого тоже нужно время и опыт

7) ахахах "хотя бы на уровне чтения технической документации" ахахах. "Технический" язык зачастую сопоставим по сложности с "юридическим", методология чтения худ. лит-ры и тех. лит-ры отличаются глобально. Это беллетристику можно читать по-диагонали, а с техникой каждое слово/фраза и каждая его интерпретация может вносить кардинальную лепту в понимание сути технического решения. Ну и разумеется, тех. лит. нет смысла читать, если вы не применяете то, что там написано в бою. По мере получения опыта, ваше видение того, что изложено в книге, будет эволюционировать

8) как угодно

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

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

Если вы хотите быть лидом - ну тут сложно все. Как правило, лиды вырастают из исполнителей, т.к. для эффективной постановки задач и их контроля, должно быть в наличии хорошее понимание предметной области