- Защита от null, ключевое слово let
- Элвис-оператор ?:
- Оператор !!
- Ключевое слово let
- Android Studio контекст, возвращающий null
- 4 ответа
- Похожие вопросы:
- Android проверьте null или пустую строку в Android
- 8 ответов
- использовать TextUtils.isEmpty( someString )
- Советы по чистому коду новичкам в Java/Android
- Общие советы
- Наименование
- Функции
- Форматирование
- Классы
- Советы о разном
Защита от null, ключевое слово let
В Java существует проблема с исключением NullPointerException и разработчику нужно постоянно устраивать проверки на null. В Kotlin существует защита от подобных ошибок. Нужно использовать вопросительный знак ? у типа.
Любой объект может быть null и мы можем явно указать это через символ вопроса ?. В этом случае Kotlin будет проверять на возможность ошибки и предупреждать на этапе разработки.
Любой тип, не поддерживающий null, является дочерним типом соответствующего типа, поддерживающего null, поэтому не путайте следующие выражения:
Умное приведение Smart cast позволяет превратить переменную из одного состояния в другое: cat? превратится в cat (см. пример выше) или переменная a типа Int? превратится в Int.
Если умное приведение вам не нужно, то используйте запись с безопасным оператором ?.
Функция будет вызвана только в том случае, если значение a отлично от null. Безопасные вызовы можно сцеплять.
Не путайте null с пустой строкой «». Выводим значение переменной типа String.
Любую функцию или параметр конструктора можно объявить с null-совместимым типом. Следующий код определяет функцию printInt(), которая получает параметр типа Int? (null-совместимый Int):
Функция может иметь null-совместимый возвращаемый тип.
Можно создать массив нулевых объектов. При этом массив может содержать и строки и null.
Элвис-оператор ?:
Другой «Элвис-оператор» ?: (напоминает причёску Элвиса Пресли, если повернуть голову, как на смайликах) позволяет назначить альтернативное значение, если объект равен null.
Справа от элвис-оператора можно использовать return и выбрасывать исключения.
Оператор !!
Если вы точно уверены, что ваша переменная не null, то можете использовать оператор !!. Kotlin будет полагаться на ваш профессионализм и не станет проверять ваше предположение. Если вы ошиблись в своём предположении, то ваше приложение может грохнуться.
Например, в Android часто объявляются компоненты, а инициализация происходит позже.
Подобный способ позволяет избежать null и аналогичен записи в Java.
При полной уверенности можете написать
Ключевое слово let
Ещё один способ избежать проблем с null — это использовать ключевое слово let вместе с оператором ?.:
Код будет выводить имя кота только в том случае, если объект не равен null.
Этот подход удобен, когда имеются смешанные варианты и мы хотим выполнения кода только для объектов, которые не имеют значения null:
В массиве три элемента, но на экран выводятся только два элемента.
Такой подход сокращает и упрощает код. Допустим, у нас есть функция getBestCat(), возвращающий тип Cat?.
Можем вызвать с проверкой на null.
А можно обойтись без создания новой переменной, а сразу использовать let:
Запись означает следующее: получить объект «Самый лучший кот», и если объект не null, то позволить ему есть (eat()).
Источник
Android Studio контекст, возвращающий null
У меня есть класс, который вводит некоторые данные в SharedPreferences.
Я задаю контекст с помощью метода в моем классе MainActivity:
Однако я продолжаю получать ссылку на объект null. Пробовал несколько решений от stack overflow и не может преодолеть эту проблему.
Почему контекст возвращает null?
4 ответа
Я пытался исправить это в течение последних 2 часов. Перепробовал много чего. Фрагмент, похоже, передает контекст null моему адаптеру. Я попытался инициализировать контекстную переменную в onCreate, onCreateView и onActivityCreated. Результат тот же. Вот мой фрагмент: public class.
Я работаю над очень простым пользовательским view, мой view просто расширяет view и имеет метод рисования public class MyView extends View ; public MyView(Context context, AttributeSet attrs) < super(context, attrs); System.out.println(CONTEXT. +context); >@Override public void draw (Canvas.
Контекст-это абстрактный класс, реализация которого обеспечивается Android система
Контекст предоставляется любому Activity системой android во время выполнения ( Activity косвенно расширяет Context ). вы пытаетесь получить Context из класса MainActivity с помощью статического метода, который не будет работать и всегда будет возвращать null :
Вы всегда должны получать Context из экземпляра Activity , а не из самого класса. Вы можете сделать это легко, передав экземпляр вашего текущего действия конструктору вашего класса. Затем вы вызываете getContext() на INSTANCE этого Activity , а не сам класс Activity .
Кроме того, я хотел бы упомянуть, что ваш код в основном является анти-шаблоном. Вы никогда не должны хранить контекст в статических переменных. Я бы рекомендовал вам прочитать больше о жизненном цикле деятельности в android и контексте-это фундаментальные знания.
Вы можете получить контекст статически по всему приложению
пожалуйста попробуйте следующий код:
В файле манифеста Android объявите следующее.
Используйте этот класс
Теперь вы можете вызвать MyApplication.getAppContext(), чтобы статически получить контекст вашего приложения.
Это происходит потому, что MainActivity.getContext() — это null попробуйте передать контекст из MainActivity в ваш класс.
В MainActivity инициализации это такой:-
А также избегайте использования статических контекстов , это может привести к утечке памяти !!
С момента выпуска Android Studio 3.0 Canary я пытаюсь выучить Kotlin, и есть кое-что, чего я не могу понять. Я пытался сделать простое действие с помощью кнопки и TextView. Я не могу понять, почему Android Studio не может распознать действие как контекст. В своем коде я пытаюсь сделать тост, но AS.
Я пытаюсь использовать ZMQ в приложении android. В идеале я должен создать контекст один раз и term() его, когда приложение закрывается. Но в отличие от приложений c++. На android нет функции main(). На основе документа google о жизненном цикле активности . Функция onCreate(), onStop() может быть.
Вы получаете контекст из статического метода в классе, что означает, что этот метод вызывается до того, как класс фактически инициализируется. Если нет фактического экземпляра действия или если OS не предоставил контекст для действия, то это null. Действие имеет доступ к контексту, но после того, как управление подчеркиванием Android инициализировало его, класс не будет иметь контекста сам по себе, потому что он там есть, если вы заметите, что действия никогда не создаются с помощью конструктора, потому что Android делает это за вас.
Если вы хотите использовать статический метод с хорошим синтаксисом, то статический метод должен находиться внутри класса, который использует общие предпочтения, и должен передаваться из действия, во время любого метода жизненного цикла действия или когда пользователь взаимодействует с пользовательским интерфейсом (эти прослушиватели устанавливаются в жизненном цикле действия).
А ваша деятельность:
Похоже, ваша проблема заключается в том, что вы пытаетесь заставить другой класс использовать действие, но в Android есть действие, которое использует другие классы
Похожие вопросы:
Привет, когда новое диалоговое окно оповещение в android приложение, и есть null момент исключение, сказав, что viewroot не могу получить контекст, и возвращение контексте null. Итак, кто-нибудь.
Я пишу AsyncTask , который включает в себя progressDialog . Когда я пытаюсь передать контекст в качестве параметра, я получаю исключение null точки. Каков правильный параметр для передачи? На что c.
Следующая схема была рекламирована как способ получить контекст приложения из любого места в моем приложении android. Но иногда выполнение MyApp.getContext() возвращает null. Я попытался изменить.
Я пытался исправить это в течение последних 2 часов. Перепробовал много чего. Фрагмент, похоже, передает контекст null моему адаптеру. Я попытался инициализировать контекстную переменную в onCreate.
Я работаю над очень простым пользовательским view, мой view просто расширяет view и имеет метод рисования public class MyView extends View ; public MyView(Context context, AttributeSet attrs) <.
С момента выпуска Android Studio 3.0 Canary я пытаюсь выучить Kotlin, и есть кое-что, чего я не могу понять. Я пытался сделать простое действие с помощью кнопки и TextView. Я не могу понять, почему.
Я пытаюсь использовать ZMQ в приложении android. В идеале я должен создать контекст один раз и term() его, когда приложение закрывается. Но в отличие от приложений c++. На android нет функции.
Я работаю над xfce Xubuntu, я обновил свой android studio, и каждый раз, когда я выполняю любой проект с эмулятором, я получаю эти две ошибки: Эмулятор: предупреждение: QXcbIntegration: не удается.
Из того, что я понимаю, читая другие ответы здесь и исследуя, инъекция контекста приложения в поле должна быть защищена от утечек памяти, в то время как удержание контекста активности в поле вызовет.
Я испытываю странную ошибку, когда пытаюсь построить свой проект android studio. Я не изменил ничего существенного в своем проекте, но вдруг я получаю ошибку: *Exception является.
Источник
Android проверьте null или пустую строку в Android
в моей попытке AsyncTask Я вам адрес моего сервера. В onPostExecute() Я должен проверить адрес электронной почты empty или null . Я использовал следующий код, чтобы проверить это:
но в моем Toast Я вижу null печати. Мой полный код:
как я могу проверить для null и empty строку? Спасибо заранее.
8 ответов
использовать TextUtils.isEmpty( someString )
Примечания
- на документация заявляет, что проверяются как нулевая, так и нулевая длина. Не нужно изобретать велосипед.
- хорошей практикой является досрочно возвратить.
от комментария @Jon Skeet, действительно String значение «null» . Следующий код решил это
проверка пустой строки, если она равна нулю, длина равна нулю или содержит строку «null»
йо может проверить это с помощью этого:
и помните, что вы должны использовать точный код выше, с этим порядок. Потому что это гарантирует, что вы не получите исключение нулевого указателя из userEmail.isEmpty() если userEmail равно null.
Выше описания он доступен только с Java SE 1.6. Проверка userEmail.length() == 0 на предыдущих версиях.
вы можете проверить его с помощью метода утилиты «isEmpty» из TextUtils,
метод isEmpty(CharSequence str) проверяет оба условия, для null и length.
Если вы проверяете null или пустую строку, чтобы вы могли попробовать это
все, что вы можете сделать, это вызвать метод equals () на пустом строковом литерале и передать объект, который вы тестируете, как показано ниже :
Источник
Советы по чистому коду новичкам в Java/Android
Теме чистого кода на одном только habrahabr посвящено тысячи статей. Никогда бы не подумал, что захочу написать свою. Но после проведения компанией курсов для желающих связать карьеру с разработкой ПО, в частности разрабатывать под Android, мое мнение поменялось.
За основу статьи взяты советы из классики “Роберт К. Мартин: Чистый код”. Отобрал из них те, которые наиболее часто встречались в виде проблем у студентов. Приведенные советы написаны с учетом моего опыта разработки коммерческих Android приложений. Поэтому не ко всем Android-проектам приведенные ниже советы подойдут, я уже не говорю про другие системы.
Советы в основном приводил с примерами кода как НЕ НУЖНО делать. Как ни странно, у большинства студентов были одни и те же ошибки. Все примеры кода были придуманы, любые совпадения с реально существующим кодом случайны.
Общие советы
1. Код должен быть легко читаемым, понятным и очевидным
Программисты большую часть времени тратят на чтение и анализ написанного кода, а не на написание нового. Важно чтобы Ваш код был легко читаемым, понятным и с прогнозируемым поведением. Это позволит коллегам и Вам по прошествии времени затратить минимальное время на понимание того, что делает каждый кусок кода. Понятный код с прогнозируемым поведением позволит уменьшить вероятность ошибки при внесении изменений не автором кода.
2. При написании кода нужно придерживаться Java Code Conventions либо других спецификаций, принятых на проекте командой
Спецификацию можно сравнить с правилами оформления текста книги. Думаю, немногие захотят читать книгу, где каждый абзац отличается шрифтом, размером и цветом текста. Так и с кодом, куда легче читать оформленный в едином стиле код.
Наименование
1. Имена классов, функций, переменных и параметров должны передавать закладываемый в них смысл.
Довольно очевидный совет, но не всегда его придерживаются. Тут, в качестве примера, можно привести оглавление книги: если все главы названы просто «Главами», то понять в чем суть нельзя. Наименования классов, функций должны сообщать об их предназначении без погружения в детали реализации.
Наименования классов MyActivity, CustomView, MyAdapter говорит только об одном, что это не часть Android SDK и все. SecondActivity говорит, что это не часть Android SDK и о наличии в проекте еще одного Activity, но не факт =)
Правильно именовать классы: MainActivity, FoodsActivity, FoodCartActivity, PhoneInputView . MainActivity — очевидно, что основной разводящий экран приложения. FoodsActivity — экран с перечнем продуктов. PhoneInputView — компонент ввода номера телефона.
Следующие названия переменных бесполезны и нарушают правила наименования:
как и параметры конструктора:
2. Название публичного класса и файла должно совпадать.
Есть следующий класс
Название файла при этом оказывается “products_Activity.java”.
Это не правильно. Название публичного класса и java-файла должны совпадать.
3. В наименованиях нужно использовать только буквы латинского алфавита, никаких цифр, символов подчеркивания и дефисов. Исключения составляют наименования из стандартов (ГОСТ, ISO), символы подчеркивания для разделения слов в наименованиях констант.
Примеры выше: m_textview_1 . Часто вместо lastName пишут userName2 , что не правильно.
4. Не нужно использовать строчные “L” и “O” в качестве имен локальных переменных, т.к. их трудно отличить от “1” и “0”.
Надуманный пример, но что-то подобное я встречал в своей практике
В этой функции пузырьковой сортировки есть одна ошибка, сможете за секунды ее найти=)?
Такой код труден для чтения и при написании легко сделать ошибку, которую можно очень долго искать.
5. Не нужно указывать тип в суффиксе имен.
Вместо accountList нужно писать просто accounts . Это позволит в любое время изменить тип переменной без переименования самой переменной.
А еще ужаснее выглядит nameString, ageFloat .
Исключение составляют наследники классов Android SDK: Activity, Fragment, View, Uri и т.д. По названию NewsSynsService сразу понятно, что класс является «сервисом» и ответственен за синхронизацию новостей. Использование суффикса view в nameView, photoView позволяет легко отличить переменные, относящиеся к верстки, от остальных. Имена view обычно начинают с существительного. Но имена кнопок лучше начинать с глагола: buyButton
6. Имена могут и должны содержать термины из математики, названия алгоритмов, паттернов проектирования и т.д.
Увидев имя BitmapFactory , не автор кода сразу поймет смысл этого класса.
7. Не нужно указывать никакие префиксы при именовании.
Вместо m_user, mUser просто пишется user . Указывать префикс s для статических полей в современных IDE излишне.
Исходники Android SDK не являются здесь показателем в силу давности создания первых версий и наследования кодовой базы до наших дней.
s_ ни к чему в начале названия статического поля. К тому же название констант должно писаться прописными буквами:
8. В наименование классов нужно использовать существительные.
Классы это как объекты реального мира. Поэтому нужно использовать существительные для их названия: AccountsFragment, User, Car, CarModel .
Не нужно называть классы Manager, Processor, Data, Info , т.к. они имеют слишком общее значение. Лучше название класса длиной в два-четыре слова, чем просто Data .
9. Названия классов должны начинаться с прописной буквы.
Слова НЕ должны отделяться символом подчеркивания. Нужно следовать нотации CamelCase: GoodsFragment, BaseFragment
10. Используйте одно слово для каждой концепции.
Использование fetch, retrieve, get в одном классе сбивает с толку. Если класс назвали Customer , то имена переменных класса и параметров функций этого типа лучше называть customer , а не user .
Функции
1. Функция должна выполнять только одну “операцию”. Она должна выполнять ее хорошо. И ничего другого она делать не должна.
Под “операцией” следует понимать не одну математическую операцию или вызов другой функции, а действия на одном уровне абстракции. Чтобы определить, что функция выполняет более одной операции, следует попробовать извлечь из нее другую функцию. Если извлечение функции не дает ничего кроме простой перестановки кода, то значит разбивать дальше функцию не имеет смысла
К примеру есть функция setProducts класса ProductsAdapter :
Внутри функции происходит три основных операции: 1) фильтрация newProducts , 2) очистка и вставка новых значений в products , 3) обновление адаптера notifyDataSetChanged .
Фильтрация элементов newProducts должна происходить в другом методе и даже в другом в класса (например в presenter-е). В ProductsAdapter должны прийти уже отфильтрованные данные.
Лучше переделать код следующим образом:
Параметр newProducts содержит уже отфильтрованный список продуктов.
Можно еще строчки java products.clear(); products.addAll(newProducts);
вынести в отдельную функцию, но особого смысла я в этом не вижу. Лучше заменить notifyDataSetChanged на DiffUtil, это позволит обновлять ячейки в списке эффективнее
2. Размер функции должен быть 8-10 строк.
Функция размером в 3 экрана это не функция, это *****. У меня тоже не всегда получается ограничить размер функции 8-10 строками кода, но нужно стремится к этому. Пример по понятным причинам приводить не буду.
Функции большого размера трудно читать, модифицировать и тестировать. Разбив большую функцию на малые, легче будет понять смысл основной функции, так как мелкие детали будут скрыты. Выделяя функции можно увидеть и избавиться от дублирования кода в основной функции.
3. В теле функции все должно быть на одном уровне абстракции.
Вычисление значения локальной переменной errorMessage имеет более низкий уровень абстракции, чем остальной код внутри функции. Поэтому код java «Article » + article.getName() + » is incorrect» лучше вынести в отдельную функцию.
4. Наименовании функции и передаваемых параметров должно сообщать о том, что делает функция
Причиной выделения блока кода в отдельную функцию может являться желание в пояснении, что делает код. Для этого нужно дать подходящее название функции и параметрам функции.
Непонятно по какому полю будет происходить поиск, что передается на вход функции.
Лучше переделать в следующий вид:
Название функции говорит, что происходит поиск Product по полю id . На вход функция принимает не “null” значение. Если Product не найдется, то вернется “null”.
Роберт К. Мартин советует использовать параметры в качестве части названия функции:
Вызов функции может выглядеть так:
На проектах я такой способ не встречал. Лучше данный способ не использовать и писать полностью название:
5. Имена функций должны начинаться с глагола. Лучше длинное имя, чем не содержательное короткое.
Название start не сообщает, что именно стартует функция. Только заглянув в тело становится понятно, что функция открывает Activity.
А должно быть понятно предназначение функции уже по названию.
6. Вместо передачи в аргументы функции флага (boolean) лучше разбить функцию на две функции
Часто этот флаг является причиной увеличение размера функции при ветвлении логики выполнения в зависимости от значения флага. В таких случаях следует подумать о разбиении данной функции на две. Разное поведение функции в зависимости от переданного флага не всегда очевидно.
7. Дублирующий код следует выносить в отдельную функцию.
Код внутри setOnClickListener отличается только стилем. Этот код стоит вынести в отдельный метод:
8. Не передавайте и не возвращайте из функции “null” когда можно вернуть пустой объект.
Это позволит избежать ошибок NullPointerexception и не нужно будет в местах вызова писать проверки на null.
Kotlin поможет отучиться от вредной привычки передавать и возвращать null.)
Форматирование
1. Код в классе должен читаться сверху-вниз как газетная статья в порядке убывания уровня абстракции. Вначале идут публичные функции, затем приватные.
Основная идея совета в том, что при открытии файла программист начинает просматривать его сверху. Если вначале разместить все публичные функции, то легче будет понять основные операции с объектами класса, ответственность класса и где может использоваться. Данный совет подходит, когда проект строится на интерфейсах.
2. Связанные концепции/функции следует размещать рядом, чтобы не было необходимости постоянно перемещаться по файлу вверх-вниз. Если одна функция вызывает другую, то вызываемая функция должна располагаться под вызывающей функцией (если это возможно) и разделяться пустой строкой.
Данный совет может противоречить предыдущему. Выбрав приоритетный совет для команды, стоит придерживаться его на всем проекте.
3. Каждая последовательная группа строк кода должна представлять одну законченную мысль. Мысли отделяются друг от друга в коде с помощью пустых строк, только слишком злоупотреблять пустыми строчками не стоит
Связанная группа строк это как абзацы в статье. Для разделения абзацев используется красная строка или пустая строка. Так и в коде следует разделять разные по смыслу группы строк, используя пустые строки.
4. Переменные экземпляра класса, статические константы должны быть все в начале класса в одном месте.
В начале класса объявляются публичные константы, затем приватные константы и после них идут приватные переменные.
5. Используйте пробелы для повышения читаемости кода
- в математических операциях для отделения символа операции от операндов: int x = a + b;
- отделения параметров функций: private Article createNewArticle(String title, String description)
- передаваемых параметров функции: createNewArticle(title, description)
6. «Магические цифры, строки» должны быть вынесены в константы .
Пожалуй, самый популярный совет, но все равно продолжают его нарушать.
Лишь прочитав постановку задачи я понял, для чего в коде использовалось число “10”. Лучше это число вынести в константу и дать осмысленное имя.
Строки тоже стоит выносить в константы, особенно если используются в более чем одном месте.
Классы
1. Класс должен иметь одну “ответственность”, одну причину для изменения.
К примеру, наследники класса RecyclerView.Adapter должны отвечать за создание и связывание View с данным. В нем не должен находится код сортировки/фильтрации списка элементов.
Часто в файл с Activity добавляют класс RecyclerView.Adapter, что является не правильным.
2. Не нужны пустые методы или просто вызывающий метод из родительского класса
3. Если переопределяете какой-то метод без вызова метода родительского, то проверьте, что так можно делать.
Загляните в исходники родительских классов, документации. Переопределяемые методы жизненного цикла Activity, Fragment, View должны обязательно должны вызывать методы родительского класса.
Есть аннотация @CallSuper , предупреждающая о необходимости вызывать родительский метод при переопределении.
Советы о разном
1. Используйте средства Android Studio для улучшение качества Вашего кода.
Если она подчеркивает или выделяет код, значит что-то может быть не так. В Android Studio есть средства Rearrange, Reformat, Extract Method, Inline Method, анализаторы кода, горячие клавиши и т.д.
2. Не нужно комментировать каждый метод, код должен быть самодокументированным.
Следует отметить, что комментарии должны пояснять намерения и причины, а не поведение кода. Создавая комментарий, необходимо брать на себя ответственность о поддержании комментария в актуальном состоянии.
3. Строки, цвета, размеры должны быть в ресурсах (xml)
Не нужно писать:
Исключения составляют файлы из папок test, mock. Такие файлы не должны попадать в релизную версию
4. Не нужно передавать context в RecyclerView.Adapter. context можно получить из любой view. Элемент по клику в RecyclerView.Adapter должен меняться через notifyItemChanged, а не непосредственным изменением вьюшек в методе обработки нажатия
В методе onClick непосредственно происходит вызов bindViewHolder , что НЕ правильно.
5. В RecyclerView.ViewHolder вместо определения позиции объекта в списке нужно вызывать getAdapterPosition, а не передавать position из метода onBindViewHolder
Правильно писать:
Либо можно вместо позиции передавать ссылку на исходный объект с данными
6. Используйте Quantity Strings (Plurals) для множественного числа. Вместо написания в коде логики по подбору правильного окончания слов.
7. Не сохраняйте большие данные Bitmap в bundle. Размер bundle ограничен
8. Если прописать “id” в xml, то Android сам восстановит состояние стандартных View при повороте.
Источник