Корпоративная разработка мобильных приложений

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

Примечание . В качестве организации мы в первую очередь используем устройства BlackBerry, но другие платформы любопытны.

Несколько доменов кажутся более подходящими для родных приложений сверху:

  • Приложения с отключенными наборами данных. Мобильные приложения не всегда могут рассчитывать на подключение к Интернету. Собственные приложения отлично справляются с этим делом. Это особенно актуально для инструментов ввода данных. Если вы получаете вызов в браузере при вводе данных, работа может быть потеряна, если перезагрузка страницы после перезапуска Safari.
  • Приложения, которым нужен пользователь для загрузки таких файлов, как фотографии, видео и звуковые записи. В настоящее время нет возможности загружать локальные iPhone через MobileSafari. Собственные приложения обрабатывают этот случай. Страхование и недвижимость могут быть хорошими рынками для этого.
  • Расширенные приложения для обработки. Например, если вы хотите, чтобы приложение управления запасами, которое могло читать штрих-коды с помощью камеры iPhone, собственное приложение может обрабатывать данные изображений намного быстрее. Любое приложение дополненной реальности будет работать лучше всего в качестве родного приложения.
  • Приложения с высокой памятью. Когда запускаются другие приложения, Safari все еще загорается в фоновом режиме. Если этим приложениям требуется больше памяти, Safari освободит ОЗУ, выделенную для содержимого страницы «вкладки». Затем эта страница перезагружается, когда пользователь открывает Safari. Если вашему приложению требуется много оперативной памяти, то создание собственного приложения дает вам более высокий приоритет, чем остальное веб-приложение.
  • Нужно работать в фоновом режиме как услуга. Начиная с 4.0, конечно, вы можете создавать службы отслеживания IT-ресурсов, вести журнал GPS, корпоративные сообщения (думаю, Microsoft Office Communicator для iPhone и т. Д.), Мониторинг соответствия нормативным требованиям, уведомления о заказах, пользовательская конечная точка SIP / H.323 для VoIP-коммутатора , и т.д.
  • Большие наборы данных. Я считаю, что Safari ограничивает базы данных SQLite до 50 мегабайт. Для собственного приложения доступное пространство будет ограничено в основном доступным пространством на «диске».

Собственно, просто просматривая API. Любой API, недоступный через webapp, будет хорошим местом для начала. Я прихожу здесь, относительно 4.0 API, которые в настоящее время находятся под NDA. 🙂

Тем не менее, SproutCore Touch обеспечивает хорошую веб-платформу, которая специфична для сенсорных интерфейсов.

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

Однако, хотя я согласен с вами в отношении интрасети, веб-приложения, как правило, лучше, я думаю, что все зависит от того, для кого лучше. Очевидно, что веб-приложения для интрасети лучше для разработки, и лучше, поскольку они могут быть кросс-playform, однако я думаю, что практически все приложения лучше подходят для конечного пользователя. Не согласен? Посмотрите на количество успешных приложений для iPhone и Android, которые выходят на рынок, которые являются только родными порталами для данных некоторых сайтов. Пользователи предпочитают, как родное приложение работает над мобильным браузером.

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

Идеальным было бы сделать то и другое.

Есть что-то вроде безопасного спокойного интерфейса, который передает json или xml в родное мобильное приложение. Удобный интерфейс будет проще начать, проще протестировать, упростить прототип и легче изменить. Это также облегчило бы жизнь, когда данные должны быть синхронизированы, скопированы, клонированы или когда телефон потерян / сломан / украден / обновлен.

И тогда, имея собственное приложение, созданное в дополнение к спокойному интерфейсу, также позволит использовать среду Native UI. Это может позволить приложению работать в автономном режиме. Он может использовать собственную систему уведомлений, не пропуская SMS / push-mail. И если некоторые из релевантных данных были зеркально отражены в автономном режиме, приложение стало бы более восприимчивым и гораздо более простым в использовании с другими приложениями (там, где он поставляется с функциональностью приложений, я говорю только для Android SDK здесь и в основном Будущая версия iPhone SDK, а не Blackberry пока). Конечный результат, вероятно, был бы более чистым и гораздо более приятным приложением для работы, предполагая, что он также может быть выполнен как родное приложение.

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

В главе 8 «О Face 2.0: Основы дизайна взаимодействия» Алан Купер рассказывает о позах программного обеспечения. Одна из этих поз называется «Суверенная осанка». Эта поза представляет собой приложение, которое обычно используется в полноэкранном режиме и в течение длительных периодов времени и представляет основное приложение для данного пользователя. Visual Studio и Eclipse являются хорошими примерами суверенных приложений для разработчиков. Если рассматриваемый интерфейс является суверенным приложением для пользователя, это сильно благоприятствует родному клиенту.

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

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

Плюсы разработки собственных приложений в основном связаны с доступом к аппаратным функциям, которые недоступны через веб-интерфейсы, получая собственные преимущества производительности (например, в игровых играх), мгновенный доступ к платным клиентам через магазин платформы (например, iTunes), И ситуации безопасности, когда вы не доверяете браузеру или тому, как он обрабатывается.

Недостатками разработки собственных приложений является то, что вы запираете себя на потенциально проприетарную платформу кода, пишете кучу кода, специфичного для устройства, и вы заблокированы поставщиком. Код сложнее писать, гораздо сложнее развернуть, и у вас есть шанс вытащить коврик из-под вас. (Да, я смотрю на Apple, но может случиться с любой собственной платформой.)

Веб-приложения в отличие от них основаны на технологиях, которые широко известны и легко справляются – HTML5, CSS3, JavaScript и отличные библиотеки, такие как JQTouch, могут помочь. Хорошо спроектированные веб-приложения по большей части не волнуют, если вы на Blackberry, Android или iPhone, и будете работать на многих старых и менее способных моделях, а также на новых и устройствах, которые у нас даже нет (Или, по крайней мере, без необходимости повторной компиляции или рефакторинга), и есть некоторые доступные аппаратные функции, такие как GPS через API геолокации.

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

В целом, большинство приложений будут иметь лучший смысл в качестве веб-приложений. Тем не менее, многие веб-приложения могут быть созданы, чтобы быть почти неотличимыми от клиентских приложений. С некоторыми автономными хранилищами HTML5, функциями CSS3 и JS для переходов и поведения многие бизнес-приложения могут быть неотличимы от родных клиентов.

В случае iPhone мы можем принять это дальше: добавление значка 57x57px apple-touch-icon.png в корневой каталог вашего веб-приложения предоставит iPhone с хорошим пользовательским значком, когда пользователи добавят приложение на свои домашние экраны (iPhone позаботится о том, чтобы Закругленные углы и глянцевый визуальный эффект), и вы можете сделать приложение iPhone в полноэкранном режиме, щелкнув по его значку на главном экране, добавив. На данный момент приложение имеет свой собственный значок и работает в полноэкранном режиме – пользователь не знает, что это веб-сайт.

И если вы хотите пойти на родной язык, но не хотите отказываться от веб-стандартов, большинство собственных API предоставляют возможность разрабатывать собственные клиенты на основе HTML / CSS / JS, используя простую оболочку, такую ​​как UIWebView в Objective-C. PhoneGap – отличная кросс-платформенная платформа, позволяющая развертывать на основе стандартов на основе веб-технологий на iPhone, Android и Blackberry.