Рональд Макдональд, ну и зря, потому что он прав. От сообщения берется хэш, шифруется закрытым ключом, отправляется вместе с сообщением. Затем хэш действительно расшифровывается (фраза немного неуклюжая, расшифровывается зашифрованный хэш). Результат этой расшифровки и сравнивается с хэшом сообщения. О обратимости хэша никто не говорит.
baddev, кстати, насчёт "одобрено гуглом". На Google I/O 2017(2 года назад) был рассказ про фрагменты(есть на ютубе). Там они чётко говорят, что Активити - это точка входа, аналог main в C. Что в нейдолжен быть минимум логики, и все экраны на фрагментах. А в этом примере они херачат код в активити и не парятся.
baddev, примеры от гугла это примеры от гугла. То есть рандомных людей из него, возможно стажеров, возможно ещё кого-то, я их не знаю. Я знаю из своего опыта, что вьюха, дергающая методы презентера, дергающего методы вьюхи - это ад адовый, в этой лапше потом фиг разберешься. Возникают идиотские ситуации, когда непонятно, кто за что отвечает, кто что там валидирует. В моем примере вьюха максимально тупая - она рендерит(показывает) данные и предоставляет потоки(не обязательно Rx) событий. На этом её ответственность заканчивается. Вся логика, какая бы она ни была, сосредоточена в презентере(и её можно и нужно выносить в интеракторы, по необходимости. Интеракторы не знают ни про вьюху ни про презентер в таком случае).
Как переварить я не знаю, в нашей команде вышеописанный подход до конца придумал я, сначала было что-то похожее на то, что ты показывал. Нужно много практики, пробуй и всё. Видишь, что у гугла проблемы с этим примером - возьми другой вариант. Этот подход позволяет очень четко разделить обязанности. А когда мы переходили с фрагментов на Conductor, места написанные таким способом переносить было максимально просто - тк ни вью, ни презентер не знали про фрагменты.
При этом я не говорю, что этот подход лучший, но он однозначно лучше, чем описаный в вопросе.
baddev, имхо, если есть возможность, надо максимально быстро устраиваться джуном(или стажером) куда-нибудь. Где будут реальные задачи, и коллеги, у которых можно спросить. Без реальных задач ты большинство вещей сам не найдешь. Ну представь, ты пишешь приложение, тестируешь его на паре-тройке телефонов(в эмуляторы я не верю, они находят только проблемы эмуляторов). Выкладываешь куда-нибудь. Полет нормальный. А в реальности оно просто не установлено на достаточное количество устройств, чтобы найти проблемы и баги. Ты провел над его тестированием слишком мало времени, баги есть, но ты про них не знаешь. И никогда не узнаешь.
baddev, всё индивидуально. Джун в адекватных компаниях вообще может всё перечисленное не знать. Достаточно быть нормальным чуваком и уметь кодить, а фреймворк подтянется. Но если ты остальное программирование тоже за месяцок "учил", то ловить, конечно, нечего.
Я так скажу - грабли можно только на практике собрать, и опыт получить тоже. И за 3 месяца ты этого не сделаешь. И за 6 тоже. Если кто скажет, что он пару лет покодил под андроид и теперь он всё знает, и вообще для него не осталось тёмных мест, и багов он больше из-за этого не делает - не верь. Я под андроид 6 лет пишу. И всё ещё не знаю всё досконально. И мои коллеги тоже. Постоянно возникают вопросы, на которые кто-то (а иногда и все) из команды не знает ответа. Дальше берешь и разбираешься.
dezader, А что ещё может получиться при минимуме усилий?:) Из личного опыта и наблюдений - все эти кроссплатформенные штуки сильно проигрывают нормальной разработке. Конечно, речь не идет об играх(Unity и подобные движки).
DevMan, всё мной описанное легко отлавливается в компайл-тайме. Оно просто не соберется. вам придется писать тесты вместо типизации, и ловить тупейшие баги в проде.
Ладно, похоливарили и хватит, я ж не надеюсь, что вы осознаете и бросите джаваскрипт, как и вы не надеетесь сделать меня его адептом.
DevMan, и глобальный скоуп тут не при чём. Узко мыслите. Существуют рефакторинги, когда меняется порядок, количество, и типы аргументов функций. Существуют ошибки. Существуют команды из более чем одного человека. Множество вещей существует, от которых статическая строгая типизация спасает в компайл-тайм. А динамическая не имеет никаких плюсов.
