Подход к разработке мобильного приложения с поддержкой веб-приложения - PullRequest
2 голосов
/ 13 ноября 2010

Моя компания создала свое собственное веб-приложение для управления проектами.Это как базовый лагерь на стероидах.Основные функции этого приложения:

  • создание списков задач
  • назначение задач членам команды
  • отслеживание часов для элементов задач

Я хочу создать мобильное приложение (я) в качестве расширения веб-приложения.Мобильные приложения должны:

  • воспроизводить функции, указанные выше
  • , подключаться к той же базе данных, что и веб-приложение
  • , сохранять возможности перетаскивания
  • обеспечивает богатый пользовательский опыт, эквивалентный или превосходящий веб-приложение
  • работа на iphone, droid и blackberry

Учитывая требования выше, как я должен подходить к разработкеэто мобильное приложение?В моей компании около 20 пользователей смартфонов: 8 айфонов, 7 дроидов и 5 ежевик.

Я слышал о таких средах разработки, как Phonegap, которые позволяют разрабатывать на HTML, Javascript и CSS.Программное обеспечение тогда работает кросс-платформенный через Blackberry, Iphone и Droid.Если я программист среднего или чуть выше среднего уровня, смогу ли я создать высококачественное кроссплатформенное мобильное приложение с PhoneGap (или другой платформой для разработки x платформ), которое отвечает вышеуказанным требованиям?

Или должноЯ создаю каждое приложение для iphone, droid и blackberry независимо?

Каков наилучший подход?Каковы компромиссы?

Ответы [ 2 ]

3 голосов
/ 13 ноября 2010

Джон,

Похоже, у вас впереди немного работы! Когда у вас есть существующее веб-приложение, есть два основных подхода к тому, чтобы сделать ваше приложение доступным на любом конкретном устройстве: вы можете (1) написать собственное приложение, которое реализует функциональность, которую вы хотите, для каждого устройства, которое вы хотите поддерживать, или вы можете (2) написать веб-«обертку» для существующего приложения и предоставить контент в виде HTML / CSS тем же устройствам.

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

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

Недостаток этого подхода заключается в том, что он требует, чтобы каждое устройство имело свое собственное приложение. Поэтому, если вы поддерживаете веб-приложение, приложение для iPhone, приложение для Android и приложение Blackberry, это означает, что у вас есть 4 совершенно разных кодовых базы для обслуживания. Если вы добавите какую-то новую функцию в свое веб-приложение (что, вероятно, произойдет в какой-то момент), вам также придется реализовать эту новую функцию в трех других отдельных базах кода. Учитывая тот факт, что эти устройства могут иметь разные модели взаимодействия, это может стать проблемой. Другим недостатком здесь может быть распространение (т. Е. Вам может потребоваться пройти процесс проверки чего-то вроде магазина приложений iPhone в зависимости от того, как вы хотите распространять свое приложение). Это также означает, что количество, которое вам придется выучить, немного больше, поскольку каждое устройство имеет свой собственный набор API и «философию» программирования.

Вариант 2: написать «обертку» для вашего приложения через Интернет (возможно, с использованием библиотеки)

Этот подход также имеет много преимуществ. Во-первых, если вы используете фреймворк, такой как PhoneGap или Sencha Touch или Rhomobile , большое преимущество состоит в том, что вы теоретически пишете код «мобильного приложения» один раз и он работает на всех устройствах, поддерживаемых платформой. По сравнению с написанием собственного приложения для трех платформ, это намного меньше работы.

Недостатками здесь являются следующие. Этот подход работает как веб-сайт в браузере устройства, поэтому у вас не будет доступа ко всем функциям каждого устройства. Все замечательные вещи в iOS и Android API по определению будут вам недоступны. Вы также несколько ограничены здесь в отношении локального хранилища, но это может не сильно беспокоить вас, учитывая ваше веб-приложение. Другим недостатком является то, что таким образом от вашего сервера будет требоваться большая полоса пропускания, поскольку вы обслуживаете весь HTML, изображения и CSS, которые в противном случае вам не понадобились бы в нативном приложении. В зависимости от количества пользователей и сложности страниц, это может быть важно для вас или нет. Еще одним недостатком здесь является то, что вы не можете перейти в полноэкранный режим (например, в iPhone в Mobile Safari всегда есть панель инструментов внизу).

Общие проблемы

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

Требование «обеспечить богатый пользовательский опыт, эквивалентный или превосходящий веб-приложение», также вызывает некоторое беспокойство. В то время как приложения на базе телефона могут действительно оптимизировать способы доступа к данным и манипулирования ими, помните, что вы разрабатываете экран, размер которого составляет несколько дюймов. Физически невозможно организовать ту же самую информацию в организованном порядке, что вы можете получить с помощью широкоэкранного монитора с диагональю 21 ".

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

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

Удачи!

0 голосов
/ 17 декабря 2010

Дополнительный комментарий к тому, что Neal L опубликовал выше, с Rhomobile вы можете получить доступ к собственным возможностям устройств, а также перетаскивать свои представления.

Здесь есть несколько обучающих и примеров видео: http://rhomobile.com/webinars/

...