VZVZ

Это называется сниффинг.
Заходим в плеймаркет, ищем приложения по запросам типа "http sniffer", находим их, смотрим... скачиваем, декомпилируем))

Видел такой сниффер, и судя по всему работает он на уровне TCP, а не HTTP, т.е. еще глубже.

Но для его работы ОС требовала поставить пароль на экран разблокировки. Чего-то там с VPN и сертификатами было связано, но он еще и HTTPS умеет декодировать, что не всегда нужно, может это из-за этого? И если без декодирования, то не нужен пароль и сертификаты?

P.S. А еще вариант Genymotion + Fiddler.

Взаимодействие будет по протоколу HTTP. Приложение шлет серверу HTTP-запросы, получает ответы и обрабатывает их.

Начать можно не с приложений, а с несколько другого случая - с сайтов. Ведь сайт - это по сути то же самое, тоже сервер + клиент (клиент написан на HTML+CSS+JS и выполняется в браузере). По сайтам инфы больше, она более структурирована. А уже осознав, что такое сервер и бек-енд, можно и за Android браться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А в чем смысл данного вопроса? Проще говоря, какая разница?

И причем тут компилятор? Компилятор как раз один и тот же и там и там. Скомпилировать консольное, десктопное приложение тоже можно без main.

Почему бы вообще не отказаться от HTTP в пользу голого TCP (или WebSockets - тогда для сервака идеален NodeJS)?
Клиент подключается к серваку - и соединение просто остается открытым. Сервак через xxx времени отправляет пакет - клиент его тут же получает, при этом соединение по-прежнему открыто. Также и наоборот (клиент - серваку).

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

Не совсем, на Android много специфичного, это и такие вещи, как API для отправки SMS, и code-behind для той самой верстки.
Но вот скажем библиотека для работы с файлами Excel, Word, иным форматом файлов, удобная библиотека для работы с сетью - может быть совместима и с андроидом, и на этапе линковки (jarник вполне можно добавить к проджекту), и на этапе выполнения (если нету специфичных вещей и соблюдены еще кое-какие условия, к примеру, apk не может быть слишком большим по размеру)

И в любом случае возможна и крайне желательна абстракция, чтобы был фреймворк с классами-обертками буквально для всего.
Скажем на винде десктопной писать под голое API ОСи - это кошмарный сон любого разраба. А на андроиде почему-то в порядке вещей - со всеми отсюда вытекающими.
Даже Toast на андроиде и тот убог и однобок:
Toast.makeText(this, "Hello", 500).show();
Согласитесь, гораздо лучше было бы, если бы можно было и так:
MessageBox.show("Hello");
А для этого надо просто написать класс-обертку по имени MessageBox

Вы под винду разрабатывать пробовали? Нет? А зря.
Если бы пробовали, то понимали бы, что и ежику ясно, что разработка под нативное API ОСи - это 3,14.
Но только в винду уже давно входит высокоуровневый фреймворк .NET, который абстрагирует вас от этого 3,14 и который в общем-то можно использовать и непосредственно (хотя и он далеко не идеален, можно и еще одну обертку сделать, если уметь и понимать).
А для Android такого фреймворка толком нет ни из коробки, ни стороннего.
Так что, подобную обертку в любом случае необходимо написать самому и юзать ее.

Но! Обертка - это отдельный слой абстракции. Она никак не мешает вам группировать GUIшные классы и пакеты. GUI (туда же сервисы и т.д.) - это еще один, отдельный слой абстракции. Они не могут исключать друг друга.
Так что ничто не мешает вам сделать 2 пакета и в одном из них разместить это:
-activities
-adapters
-fragments
-model
-utils
-widgets
А в другом это:
-database
-network
-reader
-ui // здесь не GUI, а высокоуровневые средства для GUI, например, обертка для Toast

Тогда гуй останется в пакете с гуем, а пакет с фреймворком можно будет свободно перекидывать из одного проекта в другой.

Или, если проект мелкий, то можно ограничиться только этим:
-activities
-adapters
-fragments
-model
-utils (а вот сюда - кидать все обертки, ибо они и есть utils по сути своей)
-widgets

> Хотелось бы что-то похожее на MVC. Чтобы все было логично. Правильно ли будет так?
MVC не подходит для мобила и десктопа. Ибо там не может быть C, такого, как на вебе.

> как вы организуете структуру вашего проекта. Какие пакеты классов вы создаете?
Прежде всего, я создаю обертки для стандартного API. Можно сказать - фреймворк.
На винде выглядит дико писать под голое API ОС и так давным-давно никто не делает, пишут под .NET или хотя бы VCL. На Android это в порядке вещей. Линукс же.
Так как разрабы самой ОС не позаботились об этом, то заботиться приходится самому.
И даже на уровне хелловорлда чувствуется польза от этого, я не пишу
Toast.makeText(this.getActivity(), "Blablabla", 500).show();
Я просто пишу:
MessageBox.show("Blablabla");
А все остальное делает самописный класс MessageBox. Время показа Toast рассчитывается автоматом по длине текста, при этом метод show имеет и гибкие перегрузки с кучей параметров, все те же, что и в нативном Toast.
Для удобства re-use, все подобные классы лучше вынести в отдельный проект, отдельный jarник. А собственно код под этот фреймворк - писать прямо в своем проекте.
В остальном архитектура зависит от задачи, скажем HTTP-библиотека должна иметь классы GetRequest и PostRequest, и высокоуровневый класс HttpClient с контейнером куков, и т.д.
Чтобы быть хорошим архитектором, однозначно нужно рассмотреть максимум готовых фреймворков, чтобы извлечь из них лучшее.

> хотел бы найти кого-либо готовых участвовать в проекте на добровольных началах
А зачем работать бесплатно, когда можно работать за деньги?
Я еще школьником и то уже на фрилансе за деньги работал. Пусть копейки, пусть нестабильно, но хоть на мороженое и джинсы новые?

Из личного опыта:
те, кто работает бесплатно, делятся на 2 категории:
1) те, кто быстро бросит работать бесплатно, поймет, что это можно делать за деньги, и бросит вас
2) те, кто просто бросит вас

Короче, это как соседский вайфай: слетает, тормозит, периодически меняется пароль, зато 5 копеек сэкономили.

А просто на сайтах фриланса - не вариант?
Да где угодно можно поискать. Скажем на otvet.mail.ru Там как раз много тех, кому нечего делать. Напротив, мало кто там занят чем-то серьезным.

1) 4 ГБ ОЗУ надо эклипсу. Тут уж никак иначе.

2) Насчет ЦП, у меня вообще 1 ГГц. Это при Win 8.1 x64.
Для новых версий Eclipse это жуть как мало.

3) НО я себе сделал особо облегченную сборку, специально выбрав Eclipse не поновее, а полегче!
Можете тоже пользоваться, работает "из коробки":
https://yadi.sk/d/Kb1p4ZzajaU93
На моем конфиге, конечно, притормаживает, но работать вполне можно.

...Чего не скажешь об Android Studio. С ней работать не могу вообще - ЦП "не хватает".

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

Лично я отношусь к тем немногим людям, кто изучает всё достаточно глубоко. Это моя работа (вернее, одна из - я Reverse-Engineer).
Но тех, кому бы реально пригодились мои книги или статьи, тоже очень мало.
Ну вот скажем на Android до недавнего времени нельзя было штатными высокоуровневыми средствами отправить MMS без Intent. И вот я раскапываю com.android.mms, пишу код, который отправляет MMS без Intent, и выкладываю его в паблик. Ну работает. Ну отправляется. Ну прикольно. А дальше чо? Дай Бог одному человеку из всех читателей это реально пригодится.
...А времени и так на всё не хватает. Поэтому пишу статьи, и вообще занимаюсь, в первую очередь более популярными, более высокоуровневыми, темами.