Денис Загаевский я как раз поэтому и поблагодарил, я всегда думал, что при передаче через Bundle у нас на другой стороне получается _копия_ исходного объекта, и писал свой код исходя из этой неверной предпосылки.
> очень не рекомендуется править историю коммитов.
А если коммит локален, и в общий репозиторий ещё не ушёл? В Меркуриале я могу с помощью расширения strip вырезать ненужный коммит, и ни к каким проблемам это не приведёт, тем более если коммит был никак связан с коммитами до и после. В Git наверняка есть подобные возможности.
Как раз таки усложнения кода тут никакого не происходит, наоборот упрощение. Если у вас в функции десяток строчек, каждая из которых потенциально может выбросить исключение, то проще написать все эти десять строчек, обернуть их в try, а затем в отдельных catch clauses писать реакцию на выброшенное исключение. Если же все методы в случае ошибки будут возвращать null-значение (или какой-то особый код, описанный в контракте метода), то у вас нормальный код смешается с кодом по обработке ошибок, то есть нормальный flow метода будет перемежаться конструкциями вида if (result == null) { doSomething(); }, что сильно усложняет чтение кода.
Более того, в случае nextInt() могут быть выброшены три разных исключения, и обрабатывать их нужно по-разному. Если вы будете возвращать null, то потеряете ценную информацию о том, что случилось, и не сможете описать правильную реакцию на возникшую ошибку.
> возможно ли кодинг отдать одному, а верстку другому
Отдайте половину экранов одному, а половину - другому. Пусть они находятся в постоянном контакте друг с другом, чтобы была возможность обсуждения текущей разработки, общего функционала и так далее.
Чтобы на всех экранах, вне зависимости от размера и плотности, надпись отрисовывалась одинаково. Альтернатива - использовать крупное изображение, которое будет подгоняться под каждый экран, но наш дизайнер сказал, что ему не нравится как выглядит изображение, которое было подогнано - слишком "мыльное".
Начинающие очень часто формулируют свои вопросы так, что нужно догадываться, что они имели в виду. В данном случае наверняка имелось в виду: "Как мне создать такую кнопку в Андроид-приложении?"
Rou1997 Это интернет, он так работает. Кто-то задал вопрос, вы дали ответ, ваш ответ стали комментировать, указывать, что в нём неправильно, или же уточнять непонятные места. Никто не ставит перед собой задачу вас унизить, или же смешать с грязью. Это обычная беседа, в которой рождается истина, и не нужно воспринимать так близко к сердцу то, что ваши ответы не воспринимают на веру, а подвергают анализу. У вас же вторую неделю периодически бомбит на тему того, что я и другой пользователь Тостера указали вам на неправильность некоторых ваших ответов, которые вы излагали с прямо-таки религиозной фанатичностью. Успокойтесь уже.
Gizmothron вообще, если в Go-community и правда все повсеместно используют 8 символов, то это круто. Просто в моём мире Android-программирования разброда и шатания чуть побольше, посему и сужу со своей колокольни. :)
Gizmothron мы о чём сейчас беседуем, о том, как работает go fmt, или о том, какие бенефиты даёт принятый в Go стиль форматирования? Я не знаю, как работает go fmt, более того, я ни одной строчки кода на Go не написал, я просто говорю, что восьмисимвольные отступы приняты в Go не потому, что это научно доказанная правильная длина отступов, а потому, что Робу Пайку так больше нравится. Если какой-то команде больше нравится 4-х символьная длина - бог с ними, пусть используют, главное чтобы единство стиля было внутри команды.
Gizmothron так я же и не спорю, что единый стиль - это удобно. Я про то, что идея об одинаковости стиля кода во всем мире - утопия. В той же Java, в Java Code Conventions указано - отступ в 4 символа. Но есть очень известная фирма Square, написавшая четверть общеиспользуемых Android-библиотек, и они используют 2-х символьный отступ. Половина Android-программистов используют венгерскую нотацию для именования переменных, потому что так выглядит код AOSP, вторая половина использует принятое в Java именование, без всяких инфиксов. Так устроен мир, каждая команда выбирает свой стиль написания кода.
Можно запретить диалогу обрабатывать события нажатия. Попробуйте вызывать на корневой вьюхе диалога setEnabled(false), setClickable(false), или же зарегистрируйте ещё один OnTouchEventListener на корневой вьюхе диалога, и в onTouch() возвращайте false.
Wissen Wissen да, сорян, там скобочка в конце добавилась: cucumbler.ru/blog/articles/nastrojka-pycharm-dlja-... . Вообще штука удобная, после того как настроите ide, погуглите туториалы по работе с PyQt, там все очень просто. Кстати у меня диплом очень отдалённо был похож на ваше приложение - в общих чертах, я там на CUDA проводил операции над матрицами, и выводил результаты на экран. Моделировал порообразование в малых металлических частицах.
