Спасибо за комментарий. Цель данной статьи — познакомить читателя с базовыми возможностями работы с геолокационными сервисами на платформе Sailfish OS. Она рассчитана на начинающих разработчиков, которые просто хотят познакомиться с данной платформой и попробовать свои силы в разработке под нее. Именно поэтому было решено не усложнять примеры.
В принципе, достаточно удобным. На подобном небольшом проекте это, наверное, не так заметно. На больших должно быть более заметно. Из положительных моментов можно отметить, что вся логика работы с данными уходит в Store элементы, что позволяет структурировать код. Если бы мы делали все «стандартно», без централизованного хранилища, описывая логику в обработчиках событий, код бы получился довольно размазанным. Ну и, конечно, положительные момент такой, что состояние данных в любой момент доступно из Store в любой точке приложения и оно в силу реализации (Store реализованы как синглтоны) в один момент времени всегда одинаково для любого другого объекта. Такая централизованность всё таки дает ощущение надежности и единообразии. И опять же, если нам что-то нужно поменять в логике работы с данными, мы меняем в одном месте и оно работает так везде.
С QuickFlux никаких проблем не возникло, она просто добавляется в проект и «работает как есть» :) Очень упрощает жизнь, если надо реализовать подобную архитектуру. Единственный момент, но он связан скорее с особенностью Sailfish OS, а не QuickFlux. Нам пришлось покопаться в исходниках QuickFlux, чтобы изменить название библиотеки в QML на harbour.dictionary.trainer.QuickFlux. Это было необходимо для публикации приложения (вот тут есть подробное объяснение).
В целом, основная проблема была, конечно, в понимании архитектуры. В силу того, что у нас не так много опыта разработки вообще, а архитектура заметно отличается от привычного нам MVC, довольно много времени было потрачено на понимание и осознание самого принципа Flux.
Ох, как бы я не хотел дожить до времени когда будет одна ОС (которая скорее всего будет не нравится всем), а еще и один магазин, одна авиакомпания и прочее, благо хорошо помню как это было, когда все было по «одному»… Пусть лучше будет разнообразие и у Вас будет выбор под какую ОС разрабатывать, чьи телефоны покупать и так далее :)
Разумеется Jolla и ОМП нужно время чтобы найти свою нишу. И тут их история ничем не отличается от всех кумиров прошлого. Например, помню как в начале еще в FIDO гнобили телефоны Nokia, по сравнению с популярными тогда Motorolа. Было даже пара эх, специально посвященных этой теме. Я думаю все помнят как гнобили в начале Самсунги, причем в начале это даже было заслуженно. А как народ смеялся над более догорим GSM и малым количеством трубок под него, и говорил что они останутся на популярной тогда NMT (в России его чаще называли Delta по названию оператора). Это прогресс и это нормально. Мне кажется Jolla и ОМП делает очень классную и полезную работу, и то что Вы читаете эти посты и комментируете их, для меня знак что Вам это тоже интересно и это здорово.
На самом деле это не так, например, к осени разработчики будут нужны во FRUCT лабораториях, разработчики нужны в Индии и можно еще поискать. Но конечно пока масштабы не как у Android, экосистема только формируется, но и то что уже есть, выглядит очень неплохо.
Спасибо за комментарий. Цель данной статьи — познакомить читателя с базовыми возможностями работы с геолокационными сервисами на платформе Sailfish OS. Она рассчитана на начинающих разработчиков, которые просто хотят познакомиться с данной платформой и попробовать свои силы в разработке под нее. Именно поэтому было решено не усложнять примеры.
Ссылку поправили.
С QuickFlux никаких проблем не возникло, она просто добавляется в проект и «работает как есть» :) Очень упрощает жизнь, если надо реализовать подобную архитектуру. Единственный момент, но он связан скорее с особенностью Sailfish OS, а не QuickFlux. Нам пришлось покопаться в исходниках QuickFlux, чтобы изменить название библиотеки в QML на harbour.dictionary.trainer.QuickFlux. Это было необходимо для публикации приложения (вот тут есть подробное объяснение).
В целом, основная проблема была, конечно, в понимании архитектуры. В силу того, что у нас не так много опыта разработки вообще, а архитектура заметно отличается от привычного нам MVC, довольно много времени было потрачено на понимание и осознание самого принципа Flux.