Bookmark Ninja - это веб-приложение, оно запускается в браузере как на компьютере, так и на мобильном телефоне. На мобильных устройствах у него есть специальный мобильный веб-интерфейс, который выглядит как собственное мобильное приложение. В настольных браузерах он использует букмарклеты и расширения браузера, которые позволяют отправлять Ninja ссылку на текущую веб-страницу. В настоящее время на мобильных устройствах это можно сделать, только отправив ссылку по электронной почте на выделенный адрес электронной почты (нажмите Поделиться, затем выберите адрес электронной почты). Но с этим решением вы не можете добавлять теги или устанавливать целевую вкладку / категорию, что вы можете делать в настольных браузерах с помощью букмарклетов и расширений. Настало время найти лучшее решение для мобильных браузеров. Конечным решением является собственное мобильное приложение, которое на самом деле является приложением расширения для мобильного браузера.

План А

Первоначальный план заключался в разработке полноценного нативного приложения для iOS, которое взаимодействует с сервером Ninja через RESTful api. 3 года назад я узнал о REST, когда брал уроки Java, но я никогда не работал с REST, у меня нулевой опыт. Кроме того, внедрение REST влияет и на серверную часть, а не только на клиентское приложение iOS, поэтому предстоит еще больше работы.

Другая проблема - это Swift. 5 лет назад я начал разрабатывать игру для iOS на Objective C. Я работал над ней в течение года с частичной занятостью. Потом сдался, проект не закончил. Я также помню, что не был большим поклонником Objective C и Xcode. Я читал, что Swift имеет много улучшений по сравнению с Objective C, поэтому мне очень хотелось познакомиться со Swift.

План B

План Б появился, когда я начал беспокоиться о том, какой объем работы требуется для этого проекта, особенно учитывая неопределенность с REST и Swift. Моя идея заключалась в том, чтобы упростить работу с веб-просмотром в приложении для iOS. В веб-просмотре вы фактически получаете доступ к серверу Ninja через https, как в браузере, а пользовательский интерфейс выглядит как собственное мобильное приложение (с использованием PrimeFaces mobile / jQuery mobile). С помощью этого решения я могу выиграть следующее:

  • REST не требуется вообще, потому что я обращаюсь к серверу в веб-просмотре через https
  • Придется писать гораздо меньше кода Swift (все функции «добавления закладки» описаны в веб-просмотре, уже разработанном на Java)
  • Аутентификацию пользователя также можно выполнить в веб-просмотре (уже разработанном на Java).

Я подумал, что это отличная идея, поэтому решил пойти по плану Б. Реализовать расширение общего ресурса iOS таким образом заняло всего несколько дней. Я мог сэкономить много времени с помощью плана Б, так что я считаю, что это хорошее решение.

Все еще не большой поклонник Swift и Xcode

Хотя код расширения общего ресурса действительно занял всего несколько дней, Swift и Xcode разочаровали. После программирования Java и Eclipse на Swift с Xcode мне показалось, что кататься на велосипеде задом наперед. Я не могу лучше объяснить, что я чувствовал, но думаю, некоторые из вас могут понять, что я имею в виду. Я хотел бы упомянуть лишь некоторые из моих впечатлений:

  • Я чувствовал, что поддержка API не очень удобна для разработчиков. При создании проекта мне пришлось выбрать цель расширения общего ресурса. Речь идет, например, о совместном использовании веб-страницы в браузере. Итак, я подумал, что получение заголовка и URL-адреса - это что-то вроде something.getUrl () и something.getTitle (). Нет, это не так. Вам нужно написать 15 (!) Строк кода, чтобы получить URL-адрес и заголовок. И я не нашел этих 15 строк кода в официальной документации разработчиков Apple, скорее я нашел их на разных форумах и в Stackoverflow.
  • Обратная совместимость ... Когда я искал что-то в сети, большинство найденных мной кодов Swift были либо в Swift 1, либо в 2. Когда я попытался использовать эти функции, оказалось, что большинство из них были обесценены, удалены или были переименованы в Swift 3. Итак, каждый год, когда выходит новая версия iOS, мне нужно обновлять свой код, перестраивать и повторно отправлять приложение?
  • Я не мог отлаживать ... Точки останова не работали, «печать» не выводилась на консоль. Я поискал в сети эту проблему и нашел довольно много дискуссий на эту тему. Я перепробовала все, что было предложено, но не помогло. Наконец, добавлен звуковой эффект «твит» iOS в код, чтобы проверить, выполняется ли эта часть кода или нет. Ну, это не профессиональная методика отладки ...
  • Мне показалось, что синтаксис Swift такой же неудобный, как синтаксис Objective C. Хорошо, я согласен, это своего рода личное субъективное суждение.

Я не стал глубоко разбираться в Swift, но, даже поцарапав поверхность, я столкнулся со многими проблемами. Это правда, что я разработал только простое расширение общего доступа, у меня нет опыта работы с другими областями, они могут быть в порядке, я не знаю ... Тем не менее я был счастлив, что смог придумать решение, которое сэкономило много время.

Мое счастье длилось недолго

Я был очень счастлив и доволен, пока не начал читать о правилах подачи заявок в Apple App Store. Вскоре выяснилось, что у многих разработчиков были проблемы с отправкой приложений, которые включают веб-просмотр. Это кажется деликатной областью, и использование веб-просмотра может быть причиной отказа. Еще более серьезная проблема заключается в том, что Apple, похоже, не нравится вход через веб-просмотр, они предпочитают собственный вход (когда вход реализован с помощью встроенных элементов управления iOS). Это в значительной степени отстой ... и сразу же разрушает план Б. И это также означает, что, вероятно, план А - единственный вариант. Дерьмо.

Заключение

Переход к плану A означал бы много дополнительных усилий (особенно с учетом того, какой опыт у меня был со Swift за этот короткий промежуток времени). Я уже писал в одном из своих предыдущих постов о том, как решить, какие функции реализовать. Я думаю, что объем работы, который требуется для выполнения плана А, непропорционален той ценности для клиентов, которую принесет эта новая функция. Кроме того, эта функция была скорее моей идеей, а не запросом клиентов. В бэклоге есть и другие более мелкие функции, которые имеют большую ценность для клиентов, но требуют меньше работы. Теперь я лучше пойду с ними. Есть даже небольшая, но полезная функция, которая улучшит нынешний пользовательский интерфейс Добавить в ниндзя на мобильном телефоне. И все эти функции должны быть разработаны на Java на стороне сервера. Суть в том, что я решил отложить родное приложение iOS Добавить в ниндзя. Позже, когда я вернусь к этому проекту, я, вероятно, завершу план Б (веб-просмотр) и дам ему возможность отправить приложение в App Store. Но вероятность того, что его примут, очень мала. Итак, история действительно о плане А. Посмотрим.

У меня смешанные чувства. С одной стороны, мне грустно, потому что я люблю вызовы, а это определенно большой вызов. С другой стороны, мне немного легче, потому что я все еще чувствую, что я не большой поклонник Swift (Objective C), я предпочитаю Java. Но теперь я рад, что наконец-то смогу вернуться на Java на следующей неделе.