Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
Спасибо. Просто большое спасибо.
<offtop>С возвращением, бро</offtop>Под iOS не пишу, но
К сожалению, пособие о том, как набрать 400 000 000 пользователей и продать сервис за 19 Инстаграмов, затерялось где-то на книжной полке. Постараюсь его найти, если кому интересно.
было бы интересно. Ищи пособие :D
С сегодняшнего дня актуально писать код на Swift.
Если сделаете пример с кодом на Swift цены Вам не будет.
Если сделаете пример с кодом на Swift цены Вам не будет.
Не пробовали наш QuickBlox в качестве бекенда? Как раз для этих целей, и $100 не надо платить.
Пробовали, хорошая штука :) Но с тем фреймворком, что используется в статье, я работал дольше и глубже знаю его структуру, поэтому и привожу его в качестве примера.
Понял. Мы скоро релизим много вкусного:
Было бы хорошо получить обратную связь от вас после этих релизов, т.к. расчет на то, чтобы уменьшить всю эту работу еще в разы и действительно добиться вот этого «WhatsApp» за сутки, не просто на уровне proof of concept, а с UI и кучей необходимых примочек.
- open-source проект-пример с готовым профессиональным UI из коробки под iOS, Android и Web. Всё можно менять, но не нужно будет делать пресловутые чат бабблы с нуля.
- Chat 2.0 — набор дополнительных REST JSON API для управления чат-сервером, чатами и комнатами + более мощная админка для ручного управления
- полная интеграция с WebRTC для видео и аудио звонков
Было бы хорошо получить обратную связь от вас после этих релизов, т.к. расчет на то, чтобы уменьшить всю эту работу еще в разы и действительно добиться вот этого «WhatsApp» за сутки, не просто на уровне proof of concept, а с UI и кучей необходимых примочек.
Пользуюсь в 1 проекте, Все хорошо, только 1 вопрос:
А документация полная по всем методам в библиотеке под Android, да и под iOS имеется?
А документация полная по всем методам в библиотеке под Android, да и под iOS имеется?
да, конечно, вот джавадоки:
sdk.quickblox.com/android/
и эпплдоки:
sdk.quickblox.com/ios/
скоро выпускаем серьезный апгрейд iOS библиотеки
sdk.quickblox.com/android/
и эпплдоки:
sdk.quickblox.com/ios/
скоро выпускаем серьезный апгрейд iOS библиотеки
Какой же это мессенджер за 24 часа, если у него под капотом чужой движок передачи данных и чужой механизм работы с БД. Это скорее «простенький UI за 24 часа».
Как обычно, 95% времени занимает доделать остальные, хм, «5%» работы. Нормальные тянущиеся бабблы для сообщений, сложные случаи одновременной отправки-прихода-переотправки-удаления. А когда дойдет до того, что нужно будет добавить еще один тип сообщений? Мы же хотим и видео отправлять, и фоточки, и стикеры и прочую муть.
Касательно примера: на каждый приход сообщения делается reloadData. Вы серьезно? И когда у ячеек будут разые размеры, то каждый раз перерасчитывать все высоты? А если там CoreText? Нужны отдельные insert'ы и reload'ы. И в UITableView там начинается самое интересное. Поэтому (и не только поэтому) я бы посоветовал сразу делать UI на основе UICollectionView.
UI всегда состоит из мелочей, которые особенно важны пользователям и именно они занимают львиную часть работы.
Как обычно, 95% времени занимает доделать остальные, хм, «5%» работы. Нормальные тянущиеся бабблы для сообщений, сложные случаи одновременной отправки-прихода-переотправки-удаления. А когда дойдет до того, что нужно будет добавить еще один тип сообщений? Мы же хотим и видео отправлять, и фоточки, и стикеры и прочую муть.
Касательно примера: на каждый приход сообщения делается reloadData. Вы серьезно? И когда у ячеек будут разые размеры, то каждый раз перерасчитывать все высоты? А если там CoreText? Нужны отдельные insert'ы и reload'ы. И в UITableView там начинается самое интересное. Поэтому (и не только поэтому) я бы посоветовал сразу делать UI на основе UICollectionView.
UI всегда состоит из мелочей, которые особенно важны пользователям и именно они занимают львиную часть работы.
Уважаемый prizzrak,
1. В статье я написал, что можно использовать самописный сервер, но это может занять больше 24х часов.
2. Не вижу ничего плохого в том, чтобы использовать готовое решение, в котором есть и кроссплатформенность, и удобный API, и пуш-нотификации, и текстовые, видео и аудио сообщения. Более того, там есть аудио и видео звонки. Сколько времени вы потратите на то, чтобы поднять такой сервер? Полагаю, больше 24х часов.
3. Тянущиеся баблы будут во второй части — там сложный UI.
4. «Сложные случаи одновременной отправки-прихода-переотправки-удаления» правильно обрабатываются этим фреймворком из коробки. Еще один плюс использования готового решения.
5. «А когда дойдет до того, что нужно будет добавить еще один тип сообщений?» — увы, этот туториал только про текстовые, аудио, видео сообщения, передачу файлов и аудио и видео звонки, а так же про профили пользователей. К сожалению, я решил этим ограничиться.
6. Да, в этом примере делается reloadData. В следующей части я и покажу, как делать insert'ы. Не вижу смысла использовать здесь UICollectionView. Это мое личное мнение, вы можете написать статью, используя UICollectionView, вам никто не мешает.
7. Да, UI состоит из мелочей, которые я и затрону во второй части. «Делаем красивый UI» в описании второй части, как бы, намекает.
В любом случае, спасибо за feedback. Надеюсь, я ответил на ваши насущные вопросы. Если еще что-то не ясно — не стесняйтесь спрашивать.
1. В статье я написал, что можно использовать самописный сервер, но это может занять больше 24х часов.
2. Не вижу ничего плохого в том, чтобы использовать готовое решение, в котором есть и кроссплатформенность, и удобный API, и пуш-нотификации, и текстовые, видео и аудио сообщения. Более того, там есть аудио и видео звонки. Сколько времени вы потратите на то, чтобы поднять такой сервер? Полагаю, больше 24х часов.
3. Тянущиеся баблы будут во второй части — там сложный UI.
4. «Сложные случаи одновременной отправки-прихода-переотправки-удаления» правильно обрабатываются этим фреймворком из коробки. Еще один плюс использования готового решения.
5. «А когда дойдет до того, что нужно будет добавить еще один тип сообщений?» — увы, этот туториал только про текстовые, аудио, видео сообщения, передачу файлов и аудио и видео звонки, а так же про профили пользователей. К сожалению, я решил этим ограничиться.
6. Да, в этом примере делается reloadData. В следующей части я и покажу, как делать insert'ы. Не вижу смысла использовать здесь UICollectionView. Это мое личное мнение, вы можете написать статью, используя UICollectionView, вам никто не мешает.
7. Да, UI состоит из мелочей, которые я и затрону во второй части. «Делаем красивый UI» в описании второй части, как бы, намекает.
В любом случае, спасибо за feedback. Надеюсь, я ответил на ваши насущные вопросы. Если еще что-то не ясно — не стесняйтесь спрашивать.
Ну так и назвали бы честно статью — «Интеграция с C2Call». О чем сейчас туториал — непонятно. Использование UITableView на базовом уровне? Свежо.
>> Не вижу смысла использовать здесь UICollectionView.
Надеюсь, что при выборе использования одной сторонней библиотеки для всего вы куда более серезьно рассмотрели все проблемы, чем когда решили использовать UITableView.
>> Не вижу смысла использовать здесь UICollectionView.
Надеюсь, что при выборе использования одной сторонней библиотеки для всего вы куда более серезьно рассмотрели все проблемы, чем когда решили использовать UITableView.
Эта серия туториалов о том, как с нуля поднять свой мессенджер. Может быть полезной для новичков. Прошу прощения за то, что первая часть получилось немного суховатой для вас. Полагаю, то, что может быть интересно вам, просто сюда не влезло и будет во второй части.
Статья названа честно. Это чат-мессенджер по типу WhatsApp за сутки.
Расскажите мне, чем плох UITableView для решения этой задачи, пожалуйста. Вполне возможно, что это я дурак и делаю все неправильно.
Статья названа честно. Это чат-мессенджер по типу WhatsApp за сутки.
Расскажите мне, чем плох UITableView для решения этой задачи, пожалуйста. Вполне возможно, что это я дурак и делаю все неправильно.
Да это какой-то антитуториал :)
Еще раз посмотрел предложенный код — так там еще и fetchChatHistory вытягивает всю О_о историю чата. Нет ни слова про частичный фетч, ни как будет определяться, что изменилось в FRC и как делать diff для обновления UI…
Не понятно на что там потрачено 24 часа. На написание статьи на хабре что ли.
Еще раз посмотрел предложенный код — так там еще и fetchChatHistory вытягивает всю О_о историю чата. Нет ни слова про частичный фетч, ни как будет определяться, что изменилось в FRC и как делать diff для обновления UI…
Не понятно на что там потрачено 24 часа. На написание статьи на хабре что ли.
У меня создается стойкое ощущение, что вы просто хотите к чему-то придраться.
Да, местами код не идеален. Про частичный фетч хотел рассказать во второй статье.
Вы правда хотели, чтобы я все это уместил в одну статью? Не забывайте, что это только первая часть.
Да, местами код не идеален. Про частичный фетч хотел рассказать во второй статье.
Вы правда хотели, чтобы я все это уместил в одну статью? Не забывайте, что это только первая часть.
Я думаю, товарищ prizzrak, как разработчик Viber, точно знает, что невозможно написать мессенджер за 24 часа ;)
Мне понравился ваш туториал, поэтому, пожалуйста, продолжайте несмотря на всю критику. Уже несколько раз пытался начинать писать приложение на iOS, но обычно сталкивался с отсутствием туториалов, описывающих более-менее приближенные к реальности концепты. После прочтения вашего поста занялся снова и с нетерпением жду вторую часть! Спасибо. ;)
Да, разверните мысль про UICollectionView.
Надо иметь ввиду, здесь я веду речь исключительно в разрезе использования UITableView/UICollectionView в качестве контроллера для UI элементов Conversation.
С UITableView есть одна очень большая проблема. Она связана с тем, что контроллер должен обновляться. Часто. Каждая отправка/прием/обновление статуса(sending/delivered/seen/unsent) сообщения генерируют обновление для UI. Перезагружать данные в таблице целиком (как в примере) нельзя, это чревато просто гигантским оверхедом. Нужно перезагружать/вставлять/удалять ячейки по-отдельности. И, как со мной любезно согласился backmeupplz, ввиду того, что UI состоит из мелочей — все эти операции должны быть анимированны. Анимации могут быть добавлены группами, сразу к нескольким ячейкам. И из-за того, что такие операции вызываются очень часто, предыдущие анимации не успевают закончиться, а когда для одной и той же ячейки применяется несколько анимаций — UITableView просто падает. Это все — главный поток, городить гуарды и блокировать поток нельзя. Если делать очередь анимаций — это дает весьма заметный лаг на действия пользователя: он вроде написал сообщения, а оно не может появиться, пока не отработают предыдущие анимации. Не говоря уж о принципиальной большой сложности реалицзации этой очереди. В UICollectionView есть batchUpdate.
Далее. UITableView — это функционально UICollectionView с вертикальным лэйаутом, который никак нельзя изменить. Например, есть простая задача. Баббл с исходящим текстом прижимается к правой стороне. Баббл с входящим — к левой. Ну, как в Wath’s app. Нужно сделать так, чтобы верхняя граница левого баббла была по середине высоты правого баббла, чтобы бабблы располагались компактнее. Каждый баббл — ячейка. Как вы будете решать эту задачу на UITableView? В UICollectionView пишется кастомный лайаут и все.
Далее. На экране могут быть разные дополнительные динамические и статические элементы, кроме текстовых бабблов. Это разные разрывные линии, isTyping, разлиные системные сообщения. ЧТо-то из этого можно сделать отедльными ячейками. Но когда вы начнете делать ячейку “user is typing”, которая должна постоянно появляться и пропадать не вызывая движения всей таблицы, которая была сделана на UITableView… UICollectionView вместе с supplementary view передают горячий привет.
Далее. UIDynamicKit. Больше можно ничего не писать.
Конечно, и у UICollectionView есть свои подводные камни. Я не помню у эппла ни одного компонента без магии. Но только того, что я написал, хватило нам для того, чтобы мы дропнули iOS5 и переписали код на UICollectionView.
С UITableView есть одна очень большая проблема. Она связана с тем, что контроллер должен обновляться. Часто. Каждая отправка/прием/обновление статуса(sending/delivered/seen/unsent) сообщения генерируют обновление для UI. Перезагружать данные в таблице целиком (как в примере) нельзя, это чревато просто гигантским оверхедом. Нужно перезагружать/вставлять/удалять ячейки по-отдельности. И, как со мной любезно согласился backmeupplz, ввиду того, что UI состоит из мелочей — все эти операции должны быть анимированны. Анимации могут быть добавлены группами, сразу к нескольким ячейкам. И из-за того, что такие операции вызываются очень часто, предыдущие анимации не успевают закончиться, а когда для одной и той же ячейки применяется несколько анимаций — UITableView просто падает. Это все — главный поток, городить гуарды и блокировать поток нельзя. Если делать очередь анимаций — это дает весьма заметный лаг на действия пользователя: он вроде написал сообщения, а оно не может появиться, пока не отработают предыдущие анимации. Не говоря уж о принципиальной большой сложности реалицзации этой очереди. В UICollectionView есть batchUpdate.
Далее. UITableView — это функционально UICollectionView с вертикальным лэйаутом, который никак нельзя изменить. Например, есть простая задача. Баббл с исходящим текстом прижимается к правой стороне. Баббл с входящим — к левой. Ну, как в Wath’s app. Нужно сделать так, чтобы верхняя граница левого баббла была по середине высоты правого баббла, чтобы бабблы располагались компактнее. Каждый баббл — ячейка. Как вы будете решать эту задачу на UITableView? В UICollectionView пишется кастомный лайаут и все.
Далее. На экране могут быть разные дополнительные динамические и статические элементы, кроме текстовых бабблов. Это разные разрывные линии, isTyping, разлиные системные сообщения. ЧТо-то из этого можно сделать отедльными ячейками. Но когда вы начнете делать ячейку “user is typing”, которая должна постоянно появляться и пропадать не вызывая движения всей таблицы, которая была сделана на UITableView… UICollectionView вместе с supplementary view передают горячий привет.
Далее. UIDynamicKit. Больше можно ничего не писать.
Конечно, и у UICollectionView есть свои подводные камни. Я не помню у эппла ни одного компонента без магии. Но только того, что я написал, хватило нам для того, чтобы мы дропнули iOS5 и переписали код на UICollectionView.
Теперь понятно. Просто вы так много нюансов оставили за скобками утверждения в начале, что появился такой вопрос у меня.
1. Не знаю, каким образом вы писали код для UITableView или насколько быстро отправляли\принимали сообщения, но insert вполне достаточно, чтобы вставлять ячейки со скоростью 3-4 в секунду, да при том анимировать все это действо. UITableView мы использовали в нескольких соц. сетях, которые разработали — везде все красиво и не подтормаживает.
2. Решение с тем, чтобы один бабл притянуть влево, а другой вправо — это простое создание двух прототипов ячеек. И не надо мне говорить, что это неправильное решение. Примите тот факт, что есть несколько правильных решений, которые могут отличаться от вашего.
3. Чтобы баблы распологались компактнее — тут да, удобнее использовать UICollectionView. Но у нас нет такой задачи в этом туториале.
4. «User is typing» свободно делается еще одним прототипом ячейки. Про правильные решения посмотрите, пожалуйста, пункт 2.
5. У нас нет задачи использовать здесь UIDynamicKit. Если бы была, то да — удобнее использовать UICollectionView.
6. Я только что привел 5 причин, почему дропать UITableView в данной ситуации не обязательно.
Выше уже писал, но не кажется ли вам, что все проблемы притянуты за уши? UITableView вполне себе справляется со всеми поставленными задачами в рамках данного руководства. А про UICollectionView вообще можно написать отдельную статью.
2. Решение с тем, чтобы один бабл притянуть влево, а другой вправо — это простое создание двух прототипов ячеек. И не надо мне говорить, что это неправильное решение. Примите тот факт, что есть несколько правильных решений, которые могут отличаться от вашего.
3. Чтобы баблы распологались компактнее — тут да, удобнее использовать UICollectionView. Но у нас нет такой задачи в этом туториале.
4. «User is typing» свободно делается еще одним прототипом ячейки. Про правильные решения посмотрите, пожалуйста, пункт 2.
5. У нас нет задачи использовать здесь UIDynamicKit. Если бы была, то да — удобнее использовать UICollectionView.
6. Я только что привел 5 причин, почему дропать UITableView в данной ситуации не обязательно.
Выше уже писал, но не кажется ли вам, что все проблемы притянуты за уши? UITableView вполне себе справляется со всеми поставленными задачами в рамках данного руководства. А про UICollectionView вообще можно написать отдельную статью.
Вы привели один аргумент «мне это не встречалось» и несколько «сегодня мне это не нужно». Если с первым еще как-то можно согласится, то второе — это конец. Ваши решения немасштабируемы. Нужно будет добавить — и все нужно будет выкинуть и написать снова. И если раньше разработчики были ограничены числом поддерживаемых осей или числом доступных контролов, то сейчас это больше похоже на «склепаем на коленке кое-как».
Вы где-то выше спросили к чему у меня претензии. У меня претензии к качеству, к поверхностности и эпическому замаху на what's app, хотя на деле показан пшик.
За сим извольте откланяться.
Вы где-то выше спросили к чему у меня претензии. У меня претензии к качеству, к поверхностности и эпическому замаху на what's app, хотя на деле показан пшик.
За сим извольте откланяться.
Уважаемый prizzrak,
Это не продукт, который нужно масштабировать, а просто туториал. Proof of concept, если желаете — без каких либо претензий на эпичность и значимость. Просто статья, которая может показать начинающим, как создаются приложения от 0 и до определенной готовности.
Это не продукт, который нужно масштабировать, а просто туториал. Proof of concept, если желаете — без каких либо претензий на эпичность и значимость. Просто статья, которая может показать начинающим, как создаются приложения от 0 и до определенной готовности.
Мессенджер за сутки? Вы смеётесь! Cинхронизация списка контактов, подтверждение доставки сообщений, смайлы, ошибки базы данных, многопоточная рассинхронизация. Если бы всё было так просто, скайп бы не глючил :)
Я уже ожидал увидеть статью о написании на swift :))
> C2Call
Чего только не выдумают, лишь бы Jabber не юзать.
Чего только не выдумают, лишь бы Jabber не юзать.
А есть какие то анонимные мессенджеры с хорошим шифрованием и открытым кодом?
Если интересно, могу рассказать (возможно отдельной статьей, либо просто дав доступ к исходникам) о том, как сделать красивый UI для bubbles для чата. Как раз недавно задачу такую реализовывал.
Хотелось бы добавить, что двухсимвольный префикс классов — прерогатива Apple.
Простым смертным рекомендуется использовать трёхсимвольные префиксы.
Хотя с релизом Свифта это правило потеряет актуальность.
Простым смертным рекомендуется использовать трёхсимвольные префиксы.
Хотя с релизом Свифта это правило потеряет актуальность.
Правда? Никогда не знал об этой детали. И десятки других разработчиков, судя по всему, тоже: cocoadev.com/ChooseYourOwnPrefix
Не все читают документацию, что поделать.
…
Two-letter prefixes like these are reserved by Apple for use in framework classes.
…
Your own classes should use three letter prefixes.
…
Но у меня почти все проекты тоже с двумя :)
…
Two-letter prefixes like these are reserved by Apple for use in framework classes.
…
Your own classes should use three letter prefixes.
…
Но у меня почти все проекты тоже с двумя :)
Я смотрю, тут некоторые слишком болезненно восприняли название статьи. Ну нельзя же так серьезно (уверен, автор назвал так статью не без доли иронии)! Никто не умаляет достоинств разработчиков мессенджеров, всем понятно, что нормальный мессенджер за сутки не делается.
Цель статьи — объяснить новичкам некие базовые принципы работы на примере разработки конкретного… приложения (ну, или UI).
Что же в этом плохого? На похожих статьях училсяговнокодить на PHP.
Вот в комментах уже некоторые нюансы упомянули (частично фетчить историю и т. п.), но как-то агрессивно (и так полно агрессии в последнее время, куда же больше)
Тем, кто хочет разобраться и нужны реальные примеры — вполне полезная статья. В нете полно трэша, а тут более менее пристойное что-то.
Или я не прав?
Цель статьи — объяснить новичкам некие базовые принципы работы на примере разработки конкретного… приложения (ну, или UI).
Что же в этом плохого? На похожих статьях учился
Вот в комментах уже некоторые нюансы упомянули (частично фетчить историю и т. п.), но как-то агрессивно (и так полно агрессии в последнее время, куда же больше)
Тем, кто хочет разобраться и нужны реальные примеры — вполне полезная статья. В нете полно трэша, а тут более менее пристойное что-то.
Или я не прав?
А магазин стикеров будет?!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как собрать WhatsApp за сутки. Часть 1