VZVZ

JSON нужно делать не всегда, а либо в тех случаях, когда требуется, чтобы с API работал не только браузер, но и мобильные клиенты или еще какие-то (которым не нужны готовые данные в HTML, а нужен JSON для парсинга), или когда лучше, чтобы клиент был толстым. Еще JSON, очевидно, несколько облегчает отладку.

В целом, в идеале, бек-енд сайта должен уметь возвращать и HTML для браузера (который JS не нужно парсить => быстродействие на клиенте), и JSON для других целей, и, может быть, и что-то еще.
Так сделано в VK, например.

Это я про HTTP. Если WebSockets все поля кодируют в JSON - ничего страшного, ведь возможен вот такой финт ушами:
{"html": "здесь html"}
И можно еще вот так сделать, элегантно объединив преимущества HTML и часть преимуществ JSON:
{"html": "здесь html", "error": "OK"}
Я подобное в Googleовских сервисах видел. Интересное решение, и определенно имеет право на жизнь.

Из-за обилия источников теряюсь, с чего начать и как продолжить.

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

С самим линуксом знаком плохо

Добудьте линукс (учитывая мое железо, в моем случае это скорее всего будет VPS + быстрый инет, остальное дороже) и просто пишите под него, от хелловорлда и далее.

написания драйвера для принтера

Начинать опять же надо с хелловорлда.
Мне на винде даже драйвер с одной-единственной функцией уже был интересен, он создавал файл на диске C:, что запрещено без прав админа. А деление на нуль (и того проще) вызывало BSOD))
Здесь я обошелся без гугла, на форуме задал вопрос (прям так и спросил "как написать простейший рабочий драйвер под винду, что установить и т.д.") и мне повезло, нашелся чел, который и разъяснил все, и пример кода привел, и советов дал, которые счел нужным.

Я полный нуб :(

Так учитесь. Учитесь искать ошибку не только методом копания в коде, навыки отладки тоже освоить нужно.
Надо научиться использовать LogCat или хотя бы try-catch+Exception.getMessage()+Toast.
Прямо сейчас сядьте и разбирайтесь.

Без этого только гадать можно.
А верно ли прописали в манифесте? А что в MainActivity.onCreate и вообще MainActivity? А может дело в ListActivity? А может при клике еще какой-нибудь код вызывается и приводит к ошибке?
И т.д. и т.д. от самого простого к самому невероятному.

А почему именно PHP-то? Почему с VK всех тянет работать именно на PHP? С ним скорее на каком-нибудь C# надо работать. Даже если требуется облако, есть же еще VPS как вариант.

без моего личного присутствия за компьютером

Как минимум 1 раз понадобится приложению разрешить доступ к VK через ваш аккаунт.

просто по указаным логину и паролю

Авторизацию по логину и паролю не поддерживается в API, это нужно работать с бек-ендом самого сайта, это совсем другое. Сниффер понадобится, им отследить запросы, идущие из браузера, и имитировать их. Также мб стоит ихнее приложение Android покопать сниффером, ведь там-то логин и пароль, как и на сайте.

проверить почту

Так вы про почту или про личку ВК?

Что за приложение? Наверно, это игра, в ней какой-то движок, а это формат его файлов. Нужно гуглить эти расширения, этот движок. А если реально никакой инфы толком о них, то HEX-редактором попытаться их исследовать и/или копать саму игру: если в ней нужный код написан на Java, то юзать fernflower и jd-gui (и smali еще можно - он вернет асм, но зато без ошибок), а если на C++ (лежит в папке libs не то lib) - то IDA Pro + Hex-Rays.

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

А ваш вариант со всеобъемлющим деревом (и даже не деревом, а списком - вы-то сами не дерево составляете, как на картинке, а список) в корне неверен, потому и получается хрень, вроде вашего "научиться паять".
Что паять? Можно паять кондеры в блоках питания или "мастер киты", можно паять процессоры на материнках планшетов, можно паять прохудившиеся ведра, можно трубы в холодильнике паять, а кто-то, возможно, и к ЛЭП под напряжением может что-нибудь припаять. А можно в том же самом планшете всего лишь разъем заменить, а не процессор.
И законы физики, очевидно, для всего этого азные понять надо. Ну и да, пайка без понимания тех. процесса - бесполезна, поэтому выносить ее в отдельный пункт типа "сиди паяй и даже не смей думать, а то еще закон физики какой откроешь для себя" - вообще абсурд, без нужды ничего паять не надо.

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

Ибо подход должен быть интеллектуальным, а не категоричным "да/нет".
Если "да" - то есть ставить целью в рамках любой задачи раскопать все на свете до последнего бита, то придется копать все стандартные библиотеки, платформы, IDE, ОС (а че? вдруг пригодится? бывает) - то сами понимаете, никакого времени не хватит, и реальный заказчик такое времяпрепровождение не оплатит.
А если "нет" - то есть всегда и везде плавать на поверхности - то вы будете не уникальны и многое не осилите.

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

1) Обязательно наличие padding (внутренних "полей" со всех сторон активности)

2) Кнопки не должны быть слишком большими, это сбивает с толку на любой платформе. Для мобильников (НЕ планшетов) достаточно сделать их стандартной высоты, а длиной в экран (и все это по центру), или горизонтально их расположить, каждая 1/3 экрана (+padding). Как вариант, можно стандартными диалогами воспользоваться попробовать, тогда может и на планшетах будет сразу норм без костылей, этого не пробовал.

3) Должно быть краткое пояснение, что это и к чему.

4) ...И тут мы плавно переходим к главному замечанию по данному вопросу:
А для чего вообще это все нужно? Какая цель 3 режимов и какая цель этого диалога на этом месте?
Что собой представляет чат по блютусу или USB, реально ли такое чудо нужно юзеру?
Если всем этим реально нужно грузить юзера, то подписи на кнопках (или пояснение) надо делать исходя из этого, а наш жаргон про "TCP" юзер вообще знать не обязан.
А может не нужно, просто сделать 1 вариант по умолчанию, далее в настройках?
Если делать все шиворот-навыворот - сначала выдумать какое-то решение, а потом пытаться согласовать его с задачей (вместо того, чтобы сначала поставить задачу, а потом уже ее решать) - то удобный интерфейс не получится.

Неясен вопрос, неясно, какую цель вы вообще преследуете. Отвечу в общем.
Если необходимо получить код на C/C++, то нужен декомпилятор Hex-Rays. Сама по себе IDA - только дизассемблирует (ну еще парсит декорации функций, приводя их в вид сишных заголовков, ищет строки и пр.), этого недостаточно для серьезного реверс-инжиниринга в приемлемые сроки.
У меня IDA with Hex-Rays установлена.

У вас постановка задачи неправильная. Надо не изучать языки, а учиться программировать либо верстать, причем ставить себе реальные задачи.
Верстальщику необходим минимум JS, программисту необходим минимум HTML+CSS. Кем вам быть - это зависит от вас, верстка может быть реально востребована только вкупе с авторским дизайном, так что если вы художник по натуре, то лучше становитесь верстальщиком.

Главная проблема Open Source - это, скажем так, маркетология до мелочей: разрабы не понимают, для каких целей они пишут каждую фичу и проект в целом, и пишут не то, что реально нужно людям (опыта нет, они не знают, что нужно), а то, что им хочется писать, вот и получаются велосипеды с квадратными колесами, которые даже даром мало кому нужны, но зато прикольно.
Если бы вы практиковали критический подход к некой области, скажем к средствам разработки, и имели опыт, то вы могли бы здорово улучшить какой-нибудь Eclipse, добавив в него реально нужное, доведя до ума сырое и выкинув не очень нужные вещи, которые бросаются в глаза во всех менюшках и этим создают типичный линуксовый дискомфорт юзабилити. При этом программистом вы сами могли бы и не быть, вы бы создавали ТЗ, а другие выполняли (а опыт у вас был бы от использования Eclipse вашими подопечными на работе, вместе с которыми вы активно исследовали его проблемы - критический подход)
Вот только сам подход писать чисто бесплатное ПО, которое нужно людям в лучшем случае даром, это уже само по себе нифига не маркетология. А для вас Open Source - это именно бесплатное, ведь так?

Можно. Модель - это хранилище данных, связанных с View.
А вот где Controller? И нафига он в десктопном приложении? В вебовском понятно, каждая Action - это URL, каждому URL соответствует страница или иной ответ сервера (View+Model), все логично. А в десктопном что будет Actionами? Окна? Так они доступны из точки входа и далее друг из друга, а не извне, как URL.

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

Что-то не вижу связи с технологией Drag & Drop.
"Drag and drop framework" - это вы сами придумали?
Может, правильнее будет такую штуку назвать WYSIWYG?

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

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

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

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

> p.s.s. может книги или статьи на этот счет посоветуете.
Да любая толстая книга подойдет. Встаете один в просторной комнате, берете ее, размахиваетесь... Дальше ясно?

Смотря что за приложение.
Бывают приложения, по функционалу очень похожие на сайты: интерфейс, работа с сетью - и всё, а API ОС почти не используется.
Например, приложение для заказа суши или такси, мобильный клиент для соцсети...
Такие приложения вполне можно писать на PhoneGap/Cordova, по крайней мере в том случае, если у вас уже есть интерфейс на HTML+CSS (или устоявшаяся команда верстальщиков) и вы не хотите тратить кучу сил и времени на переход на нативный GUI.

> и надо будет ли пользователю устанавливать php?
Вообще-то PHP на сервере идет.
Вот чтобы сидеть на тостере, вам же не надо устанавливать PHP или еще что-то серверное?

> и публиковать их на плеймаркет?
С чего бы нет? Обычный apk, в нем WebView, а в нем HTML+CSS+JS.

> var content = document.querySelectorAll('.content');
Конечно, будет на всех происходить. All же.
Надо внутри onclick использовать this (или еще как), чтобы обращаться только к конкретному элементу...