Расширение приложения Android для дополнительных функций

Существует базовое мобильное приложение ERP для Android. Клиент запросил дополнительные функции, для которых потребуется больше экранов (и Activities ) и дополнительных функций.

Есть ли способ добавить некоторое расширение для основного мобильного приложения, чтобы интегрировать дополнительные функции или я должен кодировать код кода основного приложения?

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

Будет ли иметь значение, если дополнительные функции должны использовать тот же db, что и основное приложение?

Спасибо заранее за вашу помощь.

Solutions Collecting From Web of "Расширение приложения Android для дополнительных функций"

Ответ на ваш вопрос лежит в принципе Open / Closed, представленном Бертран Мейер. Принцип Open / Closed – очень простой принцип объектно-ориентированного проектирования, который гласит, что

Программные объекты (классы, модули, функции и т. Д.) Должны быть открыты для расширения, но закрыты для модификации "

Из вашего вопроса ясно, что вы определили основные функции в своем приложении. Поэтому вместо того, чтобы модифицировать эти основные функциональные возможности и сделать их более конкретными, я бы рекомендовал на основе принципа Open / Closed, что вы должны заморозить свои функции кода и написать свои специфические функции для клиента, не повреждая ядро.

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

Не будет иметь значения, если ваше приложение использует тот же db, что и ваше основное приложение, при условии, что все ваши приложения его используют, иначе оно не должно быть в вашем основном приложении в первую очередь.

Надеюсь, это объяснение поможет вам.

Обновить:

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

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

Это своего рода вопрос философии философии. Вот пара вариантов, которые могут дать вам идеи:

  1. Вы могли бы задуматься о том, как сделать свой код / ​​функции основного приложения в пользовательскую библиотеку. Тогда ваше новое основное приложение представляет собой просто простую оболочку, включающую пользовательскую библиотеку. Ваши дополнительные функции для конкретного клиента могут быть другим приложением, которое также ссылается на основную библиотеку, но будет включать дополнительные функции. Существует множество учебников о том, как превратить ваше приложение в пользовательскую библиотеку. В конечном итоге вы столкнетесь с различными приложениями, нацеленными на разных клиентов. (Совет, который потребовался для меня, чтобы открыть его, заключается в том, что если у вас есть имя ресурса в вашей пользовательской библиотеке, вы можете «переопределить» его, используя одно и то же имя в приложении, которое включает в себя библиотеку. Еще один совет: вам нужно по существу Дублируйте манифест библиотеки в приложении, перечисляя все действия в библиотеке, которые будут использоваться приложением.) Я не пробовал это, но может быть, что ваши дополнительные функции – это библиотеки, которые включены в различные приложения.

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

Оба эти решения должны использовать один и тот же дБ, поскольку они будут вызывать одни и те же основные классы и т. Д.

Другим возможным решением является создание Библиотечного проекта. Поместите свой основной код приложения ERP внутри библиотеки Project, а затем создайте другой проект для разных клиентов. Каждый из этих проектов также будет использовать один и тот же проект библиотеки.

В проекте основной библиотеки можно было бы api динамически регистрировать новые функции (например, меню, в котором могут отображаться новые элементы меню).