Есть и ещё один в меру костыльный вариант, но который не требует наличия того же решарпера. По сути, вся задача сводится к тому, чтобы при добавлении нового элемента в enum, switch кидал ошибку при компиляции. Добиться этого можно, добавив дополнительное значение в enum и проверку времени компиляции в switch. Выглядит примерно так:
Есть enum:
- enum Test {
- A
- }
Есть switch с элементами enum:
- Test value = Test.A;
- switch (value) {
- case Test.A:
- ...
- break;
- default:
- throw new ArgumentOutOfRangeException();
- }
3.1. Добавляем в enum элемент Last:
- enum Test {
- A,
- Last
- }
В нашем случае элемент Last — число 1, т.к. по умолчанию члены enum — константные целые числа от 0 по возрастанию.
3.2. Добавим специальный код в switch:
- Test value = Test.A;
- switch (value) {
- case Test.A:
- ...
- break;
- case Test.Last:
- const int _ = 1 / (1 / (int) Test.Last)
- throw new ArgumentException();
- default:
- throw new ArgumentOutOfRangeException();
- }
Выражение 1 / (1 / (int) Test.Last) будет вычислено во время компиляции. В случае, если Last будет больше второго числа (1 в скобках), то второе частное будет равно 0, что приведёт к делению на 0 во время компиляции и выкинет ошибку. Как только решили добавить новое значение в enum, его нужно добавить перед Last, чтобы значение Last увеличилось.
Конечно же здесь есть недостатки:
Добавляется ещё одна проверка в switch — overhead в runtime
Можно применять только в случае, когда элементы в enum — возрастающие числа, а Last — последний элемент
Нужно помнить, зачем в enum элемент Last
Но тут уже нужно самим решить, стоит оно того или нет в конкретном случае.
P.S. если кто-то знает, как отключить в markdown хабра удаление пробелов в начале строки, welcome
Тут ещё флагманская серия самсов есть. S10e прям идеал, но камера может кому-то не зайти + 60 герц. Остальные длиннее, но по ширине узкие, так что если фактор "удобно в руке держать", то тоже зайдёт
Да, всё так. Я лишь привёл пример, когда "эта фича котлина даёт что-то полезное" - при работе котлина с котлином (ещё есть работа котлина с аннотированный джава, но тут уже польза чуть более субъективна)
Так это, все манипуляции с null сделаны с одной целью: проверки на null в compile time при условии, что идёт работа котлина с котлином. Ни о каком null safe вообще везде речи и не идёт. Поэтому да, если у вас проект на джаве, то у вас будут проблемы с null в тот момент, когда вы начнёте добавлять котлин. Со временем же, когда нового кода на котлине станет больше, проверки уже будут выполняться в compile time, в этом и основной смысл. Насчёт JNI/JNA чутка не понял. Если код для того же JNI уже написан на джаве, то получаем взаимодействие котлина с джавой, если на котлине, то получаем взаимодействие котлина с котлином, тем самым сводя ситуацию к ситуации с исходным интеропом
Ну, я, к примеру, работал. Разрабатывал лончер под андроид. По ночам я не работал. Более того, как рабочий день заканчивался, просто уходил (не в том смысле, что везде запара, а мне плевать, а в том, что и запары нет, просто на след день доделаю, что нужно). Из того, чтобы работать по ночам знаю только 1 пример: есть команда, которая отвечает за работоспособность сервисов. У них есть ночные дежурства, тип смотреть, чтоб всё работало. Но и то, опять же, со слов челика, который там работал (возможно, и работает, но я не знаю), это не то, что ты сидишь и тупишь в монитор, а то, что если возникнет какая проблема, то тебе нужно будет встать, собраться и её поправить
Не могу сказать ничего по большей части комментария, т.к. там чисто личные предпочтения (переключение девайсов/громкость), но чутка проясню по поводу магнитного колеса.
Сейчас просто пользуюсь MX Master 2s, у которой это самое колесо есть. Там тоже 2 режима, как вы и сказали, один — обычное колесо, второй — колесо с свободной прокруткой, т.е. провёл и оно вращается, пока сила тяжести и трения не остановят.
Сначала пробовал этими режимами по отдельности пользоваться, но получалось не очень удобно (первым режимом неудобно длинные статьи листать, а вторым — код, где нужно на конкретном месте останавливаться). Но есть возможность эти два режима совместить. Можно настроить силу вращения колеса, при которой оно переходит из первого во второй режим. Тогда на малые расстояния можно мотать в первом "точном" режиме, а если надо пролистать что-то большое, то закрутить быстрее. После недели использования это уже вошло в привычку и дико удобно.
Это всё на случай, если вдруг решите когда-нибудь попробовать снова, и этот момент будет критичным
Полностью согласен (кроме неверного вывода). Вот только в исходном сообщении, на которое я отвечал, вы явно имели ввиду не тот случай, когда мы можем от пользователя что-то узнать, чтобы эту самую вероятность тупика уменьшить. А именно, что хотели ответ на общий вопрос, когда этой информации нет (собственно, фраза
которая была заведена с какими-то учетными данными (например, временный email Apple), при условии, что он не помнит, с какими, и возможности вспомнить у него нет
об этом и говорит). Если же вы всё-таки хотели узнать способ об уменьшении вероятности тупика, о чём сказали сейчас, то я не понимаю, чем мой ответ не подошёл. Он то как раз о действиях со стороны разработчика, которые могут эту самую вероятность уменьшить
Вполне себе читал. Вот только отвечать на вопрос в общем смысле, в котором хотите его знать вы, бесполезно, потому что ваш вопрос изначально подразумевает невозможность этой самой поддержки. Если я правильно понимаю, о чём вы говорите, то речь идёт об идентификации пользователя в том случае, когда он не обладает никакой информацией вообще. Т.е. не знает ни почту, с которой заходил, ни когда он заходил, ни ip, с которого заходил, вообще ничего. Если он ничего этого не знает, то и помочь ему никак нельзя, тут даже в теории нечего предложить. Именно поэтому и «это тогда проблема клиента» для данного конкретного общего вопроса не то, что годится, а единственный возможный вариант.
Но если таки допустить, что пользователю что-то известно (любая информация из приложения или как он его использовал), то можно накидать кучу рабочих вариантов, один из которых я привёл.
А то ваш вопрос говорит о том, что пользователь ничегошеньки не знает, но при этом мы должны как-то о нём информацию достать, а вот это как раз и будет телепатией, которой *кхе-кхе* пока ещё никто не научился
К примеру, добавлять отдельное поле "email для ответа" на экран для сообщений об ошибках. А при нажатии на "Отправить" в этом же окне кидать на сервер уникальный идентификатор аккаунта пользователя (хоть актуальный email, тут что больше нравится) и email. Так и пользователя на сервере определить можно, и понятно, куда писать
Тут основной плюс — кодогенерация. На больших проектах, где куча классов, dagger может выиграть пару десятков или иногда сотен миллисекунд на старте приложения чисто из-за отсутствия необходимости строить все графы зависимостей в рантайме. Пример сравнения производительности тут: https://github.com/Sloy/android-dependency-injection-performance
Есть и ещё один в меру костыльный вариант, но который не требует наличия того же решарпера. По сути, вся задача сводится к тому, чтобы при добавлении нового элемента в enum, switch кидал ошибку при компиляции. Добиться этого можно, добавив дополнительное значение в enum и проверку времени компиляции в switch. Выглядит примерно так:
3.1. Добавляем в enum элемент
Last:В нашем случае элемент Last — число 1, т.к. по умолчанию члены enum — константные целые числа от 0 по возрастанию.
3.2. Добавим специальный код в switch:
Выражение
1 / (1 / (int) Test.Last)будет вычислено во время компиляции. В случае, если Last будет больше второго числа (1 в скобках), то второе частное будет равно 0, что приведёт к делению на 0 во время компиляции и выкинет ошибку. Как только решили добавить новое значение в enum, его нужно добавить перед Last, чтобы значение Last увеличилось.Конечно же здесь есть недостатки:
Last— последний элементLastНо тут уже нужно самим решить, стоит оно того или нет в конкретном случае.
P.S. если кто-то знает, как отключить в markdown хабра удаление пробелов в начале строки, welcome
С помощью котлина можно сделать всё, что можно сделать с помощью джавы. И акселерометр и жизненный цикл
Иии, я был неправ. Нельзя так сделать в шарпе. Так что да, новый new вполне оправдан и тут
deleted
Тут ещё флагманская серия самсов есть. S10e прям идеал, но камера может кому-то не зайти + 60 герц. Остальные длиннее, но по ширине узкие, так что если фактор "удобно в руке держать", то тоже зайдёт
Кажется, баг)
Но можно написать v.invoke(), что уже скомпилится
А, ну если не имелось, тогда всё ок, ограничения действительно есть, тут не поспоришь
Да, всё так. Я лишь привёл пример, когда "эта фича котлина даёт что-то полезное" - при работе котлина с котлином (ещё есть работа котлина с аннотированный джава, но тут уже польза чуть более субъективна)
Так это, все манипуляции с null сделаны с одной целью: проверки на null в compile time при условии, что идёт работа котлина с котлином. Ни о каком null safe вообще везде речи и не идёт. Поэтому да, если у вас проект на джаве, то у вас будут проблемы с null в тот момент, когда вы начнёте добавлять котлин. Со временем же, когда нового кода на котлине станет больше, проверки уже будут выполняться в compile time, в этом и основной смысл. Насчёт JNI/JNA чутка не понял. Если код для того же JNI уже написан на джаве, то получаем взаимодействие котлина с джавой, если на котлине, то получаем взаимодействие котлина с котлином, тем самым сводя ситуацию к ситуации с исходным интеропом
Ну, я, к примеру, работал. Разрабатывал лончер под андроид. По ночам я не работал. Более того, как рабочий день заканчивался, просто уходил (не в том смысле, что везде запара, а мне плевать, а в том, что и запары нет, просто на след день доделаю, что нужно). Из того, чтобы работать по ночам знаю только 1 пример: есть команда, которая отвечает за работоспособность сервисов. У них есть ночные дежурства, тип смотреть, чтоб всё работало. Но и то, опять же, со слов челика, который там работал (возможно, и работает, но я не знаю), это не то, что ты сидишь и тупишь в монитор, а то, что если возникнет какая проблема, то тебе нужно будет встать, собраться и её поправить
Не могу сказать ничего по большей части комментария, т.к. там чисто личные предпочтения (переключение девайсов/громкость), но чутка проясню по поводу магнитного колеса.
Сейчас просто пользуюсь MX Master 2s, у которой это самое колесо есть. Там тоже 2 режима, как вы и сказали, один — обычное колесо, второй — колесо с свободной прокруткой, т.е. провёл и оно вращается, пока сила тяжести и трения не остановят.
Сначала пробовал этими режимами по отдельности пользоваться, но получалось не очень удобно (первым режимом неудобно длинные статьи листать, а вторым — код, где нужно на конкретном месте останавливаться). Но есть возможность эти два режима совместить. Можно настроить силу вращения колеса, при которой оно переходит из первого во второй режим. Тогда на малые расстояния можно мотать в первом "точном" режиме, а если надо пролистать что-то большое, то закрутить быстрее. После недели использования это уже вошло в привычку и дико удобно.
Это всё на случай, если вдруг решите когда-нибудь попробовать снова, и этот момент будет критичным
Но если таки допустить, что пользователю что-то известно (любая информация из приложения или как он его использовал), то можно накидать кучу рабочих вариантов, один из которых я привёл.
А то ваш вопрос говорит о том, что пользователь ничегошеньки не знает, но при этом мы должны как-то о нём информацию достать, а вот это как раз и будет телепатией, которой *кхе-кхе* пока ещё никто не научился
К примеру, добавлять отдельное поле "email для ответа" на экран для сообщений об ошибках. А при нажатии на "Отправить" в этом же окне кидать на сервер уникальный идентификатор аккаунта пользователя (хоть актуальный email, тут что больше нравится) и email. Так и пользователя на сервере определить можно, и понятно, куда писать
Тут основной плюс — кодогенерация. На больших проектах, где куча классов, dagger может выиграть пару десятков или иногда сотен миллисекунд на старте приложения чисто из-за отсутствия необходимости строить все графы зависимостей в рантайме. Пример сравнения производительности тут: https://github.com/Sloy/android-dependency-injection-performance