Узнайте, какие ошибки часто делают разработчики и почему это может испортить всю работу.
Самые распространенные ошибки при разработке мобильных приложений :
Вопрос о платформе
Слишком много функций
Непропорциональное требование к избыточному пространству
Недооценка папки обновлений
Слишком много размышлений на сайте
Повышенное внимание к визуальным элементам
Вопрос о платформе
Все это переоценено. Догматика всегда заступается за одно решение - iOS или Android. Раньше это имело смысл (отсутствие технологий), но сегодня оно меняется. Почему бы не использовать обе платформы по одной цене? Одновременная разработка как в среде iOS, так и в среде Android (платформа Windows в настоящее время является проблемой меньшинства, или, по крайней мере, мы это понимаем), может иметь хороший экономический смысл с точки зрения параметров цена / производительность, и качество приложения будет более чем достаточным (например, внутренняя узко практическая работа приложения для компании). На этом этапе, например, технология Xamarin может легко передавать один раз созданный код для всех необходимых сред.
Также верно и то, что при разработке игровых приложений, безусловно, хорошо делать процесс разработки параллельно, для которого Xamarin, по мнению наших разработчиков, не подходит хорошо и в таком случае приносит больше вреда, чем пользы.
Слишком много функций
Достоверная, но верная пословица гласит, что в простоте есть сила. Представьте себе следующий сценарий - вы находитесь в процессе разработки и получаете интересную идею о том, что приложение XY действительно может выполнять функцию XZ в то же время, когда функция ZYX действительно работает. Ты понимаешь, куда я иду? Само по себе не плохо, что разработчики получат совершенно новую идею от клиента в процессе создания приложения, что приложение еще может сделать, или предложить это клиенту. Но неправильно то, что мысли о дополнительных «дополнительных» функциях и настройках приложения привлекут все внимание разработчика.
Новички (не оскорбляющие их способностей, ни сейчас, ни отдельные лица, ни начинающие разработчики) в мире разработки приложений могут быть легко подвержены такой, по их мнению, невинной потере внимания к гл. важные функции и разбавить его, возможно, приятными вещами, но на данный момент не так важны с точки зрения работы и производительности приложения.
Поддержание необходимого количества функций, которые будут одновременно коррелировать с простотой «пользовательского опыта» и логического прохождения приложения, является правильным выбором.
Непропорциональное требование к избыточному пространству
Больше, чем обычная ошибка. Мобильный телефон - это среда, отличная от классического рабочего стола, и об этом всегда следует помнить. Хранение данных, использование памяти или работа с батареями работает по-разному как на вашем мобильном телефоне, так и на ПК, хотя может быть одинаковым. Но именно на различия нужно обратить внимание и знать.
Какой должен быть соответствующий размер приложения? Это всегда актуальный вопрос для разработчиков, на который нельзя ответить дважды одинаково. Найти четко сформулированный универсальный ответ - это тоже не принесет пользы. Возможно, ответ правильный, говоря, что если приложение на телефоне занимает много места по вкусу пользователя, оно, скорее всего, будет удалено.
Но ясно, что если вы разрабатываете действительно простую и обширную игру с великолепной графикой, то размер, безусловно, будет пропорционален ей. Но если мы говорим о клиентских и бизнес-приложениях, то в действительности они излишне теряются в размерах. Например, это займет немного больше времени: разработчик удалит неиспользуемые ресурсы, сведет к минимуму использование ресурсов из библиотек, сжимает файлы PNG и JPEG и сократит избыточный код приложения.
Недооценка папки обновлений
Независимо от того, разрабатываете ли вы внутреннее бизнес-приложение или приложение, которое соответствует бизнес-целям спонсора, в каждом упомянутом случае разработчики всегда должны обеспечивать синергизм в процессе обновления.
Только при тестировании и развертывании в живом трафике могут (и часто делают) законные требования улучшить работу и производительность приложения со стороны пользователя - футболист также работает лучше всего, так как он действительно работает только на поле, а не сидит без дела на приятно изолированном инверторе. Вот почему штамповка лозунга «как только мы его запрограммируем, и нам не нужно прикасаться к нему вечно», не совсем то кредо для столь желанной практичности. Разработчики должны уметь идентифицировать запросы и предлагать подходящее решение.
Слишком много размышлений на сайте
Хорошо, у компании есть веб-сайт, и она хочет, чтобы новое приложение учитывало его и отражало их отличительные особенности. Опять же, это не может быть ошибкой. Однако неправильным является то, что этот образ мыслей часто развивается в форме, в которой компания / клиент подсознательно хочет, чтобы приложение фактически имело те же функции и элементы, что и сайт. Не имеет смысла создавать новое мобильное приложение. Здесь разработчик должен терпеливо объяснить все на стороне клиента и посмотреть снова, и, возможно, переосмыслить цели и группу пользователей, которые будут использовать недавно разработанное приложение.
Повышенное внимание к визуальным элементам
Создание рабочих приложений не обязательно означает наличие самых креативных визуальных частей. Креатив - хороший слуга, но плохой хозяин (мы немного знаем об этом с моим коллегой). Творчество и визуальность в целом должны иметь свои пределы и помогать встречать столицу. цели. Это как приготовление и острая еда, просто щепотка, и это фантастика, просто щепотка, и это ... Ну, вы знаете, где.
Если вы хотите «оживить» приложение с помощью визуальных элементов, попробуйте поработать с ними более обычным способом (в конце концов, разработчики не выполняют приложения для поиска воды на Jupiter и т. Д. На каждом этапе, где творческий визуальный компонент будет хорошим разнообразием). так что пользователь приложения может понять только само изображение. Не заставляйте меня думать, Стив Круг, я рекомендую прочитать, это уже культовая проблема UX.