Касательно шаговой доступности. А если из строя выйдет STM32? или слетит прошивка по какой либо причине? Логичнее ацп было сделать модульным для быстрой замены в случае чего. По поводу реле, в своем доме для автоматизации переключения фаз я использовал магнитные пускатели с контакторами и таймерами. В принципе выполняется то же самое действие что и у автора, только переключаются фазы при пропадании одной фазы. Сейчас собираюсь это дело впихнуть в экосистему дома для удаленного контроля и мониторинга, и мне будет достаточно только 1 контроллера и несколько реле, даже конструкцию не придется разбирать и переделывать.
Все магнитные пускатели стоят в собственном распределительном шкафу в подъезде, где может присутствовать как влажность (при прорыве трубы горячей воды в подвале поднимается сильный пар на первых этажах подъездов, где собственно и установлен шкаф) и низкие температуры, так и совсем низкая влажность с температурой под 45-50 градусов, и за почти 4 года эксплуатации не вышло не одного пускателя из строя, и вся система в целом работает в нормальном режиме.
Нагрузка на пускатель достигает 90А в зимний период
Если мне память не изменяет, то 3 андроид только для планшетов был. И там гугл сам чуть ли не настаивал на использовании фрагментов. Просто там дизайн в приложениях был таков что менялись части активити, а не вся активити. То есть фрагменты изначально и были созданы для того что бы изменить часть активити не прибегая к полной ее перезагрузки (заменить ее фрагмент), а так же фрагменты были и есть предназначены для повторного использования кода. Например вам нужно показать один и тот же участок с логиков в разных окнах, тут на помощь как раз и приходят фрагменты. Или что бы в 1 активити не плодить тонну заменяемых объектов, которые могут замедлить работу приложения. Но фрагменты никак не панацея. Нужно уметь разделять понятие фрагментов и активити. Активити это окно грубо говоря, а фрагмент — это фрагмент этого окна.
Мне данный момент в ios нравится, там на подобии фрагментов есть ContainerView, который используют в главном окне что бы разделить какую то логику в окнах. Но там это реализовано так, что разработчик не хочет использовать это повсеместно, а лишь использует при необходимости и только там где это реально нужно
Увы такая мода если новое что то выходит это используют повсеместно, потом начинают осознавать что это не есть хорошо
Просто вы завуалировали ответ, судя по которому может несколько решений в голову прийти. Я же конкретизировал метод который эстетично подходит для решения данной проблемы, и является общепринятым.
Просто вы пишите статью о том с какими проблемами столкнулись и какие решения приняли, и писать это в общих чертах не есть правильно, немного конкретики не помешает.
Вообще многие описанные проблемы не считая проблемы №6 очень банальны, и если вы пришли в андроид с любого другого языка программирования, то многие эти проблемы должны отпасть сами собой, потому что принципы одни и те же, можно легко на гуглить решение для конкретного языка/платформы
Если данные типа настроек, или сохранение состояния какой либо переменной, то тут лучше использовать SharedPreferences. Реалм очень большой, если для проекта 6-7 мб лишних не проблема то реалм идеальный вариант, если проект весит меньши библиотеки то реалм зло. Я в своем проекте из-за этого использовал Sugar ORM, она не такая шустрая, но если правильно распределить потоки, то особо не заметно, но принцип работы и синтаксис аналогичен реалму, и вес прибавляется всего пара сотен килобайт. Просто пользователи ругались на размер, а у конкурентов был размер на много ниже, из-за этого пришлось попрощаться с реалмом, и визуально в скорости не проиграл
Я думаю SharedPref тут меньше из зол, он даже не даст настолько ощутимого эффекта о котором говорит автор, там что-то по серьезднее запускается. Еще подобный косяк кстати был замечен на сдк >=20, там в анимации активити при переходах иногда бывают затупы, ощущение что они искуственные чтобы перевести все на фрагменты
К слову, фрагмент на то и называется фрагментом, что он заменяет часть GUI, за новое окно отвечает именно Activity. Нужно понимать разницу и разделять эти понятия, каждый метод предназначен для своей задачи
Исключительно на момент старта. Если архитектура правильная то разницы вы абсолютно никакой не увидите. К примеру переделывал свой, довольно большой проект (более 30 уникальных активити) на фрагменты, переделывал исключительно из-за навигации. Так вот по производительности особую разницу я не заметил. Если у вас ощутимо тормозит запуск новой активности, то стоит обратить внимание где именно происходит утечка, видимо что то в основном потоке нагрузочное стартует
Проблема очень эстетично решается через создание синглтона главной активити, в которой происходит управление фрагментами, и уже через синглтон вызывать открытие нового фрагмента
Моя аудитория не больше чем у телеграма, но большая часть моей аудитории не использует телеграм, в этом проблема. Ну и опять таки, как я выше написал, тема дискуссии в том какой пуш сервис выбрал, телеграм не имеет ровно никакого отношения к пуш сервисам. Вы же не напишете в телеграм что бы ползователь открыл приложение
Если он уже его использует, лишнее в нем будет мешать.
+1
2 — вы малоизвестный стартап с неизвестной моделью монетизации. Что с вами будет завтра — непонятно.
Вы излишне ставите акцент на том, что стартап закроется, для этого есть инкубационный период, и блогосфера, где можно следить за развитием стартапа. Телега тоже когда то была стартапом, и принимая во внимание то, что она никак не монетизируется на данный момент, неизвестно именно что с ней будет завтра, Дуров не вечный.
Как говорится не попробуешь, не узнаешь!
По последнему аргументу — один популярный сайт провел опрос по которому становил что 100% граждан пользуются Интернетом. Слать напрямую пуш сложно и для многих нереально. Слать напрямую телеграмм — элементарно.
На самом деле не так элементарно, публика телеграмма крайне ничтожна, приемущественно снг, если делать акцент на глобальность то телеграм тут проигрывает по всем параметрам, как бы Дуров не кричал что они ориентированы на Европу и штаты. Даже в РФ доля телеграмма крайне ничтожна. Я как ITшник даже неприемлю ботов в телеграмме, они меня просто вымораживают, настолько убогая платформа, хотя сам телеграм очень хорош
В статье речь шла именно про пуши внутри приложения, пушовер и тд это уже побочный эффект, именно по этому телега тут вообще никаким боком не может идти. И к тому же, как ниже описали, телега это мессенджер, и должен по идеи использоваться по своему прямому назначению
Отличный развернутый ответ.
Возможно я покажусь консервативным, но считаю что каждый должен заниматься своим делом. Телеграмм был создан как мессенджер, и я вообще не понимаю эти введения как боты и тд, информационные каналы ладно это нормально, но боты, с их инлайн режимом, это извращение какоето. Мессенджеры должны быть мессенджерами, пуш сервисы должны быть пуш сервисами. Сувать все воедино это конечно может показаться хорошей идеей, но с другой стороны это получится помойная яма.
Но это сугубо мое мнение
К слову о пиаре. Я про пиар написал, потому что, беглый осмотр вашего сервиса показал мне то, что ваш сервис не совсем то решение о котором говорится в статье, поэтому я расценил это как пиар. Человек ведь вел речь о выборе платформы перехода, что бы перейти с парса на аналогичный сервис платный/бесплатный.
На счет вашего сервиса я могу заблуждаться, может недоглядел подобную возможность, но на ней по крайней мере не сделан акцент, хотя сервис посвящен пушам
Пушовер таки имеет ряд ограничений в том числе в создании каналов и бесплатных приложений там нет.
Пушовер я привел в пример к вашему сервису, они ведь насколько я бегло успел рассмотреть практически идентичны. К моим нуждам пушовер ну вообще никак не подходит.
Мне нужно было что бы пуши приходили именно в мое приложение, а не куда то. Более того в пушах содержится информация, и мне нужно было приличное сдк для работы со всем этим. OpenSignal очень качественно запилили сдк свои, подключение приятное, практически без телодвижений, в андроид версии над небольшой переработкой пришлось пару часов потратить, а вот в иос все быстро встало и сходу работало.
Я не вкоем случае не идеализирую OpenSignal. Я лишь выразил свое мнение, как в свое время он облегчил мне жизнь. К примеру сейчас работаю над одним заказом ios приложения, проект крупный очень, и они сейчас очень сильно мучаются с пушами, у них своя реализация отправки, но работает она честно говорят от случая к случаю, хотя у них и ресурсы большие и бюджеты внушительные, вот сейчас они тоже подумали над переходом в OpenSignal
Биллинга вы не увидите — там на главной есть https://onesignal.com/#pricing
100% Free
На счет остального я с вами согласен, возможно и так, но на сегодняшний день они мне упростили жизнь, моих серверных знаний не хватило на реализацию полноценной отправки большого количества пушей. За данный объем пушей бекендлес с меня 3 шкуры содрал, хотя и не выполнил 100% рассылку, работал раз через раз. Я 3 месяца мучался с этой проблемой, безуспешно, пока случайно не набрел на этот сервис, искал полноценный платный, был готов платить, но попался он, и сегодня я счастлив. В день они мне шлют порядка 300 000 пушей, в месяц около 9 миллионов +-, и никаких проблем.
Более того удобно заточена сдка, можно в настройках приложения дать возможность пользователю включать и отключать пуши, просто давая параметры самой сдк, не нужно в беке контролировать этот момент.
Это позволило мне избавится от многих проблем, и сосредоточится на качестве самого приложения
Все магнитные пускатели стоят в собственном распределительном шкафу в подъезде, где может присутствовать как влажность (при прорыве трубы горячей воды в подвале поднимается сильный пар на первых этажах подъездов, где собственно и установлен шкаф) и низкие температуры, так и совсем низкая влажность с температурой под 45-50 градусов, и за почти 4 года эксплуатации не вышло не одного пускателя из строя, и вся система в целом работает в нормальном режиме.
Нагрузка на пускатель достигает 90А в зимний период
Мне данный момент в ios нравится, там на подобии фрагментов есть ContainerView, который используют в главном окне что бы разделить какую то логику в окнах. Но там это реализовано так, что разработчик не хочет использовать это повсеместно, а лишь использует при необходимости и только там где это реально нужно
Увы такая мода если новое что то выходит это используют повсеместно, потом начинают осознавать что это не есть хорошо
Просто вы пишите статью о том с какими проблемами столкнулись и какие решения приняли, и писать это в общих чертах не есть правильно, немного конкретики не помешает.
Вообще многие описанные проблемы не считая проблемы №6 очень банальны, и если вы пришли в андроид с любого другого языка программирования, то многие эти проблемы должны отпасть сами собой, потому что принципы одни и те же, можно легко на гуглить решение для конкретного языка/платформы
Если данные типа настроек, или сохранение состояния какой либо переменной, то тут лучше использовать SharedPreferences. Реалм очень большой, если для проекта 6-7 мб лишних не проблема то реалм идеальный вариант, если проект весит меньши библиотеки то реалм зло. Я в своем проекте из-за этого использовал Sugar ORM, она не такая шустрая, но если правильно распределить потоки, то особо не заметно, но принцип работы и синтаксис аналогичен реалму, и вес прибавляется всего пара сотен килобайт. Просто пользователи ругались на размер, а у конкурентов был размер на много ниже, из-за этого пришлось попрощаться с реалмом, и визуально в скорости не проиграл
Исключительно на момент старта. Если архитектура правильная то разницы вы абсолютно никакой не увидите. К примеру переделывал свой, довольно большой проект (более 30 уникальных активити) на фрагменты, переделывал исключительно из-за навигации. Так вот по производительности особую разницу я не заметил. Если у вас ощутимо тормозит запуск новой активности, то стоит обратить внимание где именно происходит утечка, видимо что то в основном потоке нагрузочное стартует
Проблема очень эстетично решается через создание синглтона главной активити, в которой происходит управление фрагментами, и уже через синглтон вызывать открытие нового фрагмента
Ну тут обычно все наоборот, все обычно начинают с SharedPreferences, а потом уходят в сторону БД, как бы логично от простого к сложному. Просто нужно понимать разницы, SharedPreferences предназначен больше сохранения состояний/настроек, можно конечно его и под все подряд использовать, но это не есть правильно.
Даже если быть самоучкой то первый поиск в гугле приводит к SharedPreferences https://www.google.se/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5+%D0%B2+android+java
+1
Вы излишне ставите акцент на том, что стартап закроется, для этого есть инкубационный период, и блогосфера, где можно следить за развитием стартапа. Телега тоже когда то была стартапом, и принимая во внимание то, что она никак не монетизируется на данный момент, неизвестно именно что с ней будет завтра, Дуров не вечный.
Как говорится не попробуешь, не узнаешь!
На самом деле не так элементарно, публика телеграмма крайне ничтожна, приемущественно снг, если делать акцент на глобальность то телеграм тут проигрывает по всем параметрам, как бы Дуров не кричал что они ориентированы на Европу и штаты. Даже в РФ доля телеграмма крайне ничтожна. Я как ITшник даже неприемлю ботов в телеграмме, они меня просто вымораживают, настолько убогая платформа, хотя сам телеграм очень хорош
Возможно я покажусь консервативным, но считаю что каждый должен заниматься своим делом. Телеграмм был создан как мессенджер, и я вообще не понимаю эти введения как боты и тд, информационные каналы ладно это нормально, но боты, с их инлайн режимом, это извращение какоето. Мессенджеры должны быть мессенджерами, пуш сервисы должны быть пуш сервисами. Сувать все воедино это конечно может показаться хорошей идеей, но с другой стороны это получится помойная яма.
Но это сугубо мое мнение
На счет вашего сервиса я могу заблуждаться, может недоглядел подобную возможность, но на ней по крайней мере не сделан акцент, хотя сервис посвящен пушам
Ну апи я бы не сказал что у телеграмма проще, там много ньюансов своих. просто у всего свое примемение.
Пушовер я привел в пример к вашему сервису, они ведь насколько я бегло успел рассмотреть практически идентичны. К моим нуждам пушовер ну вообще никак не подходит.
Мне нужно было что бы пуши приходили именно в мое приложение, а не куда то. Более того в пушах содержится информация, и мне нужно было приличное сдк для работы со всем этим. OpenSignal очень качественно запилили сдк свои, подключение приятное, практически без телодвижений, в андроид версии над небольшой переработкой пришлось пару часов потратить, а вот в иос все быстро встало и сходу работало.
Я не вкоем случае не идеализирую OpenSignal. Я лишь выразил свое мнение, как в свое время он облегчил мне жизнь. К примеру сейчас работаю над одним заказом ios приложения, проект крупный очень, и они сейчас очень сильно мучаются с пушами, у них своя реализация отправки, но работает она честно говорят от случая к случаю, хотя у них и ресурсы большие и бюджеты внушительные, вот сейчас они тоже подумали над переходом в OpenSignal
На счет остального я с вами согласен, возможно и так, но на сегодняшний день они мне упростили жизнь, моих серверных знаний не хватило на реализацию полноценной отправки большого количества пушей. За данный объем пушей бекендлес с меня 3 шкуры содрал, хотя и не выполнил 100% рассылку, работал раз через раз. Я 3 месяца мучался с этой проблемой, безуспешно, пока случайно не набрел на этот сервис, искал полноценный платный, был готов платить, но попался он, и сегодня я счастлив. В день они мне шлют порядка 300 000 пушей, в месяц около 9 миллионов +-, и никаких проблем.
Более того удобно заточена сдка, можно в настройках приложения дать возможность пользователю включать и отключать пуши, просто давая параметры самой сдк, не нужно в беке контролировать этот момент.
Это позволило мне избавится от многих проблем, и сосредоточится на качестве самого приложения