Привет друзья,

В сегодняшней статье мы обсудим мобильные приложения, в частности, как выбрать реализацию для вашего нового приложения. Существует довольно много разных вариантов разработки приложений, но в основном они делятся на два основных лагеря: собственные мобильные приложения и мобильные веб-приложения. Я дам краткое определение каждого типа архитектуры приложения и различные соображения по выбору одного из них. Теперь есть много разных способов разработки мобильных приложений с выбором из множества разных языков. В этой статье мы не будем обсуждать какой-либо кроссплатформенный фреймворк или языки разработки, а будем обсуждать два высокоуровневых подхода к выпуску вашего потрясающего продукта и его использованию на мобильных устройствах. Это собственные мобильные приложения и мобильные веб-приложения. Итак, приступим.

Определения различных типов архитектур приложений

Популярность мобильных приложений резко возросла с момента выпуска iPhone в 2007 году. Сегодня сотни тысяч приложений доступны как в App Store, так и в Google Play. Список этих приложений, казалось бы, бесконечен. В начале мобильной революции было всего несколько способов разработки приложений для iPhone или Android, причем двумя основными вариантами были Xcode (Objective C) и Eclipse (Java / Android SDK).

Нативные мобильные приложения
Нативные мобильные приложения разработаны и запрограммированы для работы на определенном мобильном устройстве. Эти приложения построены на основе собственной операционной системы устройства и используют свои основные службы для выполнения действий на устройстве, отображения окна, доступа к камере и т. Д. Родные мобильные приложения разработаны и закодированы для использования на конкретном устройстве ( IOS / Android) и, как правило, конкретный тип устройства (телефон / планшет). Родные мобильные приложения устанавливаются на устройство с помощью соответствующего App Store. Каждый раз, когда разработчик хочет развернуть новое приложение в App Store, он должен пройти строгий процесс утверждения со стороны Apple или Google. Подобные утверждения требуются каждый раз, когда требуются обновления приложения.

Мобильные веб-приложения
Мобильные веб-приложения - это программное обеспечение, предназначенное для работы в браузере на любом типе устройства. Мобильные веб-приложения построены на веб-технологиях HTML и Javascript, чтобы выполнять тяжелую работу по интерфейсу. Мобильные веб-приложения обычно не могут получить доступ к основным службам устройства, поэтому они более ограничены в возможностях по сравнению со своими родными собратьями мобильных приложений. Мобильные веб-приложения развертываются на веб-сервере без установки каких-либо устройств.

Что следует учитывать при выборе нативной веб-архитектуры или архитектуры для мобильных устройств

Итак, давайте углубимся в соображения при выборе архитектуры вашего приложения. Это не исчерпывающий список факторов, однако он должен дать пищу для размышлений с точки зрения принятия этого важного решения.

Важная вещь, которую я хотел бы вынести из этой статьи, заключается в том, что, хотя технически возможно реализовать большинство функций в любой данной архитектуре, в каждом пути есть свои положительные и отрицательные стороны. Хотя вы можете быть настроены на создание следующего вирусного приложения с идеей вашего потрясающего продукта и доминировать в чартах App Store, оно может больше подходить для внедрения в мобильный Интернет. Поэтому, пожалуйста, уделите время тому, чтобы тщательно продумать, как вы будете проектировать и доставлять свое приложение.

Как предполагается использовать продукт?
Первое, что мы обсудим, - это то, что на самом деле делает ваш продукт? В чем основная причина, по которой ваше приложение необходимо? Является ли вариант использования приложения быстрым 10-секундным социальным взаимодействием? Для этого требуется приложение, которое открывается быстро, сразу переходит к работе, а затем так же быстро закрывается. В этой ситуации мобильное приложение Native было бы лучшим выбором, чтобы обеспечить оперативность и возможность наводить порядок в фоновом режиме еще долго после того, как пользователь перешел к следующей задаче.

Или ваш вариант использования - это быстрая 5-минутная игра с богатой графикой и звуковым сопровождением, чтобы поездка на трамвае шла быстрее. Опять же, в этой ситуации родное мобильное приложение было бы лучшим выбором для обеспечения производительности и отзывчивости, необходимых для обеспечения игрового процесса.

И наоборот, ваш вариант использования - продукт, который используется несколько раз в год, чтобы помочь вам привести свои финансы в порядок или записаться на прием к врачу-специалисту. Взаимодействие обычно будет более продолжительным и потребует ввода большего количества данных для последующей обработки. Однако приложение не будет облагать налогом устройство, и ему не потребуется доступ к какой-либо камере, GPS и т. Д. В этом случае мобильное веб-приложение было бы лучшим выбором для ввода и хранения информации. Кроме того, когда приложение используется нечасто, мы часто обнаруживаем, что им сложно сохранить свое место на устройстве, особенно для устройств с ограниченным объемом памяти, когда настройки выгружают редко используемые приложения. Рассмотрение того, что делает ваш продукт, будет иметь большое значение для выбора архитектуры приложения.

Что нужно продукту для выполнения своей работы?
Вторая область, которую следует учитывать после того, как мы узнаем функциональность нашего приложения, - это понять, к какому приложению потребуется доступ для выполнения своей работы. Например, если вашему приложению необходимо использовать встроенные в устройство функции, такие как GPS, акселерометры или внутреннее хранилище, ваше приложение может не подходить для развертывания в качестве веб-приложения. Теперь доступ к таким вещам, как камера устройства, может быть получен в мобильных веб-приложениях, так что это не та точка принятия решения, которая была раньше. Однако я считаю, что если приложение должно реализовывать большую вычислительную логику, такую ​​как сжатие или шифрование изображений, для достижения производительности и ожиданий пользователя, собственное приложение может быть более подходящим для этой цели.

С другой стороны, если вашему приложению не нужно делать что-то особенное с устройством, а нужно только отображать большой объем контента, мобильное веб-приложение будет подходящим выбором.

Как часто вам нужно будет его обновлять?
Третье соображение, которое мы обсудим, - это то, как часто нужно будет обновлять приложение. Является ли природа приложения таковой, что для поддержания актуальности требуется частое обновление, или приложение более статично по своей природе с менее регулярными обновлениями? С собственными мобильными приложениями возникает больше проблем при обновлении приложения, поскольку существует процесс утверждения, при котором каждое обновление требует утверждения, обработка которого может занять до 24–48 часов. В мобильных веб-приложениях процесс обновления не требует одобрения Apple или Google и ограничивается только скоростью вашего цикла разработки. Помимо растущих трений вокруг процесса утверждения приложений, с собственными мобильными приложениями вам также необходимо учитывать обновления для двух основных платформ (если вы их поддерживаете), что еще больше усложняется, если ваше приложение поддерживает версии для телефонов и планшетов. Обновление мобильного Интернета выполняется только один раз для всех платформ.

Ресурсы
Последнее, что мы обсудим, касается ресурсов. У вашей команды уже есть опыт работы с нативными мобильными или мобильными веб-приложениями? Знание конкретной технологии и опыт ее реализации дает вам толчок к доставке вашего потрясающего продукта. Хотя необходимость изучать все с нуля может иметь негативные последствия, особенно если сроки сжатые, а исследуемые технологии являются передовыми.

Другое важное соображение, связанное с ресурсами, связано с возможностью поддержки приложений после их развертывания и необходимости обновления. Если ваше приложение необходимо развернуть на iOS и Android, на телефоне и планшете, необходимо проделать большую работу по поддержке синхронизации и обновления версий. Это нормально, если у вас есть большая команда, способная справиться с этими требованиями, однако, если у вас небольшая группа, то поддерживать это может быть непросто.

Заключение

Я надеюсь, что эта статья даст вам пищу для размышлений о том, как вы будете предоставлять свое мобильное приложение с помощью нативной мобильной или мобильной веб-разработки. Как я сказал в начале этой статьи, вопрос не в том, какой фреймворк или какой язык. Тем не менее, больше об архитектурном решении о выборе развертывания приложения на каждом устройстве или централизованно развернутого веб-приложения. У обоих вариантов есть свои плюсы и минусы, поэтому решение действительно сводится к конкретным потребностям вашего приложения и вашей способности их использовать.

Первоначально опубликовано на https://www.herdingcoders.com.