Comments 54
Каким образом учитываются зависимости между модулями?
Как решаются возможные конфликты (два модуля претендуют на модификацию одной части интерфейса)?
Может ли один плохой модуль сломать все приложение?
Как решаются возможные конфликты (два модуля претендуют на модификацию одной части интерфейса)?
Может ли один плохой модуль сломать все приложение?
1. Зависимости и конфликты контролируются корневым модулем, который загружает и линкует все прочие модули.
2. Да, если в систему встроить заведомо нерабочий модуль, то всё грохнется. Однако, прежде чем такой модуль будет подключен к программе, он должен пройти несколько этапов контроля, начиная от сборки под разные платформы и заканчивая интеграционным тестированием.
Вообще говоря, будет некий централизованный список «доверенных» модулей, которые уже прошли все стадии контроля, и которые пользователь сможет подключить в приложение, скачав их с сервера через это же приложение или с сайта.
2. Да, если в систему встроить заведомо нерабочий модуль, то всё грохнется. Однако, прежде чем такой модуль будет подключен к программе, он должен пройти несколько этапов контроля, начиная от сборки под разные платформы и заканчивая интеграционным тестированием.
Вообще говоря, будет некий централизованный список «доверенных» модулей, которые уже прошли все стадии контроля, и которые пользователь сможет подключить в приложение, скачав их с сервера через это же приложение или с сайта.
Зависимости и конфликты контролируются корневым модулем, который загружает и линкует все прочие модули.
А как корневой модуль узнает, что модуль A зависит от модуля B?
В комплекте с каждым модулем идёт мета-файл в формате JSON, в котором хранится информация, на основании которой корневой модуль и производит линковку. Связываются модули по интерфейсам.
Вот, например, мета-файл модуля с логикой для списка задач:
Вот, например, мета-файл модуля с логикой для списка задач:
{
"Type": "PluginModel",
"Interface": "ITaskTreeModel",
"Name": "TaskListModel",
"RelatedPluginInterfaces": [
"IExtendableDataManager",
"IMainMenuModel"
]
}Спасибо, видно, что вы серьезно подошли к задаче.
- Как корневой модуль обрабатывает наличие нескольких реализаций одного интерфейса?
- Может ли модуль стать корневым для своих подмодулей и использовать тот же механизм для разрешения зависимостей?
- Можно ли получить актуальный граф модулей в пригодном для понимания человеком виде?
Такая модульная система хороша. Ещё бы отслеживать версионность и автоматически всё подтягивать, обновлять. В odoo тоже примерно так реализовано. И там тоже есть todo модули и, если поискать, то и с pomodoro.
Класс, спасибо — обязательно рассмотрю поближе)
А в неё модули добавляют только разработчики компании или любые?
А в неё модули добавляют только разработчики компании или любые?
Она opensource, я сам для себя писал специфический модуль. Всё довольно просто, особенно сейчас. В 6 версии было сложнее.
1.Через пользовательский интерфейс предложит пользователю выбрать один из них. Но вообще, такая ситуация не должна возникнуть при правильном использовании приложения.
2. Вообще говоря, я хотел раскрыть эту тему в следующей статье, но вкратце есть всего 4 типа модулей:
За исключением описанных ролей — я не закладывал абсолютно никаких ограничений на функциональность, только на назначение. Так что да, можно хитровывернуться как вы предложили)
3. Можно, но сейчас это не реализовано. Однако, можно реализовать всё что угодно — нужно лишь знать интерфейс нужного модуля. Вот, например, интерфейс того самого корневого модуля:
В принципе, можно хоть сейчас строить такой граф.
2. Вообще говоря, я хотел раскрыть эту тему в следующей статье, но вкратце есть всего 4 типа модулей:
- Model — бизнес логика и взаимодействие с другими модулями
- View — пользовательский интерфейс
- DataManager — предоставляет доступ к независимым от источника данным и общается с DataSource в контексте источника данных (запросы, протоколы и прочее). Это такой, буферный тип для отделения логики от источника
- DataSource — взаимодействует напрямую с источником данных
За исключением описанных ролей — я не закладывал абсолютно никаких ограничений на функциональность, только на назначение. Так что да, можно хитровывернуться как вы предложили)
3. Можно, но сейчас это не реализовано. Однако, можно реализовать всё что угодно — нужно лишь знать интерфейс нужного модуля. Вот, например, интерфейс того самого корневого модуля:
class IMainMenuModel : public IModelPlugin
{
public:
struct MenuItem{
MetaInfo* meta;
QList<MetaInfo *> Items;
QList<MenuItem*> SubItems;
};
virtual MenuItem* GetRootMenuItem() = 0;
virtual void RunItem(MenuItem* item, MetaInfo *viewMeta) = 0;
};
В принципе, можно хоть сейчас строить такой граф.
У меня ощущение, что вы только что придумали мобильную операционную систему. Приложения — и есть те самые модули.
Да, согласен, но если писать приложения под какую-либо операционную систему, то они смогут выполняться только на ней.
В моём же случае я использую фреймворк Qt для обеспечения переносимости логики и интерфейса на любую платформу. Что-то вроде кроссплатформенной операционной системы получается, простите мой французский.
В моём же случае я использую фреймворк Qt для обеспечения переносимости логики и интерфейса на любую платформу. Что-то вроде кроссплатформенной операционной системы получается, простите мой французский.
Тоже пробовал сделать подобное приложение, но тогда Qt под Android работал не лучшим образом, по крайней мере, виджеты. А как с этим сейчас, виджеты, наверно, совсем забросили, а QML-то доделали?
Да, раньше с Qt было намного сложнее чем сейчас…
QML ещё делают, но в целом он уже очень привлекательный. Призывают бросать в топку виджеты и переходить на QML. Я пока не отказываюсь от виджетов, так как с ними удобнее работать из плюсов, но если что-то красивое надо сделать, то объединяю виджеты с QML.
QML ещё делают, но в целом он уже очень привлекательный. Призывают бросать в топку виджеты и переходить на QML. Я пока не отказываюсь от виджетов, так как с ними удобнее работать из плюсов, но если что-то красивое надо сделать, то объединяю виджеты с QML.
В QML тоже есть кое-какие виджеты. По крайней мере, их делали, но я их не дождался и перешёл на Java+Android API, тем более, что актуальную задачу без этого просто не реализовать. Пока обдумываю выделение кроссплатформенного кода в отдельные модули на C++ без фреймворков с легковесными мордами на HTML и нативных API.
Я над подобным проектом уже бьюсь давно :). Но понимания как сделать правильно до сих пор нет. Основная проблема, что в голове вырисовывается картинка как оно должно работать, делаю прототип и понимаю что пользоваться не удобно. Отдельная головная боль это хранение данных в облаке и шаринг данных между несколькими пользователями…
Прекрасно, я рад что вы есть!: ь
А вы какие инструменты используете и как обеспечиваете модульность архитектуры?
А вы какие инструменты используете и как обеспечиваете модульность архитектуры?
Android Studio для написания ядра и основного интерфейса, модульность пока не трогал так как в голове нет понимания до конца как обеспечивать связку данных и опять таки как будет влиять ситуация когда у одного товарища есть какой либо модуль а у другого нет и при этом у них данные расшарены друг для друга.
И по облаку смотрю упорно в сторону Django/Flask
И по облаку смотрю упорно в сторону Django/Flask
Ах да, еще в моей голове крутится такой факт — что не плохо было бы привязывать начало одних задач к завершению других задач
Желающих иметь идеальный планировщик больше, чем вы можете представить. Но ваши помидоры, это мелочь по сравнению с тем, что действительно хочется.
Вот тут народ пишет:
А ещё хочется чтобы при отмене одной задачи отменялись её потомки и создавались другие. Хочется чтобы задачи создавались сами на основе внешних событий, звонков, писем, превышения скорости в мониторинге автомобиля… Вообще хочется чтобы всё само происходило по разным сценариям.
Так вот всё это возможно в планфиксе. И если чего-то не возможно, то можно попросить добавить это и разработчики делают. Единственное чего у них пока нет, это удобного мобильного приложения, обещают уже год.
Вот тут народ пишет:
не плохо было бы привязывать начало одних задач к завершению других задач
А ещё хочется чтобы при отмене одной задачи отменялись её потомки и создавались другие. Хочется чтобы задачи создавались сами на основе внешних событий, звонков, писем, превышения скорости в мониторинге автомобиля… Вообще хочется чтобы всё само происходило по разным сценариям.
Так вот всё это возможно в планфиксе. И если чего-то не возможно, то можно попросить добавить это и разработчики делают. Единственное чего у них пока нет, это удобного мобильного приложения, обещают уже год.
Я согласен с вами, что наши помидоры это мелочь — я просто показал этот случай как пример.
Спасибо, я не знал о таком инструменте. Обязательно ознакомлюсь.
А как у них реализовывается создание задачи при превышении скорости автомобиля?
Спасибо, я не знал о таком инструменте. Обязательно ознакомлюсь.
А как у них реализовывается создание задачи при превышении скорости автомобиля?
Я сам его искал очень долго, но вот уже второй год отличного полёта. Рекомендую.
Не изобретайте велосипед, прикрутите лучше свой мобильный интерфейс к их API, я буду первым тестером и возможно покупателем.
Система мониторинга умеет слать email, а планфикс умеет при поступлении письма разбирать его и при выполнерии условий создавать задачи по шаблонам. Потом планфикс вызывает через API телефонии диспетчера и водителя, водитель получает втык, запись разговора прикрепляется в задачу, задача завершается. Если же нет, то диспетчер оповещается планфиксом уже через телеграмм ботом, а если и так нет реакции, то через час создаётся задача старшему диспетчеру и он начинает нагибать первых двух исполнителей.
Очень мощный инструмент автоматизации бизнес-процессов. И при этом там легко вести личные дела, использовать его как ежедневник и ещё куча других вариантов использования, судя по тому что пишут люди в успешных кейсах.
Не изобретайте велосипед, прикрутите лучше свой мобильный интерфейс к их API, я буду первым тестером и возможно покупателем.
А как у них реализовывается создание задачи при превышении скорости автомобиля?
Система мониторинга умеет слать email, а планфикс умеет при поступлении письма разбирать его и при выполнерии условий создавать задачи по шаблонам. Потом планфикс вызывает через API телефонии диспетчера и водителя, водитель получает втык, запись разговора прикрепляется в задачу, задача завершается. Если же нет, то диспетчер оповещается планфиксом уже через телеграмм ботом, а если и так нет реакции, то через час создаётся задача старшему диспетчеру и он начинает нагибать первых двух исполнителей.
Очень мощный инструмент автоматизации бизнес-процессов. И при этом там легко вести личные дела, использовать его как ежедневник и ещё куча других вариантов использования, судя по тому что пишут люди в успешных кейсах.
Спасибо, я покопаю глубже по поводу этой панацеи)
Нет, я имел ввиду как они определяют что скорость превышена — в машине установлена какая-то аппаратура или они с GPS телефона информацию берут?
Нет, я имел ввиду как они определяют что скорость превышена — в машине установлена какая-то аппаратура или они с GPS телефона информацию берут?
У нас аппаратура, но можно и с телефона. mobyfleet.ru/gps
Они специально для нас добавили функционал геозон, в которых можно указывать максимальную скорость.
Кстати по поводу определения текущей скорости ещё не всё решено. Есть подводные камни.
Они специально для нас добавили функционал геозон, в которых можно указывать максимальную скорость.
Кстати по поводу определения текущей скорости ещё не всё решено. Есть подводные камни.
Единственное чего у них пока нет, это удобного мобильного приложения, обещают уже год.Это перечёркивает все их достоинства. А ещё, как я понял, у них нет автономной работы. Я частенько бываю в местах, где даже голосовая связь отваливается, не то, что Интернет. Внезапно остаться без всех своих задач и планов — перспектива не из приятных.
Согласен, перечёркивает, есть мобильная версия и боты в телеграме, пока как-то перебиваемся.
В мобильном приложении обещают и автономную работу и именно это, я так понимаю и затягивает процесс. Потому как не совсем понятно, как обрабатывать автономность в случае групповой работы над задачами. В сингл режиме то проблем особых нет, хотя вдруг у вас есть и телефон и комп и ещё несколько устройств, и как это всё синхронизировать и решать конфликты при появлении связи?
А в мультиплеере вообще сложно, вы что-то по задаче сделали в автономном, а её уже закрыли или изменили и ваши действия уже не повлияют на сценарии так, как вы хотели. Да и даже если ничего не изменили, это же надо и серверные сценарии тянуть на клиент, чтобы они там выполнялись.
Надеюсь им удастся сделать что-то более интересное, чем простую автономную записную книжку
В мобильном приложении обещают и автономную работу и именно это, я так понимаю и затягивает процесс. Потому как не совсем понятно, как обрабатывать автономность в случае групповой работы над задачами. В сингл режиме то проблем особых нет, хотя вдруг у вас есть и телефон и комп и ещё несколько устройств, и как это всё синхронизировать и решать конфликты при появлении связи?
А в мультиплеере вообще сложно, вы что-то по задаче сделали в автономном, а её уже закрыли или изменили и ваши действия уже не повлияют на сценарии так, как вы хотели. Да и даже если ничего не изменили, это же надо и серверные сценарии тянуть на клиент, чтобы они там выполнялись.
Надеюсь им удастся сделать что-то более интересное, чем простую автономную записную книжку
Внезапно оказаться в местах, где даже голосовая связь отваливается да ещё без всех своих задач и планов — отличная перспектива.
Хорошей всем пятницы, а я в отпуск, рыбу ловить.
Пока ещё нет автономной работы и это ещё возможно.
Хорошей всем пятницы, а я в отпуск, рыбу ловить.
Пока ещё нет автономной работы и это ещё возможно.
Пытался реализовать что-то подобное. Дошёл до задачника и переключился на учёт физкультуры. По ходу пришёл к выводу, что в Android поддержка модульности реализована не лучшим образом, потому что все приложения как бы независимы и какой-либо группировки в магазине нет. Как следствие, проще организовать взаимодействие между приложениями, хоть через сокеты или интенты. Но более тонкой настройки уже не получится.
Спасибо что поделились своими проектами — представляю сколько сил было вложено. А в каком виде у вас был использован модульный подход?
Да, я, к сожалению, тоже столкнулся с такой же проблемой. Вы не встречали существующих приложений, которые общаются через сокеты или интенты? Любопытно, насколько вообще такой подход распространён.
Да, я, к сожалению, тоже столкнулся с такой же проблемой. Вы не встречали существующих приложений, которые общаются через сокеты или интенты? Любопытно, насколько вообще такой подход распространён.
А модульный подход у меня не использовался, но я его продумывал.:) Если под Linux это решается достаточно легко с помощью динамических библиотек (а в Qt вообще есть система плагинов) и зависимостей в пакетах, то в Android пока кроме выделения библиотек при компиляции и отдельных служб ничего не придумал.
Спасибо за статью. Примерно такую же задачу сейчас решаю тольк с crm/erp
Спасибо за отзыв. Насколько я понимаю, crm/erp это методология? А с помощью чего реализовываете?
Я бы сказал что это и методология и система, все взаимосвязано. Фактически все началось с того что ни одна не подошла, где то что то не хватало, где то было слишком много. А менять нельзя. Поэтому решили сделать модульную систему и выложить все на Github, может кому будет интересно присоединиться :). Пока делаем только веб приложение, поэтому — Vue.js -и LoopBack.
Как мне кажется, проблема «модульного» подхода в том что в итоге потом будет зоопарк, нужно будет как-то понимать как все эти комбинации модулей между собой взаимодействуют.
То есть наверное можно поддерживать небольшой зоопарк, небольшой зоопарк это не сложно. Но тогда у пользователя не будет всех фишек которые он бы хотел. А если делать все фишки которые бы он хотел, то тогда будет сложно гарантировать что всё будет работать достаточно гладко во всех комбинациях.
Автор, кстати, не пробовал org-mode? По-моему их идеалогия очень схожа. Правда поддержка мобильника всё ещё оставляет желать лучшего. Хотя вот активно пилится orgzly например, у них море планов.
То есть наверное можно поддерживать небольшой зоопарк, небольшой зоопарк это не сложно. Но тогда у пользователя не будет всех фишек которые он бы хотел. А если делать все фишки которые бы он хотел, то тогда будет сложно гарантировать что всё будет работать достаточно гладко во всех комбинациях.
Автор, кстати, не пробовал org-mode? По-моему их идеалогия очень схожа. Правда поддержка мобильника всё ещё оставляет желать лучшего. Хотя вот активно пилится orgzly например, у них море планов.
Несомненно, без зоопарка не получится, но я и не сказал что будет просто — нужно разработать методологию группировки и поиска всех этих модулей, а также варианты их доступного отображения для пользователя. Вообще говоря, эту часть системы тоже надо сделать модульной, чтобы множество разработчиков могло получить доступ к этим данным и попытаться сделать лучший вариант. Потом просто методом естественного отбора всплывут лучшие решения.
По поводу гладкости работы — запланировано обеспечить несколько этапов контроля новых модулей: сборка под разные платформы, автоматическое тестирование (функциональное, интеграционное), код-ревью другими разработчиками, выпуск модуля в бета-группу, а только после этого уже разрешение доступа к модулю всем пользователям. Тут много идей, но работы предстоит ещё больше.
Спасибо за информацию — не был знаком с ними. А какие у orgzly планы, ну из самых интересных?
По поводу гладкости работы — запланировано обеспечить несколько этапов контроля новых модулей: сборка под разные платформы, автоматическое тестирование (функциональное, интеграционное), код-ревью другими разработчиками, выпуск модуля в бета-группу, а только после этого уже разрешение доступа к модулю всем пользователям. Тут много идей, но работы предстоит ещё больше.
Спасибо за информацию — не был знаком с ними. А какие у orgzly планы, ну из самых интересных?
А вы пробовали анализировать предметную область? Сколько, действительно, различающихся по назначению модулей там можно придумать? То, что приведено у вас в разделе «Перспективы», — это (помимо машинного обучения) интеграция со сторонними устройствами.
Дело в том, что предметная область в данном случае не определена до того самого момента, как пользователь соберёт свой приложение. За исключением интеграции со сторонними устройствами, необходимо также учесть интеграцию со сторонними приложениями, все возможные функции персонального приложения и всевозможные вариации пользовательского интерфейса: начиная от цвета ярлыка — заканчивая отображением для очков виртуальной реальности.
Предметная область как раз определена хорошо. Это личная продуктивность и тайм-менеджмент. На эту тему написано много томов, но существенно различных стратегий управления делами может быть не так много. Если стратегий мало, то и интересных комбинаций много не получится. А значит, открытая платформа-конструктор не будет иметь преимущества перед каким-то специализированным планировщиком. На мой взгляд это ключевой вопрос, который нужно проанализировать, чтобы понять, есть ли потенциал у вашего конструктора.
А интеграционных модулей можно придумать бесконечное количество. Экспорт-импорт данных, синхронизация, всякие гаджеты, оформление UI. Это все полезно, но не то, что создает продукт.
А интеграционных модулей можно придумать бесконечное количество. Экспорт-импорт данных, синхронизация, всякие гаджеты, оформление UI. Это все полезно, но не то, что создает продукт.
Согласен с вами, что количество различных стратегий счётно и, если поискать, то можно найти готовую обзорную статью. Однако, если вы посмотрите на иллюстрацию в заголовке статьи, то сможете увидеть там множество серьёзных и успешных продуктов, которые, тем не менее, различаются только тем, что вы как раз перечислили. Дело в том, что аудиторию пользователей можно сравнить с ситуацией в басне «Лебедь, рак и щука» — все тянут в разные стороны: минималистичнее — функциональнее, в облако — на устройстве, десктоп — смартфон, ещё функций — слишком много функций. И в результате этого процесса, разработчик делает выбор в сторону требований большинства аудитории, ограничивая, тем самым, свой рост. В данном же случае, «Лебедь, рак и щука» могут тянуть хоть в разные измерения — система от этого станет только устойчивее.
Я не говорю что этот продукт является панацеей от всех бед разработки — он с таким же успехом добавляет новых, но вот проблему, которую я озвучил, он должен решить однозначно.
Я не говорю что этот продукт является панацеей от всех бед разработки — он с таким же успехом добавляет новых, но вот проблему, которую я озвучил, он должен решить однозначно.
Мне кажется, это получается адский мульти-тул для сложных задач вместо отвёртки или хотя бы швейцарского ножа.
Идеальный инструмент — тот, которым легко и приятно пользоваться, а не тот, который покрывает 110% запросов пользователей.
А это решается не модульностью, а хорошим дизайном и usability, от удобных шорткатов на компе до хорошего мобильного приложения. А то рождаются всякие убогие Trello, где интерфейсных ошибок больше, чем фич, зато его можно расширять модулями power ups!
Или посмотрите для примера на сегмент текстовых редакторов или редакторов кода. Монстры редко выживают, а уж модульность вообще мало кому нужна, хотя тоже можно было бы собирать идеальный редактор по кусочкам.
И, да, проще держать notepad, sublime text, word и phpstorm в придачу, потому что для разных целей удобно держать разные отвёртки.
Несомненно, если некорректно организовать расширение системы модулями, то от этого она лучше не станет, а только усложнится и станет бесполезной грудой кода. Но я и не говорил, что хорошо сделать такой инструмент будет простой задачей — встаёт много проблем по организации удобного подключения модулей как для пользователей, так и для программистов.
Я бы прямо сейчас бросил всё и начал радоваться жизни, если бы
Я бы прямо сейчас бросил всё и начал радоваться жизни, если бы
которым легко и приятно пользоватьсязначило для всех пользователей одно и то же. Рынок, к сожалению, переполнен продуктами, которые различаются лишь
хорошим дизайном и usability, а функционально являются идентичными на 70-95%. Да, варьируются масштабы проектов, но по сути, здесь уже вступает в дело маркетинговая политика, а не способности программистов.
Модульный интерфейс уже есть — TaskWarrior (+ TimeWarrior) и многочисленные дополнения и утилиты к нему. Да и Android приложение есть.
Спасибо, не слышал о нём. Да, очень много сделано у них и сообщество прекрасное. Обязательно рассмотрю его получше.
Однако, ознакомившись с документацией, хочу отметить следующие моменты:
В разделе Philosophy:
В разделе Extension API:
Однако, ознакомившись с документацией, хочу отметить следующие моменты:
В разделе Philosophy:
Taskwarrior carefully limits the features it supports, in order to focus on doing one thing well. It does not offer reminders and time tracking, because there are other projects dedicated to implementing those features well.Получается, что они заведомо ограничивают возможности расширения системы. Это не плохо — вполне вероятно, что у них прекрасно получается, но я в этой статье говорил о системе, в которой нет ограничений функциональности.
If a feature improves the way we manage task lists, then it belongs in Taskwarrior, otherwise it belongs in some other software.
В разделе Extension API:
Several Timewarrior reports are written as extensions, which uses an API to provide filtered data and configuration to the external command. This is a one-way process, the extension has no way to communicate back to Timewarrior. Future rules will allow this.Здесь же вообще говорится, что расширения не могут влиять на работу основного приложения. Да, они говорят что в дальнейшем ситуация изменится, так что если это действительно будет так, то этот пункт критики можно не учитывать.
UFO just landed and posted this here
К сожалению, телефон, не справляется с задачей агрегации приложений: они в большинстве своём разрозненны и между собой взаимодействуют плохо. Например, простой поход в магазин: нужно определить список покупок, желательно заранее прикинуть стоимость, вписать в план, в магазине иметь возможность свериться с планом и отметить купленное, а потом записать расходы и хорошо бы учесть пополнение запасов. Это уже три модуля (финансы, время, запасы), которые нужны не всем. Я бы ещё добавил физкультуру и питание, а также управление «умным домом», которым тоже хорошо бы обмениваться информацией. Сделать это всё одним приложением можно, но блаутварь получится ещё та. А между отдельными приложениями потребуется обмен данными и переходы от одного к другому.
UFO just landed and posted this here
Спасибо за ваш отзыв)
Как вы упомянули:
Абсолютно согласен с вами, что одно приложение ставить намного проще чем этакую махину, но я и не утверждаю что оно поглотит весь рынок, мимикрируя под все существующие приложения. Может мимикрировать то оно и сможет, но чтобы заставить его это сделать будет нужно будет, само собой, приложить некоторые усилия — что является минусом относительно «готовых» приложений. Однако это не приговор — здесь уже встают задачи по сведению этих усилий к минимуму и сокрытии от пользователя (по крайней мере в начале) всех доступных возможностей — чтобы не пугать его раньше времени.
И кстати, вы говорите об агрегации приложений — однако, в этой системе функции будут представляться отдельными библиотеками подключенными в одно приложение. То есть здесь агрегация идёт на уровне интерфейсов модулей. Чтобы это получше описать, воспользуюсь вашим примером:
Как вы упомянули:
По сути вы делаете аналог, но только для телефона.Однако, я делаю эту систему переносимой на все платформы — то есть весь спектр реализованных функции будет в том же виде доступен на любом устройстве.
Абсолютно согласен с вами, что одно приложение ставить намного проще чем этакую махину, но я и не утверждаю что оно поглотит весь рынок, мимикрируя под все существующие приложения. Может мимикрировать то оно и сможет, но чтобы заставить его это сделать будет нужно будет, само собой, приложить некоторые усилия — что является минусом относительно «готовых» приложений. Однако это не приговор — здесь уже встают задачи по сведению этих усилий к минимуму и сокрытии от пользователя (по крайней мере в начале) всех доступных возможностей — чтобы не пугать его раньше времени.
И кстати, вы говорите об агрегации приложений — однако, в этой системе функции будут представляться отдельными библиотеками подключенными в одно приложение. То есть здесь агрегация идёт на уровне интерфейсов модулей. Чтобы это получше описать, воспользуюсь вашим примером:
Я вот поставил его, и хочу чтобы приложение задач было связано с приложением миндмап, т.е. чтобы я мог видеть задачи наглядно.В архитектуре системы, список задач будет представлен модулем в котором хранятся только данные, а к нему уже будет подключаться модуль, который занимается только отображением — это что-то вроде подхода MVC. То есть один и тот же список задач можно, при подключении соответствующего модуля, отобразить как угодно.
Неплохо-неплохо. А кто-то до сих пор использует листики на холодильнике
Очень круто, если человек использует хотя бы листики, уверен, подавляющее большинство вообще ничего не использует и даже не испытывает потребности, но речь тут про тех, кому мало и листиков и даже того, что напридумывало человечество на данный момент. Ещё раз, удачи автору, чем больше такого на рынке, тем лучше.
Sign up to leave a comment.
Существует ли идеальный планировщик личных задач? Разработка модульного планировщика