У меня, скорее всего, что-то подобное с логикой MTP и PTP на телефоне. Фотографии копируются идеально, пока у них не появляются 'сателлиты' с одинаковым временем съемки и датой, отличающейся всего на одну цифру в дне. Как только это случается, телефон отдает более свежую фотографию под более старым именем.
Я вот давно мучаюсь с байндингами для Zendesk SDKs. Точнее как, оно работает почти всегда, но иногда даже запустить приложение не удаётся, так как что-то не до конца работает, а их поддержка отказывается помогать, так как они не работают с Xamarin. Ну и сам процесс создания отличается сильно от справочной статьи в худшую сторону.
Знакомому в Сиднее пришел штраф за выезд на выделенную полосу для общественного транспорта когда он пропускал скорую. Оспорить самостоятельно не получилось, но терять время в суде не захотел, пришлось оплатить.
Мы как-то за световой день из Аделаиды до Элис Спрингс доехали с продолжительной остановкой в Кубер-Педи. Если бы не ограничение по времени на следующий день были бы в Дарвине, а так пришлось повернуть к побережью. В NT ограничение 130, но некому за этим следить, поэтому все зависит от машины и водителя. Но мой случай скорее исключение, так как расстояние самое короткое и дорога самая прямая.
Насколько я знаю, многие крупные игроки, такие как Commonwealth Bank и Westpac, уже давно осуществляют бесконтактные платежи подобно Apple Pay. Мне, как клиенту CBA, вообще непонятно зачем использовать Apple Pay когда я уже больше двух лет могу оплачивать любые покупки с телефона через банковское приложение (на мой взгляд лучшее в своей категории).
Половина энтерпрайза все еще использует document.write, некоторые даже в относительно новых продуктах. Все зависит от того, какой ответ нагуглился и заработал первым у «талантливого» offshore разработчика.
А вот такой вопрос — сколько, по-вашему, стоит такая находка? Я согласен, что $15000 звучит немного, даже мало, но как определить верхний предел? Один человек даст максимум бутылку за доступ к аккаунту подруги, а другой готов состояние отдать, чтобы вытащить коммерческую тайну из переписки конкурента.
Я немного не понял (даже после прочтения вашей статьи) как Eddystone устраняет все недостатки. Если он настроен на передачу URI, то решается проблема множества приложений, так как их заменяет браузер. Если же он настроен как часть Google's beacon platform, то какая разница как он себя представляет (Eddystone, iBeacon, etc), если необходимо отдельное приложение, которое будет соединяться с облаком и вытягивать метаданные по идентификатору маячка? Кроме того, насколько я понимаю, база маячков будет создаваться опять же под конкретное приложение, соответственно, если у каждого торгового центра свое приложение, то придется ставить их все.
Я, конечно, тоже за грамотность, но, если честно, меня сильно удивило, что у статьи про довольно интересную и сложную вещь всего один комментарий, и тот — про орфографию… Вы бы по делу прокомментировали.
Настоятельно рекомендую адаптер из статьи. Приобрел два таких (черный и белый) перед поездкой по Европе и Азии — очень удобно! Одно «но» — телефон на Android заряжается медленнее через встроенный порт, чем через собственную зарядку. У iPhone вроде как все хорошо.
В рамках одной Activity можно и View использовать. У них тоже будет отдельных код в своих классах. Ну вот если вам нравится их использовать, расскажите мне, пожалуйста, почему? Неужели только из-за того, что два фрагмента умещаются на одной Activity? Должны же быть весомые преимущества? Я серьезно не понимаю и хочу разобраться уже долгое время.
Что касается ада — это я про диаграмму по вышеприведенной ссылке.
В общем, автор пришел к тому же, что и я: фрагменты необходимы только для красивой бесшовной анимации между экранами, либо (это я уже от себя) как элемент SDK, чтобы сторонние разработчики могли легко интегрировать элементы интерфейса в свои экраны, не нарушая иерархии своих Activity.
Но, как показывает практика, если нет требования о стопроцентной плавности UI, можно анимацию перехода и на Activity реализовать. Так, в приложении Google IO паттерн Navigation Drawer работает с Activity, каждая из которых имеет в своем составе Drawer, а переход осуществляется через fade in/out контента параллельно с анимацией самого Drawer'a. В приложении, над которым я работаю, я применил похожий подход, когда элементы одной Activity подводятся анимацией к реперным точкам, запускается новая Activity с отключенной анимацией перехода и копиями вышеупомянутых элементов в тех же реперных точках, а затем элементы разводятся анимациями по своим местам. Да, чуть-чуть лагает, но не настолько, чтобы погружаться в ад фрагментов.
Что касается ада — это я про диаграмму по вышеприведенной ссылке.
В общем, автор пришел к тому же, что и я: фрагменты необходимы только для красивой бесшовной анимации между экранами, либо (это я уже от себя) как элемент SDK, чтобы сторонние разработчики могли легко интегрировать элементы интерфейса в свои экраны, не нарушая иерархии своих Activity.
Но, как показывает практика, если нет требования о стопроцентной плавности UI, можно анимацию перехода и на Activity реализовать. Так, в приложении Google IO паттерн Navigation Drawer работает с Activity, каждая из которых имеет в своем составе Drawer, а переход осуществляется через fade in/out контента параллельно с анимацией самого Drawer'a. В приложении, над которым я работаю, я применил похожий подход, когда элементы одной Activity подводятся анимацией к реперным точкам, запускается новая Activity с отключенной анимацией перехода и копиями вышеупомянутых элементов в тех же реперных точках, а затем элементы разводятся анимациями по своим местам. Да, чуть-чуть лагает, но не настолько, чтобы погружаться в ад фрагментов.