Attackers might be trying to steal your information from battle.hexlet.io (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
IMHO единственная полезная информация для пользователей хабра, это упоминание интересной тулзы от интела lib houdini (которая, стоит заметить, упомянута в статье с орфографической ошибкой)…
основная проблема в том, что невозможно померить за один проход LinearLayout (LL) в котором есть веса. Все элементы, у которых есть веса будут мерится два раза. Если будут вложенные LL, то количество измерений будет расти экспоненциально. например LL1 содержит в качестве ребенка LL2 у которого стоит вес. Все дети LL1 у которых нет веса измерятся один раз, у которых есть измерятся два раза. Все дети LL2 у которых нет весов измерятся два раза, а у которых он есть уже 4 раза. померить некоторые вью довольно тяжело.
RelativeLayout расставляет все за один проход, но этот проход довольно сложный.
поэтому конкретно ответить на этот вопрос нельзя.
часто лучше написать кастомный контролл, который все по-быстрому расставит. чем пытаться собрать лейаут из универсальных блоков.
у меня вектор, есть еще kickr, в студии есть таксы. Все показывают более-менее если правильно настроено/собрано/подключено. недавно друг тестировал stages, говорит сильно врет )
так и пишите, что если координаты вью в пикселях (pt/mm/dp/sp), либо достаточно стандартной gravity. Что такое «строго» в вашем варианте хрен поймешь.
Margin – отъедает место у самого элемента, padding – у окружения
это вообще все неверно. Margin это отступы, которые учитывает родительский элемент при позиционировании ребенка, у которого задано Margin. Не все ViewGroup поддерживают Margin и на размер ребенка Margin напрямую не влияет. Так как Margin не принадлежит геометрии ребенка, то и клики ребенку не доходят из этой области, они идут родителю. Padding же работает подругому. Сама View, у которой он задан занимается его расчетом. Например, view не учитывает паддинг когда рисует свой фон, но учитывает его и делает отступы для своего содержимого.
вы так написали, что «возьмем rtos, нагородим очередей и все полетит»
очереди пораждают не меньше проблем, чем не очереди, всем надо уметь пользоваться. Можно послать много команд и переполнить очереди, контроллер может сгенерить много данных и переполнить очередь, точно так же как и переполнить буфер, который был до этого. По сути то разницы никакой нет, что переполнять. Да и очереди надо обслуживать, например в некоторых ситуациях их надо очищать, выкидывать что-то древнее…
Проблема большого количества данных решается на уровне потока передаваемых данных (USART в данном случае), для чего есть специальные сигналы/команды приостанавливающие передачу.
протоколы, которые позволяют выполнять команды паралелльно сложней. в первом варианте все просто, запрос(з)->ответ(о). А вот во втором (где можно з, з, з, о, з, о, з, з...) уже надо прописывать записимости между командами, что нельзя выполнять какую-то, пока не получим ответ на предыщую. может так получится, что контроллер будет выполнять команды из более приоритетных очередей или будет не успевать их выполнять и уставка на мотор будет запаздывать.
с некоторой сложности проекта, конечно нужно использовать RTOS, ее вообще можно использовать в прицнипе всегда, так как пустая, она практически ничего не весит.
П.С. Ваш программист из примера, который грамотно может расставить мьютексы в сложном приложении, странный. Раз он может сделать это, то уж точно догадается использовать очереди, если этот вариатн будет лучше ) очередь вообще простая структура, ее и без RTOS можно накидать.
киловатт выдать не проблема, у меня максималка 1500Вт за 5с (средний любитель). Проблема держать мощность более-менее длительное время. Например, с моими 76кг я в час среднюю могу выдать 300Вт. Ребята из сборной в районе 400Вт. В общем вскипятить чай можно за приемлимое время ))
да ваша правда, стормозил. теперь наш девайс еще и просыпается каждые 30 секунд. ну ладно у нас одно такое приложение. а теперь ставим 10 таких приложений с вашим подходом… да это какоето зло, постоянно просыпаемся, пишем в файловую систему. а если девайс у нас слабенький и андоид решает выгрузить наше приложение… то создаем процесс, грузим в него VM, стартуем потоки, инициализируем все, ставим маленький флажок (читаем и пишем на файловую систему) потом все это прибиваем, выгружаем… а теперь поставим 20 таких приложений, тут уже и хороший девайс начнет прибивать аппы и постоянно их создавать чтобы обработать аларм…
И еще в новых андроидах есть elapsedRealtimeNanos то есть почти все что вы сделали, можно выкинуть, а в старых есть почти полноценная замена uptimeMillis. Его на нерутованном девайсе уже хрен изменишь.
Я вообще не понимаю что вы написали. setRepeating alarm вообще может не вызываться если девайс спит (то что ваш не спит, это другой вопрос). System.currentTimeMillis() и RTC_WAKEUP это wall clock, то есть я переведу время на 10с назад и все аларм сработает на 10с раньше, чем должен. я вообще могу не трогая ваш код постоянно ускорять или замедлять ход времени у вас написав простенький скрипт. Еще ваш времямер будет работать только если приложение не на карточке. вы всегда делаете incrementTimeAndSaveSystemTime на фиксированный интервал, и пофиг что ночью был спил и мы не вызывались часов 7 подрят, мы просто приплюсуем +=TIME_PERIOD. А зачем вы всегда используете currentTimeMillis? То есть я честный пользователь, приехал к бабушке в другой часовой пояс, а мне ваша система все блокирует и говорит что я хакет и пытаюсь вас обмануть и перевожу часы назад? Почему бы не использовать nanoTime и аларм шедьюлить тоже в nanoTime?
кстати подарили 150р, после того как заполнил свои данные, как одному из первых пользователей, я доволен ) думаю всем была доступна такая возможность. Пока все отлично работает, не считая багов зарепорченных в первое время. В субботу попробую оплатить аэроэкспресс )
я вообще мечтаю о волшебной корзине. в нее можно скидывать все устройства (фонарики, велокомпьютеры, трекеры, часы...), сверху еще ноутбуком прикрыть, и вся эта куча заряжается. еще я мечтаю о стене. к этой волшебной стене можно прикреплять устройства (на магнитах, например) и они висят на стене, не теряются и заряжаются ) за беспроводной зарядкой будущее, провода уже никому не нужны.
Записался на тестирование. Но вообще могли бы и чтонить давать ) майку, например, скидку на телефоны htc, пару баксов на счет, ну или занесение в список почетных тестеров на сайте )) А то время тратишь, неудобства терпишь (помню както виджеты от яндекса, убили рабочий стол), а в ответ ничего.
И вы вашим асинктаском, который просто ждет неизвестно сколько времени, блокируете от выполнения другие асинк таски. Экзекьютор для асинктасков однопоточный с 4й версии андроида.
Я чего-то не понимаю, или вы решили согреть пользователя? while (this.mLocation == null && System.currentTimeMillis() - sec < TIME_OUT) {}
Да и доступ к переменной mLocation никак не синхронизирован. Вы же читаете ее в цикле из другого потока…
поставить напоминалку в каледарь не? я ставлю всякие банальные напоминалки «первый раз увидел», «первый поцелуй», «первый ...», а потом тролю подругу, тем что сегодня 100 дней с того момента как мы первый раз сходили в кино, а она не помнит )
мне всегда интересно как htc удается делать такие хорошие фотографии? Мой One даже близко так не фотает ) Когда светло я доволен, а вот вечером или когда пасмурно — все в шумах.
RelativeLayout расставляет все за один проход, но этот проход довольно сложный.
поэтому конкретно ответить на этот вопрос нельзя.
часто лучше написать кастомный контролл, который все по-быстрому расставит. чем пытаться собрать лейаут из универсальных блоков.
так и пишите, что если координаты вью в пикселях (pt/mm/dp/sp), либо достаточно стандартной gravity. Что такое «строго» в вашем варианте хрен поймешь.
это вообще все неверно. Margin это отступы, которые учитывает родительский элемент при позиционировании ребенка, у которого задано Margin. Не все ViewGroup поддерживают Margin и на размер ребенка Margin напрямую не влияет. Так как Margin не принадлежит геометрии ребенка, то и клики ребенку не доходят из этой области, они идут родителю. Padding же работает подругому. Сама View, у которой он задан занимается его расчетом. Например, view не учитывает паддинг когда рисует свой фон, но учитывает его и делает отступы для своего содержимого.
очереди пораждают не меньше проблем, чем не очереди, всем надо уметь пользоваться. Можно послать много команд и переполнить очереди, контроллер может сгенерить много данных и переполнить очередь, точно так же как и переполнить буфер, который был до этого. По сути то разницы никакой нет, что переполнять. Да и очереди надо обслуживать, например в некоторых ситуациях их надо очищать, выкидывать что-то древнее…
Проблема большого количества данных решается на уровне потока передаваемых данных (USART в данном случае), для чего есть специальные сигналы/команды приостанавливающие передачу.
протоколы, которые позволяют выполнять команды паралелльно сложней. в первом варианте все просто, запрос(з)->ответ(о). А вот во втором (где можно з, з, з, о, з, о, з, з...) уже надо прописывать записимости между командами, что нельзя выполнять какую-то, пока не получим ответ на предыщую. может так получится, что контроллер будет выполнять команды из более приоритетных очередей или будет не успевать их выполнять и уставка на мотор будет запаздывать.
с некоторой сложности проекта, конечно нужно использовать RTOS, ее вообще можно использовать в прицнипе всегда, так как пустая, она практически ничего не весит.
П.С. Ваш программист из примера, который грамотно может расставить мьютексы в сложном приложении, странный. Раз он может сделать это, то уж точно догадается использовать очереди, если этот вариатн будет лучше ) очередь вообще простая структура, ее и без RTOS можно накидать.
while (this.mLocation == null && System.currentTimeMillis() - sec < TIME_OUT) {}Да и доступ к переменной mLocation никак не синхронизирован. Вы же читаете ее в цикле из другого потока…