Архитектура решения для мобильных приложений (Android для запуска, несколько платформ) - PullRequest
1 голос
/ 13 апреля 2011

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

Приложение должно в конечном итоге работать на iPhone, Windows Mobile, BlackBerry и Android. Есть также некоторые бизнес-правила, которые заставляют меня сомневаться в том, какой должна быть общая архитектура.

Во-первых, позвольте мне объяснить небольшую терминологию. клиент - это бизнес, который фактически является одним из наших клиентов. Клиенты не знают друг друга. Суперпользователи могут делать все для всех клиентов и являются нашими сотрудниками. Администраторы могут сделать все для конкретного клиента и работают на нем. Конечный пользователь является клиентом клиента. Конечный пользователь может иметь дело с одним из наших клиентов или, возможно, с несколькими из них. Но они не могут этого знать (я не могу представить им список всех клиентов и позволить им выбрать, с кем они связаны).

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

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

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

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

1 Ответ

1 голос
/ 14 апреля 2011

У меня нет опыта создания мобильных решений, но я сразу же подумал, что предпочел бы первый вариант: «иметь пользовательский интерфейс на мобильной платформе и данные, передаваемые через сервисы».

Моя причина для этого - опыт пользователя. Я использую Windows Mobile (WP7), и мне действительно нравится родной интерфейс - он интересный и эффективный (самое главное). Для сравнения, просмотр веб-приложений не так приятен или прост.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...