При создании приложения iOS от конца до конца, нужно ли сначала создать первый или задний конец?

Question

Я был разработчиком в течение 10 лет (без iOS), и работа в большой компании никогда не создавала приложения в конце. Просто работал над очень большими приложениями, на куски.

Я начинаю входить в iOS для удовольствия и иметь приложение в моей голове, которое я хочу создать. Я все связал все с помощью интерфейса приложения iOS. С тех пор я начал начинать кодирование. У меня около 15 сцен в раскадровке (общее приложение, вероятно, будет 100+), и сейчас я просто использую жестко закодированные «поддельные» данные.

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

Есть ли у кого-нибудь предложения и причины, почему один способ лучше другого?

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

Кроме того, я мало знаю о создании задних концов. Приложение, которое я создаю, не похоже на твиттер, но для доступа к данным и для этого примера, допустим, это так. Основной вид приложения - это что-то вроде twitter. Пользователь может ударить обновление и получить много новых точек данных («твиты» в твиттере) с сервера. Таким образом, приложение может быть очень интенсивным. Лучше ли я использовать что-то вроде Parse и оплачивать их услуги, или создавать что-то в LAMP, или что-то еще. За последние 10 лет я много работал с SQL и базой данных, и мне очень нравится этот аспект задней части.

Мысли? Предложения?

Спасибо!

Answer 1

Я бы сказал, что у вас есть 3 варианта здесь:

Передний конец первого, фоновым после

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

Back-конец первого, передний конец после

Вы можете здесь действительно не видите, где вы собираетесь при разработке фоновым. Вы увидите (вы даже можете это уже узнать), что то, что вы создадите для клиента, может быть не таким, как оно выглядело в вашей голове. Вероятно, вам придется много переработать на заднем плане.

Передний и обратный конец вместе

Это, как я обычно работаю. Запустите front-end так же, как и с жестко закодированными данными, и начните как можно скорее работать с фоновым контентом. Переместите ваши данные шаблона на нем, чтобы вы могли убедиться, что они хорошо общаются. Затем попробуйте работать одновременно. Таким образом, если вы передумаете о чем-то с одной стороны, вам не придется переделывать много кода с другой стороны.

---

Что касается фоновым решения, в значительной степени все, что я могу сказать, что я использовал Parse.com услуги, и это очень хорошо. В моем случае я не был готов самостоятельно создать весь back-end. Если можете, возможно, они вам не нужны. Но, (и это большой), SDK Parse может позаботиться обо всем сообщении между вашим back-end и вашим интерфейсом. Вам не нужно управлять доступностью сети, кешированием и всем, о чем вам нужно подумать, когда вы разрабатываете для мобильной ОС. Это очень мило.

Их бесплатный план позволяет запускать 1M-запросы каждый месяц, что довольно много. Но если вы хотите пойти дальше и уменьшить количество запросов к Parse, вы можете объединить свои собственные серверные и их собственные. Он может не работать для вашего конкретного случая, но вы можете получить доступ к вашему серверу для проверки доступности новых данных и только затем выполнить запрос Parse. Например, для новостного приложения, получите новости на parse.com, сохраните самую последнюю дату новостей на своем сервере, сохраните последнюю дату обновления на клиентском устройстве и перед доступом к синтаксическому анализу сравните даты с вашим сервером. Если необходимо, запрос анализирует, если нет, перейдите в кэш (обрабатывается SDK синтаксического анализа). Таким образом, вы можете ограничить количество запросов и остаться в свободном плане.

Вероятно, вы должны попытаться оценить количество запросов, которые вы будете получать в месяц, и денежное влияние перед выбором.

Просто мое мнение:]

Answer 2

Я хотел бы предложить вам добавить новые функции в приложение с наименьшей возможной сложности. Как и e. г. «Пользователь может видеть список всех зарегистрированных пользователей». - Этот пример может не очень хорошо подходить для вашего дела, но я надеюсь, что вы поймете суть: создавайте одну маленькую вещь за раз.

Но для этих мелочей: совершите полное путешествие спереди и назад. Поскольку это не должно занять слишком много времени, чтобы завершить такую ​​функцию, на самом деле не имеет значения, если вы сначала заполните интерфейс или бэкэнд. Так что для этой части: в основном то, что @rdurand уже сказал;)

Что касается внутреннего интерфейса Я вижу два варианта:

1. Либо вы создаете какой-то REST-услуги самостоятельно. Выбор техники должен зависеть от того, что вы уже знаете. Я большой поклонник JAX-RS, но если у вас еще нет опыта работы с java, вам может быть трудно с этим справиться.
2. Используйте какой-то SAAS-API. Я слышал хорошие вещи о http://www.apiomat.com/, но никогда не использовал его сам ...

удачи;)