у меня складывается впечатление, что к платным приложениям и приложениям со встроенными покупками Apple относится мягче.
Лично столкнулся с отказом на размещение бесплатного приложения, которое «не соответствовало требованиям». после того как предоставил ссылки на аналогичные платные решения, уже находящиеся в App Store, лед тронулся.
спасибо за ваше решение!
Статья в очередной раз вызвала у меня вопрос — ведь это же максимально распространенная задача: удобная кроссплатформенная локализация с теми фичами, о которых вы пишите. Разработка мобильных приложений появилась не вчера. Почему же нет удобного и массового решения этой задачи? Или я просто не знаю о нем?
Сегодня получал посылку на почте, «тречил» посылку через их ультрасовременное и вполне пригодное приложение, вопросов к нему нет, а вот к процессу стояния в очереди и получения на самой почте, как всегда есть ряд вопросов.
Это понятно, но до того как пользоваться, я хочу посмотреть как это будет выглядеть глазами обычного пользователя, который увидит форму на сайте. Загляните в Яндекс.Кассу — там нужно ввести номер телефона, чтобы понять как будет выглядеть форма?
Столкнулся с резким увеличением потребления ресурсов и медленной загрузкой приложения. После профайлинга заметил, что дело в нестандартных шрифтах, добавленных в проект. После перехода на системные шрифты, приложение стало гораздо быстрее работать.
В истории с Pokemon Go мне кажется важным тот факт, которому мало уделяют внимание.
Дело же не только в том, где размещать обзоры и делать вбросы, тут же дело в том, что выросло поколение тех, кто много месяцев к ряду смотрел покемонов, знает их и ностальгирует по детству, мечтал чтобы у него был свой Пикачу или еще кто) Целая армия лояльной публики. Просто, мне кажется, что далеко не любую игру/приложение можно продвинуть только грамотным размещением информации и вбросами.
А с технической точки зрения я революции не увидел (хотя в покемонов не играл): ровно 10 лет назад на моей Nokia 3230 была игра, где нужно было стрелять по каким-то бактериям или вирусам, которые накладывались на изображение с камеры.
Хорошая идея + можно сделать рекламный баннер и возможность отключить рекламу за 15 рублей. Это позволит получать небольшой доход на рассылку через смс шлюзы.
Спасибо за статью, жду продолжения.
Лично я не смог полюбить Core Data — слишком громоздким он мне показался.
Кстати, ваш пример действительно ближе к реальным задачам, чем многое из того, что я видел. При этом очень хочется увидеть оптимальный способ взаимодействия данных в Core Data с данными с сервера. К примеру, список заказчиков и данные по ним хранятся на сервере, и при наличии изменений они дозагружаются на устройства. И наоборот — при изменении данных на устройстве, они меняются и на сервере.
Спасибо за статью, лично я из неё сделал такие выводы:
1) перестав работать с сервисом, убрать весь его код из своего проекта
2) для проектов со сторонними скриптами проверять переодически, что нет скриптов, возвращающих 404
3) если я делаю сервис, не «бросать» свои домен
4) если я имею сервис и «бросил» свои домены — заблаговременно известить тех, кто может использовать такой домен
Мне почему-то кажется, что все сильно проще и этот зловред был добавлен изначально в обычную версию и уже таким был загружен на сайт. То есть, я за то, что это скорее диверсия, чем взлом и подмена.
В противном случае получается, что любую программу для Mac, которая распространяется не через App Store можно так "дооснастить" таким шифровальщиком. Верить в это не хочется)
я вот теперь не знаю, по какому принципу выбирать, какому сервису доверять. Уж Parse был надежный, нежадный, с комьюнити, симпатичный, перспективный… Теперь только и делают, что присылают письма с вариантами для миграции.
Согласен с вами, ссылка на соответствующую страницу github будет руально полезнее для тех, кто может прочесть и понять текст на английском, но думаю, что эта запись, во-первых, ориентирована на тех, кто будет искать "альтернативы сервису Parse", а, во-вторых, тех, кто хочет прочитать комментарии на эту тему опять же на русском.
Для отправки Push-уведомлений OneSignal действительно может заменить Parse, особенно когда нужна именно бесплатная замена. OneSignal трудно назвать полноценной альтернативой Parse, потому что у них есть только уведомления.
Могли бы вы пояснить на каком-то другом примере преимущества от подобных операций — на чем реально можно много сэкономить ресурсов.
Просто в данном случае размер картинки, конечно, удалось получить без каких-либо сторонних библиотек, но для другого программиста данный код в проекте может вызвать больше вопросов. Тут выгода не так очевидна, на мой взгляд.
Лично столкнулся с отказом на размещение бесплатного приложения, которое «не соответствовало требованиям». после того как предоставил ссылки на аналогичные платные решения, уже находящиеся в App Store, лед тронулся.
Статья в очередной раз вызвала у меня вопрос — ведь это же максимально распространенная задача: удобная кроссплатформенная локализация с теми фичами, о которых вы пишите. Разработка мобильных приложений появилась не вчера. Почему же нет удобного и массового решения этой задачи? Или я просто не знаю о нем?
Дело же не только в том, где размещать обзоры и делать вбросы, тут же дело в том, что выросло поколение тех, кто много месяцев к ряду смотрел покемонов, знает их и ностальгирует по детству, мечтал чтобы у него был свой Пикачу или еще кто) Целая армия лояльной публики. Просто, мне кажется, что далеко не любую игру/приложение можно продвинуть только грамотным размещением информации и вбросами.
А с технической точки зрения я революции не увидел (хотя в покемонов не играл): ровно 10 лет назад на моей Nokia 3230 была игра, где нужно было стрелять по каким-то бактериям или вирусам, которые накладывались на изображение с камеры.
Лично я не смог полюбить Core Data — слишком громоздким он мне показался.
Кстати, ваш пример действительно ближе к реальным задачам, чем многое из того, что я видел. При этом очень хочется увидеть оптимальный способ взаимодействия данных в Core Data с данными с сервера. К примеру, список заказчиков и данные по ним хранятся на сервере, и при наличии изменений они дозагружаются на устройства. И наоборот — при изменении данных на устройстве, они меняются и на сервере.
1) перестав работать с сервисом, убрать весь его код из своего проекта
2) для проектов со сторонними скриптами проверять переодически, что нет скриптов, возвращающих 404
3) если я делаю сервис, не «бросать» свои домен
4) если я имею сервис и «бросил» свои домены — заблаговременно известить тех, кто может использовать такой домен
В противном случае получается, что любую программу для Mac, которая распространяется не через App Store можно так "дооснастить" таким шифровальщиком. Верить в это не хочется)
Просто в данном случае размер картинки, конечно, удалось получить без каких-либо сторонних библиотек, но для другого программиста данный код в проекте может вызвать больше вопросов. Тут выгода не так очевидна, на мой взгляд.