Помогите организовать логику работы приложения

[isee.dev]

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

Суть задания. У нас есть сайт. На сайте пользователь может купить купон, который выдается в электронном виде в виде 10 символов (буквы цифры)

Также у нас есть партнеры. Которые эти купоны принимают и обменивают на товар или услугу. Купон им необходимо “Активировать”. Что касается веб версии, то каждый партнер имеет уже этот функционал на нашем сайте в спец. кабинете, и давно уже активирует купоны, однако нужно сделать приложение, что бы там был сканер кюр кодов и можно было активировать купон через приложение. Просто сканируя код как в кинотеатре.

Мне необходимо найти ответы на такие вопросы:

1. Через какую библиотеку/фреймворк и тд я могу работать со своим сайтом?

Я вообще веб программист, и знаком со всеми ньюансами по вебу. У нас есть свой сервер, своя бд с огромным количеством таблиц и записей.

2. Каким образом осуществляются запросы от приложения? Только Get или есть еще Post?

3. Какие ответы должен давать сайт? В каком формате, и какие форматы ответов вообще поддерживает ios

4. Каким образом и когда делаются запросы к бд сайта, имею введу про многопоточность. Сам я еще эту тему на ios не проходил, но суть я понимаю. В моем проекте по сути, каждая вью это просто отображение информации из БД нашего сайта. На самом устройстве нечего хранить. Поэтому нужно ли делиться на потоки, что бы вью грузились отдельно а информация отдельно?

Это наверное основные вопросы, которые меня пока мучают:)

[lodar]

Вы меня простите конечно, но все ваши вопросы относятся к веб. Вы фронтендер или бэкэндер? Определитесь с архитектурой api, например RestFul, формат обмена опять же вам решать, проще всего json. Протокол взаимодействия http. Потом напишите апи и только потом уже думайте о мобильном приложении.

[isee.dev]

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

[haymob]

1. URLSession
2. Любым

var request = URLRequest(url: URL(string: "http://...")!)
request.httpMethod = "POST" // GET PUT DELETE
request.setValue("application/json", forHTTPHeaderField: "Content­-Type") // Header
request.httpBody = try! JSONSerialization.data(withJSONObject: ["name": "test"]) // Body

URLSession.shared.dataTask(with: request) { data, response, error in }.resume()

3. Любые, проще всего json

URLSession.shared.dataTask(with: request) { data, response, error in
    guard let data = data else { return }
    let object = try! JSONSerialization.jsonObject(with: data)
    print(object)
}.resume()

4.

URLSession.shared.dataTask(with: request) { data, response, error in // Работает в бекграунде
    guard let data = data else { return }
    let object = try! JSONSerialization.jsonObject(with: data)
    print(object)
    DispatchQueue.main.async { // UI нужно обновлять в основном потоке
        
    }
}.resume()

[isee.dev]

Спасибо большое! код ваш понятен. Буду применять! Благодарю!

[isee.dev]

Можете еще помочь дополнительно определить для себя, как реализовать логику работы раздела “мой профиль”

На сайте, в разделе мой профиль пользователь может менять свои данные - грузить фото, менять имя, контакты и тд.

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

Я представляю себе это так:

На веб сервере
Для данных профиля я создам к примеру поле “lastModified”, где буду ставить дату последнего редактирования профиля.

В приложении
В первый раз я загружаю все данные из веба, и сохраняю в памяти устройства, сохраняю значение поля lastModified.

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

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

Верна ли такая логика? или все делается как то по другому?

[haymob]

Логика верна, но такую “сложную” синхронизацию имеет смысл делать когда большой объём данных, в случае с профилем проще каждый раз грузить новые данные.

[nikmich]

1. Советую Alamofire.
   1.1 И post, и get. Я вообще предпочитаю только post. Мне так проще.
2. Для меня удобнее всего json. Посмотрите фреймворк SwiftyJson.
3. Делить, конечно, нужно. View грузятся в потоке main синхронно. А информацию из БД по сети лучше грузить в бэкграунде асинхронно и подгружать во вью по мере готовности. Иначе в интерфейсе будут тормоза, дерганья и прочие штуки, которые не любят пользователи. Стандарт в iOS обновления экрана равен 60fps, а этого можно достичь только если не мешать главному потоку, в котором обновляется интерфейс.

[haymob]

Советую Alamofire

Чем Alamofire лучше URLSession и в каких ситуациях?

Посмотрите фреймворк SwiftyJson

Чем SwiftyJson лучше стандартных средств в swift 4?

View грузятся в потоке main синхронно

Что будет если я обновлю вью асинхронно и какая разница?

грузить в бэкграунде асинхронно

А если бекграунд поток свободен и я в нём гружу синхронно?

и прочие штуки,

Что за штуки такие?

[nikmich]

В программировании все можно реализовать самыми разными способами. И нету одного-единственного правильного. Поэтому очень многое зависит от предпочтений.
URLSession, если его специально не сконфигурировать, будет работать в main-потоке. Alamofie из коробки сконфигурирован так, чтобы работать в бэкграунде, хотя его можно дополнительно сконфигурировать для более тонкой настройки.
SwiftyJson - это тоже вопрос предпочтений. Мне нравится его сахар. Хотя в swift 4 с json стало получше, это правда. А до этого была сплошная боль.
Если вы не предпримите дополнительных действий, то view в main будут грузиться синхронно. Обновлять view асинхронно или синхронно - это зависит от потребности. Если экран обновляется плавно, то можно, наверное, и не заморачиваться с асинхронностью.
А штуки, которые не любят пользователи - это, например, дерганье при скроллинге table view или collection view, зависания, когда приложение не реагирует на жесты.

[haymob]

И нету одного-единственного правильного.

Есть. Использовать нативные средства что предоставляет платформа, вы же наоборот предлагаете использовать пару костылей.

будет работать в main-потоке

Нет не в main, из коробки в бекграунде, видимо вы с ним даже не работали.

[nikmich]

Есть. Использовать нативные средства что предоставляет платформа, вы же наоборот предлагаете использовать пару костылей.

Это холиварная тема. Нет смысла ее развивать. Так можно докатиться до того, что правильнее всего программировать сразу в машинных кодах. Но я бы вместо машинных кодов предпочел хотя бы ассемблер. Кстати, вспомнилось тут про ассемблер)) Много лет назад ассемблерщики делились на два класса. Первые - те, которые предпочитали условия писать на masm с помощью .if expression, и те, которые предпочитали jnz offset, потому что .if не круто. Я предпочитал .if, потому что так нагляднее))

Насчет URLSession - возможно.

[haymob]

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

Еще можно докатиться что на каждый чих будешь искать фреймворк. Я скорее к тому что, нужно сначала изучить что есть в платформе, а уж потом изучать всякие индусские библиотеки/фреймворки

[nikmich]

Искать или не искать - это опять же вопрос религиозный. Почему бы не поискать, если есть такое желание? Я вообще предпочитаю поискать готовое решение, посмотреть как там сделано, потом вырезать нужный кусочек и вставить в проект, чтобы не таскать всю библиотеку. Например, есть замечательная библиотека Chameleon, но из нее я пользуюсь только цветами UIColor.flatRed(), .flatGreen() и т.д. Зачем тащить в проект весь фреймворк, когда можно вырезать оттуда маленький кусочек? И зачем прописывать все цвета заново, когда там все уже есть?

[haymob]

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

[nikmich]

Любой фреймворк это обертка над чем-то. Вы, наверное, из тех людей, которым нужен только хардкор. Если рисовать, то только в Paint, ни в коем случае не в Photoshop, если писать, то только в Notepad, ни в коем случае не в Word. Это все для слабаков. Я же предпочитаю искать баланс. Если фреймворк занимает мало места и хорошо делает свою работу, буду использовать фреймворк. Если есть возможность и время, посмотрю, как там реализовано. Если фреймворк не подходит, то реализую все сам. Все зависит от задач и условий. А для вас есть только или-или: белое и черное, полутонов не бывает. Ну ок, это ваша позиция, наверное, вам так нравится. На этом дискуссию считаю закрытой.

[Ookey]

А в чем плюсы Alamofire и SwiftyJson? Над первым все равно прихрдится писать обертку. Второй абсолютно бессмысленен в Swift 3+

[haymob]

Нет, я не из таких. Я из секты где не любят поддерживать чужой код и предпочитают всё нативное (для платформы) или официальные SDK (Facebook Firebase etc).