о
Для тех, кто читает это и не читал часть 1, это всего лишь подборка моего личного опыта программирования и публикации моего первого приложения. Хотя в конечном итоге я хотел бы стать достаточно хорошим писателем, чтобы писать учебные пособия, сейчас я просто практикую, используя свой недавний опыт. Спасибо вам всем за ваше время.
Мое приложение Карточки OWL 1-го уровня en – cn использует в общей сложности 6 экранов, в этой части я рассмотрю некоторые экраны и объясню, как я его создал, и некоторые улучшения, которые я сделал на этом пути.
Титульный экран
Экран заголовка состоит из текстовых представлений, изображений и кнопки для перехода к следующему экрану. Все они находятся внутри линейного отображения (вертикального или горизонтального в зависимости от ориентации), и это линейное отображение обернуто в виде прокрутки внутри представления ограничений.
Сначала я настроил вид прокрутки, чтобы попытаться обойти создание нескольких макетов экрана для разных ориентаций и размеров… это не сработало. В конце концов я пошел и создал отдельный макет для каждого необходимого измерения, но, когда я писал это, заметил, что забыл очистить старые виды прокрутки … упс.
Экран заголовка не является родительским действием для любых других экранов, потому что я хотел, чтобы он отображался только на короткое время, когда пользователь входит в приложение, этот экран был разработан для представления основной информации о приложении, когда оно было впервые запущено, и после этого в этом не было необходимости. Единственное существенное программирование, которое я сделал на титульном экране, заключалось в том, что при первом запуске приложения отображалось всплывающее пользовательское оповещение и всплывающее сообщение.
Диалоговое окно настраиваемого оповещения предназначалось для ввода имени пользователя и сохранения его в общих настройках по умолчанию, чтобы при каждом последующем вызове onCreate() для действия a приветствие, отображаемое имя” показывался пользовательский тост.
Код инициализации предупреждения: AlertDialog. Каталог предупреждений строителя. Конструктор(это); окончательный текст редактирования EditText(это); alert.setMessage(R.строка.set_display_name_alert_message); alert.setTitle(R.строка.welcome_to_owl_flash_cards_alert_title); edittext.setText(mpreferences.getString(настройки активности. KEY_PREF_EDIT_ ИМЯ_ПОЛЬЗОВАТЕЛЯ, “”)); alert.setView(редактируемый текст);
Он создает редактируемый текст, и если имя пользователя уже было в общих настройках по умолчанию, оно отображает это имя пользователя, чтобы его можно было перезаписать. После этого он устанавливает только кнопку положительного оповещения.
alert.setpositivebutton(R.строка.alert_dialog_ok_button, новый диалоговый интерфейс. OnClickListener()
внутри положительного предупреждения он сохраняет новое имя пользователя и устанавливает в настройках get_user_name значение false, чтобы предупреждение не появлялось каждый раз.
Это позволило мне получить все данные, необходимые для заполнения моего приветственного сообщения для возвращающихся пользователей.
Тосты интересны, потому что в рекомендациях Google обычно говорится удалять тосты перед публикацией, поэтому я попытался найти альтернативу, такую как закусочная, для моего всплывающего сообщения, но в библиотеке цветов возникли проблемы с библиотекой цветов cardviews, и я решил, что мне нужна библиотека цветов cardviews, поэтому я не мог использовать снэк-бар.
Решением был простой взлом, при котором вы генерируете тостовое сообщение, но меняете его расположение. Для этого вы создаете xml-макет, наполняете его макетом и группой просмотра.
Вид.надувать(Р.макет.welcome_custom_toast_message, (группа просмотра) findViewById(R.идентификатор.custom_toast_welcome_message));
затем вы можете создать новый тост, установить силу тяжести (необязательно), продолжительность и передать свой макет. тост.макет(макет) и покажи это. это удивительно простое и простое решение, но мне все еще нужно разобраться, почему сообщения с тостами обычно не одобряются в опубликованных приложениях.
Главный экран/Экран Меню
Экран меню состоит из 10 кнопок (9 из которых ведут к одному и тому же действию фрагмента, но с разными данными о намерениях для его заполнения, а другая 1 ведет к собственной активности, которая по сути представляет собой длинный текстовый экран.) В нем также есть меню опций для перехода к действию “Настройки” или “Поиск”. Главное меню также используется в качестве родительского действия почти для всех экранов в моем приложении.
9 основных кнопок были разными категориями флэш-карт для более легкого чтения, я справился с этим так, чтобы передать общедоступный статический окончательный ввод в дополнительные функции намерения, чтобы, когда новое действие получило намерение, оно заполнило себя, используя правильные данные.
На экране меню есть два интересных сегмента кода. Первый Я хотел, чтобы мои кнопки были идеальными квадратами, чтобы при прокрутке вверх и вниз по экрану они были красивыми и однородными. Для этого мне пришлось создать объект ViewTreeObserver на основе одной из моих кнопок, затем я установил для него прослушиватель глобального макета . Внутри прослушивателя Глобального макета Я смог использовать кнопки getMeasuredWidth() чтобы получить окончательную ширину и передать ее другим моим кнопкам в качестве высоты, чтобы они стали квадратными.
пример: ViewTreeObserver.getViewTreeObserver(); buttonSizeObserver.addOnGlobalLayoutListener(новый ViewTreeObserver. OnGlobalLayoutListener() { @Переопределить общедоступную пустоту ongloballayout() { manimalbutton.getViewTreeObserver().Удалить глобальный список(этот); int.getmeasuredwidth(); manimalbutton.setHeight(ширина);
Вся причина этого заключается в том, что когда вы находитесь в oncreate, ширина кнопок иногда не задается, поэтому, если вы вызовете getMeasuredWidth() без наблюдателя, ширина может быть нулевой, в результате чего ваши кнопки исчезнут.
Вторая интересная вещь, которую я должен был сделать в этом упражнении, заключалась в инициализации моей базы данных. В ходе тестирования я обнаружил, что при первой установке приложения, если вы перейдете прямо на страницу флэш-карты, они будут пустыми, и вам придется либо нажать вверх, либо назад, чтобы вернуться в меню а потом ты мог бы попробовать еще раз. Я предположил, что ни один пользователь не захочет возвращаться только для того, чтобы использовать приложение в первый раз и поэтому решение состояло в том, чтобы запустить базу данных на ранней стадии, чтобы все предварительно заполненные данные были готовы к использованию, когда пользователь войдет на следующий экран.
Экран Флэш-карты
Таким образом, этот экран состоял из 2 элементов textview, 1 элемента imageview и 1 элемента кнопки изображения. Текстовые представления были заполнены текущим английским или китайским словом и его произношением. Изображение было одним из двух изображений, основанных на том, на каком языке было текстовое представление, а кнопка изображения была кнопкой воспроизведения для воспроизведения звука слова из текстового представления.
Чтобы каждая карта выглядела как флэш-карта, мне пришлось установить OnClickListener() в мою основную группу просмотра, это позволило мне изменять текст и изображения/кнопки на основе щелчка/нажатия пользователя. Я использовал логическое значение для этого, чтобы решить, какой язык использовать.
Чтобы сделать так, чтобы одновременно было более 1 карты, я использовал просмотрщик, который был заполнен в классе активности. Просмотрщик инициировал мои фрагменты, вызвав статическую функцию с именем новый экземпляр для фрагмента, которая затем, в свою очередь, вызвала собственный конструктор по умолчанию для каждого и вернула фрагмент. Статическая функция также принимала данные, передаваемые с пейджера, и помещала их в пакет, чтобы фрагменты onCreateActivity могли их анализировать.
Дополнительные функции пакета фрагментов сначала привели меня в замешательство, потому что я создал базу данных с несколькими таблицами и каждый раз пытался передавать уникальную таблицу, этот метод заставил меня иметь несколько фрагментов и адаптеров страниц. когда я упростил свою базу данных до 1 таблицы, но со строкой для категорий, я смог уменьшить большую избыточность кода для создания фрагментов.
При создании этой страницы я обнаружил, что наблюдатели за просмотром забавны и имеют множество вариантов хранения и вызова данных в базе данных. В то время как в учебных пособиях может немного не хватать, в нескольких кодах документов для Android достаточно подробностей, чтобы многие люди начали.
Страница поиска
В Android есть виджет поиска и документация, чтобы попробовать его использовать, но я хотел попробовать свои силы в пользовательском представлении. Поэтому я просто создал макет для кнопки и поля редактирования текста и попытался поместить его в пользовательский вид, разозлился и вместо этого поместил его прямо на страницу поиска. С тех пор я узнал, как решить мою проблему с пользовательским представлением, но это для более позднего сообщения в блоге.
Страница поиска использовала интересную технику с живыми наблюдателями, взаимодействующими с моделью представления и базой данных.
Он состоял из инициализации живого наблюдателя, а также установки второго изменяемого живого наблюдателя с помощью поискового запроса. Он сделал это для того, чтобы класс viewmodel мог сохранить первого живого наблюдателя закрытым и не заставлять пользователя взаимодействовать с ним напрямую, в основном упрощая его работу, чтобы он мог более эффективно обрабатывать изменения данных.
пример: поисковая активность .из(этого).получить(CardViewModel.class ); окончательный наблюдатель> Наблюдатель>() { @Переопределение публичная недействительность при изменении(@Карточки списка с возможностью обнуления) {} mviewmodel.setsearchterm(mLastSearchTerm);
Просмотреть Класс модели
данные об общественной жизни> m Искомая карта = Преобразования.Карта переключения(условие поиска, условие поиска -> { вернуть mрепозицию.найти карточку(условие поиска); }); личные изменяемые данные Изменяемые данные<>();
public void setSearchTerm(строковый термин){ searchterm.setValue(термин); }
Причиной использования LiveObserver для поисковой активности было то, что пользователь мог выполнять поиск более одного раза, и мне не пришлось бы использовать загрузчики и асинхронные задачи для получения новых результатов или сохранения предыдущих результатов.
В заключение приведены основные интересные моменты для кодирования моего первого опубликованного приложения, позже я мог бы добавить часть 3 о публикации через Google Play.
Оригинал: “https://dev.to/davidcf/my-first-published-app-part-2-3bgg”