Artem Gapchenko

Читаем внимательно:
Caused by: android.content.res.Resources$NotFoundException: String resource ID #0x2
...
at android.widget.TextView.setText(TextView.java:4176)
at com.example.pro.appi.Main2Activity.onCreate(Main2Activity.java:133)

Вы в Main2Activity присваиваете TextView.setText(#0x2) то есть передаёте число, метод setText c числовым параметром ищет строку в ресурсах. Не находит её и падает, выводя шикарный StackTrace.

Вы должны примерно так:

int number = 5;
TextView.setText(Integer.toString(number))

1. 
   https://www.upwork.com/legal/contractor-policies/
   
   8. AGENCY POLICIES
   Every person working on behalf of an agency must have their own account and profile. These profiles must be associated with their agency on Upwork. Sharing accounts is not permitted.
   
   
2. 
   https://support.upwork.com/hc/en-us/articles/21106...
   How do I apply on behalf of the agency as a whole?
   
   Although the Connects balance is shared by the whole agency, proposals are submitted on behalf of particular workers. You cannot “apply as an agency” without assigning the proposals to a person.
   
   

нельзя

Не нужна. На всех телефонах есть кнопка home - она и есть "выход/закрыть". Другое дело что ваши пользователи могли привыкнуть к ней с 2011 года. Еще время от времени я встречаю гибридный выход: наличие в настройках включения/выключения этой кнопки.

И как-то вы плохо искали, эту проблему начали обсуждать еще в том же 2011:
https://www.quora.com/Why-dont-Android-apps-have-a...
stackoverflow.com/questions/2033914/quitting-an-ap...

Собственно что говорит один из разработчиков Android'а:

Romain Guy: The user doesn't, the system handles this automatically. That's what the activity lifecycle (especially onPause/onStop/onDestroy) is for. No matter what you do, do not put a "quit" or "exit" application button. It is useless with Android's application model. This is also contrary to how core applications work.

Это значит, что состояние view вы можете обновлять только из потока в котором view создан. Как правило - основного.
Передайте параметры в основной поток и из него обновите view

На самом деле вызывать не стоит только виртуальные методы. Т.к. если класс наследник его переопределит, то возникнет ситуация, когда метод работает до вызова конструктора класса-наследника. И если в этом методе используются какие-нибудь поля класса-наследника, они могут быть еще непроинициализированы.

А так как в Java

In Java, all non-static methods are by default "virtual functions." Only methods marked with the keyword final, which cannot be overridden, along with private methods, which are not inherited, are non-virtual.

то в конструкторе не стоит вызывать любые публичные не final методы.

Ниже C# код (т.к. работаю в основном с этим языком), иллюстрирующий это.

void Main()
{
	new B("name");
}

class A
{
    public A()
	{
	     Method();
	}
	
	protected virtual void Method()
	{
	}
}

class B : A
{
    private string Property { get; set; }
	
	public B(string value)
	{
	    Property = value;
	}
	
    protected override void Method()
	{
	    Console.WriteLine(Property.Length);
	}
}

Результат: Object reference not set to an instance of an object.

StackTrace
at UserQuery.B.Method()
at UserQuery.A..ctor()
at UserQuery.B..ctor(String value)
at UserQuery.Main()

cypselusmurarius: в вашем случае это ОТЛИЧНО (в комменте вы написали, что вам 14)! И очень похвально, что вы интересуетесь технологиями.
К сожалению, Лутц - это только теория. Типа: "вот есть велосипед. У него есть переднее и заднее колесо, у вас есть руль, которым можно задавать направление". Но прочитав подобный мануал, ездить вы вообще не научитесь. Хотя у Лутца есть неплохие примеры рабочих программ. В таком случае попытайтесь несколько раз внимательно читать примеры, и затем пытаться реализовать такой же функционал, но не просто переписывая код один в один, а немного его видоизменяя - на уровне переменных и тому подобного.
Подумайте вот о чем: какую программу вы хотели бы написать? Может, показывать список друзей вконтакте и диалоги с ними? Или, может быть, какую-то простую игру? Или может сайт сделать? Или еще чего?
Очень важно найти реальный проект, над которым вы будете работать и начать его реализовать. И в этот момент вы поймете, как ничтожны ваши знания, как многого вы не знаете. Тут вы начнете искать способы решения той или иной задачи. Прежде, чем обратиться сюда либо на форумы - попытайтесь максимально кратко сформулировать вашу задачу. К примеру: "задать другой цвет контуру треугольника в canvas" или что-то подобное. Когда четко понимаете, что нужно - пользуетесь поисковиком. Также неплохо продублировать вопрос на английском и перевести непонятные слова в словаре, чтобы понять суть ответа и применить его. Умные люди ведь сказали когда-то: "в правильно поставленном вопросе есть уже половина ответа".
И только если ничего не нашли - обращаться уже сюда.

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

Когда начался бум и восторг вокруг концепции паттернов проектирования, выкрики "GoF рулит!" и так далее, я озадачился тем, чтобы понять, что за шум?

По своей сути - паттерны - это обычные шаблоны проектирования. Заимствовано у обычных архитекторов (те, которые зданиями занимаются). Суть проста. В работе архитектора есть задачи, которые удобно решать одним или несколькими проверенными способами.

По аналогии в проектировании софта имееются свои архитектурные вопросы вроде разбиения приложения на компоненты/модули, организации зависимостей между ними, распределение функциональных обязанностей и т.п. Как ловко подметили авторы книжки из этой банды четырех (The "Gang of Four") в нашей индустрии можно также выделить некоторе количество типовых шаблонов, проверенных на практике, чтобы тем самым не наступать на уже обойденные другими грабли.

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

Чтобы понять, где они нужны - нужен опыт. То есть (я лично убежден), что учиться на ошибках других может только крайне ограниченное число людей. Все остальные обязаны набить шишки самостоятельно :)

К изучению паттернов я дам такие советы:

1) Прочтите пару книжек, чтобы понять, что это за зверь и с чем его едят. Можно взять одну из вариаций книжки GoF или какие-то производные для вашего стека разработки - познакомиться с основными популярными шаблонами. Сразу после этого я посоветовал бы прочесть книжку "Горький вкус Java" (Брюс Тейт) - она про анти-паттерны. Это чтобы понять обратную сторону их использования. Мне понравилась и уберегла думаю от многих проблем. То что на примере Java - неважно. Речь идет о шаблонах, так что представителям других стеков (к которым отношусь и я) будет просто понять все равно.

2) Постарайтесь осознать, доводилось ли вам сталкиваться в работе раньше с чем-то, что является или могло бы легко стать одним из шаблонов. Где получалось применить концепт верно, а где из-за этого только проблемы были.

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

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

Я даже пожалуй посоветовал бы подойти к освоению айтишной архитектурной мудрости с другой стороны - со стороны нефункциональных требований или так называемых "-ilities" - их много. Тут вот описаны 7 штук. А вообще их десятки.

Среди прочих - такие как maintainability (простая поддержка кода), scalability (масштабируемость), extensibility (расширяемость), availability (устойчивость ) и тп. Если, проектируя свое приложение, вы задумываетесь об этих "илитях" и стараетесь их обеспечить в необходимом проекту объеме, то, как правило, ваше приложение будет иметь отличную архитектуру. При этом шаблоны проектирования в ней появятся лаконично сами собой.

Поскольку идея использовать шаблоны - это попытка опытных программных инженеров дать десяток готовых рецептов менее опытным, чтобы пока они не научились варить "вкусную кашу", они не варили уж что-то совсем несъедобное. :) Учитесь "готовить", разбирайтесь в -ilites :) и все будет хорошо