Fastlane тоже занимаются поддержкой, https://github.com/CocoaPods/CocoaPods/issues/9148
Это хорошо для CI сборок своих фреймворков.
А как обновлять их в проектах? Руками подключать новую версию? И хранить подключённые фреймворки в репозитории проекта или как-то удобнее?
1. В верхнем баре заголовок страницы должен быть слева: developer.android.com/design/patterns/actionbar.html
2. Кнопка назад в ActionBar — это кнопка Up, а не Back. Она ведет себя не правильно (дублирует кнопку back). developer.android.com/design/patterns/navigation.html
3. Использовиние bottombar — плохо: developer.android.com/design/patterns/pure-android.html
В данном случае гораздо удобнее перемещаться по табам в bottom bar, нежели использовать стандартный Action Bar от Android.
Потому что пользователь держа телефон одной рукой с легкостью может перемещаться по табам большим пальцем. (Можно посмотреть описание «Правила большого пальца» habrahabr.ru/post/150905/)
В случае с Action Bar, пользователю бы пришлось одной рукой держать телефон, а другой перемещаться по табам. В данном случае это не совсем удобно, поскольку предполагается частая навигация пользователем между табов.
Кроме того c технической стороны Action Bar использует Fragments, для отображения контента табов. Однако Fragments по-умолчанию не умеют хранить состояние.
Нами было реализовано сохранение состояния во вкладке. То есть если из вкладки «События» перейти на страницу детального просмотра события, а потом перейти на вкладку «Лента», и вернуться обратно, то Вы окажетесь на странице детального просмотра события, а не на списке с событиями.
В случае со стандартным использованием связки ActionBar + Fragments, сохранение состояния не происходило бы.
4. В списках Android нету стрелки справа: developer.android.com/design/patterns/pure-android.html
В данном случае в стрелке «Назад» нет необходимости, поскольку списки с данными находятся непосредственно на главных страницах вкладок, поэтому пользователь может легко перейти на них используя bottom bar.
К тому же посмотрите, например, стандартное Android приложение «Play Пресса». Там в ActionBar также нет кнопки назад на списках с рубриками. И более того история навигации по табам никак не сохраняется. По кнопке back вы просто сразу выходите из приложения.
КП — один из самых популярных ИД в России. Их новостные проекты и газеты входят в ТОПы в России и Европе. Понятно, что размещать свои новости можно где угодно, но если хочется донести информацию до большого числа читателей, то Спецкор дает один из самых простых и удобных способов это сделать.
Для приложений с кастомным дизайном небольшое отхождение от стандартного интерфейса вполне допускается. В данном случае приложение разрабатывалось в едином стиле для удобства использования.
Это появилось только в 7 iOS, тогда как многие приложения поддерживают и более старые версии ОС.
Меню такого стиля нескоро выйдет из моды, поскольку позволяет удобно переходить между разделами приложения, а для случаев пересечения с интерактивным переходом назад, обычно используется блокировка перехода в меню, когда активный экран — не основной (стек навигации не пуст).
Кстати, в случае, если на экране есть кнопка «назад», начиная с iOS 7, должен работать и интерактивный переход назад жестом.
Еще, некоторые приложения стали делать такое меню в правой части экрана :)
Например, в iOS есть понятие MainThread, где происходит обработка событий от пользователя. Функция-обработчик события всегда вызывается в MainThread, и элемент, с которого получено событие, становится недоступным. Если в обработчике не написать переход в другой тред, то на время обработки интерфейс как бы подвисает, что правильно для коротких действий или например для открытия экрана. Если же требуется длительная обработка — загрузка данных и т.п., то кнопка блокируется вручную, и делается вызов обработки в другом треде.
Если, например, рассмотреть нативные таблицы, то часто реализуют открытие экрана с подробной информацией по клику на элемент списка. По умолчанию, т.е. без лишнего кода, после клика на один элемент списка, пользователь не сможет выбрать другой, пока событие не обработано, в том числе пока не открыт экран с подробной информацией. Опять же, если для того, чтобы показать более подробную информацию, нужно что-то загрузить или посчитать, то можно вынести обработку в другой тред, но для пользователя понятнее, если откроется новый экран и на нем будет показан индикатор загрузки с поясняющим сообщением, и там уже запустится загрузка в отдельном треде. Элемент, с которого поступило событие, не может быть нажат второй раз во время обработки первого события.
На титаниуме же, вы можете дважды нажать на кнопку и открыть два экрана. Стоит уточнить, что на тот момент, блокировка кнопки установкой enabled = false не работала, а на некоторых элементах интерфейса не работает до сих пор jira.appcelerator.org/browse/TIMOB-12668
Об этом и речь: можно написать работающее приложение, если исправить проблемы, которые привносит кроссплатформенная разработка. У большинства из них есть решения, да, но какой смысл решать проблемы, когда можно провести время за более приятным занятием, например, реализуя удобную фичу для пользователей.
Решение добавить еще один уровень обработки событий только сильнее отдаляет пользователя от желаемого действия. На флагманах, конечно, это будет не очень заметно, а на остальных устройствах — пользователи останутся недовольны.
Мы с него ушли довольно давно. Тогда на проекте мы собрали много глюков интерфейса, с большинством из которых сумели справиться. Проблемы были в основном от сырых библиотек, возможно, с ними сейчас получше. Главная причина, по которой ушли — это полностью нерабочее приложение на больших объемах данных. Т.е. пока тестировали — все было хорошо, как только попробовали загрузить реальные данные — приложение зависло.
Недавно видели чужое приложение на Phonegap, которое нам предложили доделать. Первая проблема, которая бросилась в глаза сродни проблемы дабл-кликов: по нажатию на кнопку в приложении, открывается новый экран и на нем срабатыает то же самое событие, если там тоже кнопка на этом месте — то вызывается обработка нажатия на нее, и так далее, как будто клик проходит сквозь экраны.
Главная проблема Phonegap, на мой взгляд, это снижение скорости реакции по сравнению с нативными приложениями. Если в нативном приложении вы хотите запустить камеру, или выполнить любую другую стандартную функцию операционной системы — вы просто делаете соответствующий вызов. И функция исполняется настолько быстро, насколько это позволяет устройство и операционная система. В phonegap вызов должен быть пропущен из веб-котента в Cordova, а оттуда попадет в систему, где и будет обработан нативными средствами.
Вполне допускаю, что подобные технологии могут заинтересовать тех, кто делает свое первое мобильное приложение, и еще не знает к чему стремиться, и как круто можно сделать натив. Может заинтересовать веб-разработчиков, которые хотят сделать какое-то несложное приложение. Но проблемы останутся те же, что и на многих кросплатформенных приложениях: вы связаны проблемами самой системы, вы все время ждете обновлений библиотеки, когда новая платформа уже на рынке, и ваши пользователи все время ждут. И каждый раз, когда у вашего приложения проблемы — будь то зависания, глюки, неспособность работать с большими данными или устаревший дизайн — вы теряете пользователей, имидж и, в конечном счете, деньги.
Статья вовсе не о том, как проектировать вьюконтроллеры, а о том, как не поиметь проблем от неосторожного использования KVO.
Тем не менее, я с вами не соглашусь, и подробно объясню, почему.
По ссылке написано только что «view objects are typically decoupled from model objects». «Обычно отделены» не значит, что их всегда необходимо отделять (иначе что?).
Если не ограничиваться схоластикой, а посмотреть на практические следствия использования конкретных наследников UITableViewCell не только как наследников UIView, но и как контроллеров для сопоставляемых им модельных объектов, то имеем вот что:
Конкретные классы ячеек (так же, как и вьюконтроллеров) зачастую проектируются под конкретные модельные классы: если у вас есть ячейка с лэйблами, однозначно сопоставленными атрибутам конкретного модельного класса, то говорить о переиспользуемости или независимости такой «вьюхи» от вашей модели (а это главная причина отделения view от model) не приходится.
Даже если вы можете представить себе сценарий, где какая-нибудь ячейка с полями «Фамилия», «Имя», «Отчество» будет переиспользована для представления разных модельных объектов в разных приложениях или частях одного приложения, то это можно успешно реализовать, объединив модельные классы общим протоколом (это можно сделать и в категориях), и имея в ячейке ссылку на модельные объекты, типизированную только протоколом. Если же вы не планируете ее так переиспользовать, то зачем усложнять себе жизнь?
Название класса ETRDocumentCell как бы намекает на класс ETRDocument. Если бы ячейка не имела к нему отношения, ее следовало бы назвать ETRTableViewCellWithALabelAndAStarShapedButton, что бы в точности отражало ее суть. Без шуток.
UIViewController как таковой не имеет отношения к модели. Он, конечно, называется контроллером, но в своей базовой реализации он контролирует вовсе не модель, а свою вьюху и другие вьюконтроллеры. В конкретных реализациях он имеет то же право работать с моделью, что и ячейки, или любые другие пользовательские реализации классов, имеющих непосредственное отношение к слою View. И критерий здесь не только в наличии класса UIView среди предков.
Нетривиальные операции с моделью должны делаться не во вьюконтроллерах, а в классах-контроллерах, не имеющих к View никакого отношения вообще. Только так они будут переиспользуемы и независимы. Чтение значений атрибутов в этом смысле операция тривиальная.
Только ячейка должна знать, какие у нее есть сабвьюхи, и как на них ложатся атрибуты модельного объекта. Имея эту логику снаружи ячейки, мы нарушаем ее целостность и инкапсуляцию, разносим знание о ее внутреннем устройстве по большему числу мест в проекте, и вообще творим «Зло».
Вынося из UITableViewController в ячейку логику по отображению модельного объекта, можно полностью избавить вьюконтроллер от знаний об отдельных объектах. То есть вьюконтроллер работает со списком, а ячейка — с его элементами. Чем не single responsibility principle?
Имея непосредственную привязку ячеек к модельным объектам, гораздо проще реализовывать любую асинхронную логику. Например, показывать прогресс бар в ячейке, соответствующей какой-нибудь загрузке. Если эта логика будет во вьюконтроллере, она будет содержать вложеннные условия и циклы с indexPath'ами и прочие радости. Да и тот же KVO по сути является такой асинхронной логикой. Можете для сравнения реализовать весь пример «по-вашему», и посмотреть, что будет аккуратнее. Вам придется либо всегда наблюдать за всеми документами, либо каким-то неочевидным образом отслеживать, для каких из них существуют ячейки. Среднестатистический программист, начав по-вашему, скорее всего сделает одну нотификацию, по которой будет делать [self.tableView reloadData], и прощай выделение ячеек, анимации, плавный скролл и так далее.
Даже reloadRowsAtIndexPaths потенциально может иметь нежелательные последствия. Да и нужно-то всего лишь поменять selected у UIButton.
Имея непосредственную привязку ячеек к модельным объектам, гораздо проще обрабатывать user interaction. Нажатие кнопок в ячейке может обрабатываться самой ячейкой без усложения вьюконтроллера. Да и в prepareForSegue:sender: не нужно никаких получений indexPath по ячейке с доставанием модельного объекта по нему.
Я уже давно использую этот паттерн во всех ячейках, и никогда не имел от этого никаких проблем, а имел один только вышеперечисленный профит, включая вьюконтроллеры не больше 250 строк. Поэтому считаю, что имею право его всем рекомендовать.
Если не хочется писать пароль в файл, а это проще для начинающих, можно внести в файл sudoers строчку
username ALL=NOPASSWD: /usr/bin/xcode-select
В нашем случае:
jenkins ALL=NOPASSWD: /usr/bin/xcode-select
но если доступ к jenkins ограничен, то можно использовать и файл, увидеть его содержимое можно только если есть доступ к Jenkins или собственно к машине с Xcode.
А мы читали вашу статью :)
У нас похожий способ генерации страничек, выращенный из iOSBetaBuilder, но мы в статье делали упор на два Xcode — в преддверии так сказать :) ну и в целом инструкция — вещь полезная.
Еще недавно находили идею — сделать мобильное приложение для получения Push-уведомений, и с Jenkins слать ссылки на него. Мне кажется, пуши лучше подходят для тестировщиков, письма — для менеджеров и заказчиков.
Можно
Можно в общем шаблоне прописать ссылку с параметром, например mydomain.ru/${JOB_NAME}/index.html
А можно для каждой отдельной задачи в Jenkins под кнопкой Advanced для каждого триггера поменять шаблон — например, на успешную сборку слать ссылку, а на сломанную — нет.
выкатили готовую коробку вида «скачай, распакуй, пропиши группы в контакте и в фейсбуке — и на всех сотовых компании новейший фидер»
, мы бы сделали еще один кусок опенсорса и тот, кто взялся бы прописывать группы в контакте и в фейсбуке нашел бы что не все сделано так, как он хочет, и все равно говорил бы, что усе плохо.
Хммм, а почему вся эта красота лежит на хабре, а не во внутреннем уютном бложеге?
А кто сказал, что она не лежит в уютном бложеке? =)
Вообще, она лежт на хабре, потому что нам интеерсно мнение потенциальных пользователей о таком приложении: что было бы интересно добавить, что подразукрасить, какие возможности подключить.
Ну и вообще говоря, есть очучение, что система эта довольно слабо кастомизируема. Для одной фирмы можно классно всё на шурупы прикрутить, а дальше будет печальнее.
А дальше будут шурупы для другой фирмы.
Это какой-то холиварный поинт кастомайзить на уровне пользователя или на уровне разработки: мы — за разработку, ты — вроде за опен-линух-путь. Мы предполагаем, что большинство наших пользователей просто возьмут и будут наслаждаться удобством, а не «о, какой интересный конструктор», поэтому мы не планируем давать шурупы конечным пользователям.
Ну нет… Суть как раз в том, что это линия наших событий. Там ведь не только записи с социальных сетей.
Насчет стилистики и дизайна замечание спорное, мы цветами выделяем разные разделы приложения, а основной стиль оформления везде одиаковый. Я думаю, тут каждая компания может выбрать что-то для себя.
Замечание под номером два — меня аж вдохновило :) Обязательно так и сделаем
Третье — очень спорное. С одной стороны экономить место на экранах мобильников — это хорошо и правильно, но и сильно плотно размещатть информацию — неудобно для восприятия. Возможно, что-то мы еще соптимизируем с местом, но пока кажется, что текущее решение — наиболее подходящее для выражения идеи Timeline и легкости интерфейса.
Фильтр событий? Например я в какой-то команде и мне плевать что там происходит у заокеанских друзей или в головном офисе и хочу читать только фид относящийся непосредственно к моему подразделению/офису в моем городе/etc. Есть такая возможность?
Да, об этой возможности мы подумали. Мне кажется, наиболее удобный вариант — это пользовательские настройки, которые позволяют выбирать, какие именно типы событий пользователь хочет видеть в таймлайне. Но к этому добавится еще и поиск по типам и, наверное, по времени, и просто по тексту.
Оповещения о срочных делах/изменениях?
Для подобного функционала необходимо добавить поддержку событий из баг-трекера или другой системы ведения проекта. О подобной возможности мыслей не было. Мы больше работали в направлении объединяющей социальной инфрастуктуры, нежели инструмента для работы.
Опять же, те сообщения, которые относятся к конкретному человеку/подразделению в такой фид-агрегатор не попадут (или я не правильно понял мысль?) и все-равно надо либо использовать другие методы взаимодействия, либо создавать аккаунты для этого приложения на каждого пользователя чтобы через него как-то взаимодействовать с конкретными людьми.
В приложении есть система авторизации, но она пока доступна только сотрудникам компании. Можно добавить любой тип событий, будь то форум, или private messages или чаты, можно создать «болталки» на каждую команду или отдел. Вопрос в том, что будет более полезно? У нас возникла идея — мы сделали базовое приложение, а теперь нам нужны отзывы: с такой системой, которая умеет показывать любые события, оповещает пользователя и дает доступ ко внутренним ресурсам компании — можно сделать любое приложение от иструмента командной работы до корпоративной социальной сети, и вариант про саппорт тоже очень органично ложится на эту основу.
Как вы собираетесь балансировать между сложной/дорогой разработкой(богатый функционал и прочее) и очередной свистоперделкой (если человек пользуется ФБ или ВК и у него есть для этого приложение, зачем ему еще одно, которое дублирует функции первого?)
Ну, не делать то, что уже есть :) Например, у нас есть список контактов, но все виды коммуникаций: емейл, смс, скайп, звонок и т.п. используют стандартные приложения. Наше приложение не собирается стать мульти-клиентом социальной сети, мы показываем события компании из самых разных источников.
Fastlane тоже занимаются поддержкой, https://github.com/CocoaPods/CocoaPods/issues/9148
Это хорошо для CI сборок своих фреймворков.
А как обновлять их в проектах? Руками подключать новую версию? И хранить подключённые фреймворки в репозитории проекта или как-то удобнее?
1.Хофстедтер
2.Купер
3.Воловиц
4.Кутраппали
2. Кнопка назад в ActionBar — это кнопка Up, а не Back. Она ведет себя не правильно (дублирует кнопку back). developer.android.com/design/patterns/navigation.html
3. Использовиние bottombar — плохо: developer.android.com/design/patterns/pure-android.html
В данном случае гораздо удобнее перемещаться по табам в bottom bar, нежели использовать стандартный Action Bar от Android.
Потому что пользователь держа телефон одной рукой с легкостью может перемещаться по табам большим пальцем. (Можно посмотреть описание «Правила большого пальца» habrahabr.ru/post/150905/)
В случае с Action Bar, пользователю бы пришлось одной рукой держать телефон, а другой перемещаться по табам. В данном случае это не совсем удобно, поскольку предполагается частая навигация пользователем между табов.
Кроме того c технической стороны Action Bar использует Fragments, для отображения контента табов. Однако Fragments по-умолчанию не умеют хранить состояние.
Нами было реализовано сохранение состояния во вкладке. То есть если из вкладки «События» перейти на страницу детального просмотра события, а потом перейти на вкладку «Лента», и вернуться обратно, то Вы окажетесь на странице детального просмотра события, а не на списке с событиями.
В случае со стандартным использованием связки ActionBar + Fragments, сохранение состояния не происходило бы.
4. В списках Android нету стрелки справа: developer.android.com/design/patterns/pure-android.html
В данном случае в стрелке «Назад» нет необходимости, поскольку списки с данными находятся непосредственно на главных страницах вкладок, поэтому пользователь может легко перейти на них используя bottom bar.
К тому же посмотрите, например, стандартное Android приложение «Play Пресса». Там в ActionBar также нет кнопки назад на списках с рубриками. И более того история навигации по табам никак не сохраняется. По кнопке back вы просто сразу выходите из приложения.
Меню такого стиля нескоро выйдет из моды, поскольку позволяет удобно переходить между разделами приложения, а для случаев пересечения с интерактивным переходом назад, обычно используется блокировка перехода в меню, когда активный экран — не основной (стек навигации не пуст).
Кстати, в случае, если на экране есть кнопка «назад», начиная с iOS 7, должен работать и интерактивный переход назад жестом.
Еще, некоторые приложения стали делать такое меню в правой части экрана :)
Если, например, рассмотреть нативные таблицы, то часто реализуют открытие экрана с подробной информацией по клику на элемент списка. По умолчанию, т.е. без лишнего кода, после клика на один элемент списка, пользователь не сможет выбрать другой, пока событие не обработано, в том числе пока не открыт экран с подробной информацией. Опять же, если для того, чтобы показать более подробную информацию, нужно что-то загрузить или посчитать, то можно вынести обработку в другой тред, но для пользователя понятнее, если откроется новый экран и на нем будет показан индикатор загрузки с поясняющим сообщением, и там уже запустится загрузка в отдельном треде. Элемент, с которого поступило событие, не может быть нажат второй раз во время обработки первого события.
На титаниуме же, вы можете дважды нажать на кнопку и открыть два экрана. Стоит уточнить, что на тот момент, блокировка кнопки установкой enabled = false не работала, а на некоторых элементах интерфейса не работает до сих пор jira.appcelerator.org/browse/TIMOB-12668
Решение добавить еще один уровень обработки событий только сильнее отдаляет пользователя от желаемого действия. На флагманах, конечно, это будет не очень заметно, а на остальных устройствах — пользователи останутся недовольны.
Недавно видели чужое приложение на Phonegap, которое нам предложили доделать. Первая проблема, которая бросилась в глаза сродни проблемы дабл-кликов: по нажатию на кнопку в приложении, открывается новый экран и на нем срабатыает то же самое событие, если там тоже кнопка на этом месте — то вызывается обработка нажатия на нее, и так далее, как будто клик проходит сквозь экраны.
Главная проблема Phonegap, на мой взгляд, это снижение скорости реакции по сравнению с нативными приложениями. Если в нативном приложении вы хотите запустить камеру, или выполнить любую другую стандартную функцию операционной системы — вы просто делаете соответствующий вызов. И функция исполняется настолько быстро, насколько это позволяет устройство и операционная система. В phonegap вызов должен быть пропущен из веб-котента в Cordova, а оттуда попадет в систему, где и будет обработан нативными средствами.
Вполне допускаю, что подобные технологии могут заинтересовать тех, кто делает свое первое мобильное приложение, и еще не знает к чему стремиться, и как круто можно сделать натив. Может заинтересовать веб-разработчиков, которые хотят сделать какое-то несложное приложение. Но проблемы останутся те же, что и на многих кросплатформенных приложениях: вы связаны проблемами самой системы, вы все время ждете обновлений библиотеки, когда новая платформа уже на рынке, и ваши пользователи все время ждут. И каждый раз, когда у вашего приложения проблемы — будь то зависания, глюки, неспособность работать с большими данными или устаревший дизайн — вы теряете пользователей, имидж и, в конечном счете, деньги.
Статья вовсе не о том, как проектировать вьюконтроллеры, а о том, как не поиметь проблем от неосторожного использования KVO.
Тем не менее, я с вами не соглашусь, и подробно объясню, почему.
По ссылке написано только что «view objects are typically decoupled from model objects». «Обычно отделены» не значит, что их всегда необходимо отделять (иначе что?).
Если не ограничиваться схоластикой, а посмотреть на практические следствия использования конкретных наследников UITableViewCell не только как наследников UIView, но и как контроллеров для сопоставляемых им модельных объектов, то имеем вот что:
username ALL=NOPASSWD: /usr/bin/xcode-select
В нашем случае:
jenkins ALL=NOPASSWD: /usr/bin/xcode-select
но если доступ к jenkins ограничен, то можно использовать и файл, увидеть его содержимое можно только если есть доступ к Jenkins или собственно к машине с Xcode.
У нас похожий способ генерации страничек, выращенный из iOSBetaBuilder, но мы в статье делали упор на два Xcode — в преддверии так сказать :) ну и в целом инструкция — вещь полезная.
Еще недавно находили идею — сделать мобильное приложение для получения Push-уведомений, и с Jenkins слать ссылки на него. Мне кажется, пуши лучше подходят для тестировщиков, письма — для менеджеров и заказчиков.
Но это тема для отдельной статьи.
Можно в общем шаблоне прописать ссылку с параметром, например mydomain.ru/${JOB_NAME}/index.html
А можно для каждой отдельной задачи в Jenkins под кнопкой Advanced для каждого триггера поменять шаблон — например, на успешную сборку слать ссылку, а на сломанную — нет.
А кто сказал, что она не лежит в уютном бложеке? =)
Вообще, она лежт на хабре, потому что нам интеерсно мнение потенциальных пользователей о таком приложении: что было бы интересно добавить, что подразукрасить, какие возможности подключить.
А дальше будут шурупы для другой фирмы.
Это какой-то холиварный поинт кастомайзить на уровне пользователя или на уровне разработки: мы — за разработку, ты — вроде за опен-линух-путь. Мы предполагаем, что большинство наших пользователей просто возьмут и будут наслаждаться удобством, а не «о, какой интересный конструктор», поэтому мы не планируем давать шурупы конечным пользователям.
Насчет стилистики и дизайна замечание спорное, мы цветами выделяем разные разделы приложения, а основной стиль оформления везде одиаковый. Я думаю, тут каждая компания может выбрать что-то для себя.
Замечание под номером два — меня аж вдохновило :) Обязательно так и сделаем
Третье — очень спорное. С одной стороны экономить место на экранах мобильников — это хорошо и правильно, но и сильно плотно размещатть информацию — неудобно для восприятия. Возможно, что-то мы еще соптимизируем с местом, но пока кажется, что текущее решение — наиболее подходящее для выражения идеи Timeline и легкости интерфейса.
Да, об этой возможности мы подумали. Мне кажется, наиболее удобный вариант — это пользовательские настройки, которые позволяют выбирать, какие именно типы событий пользователь хочет видеть в таймлайне. Но к этому добавится еще и поиск по типам и, наверное, по времени, и просто по тексту.
Для подобного функционала необходимо добавить поддержку событий из баг-трекера или другой системы ведения проекта. О подобной возможности мыслей не было. Мы больше работали в направлении объединяющей социальной инфрастуктуры, нежели инструмента для работы.
В приложении есть система авторизации, но она пока доступна только сотрудникам компании. Можно добавить любой тип событий, будь то форум, или private messages или чаты, можно создать «болталки» на каждую команду или отдел. Вопрос в том, что будет более полезно? У нас возникла идея — мы сделали базовое приложение, а теперь нам нужны отзывы: с такой системой, которая умеет показывать любые события, оповещает пользователя и дает доступ ко внутренним ресурсам компании — можно сделать любое приложение от иструмента командной работы до корпоративной социальной сети, и вариант про саппорт тоже очень органично ложится на эту основу.
Ну, не делать то, что уже есть :) Например, у нас есть список контактов, но все виды коммуникаций: емейл, смс, скайп, звонок и т.п. используют стандартные приложения. Наше приложение не собирается стать мульти-клиентом социальной сети, мы показываем события компании из самых разных источников.