Comments 13
Согласен, что сравнение двух целых чисел, которыми обычно характеризуют номера сборки, проще, чем парсинг строк в формате «1.2.17» и «1.5.13» и поочередное сравнение номеров мажора, минора и патча (на все это хорошо бы иметь тесты)
Почему-то мне казалось, что в строку iOS уже вшит этот функционал. Нет необходимости дублировать имеющийся функционал и писать на копию тесты.
да, на iOS для этой задачи можно использовать compare (по ссылке есть примеры и граничные кейсы). спасибо, добавлю в текст
Пользователь сам имеет право выбирать оставаться на старой версии или нет. Если выбрал оставаться на старой значит он добровольно выбрал баги
> 2. Проблемы обеспечения обратной совместимости
Да да, разработчики привыкшие писать вебсайты очень удивляются когда оказывается что бывают старые версии и нужно было проектировать взаимодействие с бэкендом с учетом этого. Чтож или они научится или пользователи проголосуют ногами. Не вижу почему это должно быть причиной для обновления.
>3. Недостаточно быстрое внедрение фич
Итак ваши маркетологи сказали что запили еще 100500 АБ тестов, которые добавили всего-то 300 МБ в приложение и хотят поскорее обкатать их на пользвателях… и ах да вырезали ту ненужную фичу для которой не было иконки и все равно ей пользовалось не более 15% аудитории которой можно пренебречь.
Пользователь сам имеет право выбирать оставаться на старой версии или нет. Если выбрал оставаться на старой значит он добровольно выбрал багиВозможно, он выбрал не столько баги, сколько право не нагружать свое устройство кучей украшений и доработок, которые кажутся полезными исключительно авторам приложения. К сожалению, при установках обновлений нельзя выбирать только исправление ошибок, а не исправление ошибок + добавление «сверполезных» возможностей + внесение новых ошибок
Максимально поддержу. Я недавно обновил Телеграмм, когда старая версия перестала работать. Плюсов не заметил. Из минусов - вылеты, поехавшая верстка, более долгая загрузка.
Проблема не в том, что пользователи не хотят обновляться, проблема в том, что разработчики делают так, что пользователю стремно обновлять приложения.
Мы делаем проще, в приложениях есть версия протокола, если необходимо всех перевести на последнюю версию, то при авторизации на нашем сервере проверяется версия протокола приложения и текущая актуальная. Если в приложении меньше, то оно блокируется и требует обновится, приходит команда с сообщением и урлом на стор. Таким образом можно даже сообщить обновится на другое приложение, если текущее по каким-либо причинам забанят.
То есть обновить отдельно, к примеру, iOS приложение не получится? Нужно будет сразу и Android обновлять?
Почему же, можно и отдельно. При авторизации на сервере клиент передает инфу о себе: язык, платформа, протокол и еще 5-8 параметров. И можно легко сегментировать кому обновляться.
В какой-то момент команда, отвечающая за backend, может сказать, что длительная поддержка разных версий API доставляет им сложности при разработке и тестировании.
1) Как вы и такая команда предполагаете обрабатывать ситуацию развития приложения и его перехода на новые версии ОС, когда у пользователя одно и тоже аппаратное обеспечение, которое не может обеспечить должную производительность и ресурсы новым версиям? Т.е. пользователь не обновляет ОС и не может: потолок производительности устройства достигнут, а то и новая ОСь на него просто не встанет из-за архитектурной несовместимости.
2) Каким образом предполагается перенос всех приложений и данных пользователя на новую ОС и устройство, чтобы он мог перейти на актуальную версию вашего приложения? Это нормально вообще отменять усилия пользователя по приобретению/установке/настройке/привыканию/наработке опыта эксплуатации? Если бы эти усилия не отменялись, и обновление приложения действительно было безопасно и не затратно по усилиям, тогда бы можно было обновлять автоматически. А пока это вызывает означенный конфликт.
ничто не вечно, даже поддержка windows XP
Зачем ломать или отменять то, что работает? Например, на ноутбуке 2005 года выпуска установлена Windows XP. На этом железе Windows 10 не сможет бегать: оперативки не хватит. Поддержки, в смысле обновлений? Они не нужны, по большому счёту, когда заявленная функциональность работает. Обновления безопасности становятся актуальны, когда злоумышленник может добраться до ноутубка. Однако ему будет это довольно сложно сделать ввиду среды, в которой он работает (NATP, как минимум). Тогда остаётся лишь искусственное ограничение в виде .NET. Хотя при компиляции под WinXP кода на C++, не использующего .NET, приложение прекрасно работает. Т.е. зависимость от .NET создана искусственно, и намеренно производится ограничение по версиям ОС, на которых бегает .NET.
Force Update — механизм принудительного обновления мобильных приложений