Comments 9
Может Вам стоит как то более логично закончить статью? Ну, там выделить какие то отличии, подчеркнуть в статье вещи, которые Вы вынесли в заголовок, ну, если они действительно как-то особо рассматриваются в Вашей статье (API, ionic). Километры исходников можно было не выкладывать — у Вас есть ссылка на гит хаб, кто в «теме» поймет без комментариев, кто не очень — пройдет мимо.
Я не хочу негативно высказываться, но «о чем Ваша статья»? Что я должен вынести для себя после прочтения ее? Что появился какой то очередной кросс-велосипед для моб. сегмента. Так этим никого не удивишь. Ни метрик, ни сравнений (хотя бы с аналогичным нативным).
Печально в общем…
Я не хочу негативно высказываться, но «о чем Ваша статья»? Что я должен вынести для себя после прочтения ее? Что появился какой то очередной кросс-велосипед для моб. сегмента. Так этим никого не удивишь. Ни метрик, ни сравнений (хотя бы с аналогичным нативным).
Печально в общем…
В том то и дело, что статья НЕ о сравнении чего-то. Поэтому подводить итоги и делать сравнения не с чем. Я описал путь разработки приложения от начала и до конца. Чтобы новичок, который начал писать приложение на Ionic смог бы самостоятельно это сделать. А также смог бы понять, что и откуда берется.
Во-первых, километры исходников спрятаны в спойлеры. Во-вторых, каждый шаг расписан и показывает, что изменилось и что получилось.
Я считаю, что нельзя кидать готовый код без объяснения, что, как и почему работает. Я же в статье хочу показать, как можно сделать приложение и что для этого нужно написать.
Еще раз подчеркну. Это Tutorial по созданию приложения по шагам — а не вариант сравнения между нативным и кроссплатформенным.
Во-первых, километры исходников спрятаны в спойлеры. Во-вторых, каждый шаг расписан и показывает, что изменилось и что получилось.
Я считаю, что нельзя кидать готовый код без объяснения, что, как и почему работает. Я же в статье хочу показать, как можно сделать приложение и что для этого нужно написать.
Еще раз подчеркну. Это Tutorial по созданию приложения по шагам — а не вариант сравнения между нативным и кроссплатформенным.
за туториал конечно спасибо, но если Вы хотели показать все шаги для новичков, то где билд под android ios
Я считаю, что окончательный build по различные платформы может быть вполне отдельной статьей.
Дело в том, что недостаточно просто взять и выполнить команду
Нужно настроить проект в
В данной статье я тестировал и показывал результаты, которые отображаются в браузере при выполнении команды
Дело в том, что недостаточно просто взять и выполнить команду
build
.Нужно настроить проект в
config.xml
и др., настроить resources
, такие как Icons, SplashScreen и т.д.В данной статье я тестировал и показывал результаты, которые отображаются в браузере при выполнении команды
ionic serve
А почему вы не стали использовать ленивую загрузку страниц, причем она идет сейчас по-умолчанию? Тогда вместо
this.navCtrl.push(Postlist, { item: item, type: '1' });
будет this.navCtrl.push('Postlist', { item: item, type: '1' });
и импортировать ничего никуда тогда не надо.Потому что о такой возможности я даже и не знал.
Вот вы впервые сказали мне.
Вот вы впервые сказали мне.
Для этого в папке с каждой странице должен лежать файл с именем что-то типа home.module.ts
И кстати, если использовать генератор страниц от ionic, то в последних его версиях он создает страницы уже с этим файлом. Так что в файле app.module.ts нужно подключать общие нативные модули, что сильно уменьшает и его размер и читаемость кода ))
И кстати, если использовать генератор страниц от ionic, то в последних его версиях он создает страницы уже с этим файлом. Так что в файле app.module.ts нужно подключать общие нативные модули, что сильно уменьшает и его размер и читаемость кода ))
Небольшой ремарк.
HttpModule находится в статусе deprecated и будет выкошен в следующих версиях angular (не знаю в каких)
Вместо HttpModule необходимо искользовать HttpClientModule.
Так же можете глянуть в сторону библиотчки @ngx-resource/core в связке с @ngx-resource/handler-ngx-http
По поводу CORS в приложении (на девайсе, не браузере) можно использовать нативный модуль HTTP.
В своих приложения я использую оба метода http запросов:
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)
Что можно доработать:
1. Ленивая загрузка компонентов (как выше уже написали). Примеры:
2. Адаптивный вывод карточек.
Например, пользователь будет просматривать приложение на планшете да ещё в альбомном режиме. Как будут отображаться карточки с информацией в данном случае? Они растянутся на весь экран. Можно организовать вывод количества карточек в строке в зависимости от ширины экрана. Пример:
3. Перенести загрузку и работу с данными в выделенный сервис/сервисы, вместо того, чтобы работать с данными напрямую в компонентах. Например, сервис Репозиторий — для работы с данными (сортировка, фильтрация и т.п.) и сервис Источник данных — для загрузки данных. Компоненты запрашивают данные и их необходимую обработку у сервиса Репозитория, который в свою очередь получает данные из источника. Источники данных можно в дальнейшем, при необходимости, менять. При этом при смене источника данных как-то менять классы компонентов и класс сервиса Репозитория не потребуется. Потребуется всего лишь в модуле сервиса Репозитория сменить класс сервиса Источника данных. Т.е. будет что-то в таком виде:
Тут оба класса dataSource и prodDataSource должны определять одинаковые методы. При этом класс dataSource определяет просто интерфейс, т.е. набор пустых методов или методов, возвращающие пустой массив данных. В свою очередь каждый класс сервиса реального источника данных (например, prodDataSource) эти методы по-своему реализует.
4. Добавить классы-модели данных.
1. Ленивая загрузка компонентов (как выше уже написали). Примеры:
2. Адаптивный вывод карточек.
Например, пользователь будет просматривать приложение на планшете да ещё в альбомном режиме. Как будут отображаться карточки с информацией в данном случае? Они растянутся на весь экран. Можно организовать вывод количества карточек в строке в зависимости от ширины экрана. Пример:
3. Перенести загрузку и работу с данными в выделенный сервис/сервисы, вместо того, чтобы работать с данными напрямую в компонентах. Например, сервис Репозиторий — для работы с данными (сортировка, фильтрация и т.п.) и сервис Источник данных — для загрузки данных. Компоненты запрашивают данные и их необходимую обработку у сервиса Репозитория, который в свою очередь получает данные из источника. Источники данных можно в дальнейшем, при необходимости, менять. При этом при смене источника данных как-то менять классы компонентов и класс сервиса Репозитория не потребуется. Потребуется всего лишь в модуле сервиса Репозитория сменить класс сервиса Источника данных. Т.е. будет что-то в таком виде:
@NgModule({
//...
providers: [
//...
{ provide: dataSource, useClass: prodDataSource}
],
//...
})
Тут оба класса dataSource и prodDataSource должны определять одинаковые методы. При этом класс dataSource определяет просто интерфейс, т.е. набор пустых методов или методов, возвращающие пустой массив данных. В свою очередь каждый класс сервиса реального источника данных (например, prodDataSource) эти методы по-своему реализует.
4. Добавить классы-модели данных.
Sign up to leave a comment.
Создание приложения на Ionic с использованием API