PRAIT, попробуйте немного обобщить код. Для начала напишите функцию (например myCalc(int, int, char)), которая принимает два операнда и оператор. Сразу увидите как всё преобразится: вместо длинных кусков кода, останутся запросы пользователя и вызовы функции myCalc(), которую потом можно будет дополнять и использовать если вам вдруг предложат усложнить вашу программу.
У вас очень большой путь впереди, но главное всегда делайте так, чтобы после решения очередной задачи у вас в запасе появлялась новая функция, класс, библиотека, которую вы сможете использовать в будущем. Только там можно расти куда-то.
Можно попробовать через JNI подключить свою C библиотеку кодирования паролей, и хранить пароли в зашифрованном виде. Это остановит 9 из 10 любопытствующих, но десятый при желании в итоге взломает и это.
На самом деле могут быть еще две причины затруднений:
1. Вы не знакомы с паттернами проектирования классов в ООП. Некоторые вещи программисты делают не совсем очевидными путями, потому что так диктуют "парадигмы хорошего ООП". Если их не знать, то код может выглядеть странно.
Я о биткоине прочитал в 2012 году на луркморе. Не придал значения - жалею. На хабре, по-моему, можно в потоке джинсы выловить, что делают большие компании. ixbt - про железо пишет много. Профильные форумы еще бывают, где спецы трутся.
Быстро - не выйдет. Ставят задачу - решаешь её, попутно разбираясь, что да как, спрашивая прямого начальника либо соседей. Пройдет время - поймешь. Документацию, да - веди.
Максим Ворожцов, второй вариант: в таблице City завести поле "checked". И считать что город на полных правах в базе городов, только после того, как несколько пользователей ввели его название.
getSupportFragmentManager().beginTransaction().replace(R.id.main, new Fragment1()).addToBackStack(null).commit()