Разработка приложения для InstantCMS

Великолепно! Так сказать, шагнем в 21 век.

Прочитав все вышенаписанное возникло несколько вопросов:
1. Купив лицензию, я получаю рабочий "исходный код" приложения, который я могу пилить как хочу?
2. Ценник ~150$ — это за все три приложения под все ОС? Или каждое нужно покупать отдельно?
3. Не возникнет ли проблем с загрузкой похожих приложений в апстор и гугл плей?
4. Ориентировочно, когда ждать релиз?

Я думаю за все должна быть цена сразу
Смысл покупать для Андрюши а Афоню в игнор что ли?
А для виндовс разве планируется?
coolmazau, просто спросил про три)))

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

В случаи складчины — именно так и было бы, но так как вы платите всего долларов 50-150, то это совсем не разумно с точки зрения организации бизнеса, тогда смысл нам работать над приложением. Ведь разработка самого продукта стоит гораздо больше чем 150$, а вы хотите получить все и практически бесплатно.

2. Ценник ~150$ — это за все три приложения под все ОС? Или каждое нужно покупать отдельно?

Это будет цена за 2 приложение(IOS + Андроид). Но скажу сразу, что изначально делать будем под андроид, как только все отладим, аналогичное уже будет на IOS.

3. Не возникнет ли проблем с загрузкой похожих приложений в апстор и гугл плей? А какие могут быть проблемы? Название пакетов будет у всех свое. Уникальное.

4. Думаю конец апреля, середина мая. 2017 года. Сейчас

Я, конечно, не настоящий сварщик, но, имхо, приложение для CMS нужно делать не так.
Каждый сайт уникален, и функционал который жестко "вшит" в приложение устроит лишь единицы из ваших потенциальных клиентов.
Очередь за доработками "под себя" выстроится такой, что конца видно не будет.

В моём понимании такое приложение должно быть максимально универсальным.
Я бы делал так. Само приложение — это контейнер, который умеет рендерить вьюхи (активити) по некому "манифесту", представленному в виде файла. И вот этот манифест у каждого сайта свой. Внутри манифеста определяется всё, что можно — какие разделы будут в приложении, какие данные и как в них будут выводиться. Чтобы было так:
1) запускаем приложение
2) приложение коннектится на указанный сайт и скачивает манифест
3) на основании манифеста приложение генерит свои экраны (разделы)

Проще всего это реализуется простым WebView, как делают многие сегодня. Внутрь генерим нужный HTML и все дела. Все возможности нативного приложения (уведомления и т.п.) при этом никуда не исчезают. Если не нравится WebView, то можно генерить и нативные контролы динамически, это не сложно.

Соответственно дефолтный манифест и скрипт поставляющий данные для стандартных компонентов мы потом можем включить в релиз.
А если сторонний разработчик хочет чтобы его компонент тоже мог отображаться в приложении, он просто добавляет его в манифест и пишет свой endpoint для данных.

В эту сторону нужно работать, имхо.

UPD: собственно вот DK писал примерно о том же:

Так вот, приложение в виде браузера без адресной строки. Не знаю, как это назвать, не разбираюсь. Единственное, что должно быть обязательно — синхронихация с камерой и сообщения-уведомления. (...) В общем, если приходит сообщение или уведомление — на экране телефона всплывает вверху подсказка, даже если приложение свернуто. Что касается камеры: нужно загрузить картинку — на выбор загрузить или сделать фото.

Вот да, адаптированная мобильная версия (которая выглядит не как сайт, а как приложение с кнопками) + интеграция с Android API. И не нужно будет изобретать велосипед и придумывать патчи для каждого нового компонента.

Я, конечно, не настоящий сварщик, но, имхо, приложение для CMS нужно делать не так.
Каждый сайт уникален, и функционал который жестко "вшит" в приложение устроит лишь единицы из ваших потенциальных клиентов.
Очередь за доработками "под себя" выстроится такой, что конца видно не будет.

В моём понимании такое приложение должно быть максимально универсальным.
Я бы делал так. Само приложение — это контейнер, который умеет рендерить вьюхи (активити) по некому "манифесту", представленному в виде файла. И вот этот манифест у каждого сайта свой. Внутри манифеста определяется всё, что можно — какие разделы будут в приложении, какие данные и как в них будут выводиться. Чтобы было так:
1) запускаем приложение
2) приложение коннектится на указанный сайт и скачивает манифест
3) на основании манифеста приложение генерит свои экраны (разделы)

Проще всего это реализуется простым WebView, как делают многие сегодня. Внутрь генерим нужный HTML и все дела. Все возможности нативного приложения (уведомления и т.п.) при этом никуда не исчезают. Если не нравится WebView, то можно генерить и нативные контролы динамически, это не сложно.

Соответственно дефолтный манифест и скрипт поставляющий данные для стандартных компонентов мы потом можем включить в релиз.
А если сторонний разработчик хочет чтобы его компонент тоже мог отображаться в приложении, он просто добавляет его в манифест и пишет свой endpoint для данных.

В эту сторону нужно работать, имхо.

Мы не будем вшивать функционал, мы делаем так, чтобы приложение выступало в качестве "Конструктора", то есть на основании данных сайта, меню, типа контента и проч. будет строиться само приложение. Будет специальный компонент по управлению основных настроек самого приложения. Например возьмем компоненту ivideo. Вы добавляете в пункт меню видео и указываете ему ссылку в админке {content:video} и на основании этого мы уже по заранее сверстанной схеме показываем активити для типа контента видео, и все что связано с типом контента видео, будет отображаться в приложении, начиная от категорий заканчивая наборами. Добавили допустим поле для типа контента видео, это поле автоматом будет отображаться и в приложении со своим значением. Так же будет фильтрация например по этому полю среди видео...

Мы тоже не "сварщики" и понимаем, что приложение нужно универсальное, для всех. А так спасибо за отклик

А если добавили не новый тип контента, а компонент? Например, сделал я Фотобитвы и хочу добавить их в приложение. Но не смогу, получается?

А если добавили не новый тип контента, а компонент?

Или и того хуже. Я заменил стандартный "одно-бальный" рейтинг для записей на "много-бальный". Выходит, у него вообще не будет шансов?

А если добавили не новый тип контента, а компонент? Например, сделал я Фотобитвы и хочу добавить их в приложение. Но не смогу, получается?

Поэтому в этой теме выше у меня возник вопрос, где я предлагал к обсуждению — какие компоненты будут входить в основу приложения. Для начала мы будем делать "болванку" под основные приложения, далее по запросу от пользователей будет обновляться список поддерживаемых компонентов в рамках лицензии, какие-то из адаптируемых компонентов будут платные, например ivideo. Так же будет поддержка вебвью, с помощью которой можно будет отобразить не поддерживаемую компоненту.

Спасибо за мысли )

далее по запросу от пользователей будет обновляться список поддерживаемых компонентов в рамках лицензии

Это долгая песня. Зачем так усложнять? Представьте, я заказал разработку компонента, мне его сделали, но приложение с ним не работает. Сколько дней-месяцев лет мне ждать, пока приложение станет его поддерживать? Хорошо, если это компонент в свободной продаже. А если нет? Очередь заранее занимать?

какие-то из адаптируемых компонентов будут платные, например ivideo

А это сделает приложение слишком дорогим. Не буду говорить за всех. Но для меня нормальная цена приложения 50, ну максимум 70 долларов. И должно поддерживаться абсолютно всё. Иначе обойдусь, потому что кроме платной опции поддержки некоторых компонентов, того же iVideo, нужно еще купить сам компонент iVideo. Так и разориться не долго)))

далее по запросу от пользователей будет обновляться список поддерживаемых компонентов

Да это не вариант. Компонентов десятки, плюс многие сайты меняют их под себя. Очередь встанет на годы.

Таким образом, приложение рискует получиться слишком узким и никому не нужным (да еще и очень дорогим, т.к. $150 это очень много для подобного тиражируемого решения). Механизм добавления нового функционала самостоятельно (авторами компонентов и владельцами сайтов) — это то, о чем я бы думал в самую первейшую очередь. Без него вся затея не имеет смысла, имхо.

Не успел еще все прочитать, но не проще ли сделать приложение для начала в виде тех же виджетов?
Что-то вроде фидов можно же сделать для чтения и записи. В виджетах прописывать какие-то правила или создавать виджеты под приложения.
Может это что-то не в тему, но перечитаю и обдумаю все идеи.

Компонентов десятки, плюс многие сайты меняют их под себя. Очередь встанет на годы

Засада получается.
У меня есть немного допиленый компонент "Афиша", допустим приложение поддерживает этот компонент в стандартном его виде.
Но что делать если он будет криво работать из за моих правок?
Еще больше осложняет положение то, что это не выяснить до покупки.
Может есть какаято возможность распространять лицензию на исходники, которые будут работать только через какой нибудь ключ?
Или может два типа лицензии?
Первый — для тех кому хватит стандартных функций, например настройки цветовой схемы и логотипа.
Второй — для тех кому нужно будет регулярно залезать "под капот".

А это сделает приложение слишком дорогим. Не буду говорить за всех. Но для меня нормальная цена приложения 50, ну максимум 70 долларов. И должно поддерживаться абсолютно всё. Иначе обойдусь, потому что кроме платной опции поддержки некоторых компонентов, того же iVideo, нужно еще купить сам компонент iVideo. Так и разориться не долго)))

понятно, что Приложение это недешевое удовольствие и оно не должно на каждом углу валяться) всеже это для тех, кто осознано подходит к своему проекту и понимает как его развивать. В 90% приложение не нужно большинству владельцев сайтов

yury,

В 90% приложение не нужно большинству владельцев сайтов

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

понятно, что Приложение это недешевое удовольствие и оно не должно на каждом углу валяться) всеже это для тех, кто осознано подходит к своему проекту и понимает как его развивать. В 90% приложение не нужно большинству владельцев сайтов

Что по-Вашему "осознанно"? А, например, премиум-компоненты по-Вашему валяются на каждом углу? Или Вы считаете, что все делают свои сайты не осознанно? Этакие зомбаки, делают, не знают что. Приложение не может быть дешевым, согласен. Но в таком виде, когда оно будет одинаковое для всех, оно не может быть дорогим. Хотя, у каждого свое понимание дорого/дешево. И понимать, как развивать проект, не значит швыряться деньгами, вне зависимости от суммы. А если приложение будет изготавливаться с ориентиром на Ваше мнение (см. выше), то оно не нужно будет 99% владельцев сайтов. Не случайно, видимо, данная тема выделена цветом в списке. Как я понимаю, речь идет о приложении для массового потребителя, и одной из целей, скорее всего, является популяризация движка. Но я могу ошибаться, конечно же.