Создание приложения на Ionic с использованием API

[saw_tooth]

Может Вам стоит как то более логично закончить статью? Ну, там выделить какие то отличии, подчеркнуть в статье вещи, которые Вы вынесли в заголовок, ну, если они действительно как-то особо рассматриваются в Вашей статье (API, ionic). Километры исходников можно было не выкладывать — у Вас есть ссылка на гит хаб, кто в «теме» поймет без комментариев, кто не очень — пройдет мимо.
Я не хочу негативно высказываться, но «о чем Ваша статья»? Что я должен вынести для себя после прочтения ее? Что появился какой то очередной кросс-велосипед для моб. сегмента. Так этим никого не удивишь. Ни метрик, ни сравнений (хотя бы с аналогичным нативным).
Печально в общем…

[Pashkevich]

В том то и дело, что статья НЕ о сравнении чего-то. Поэтому подводить итоги и делать сравнения не с чем. Я описал путь разработки приложения от начала и до конца. Чтобы новичок, который начал писать приложение на Ionic смог бы самостоятельно это сделать. А также смог бы понять, что и откуда берется.
Во-первых, километры исходников спрятаны в спойлеры. Во-вторых, каждый шаг расписан и показывает, что изменилось и что получилось.
Я считаю, что нельзя кидать готовый код без объяснения, что, как и почему работает. Я же в статье хочу показать, как можно сделать приложение и что для этого нужно написать.
Еще раз подчеркну. Это Tutorial по созданию приложения по шагам — а не вариант сравнения между нативным и кроссплатформенным.

[igor_malinovsky]

за туториал конечно спасибо, но если Вы хотели показать все шаги для новичков, то где билд под android ios

[Pashkevich]

Я считаю, что окончательный build по различные платформы может быть вполне отдельной статьей.
Дело в том, что недостаточно просто взять и выполнить команду build.
Нужно настроить проект в config.xml и др., настроить resources, такие как Icons, SplashScreen и т.д.
В данной статье я тестировал и показывал результаты, которые отображаются в браузере при выполнении команды ionic serve

[myemuk]

А почему вы не стали использовать ленивую загрузку страниц, причем она идет сейчас по-умолчанию? Тогда вместо

this.navCtrl.push(Postlist, { item: item, type: '1' });

будет

this.navCtrl.push('Postlist', { item: item, type: '1' });

и импортировать ничего никуда тогда не надо.

[Pashkevich]

Потому что о такой возможности я даже и не знал.
Вот вы впервые сказали мне.

[myemuk]

Для этого в папке с каждой странице должен лежать файл с именем что-то типа home.module.ts
И кстати, если использовать генератор страниц от ionic, то в последних его версиях он создает страницы уже с этим файлом. Так что в файле app.module.ts нужно подключать общие нативные модули, что сильно уменьшает и его размер и читаемость кода ))

[troyanskiy]

Небольшой ремарк.
HttpModule находится в статусе deprecated и будет выкошен в следующих версиях angular (не знаю в каких)
Вместо HttpModule необходимо искользовать HttpClientModule.
Так же можете глянуть в сторону библиотчки @ngx-resource/core в связке с @ngx-resource/handler-ngx-http

По поводу CORS в приложении (на девайсе, не браузере) можно использовать нативный модуль HTTP.

В своих приложения я использую оба метода http запросов:

• обычный с @ngx-resource/handler-ngx-http, когда приложение запущено из браузера и запросы к API происходят в том же домене (нет проблем c CORS)
• нативный с HTTP обернутый в @ngx-resource/handler-cordova-advanced-http,
  когда приложение «нативное» (нет проблем c CORS)

[cccco]

Что можно доработать:
1. Ленивая загрузка компонентов (как выше уже написали). Примеры:

• Ionic and Lazy Loading Pt 1
• Ionic and Lazy Loading Pt 2

2. Адаптивный вывод карточек.
Например, пользователь будет просматривать приложение на планшете да ещё в альбомном режиме. Как будут отображаться карточки с информацией в данном случае? Они растянутся на весь экран. Можно организовать вывод количества карточек в строке в зависимости от ширины экрана. Пример:

• Responsive Grid

3. Перенести загрузку и работу с данными в выделенный сервис/сервисы, вместо того, чтобы работать с данными напрямую в компонентах. Например, сервис Репозиторий — для работы с данными (сортировка, фильтрация и т.п.) и сервис Источник данных — для загрузки данных. Компоненты запрашивают данные и их необходимую обработку у сервиса Репозитория, который в свою очередь получает данные из источника. Источники данных можно в дальнейшем, при необходимости, менять. При этом при смене источника данных как-то менять классы компонентов и класс сервиса Репозитория не потребуется. Потребуется всего лишь в модуле сервиса Репозитория сменить класс сервиса Источника данных. Т.е. будет что-то в таком виде:

@NgModule({
    //...
    providers: [
        //...
        { provide: dataSource, useClass: prodDataSource}
    ],
    //...
})

Тут оба класса dataSource и prodDataSource должны определять одинаковые методы. При этом класс dataSource определяет просто интерфейс, т.е. набор пустых методов или методов, возвращающие пустой массив данных. В свою очередь каждый класс сервиса реального источника данных (например, prodDataSource) эти методы по-своему реализует.
4. Добавить классы-модели данных.