Sdk что это наушники

Что такое мобильный SDK?

SDK (Software development kit) — это комплект для разработки программного обеспечения, который помогает разработчикам создавать приложения для конкретных платформ. Это могут быть компьютеры, игровые приставки или мобильные устройства.

Если точнее, мобильные SDK дают разработчикам приложений все необходимое для того, чтобы легко создавать всевозможные высокопроизводительные приложения для смартфонов и планшетов, которые можно опубликовать на маркетплейсах Google Play и App Store.

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

SDK vs API

Сегодня индустрия укрепилась во мнении, что SDK — это библиотека, встроенная в приложение, а API — это облачные сервисы, которые работают совместно с SDK или приложением.

Вы создаете что-либо с помощью SDK. Вы используете или потребляете что-либо с помощью API. Вы используете SDK для доступа к функционалу библиотеки, а API для управления им.

Зачем вам нужен мобильный SDK

Качественный мобильный SDK даст вам доступ ко всем необходимым фичам, чтобы создать динамическое мобильное приложение.

Далеко не у каждого разработчика в арсенале есть всесторонние познания в программировании и обширные навыки разработки программного обеспечения. И даже те, кто всем этим обладает, предпочитают экономить значительное количество времени, используя инструменты программирования из мобильного SDK.

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

К тому же, мобильный SDK помогает вашему приложению стабильнее и лучше работать.

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

Разработчики могут создавать кастомизированные приложения и настраивать пользовательскую среду с помощью качественного мобильного SDK.

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

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

Неважно, состоит ваша целевая аудитория из наемных работников, клиентов или геймеров, вы можете быть уверены, что ваше приложение выиграет от от наличия надежного SDK-решения, которое будет удовлетворять потребности ваших пользователей.

Как сделать правильный выбор?

Интеграция мобильного SDK в ваше приложение может быть чрезвычайно полезной, но крайне важно выбрать подходящий вам SDK. Два основных аспекта, присущие хорошему мобильному SDK — правильное использование данных и безопасность.

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

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

Материал был создан на основе этих статей:

What’s a Mobile SDK?

Яна Никулина
Пишу о важном для клиентов Carrot quest.

Источник

Не все беспроводные наушники одинаково полезны или несколько слов о проблеме кодеков

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

Почему APTX?

Сегодня для большинства пользователей важнейшим из искусств наиболее предпочтительным кодеком синезубой передачи звука является APTX. Особенно хорошо, когда дополнительно применяется алгоритм, уменьшающий максимальное время задержки APTX Low Latency.

Такой вывод я делаю на том основании, что APTX кодирует звук с частотой дискретизации 44,1 кГц, разрядностью 16 бит и битрейтом до 352 кбит/с. А этого достаточно для такой верности воспроизведения, которую подавляющее большинство людей субъективно не отличит от CDDA. Также существенным фактором является то, что этот кодек сравнительно широко распространен в современных смартфонах, плеерах и беспроводных наушниках.

И тут внимательный и знающий тему читатель может мне заметить, что устройства с поддержкой SBC значительно более распространены, нежели APTX, и будет прав. Прав в том, что любой девайс, использующий старый добрый профиль A2DP (а это практически все), будет работать с SBC. Но, как говорится, есть нюанс.

Дело в том, что SBC был создан на основе кодека MPEG-1 Audio Layer II, более известный как mp2, аж 1993-го года выпуска. И, совершенно естественно, SBC унаследовал от этого алгоритма уйму недостатков, таких как шумы от ошибок квантования и прочих артефактов сжатия, хорошо заметных на слух.

Этот кодек способен обеспечить максимальный битрейт 345 кбит/с для стерео, согласно рекомендованным, и 512 кбит/с согласно максимальным параметрам энкодера. При субъективной оценке передачи звука с применением SBC-сжатия, качество SBC-звука многие оценивают как неудовлетворительное.

Для SBC характерны задержки в диапазоне от 100 до 250 миллисекунд, которых, например, не бывает при использовании APTX Low Latency.

Обилие устройств от Apple гарантировали популярность другому кодеку — AAC. Он обеспечивает битрейт 264 кбит/с с частотой дискретизации 44,1 кГц. Субъективные ощущения от качества звука, переданного при помощи AAC, пользователи описывают как нечто среднее между SBC и APTX или приравнивают к последнему. Количество устройств, работающих с этим кодеком, ограничено использованием яблочной техники.

О прочих кодеках (APTX, LDAC и др.), которые работают с хайрез форматами, можно также прочитать в уже упоминавшемся посте. Отмечу лишь, что устройства с их использованием сравнительно редки.

Совместимость или что не так с APTX?

Среди всего многообразия смартфонов, продающихся на территории нашей необъятной родины, мне не удалось насчитать и пары сотен моделей, поддерживающих APTX, причем в большинстве своём это отнюдь не дешевые устройства. Во многом это объясняется позицией компании Qualcomm Inc., которая зарабатывает на продаже лицензий APTX.

Интересно, что APTX порой даже не попадает в функционал популярных бестселлеров и некоторых флагманских устройств. Для некоторых из них, где кодек может поддерживаться на уровне чипсета (т.е. где стоят Snapdragon 835, 845, 821, 820, 810, 805, 801, 800, 650, 615, 410 и, возможно, какие-то другие), придумывают различные способы восстановить работоспособность кодека, путем “допрошивки” смартфона.

Как правило, допрошивки такого рода осуществляются через бекап. Родная версия, например, популярной прошивки MIUI, заменяется неизвестно каким андроидом, а также возникает гипотетический риск “окирпичивания”. Я молчу про то, что это слегка нарушает лицензионные права Qualcomm Inc. На всякий случай оставляю ссылку на гайд по такой прошивке, которая, возможно, не убьет ваш телефон (но это, естественно, совсем не точно).

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

Я настоятельно рекомендовал бы любые устройства, которые официально поддерживают кодек. Для чего публикую ссылку на их полный список. И это отнюдь не ради лицензионных прав разработчиков, но ради пользователей, которые рискуют многим, устанавливая левые прошивки. Более того, есть вероятность, что в современных устройствах с официальной поддержкой будет более совершенный и современный APTX HD, о котором мы подробно писали здесь.

Наушники

При выборе наушников с APTX (Low Latency, APTX HD) следует учитывать, что технология предполагает более активное энергопотребление, чем при использовании SBC. По этой причине стоит также трезво оценивать время автономной работы наушников, которое производители нередко указывают с учетом использования базового SBC-кодека. Реальное время работы с APTX обычно на 30 % меньше. В связи с этим имеет смысл приобретать наушники с большей емкостью аккумулятора.

Кроме того, многие отмечают, что использование этой технологии уменьшает радиус действия устройства до 10-15 метров при прямой видимости. Для некоторых это критично, особенно, если планируется достаточно далеко отходить от источника. Лучше проверить этот параметр перед покупкой или уточнить эти сведения у продавца-консультанта при покупке онлайн.

Личные пристрастия — не рекламы ради

Иногда в комментариях мне пишут о том, что после особенностей выбора, было бы неплохо поделиться личными предпочтениями и порекомендовать что-нибудь, что по моему мнению подойдет читателям (привет, vconst).

В данном случае могу смело порекомендовать одну из самых дешевых позиций нашего каталога, среди беспроводных наушников c APTX, т.е. MARSHALL Major II Bluetooth. Они стоят около 6 — 7 килорублей (актуальная цена на сайте, цены иногда меняются), дешевле только беспроводная версия легендарных KOSS Porta Pro (Wireless), но их басовитость на любителя.

Мой выбор обусловлен АЧХ с неравномерностью +-1,5 дБ, низким КНИ, ниже 0,7 %, полноразмерным закрытым акустическим оформлением, высокой чувствительностью 99 дб/Вт/м, сравнительно высоким сопротивлением — 64 Ом и временем автономной работы около 25 часов. Также меня порадовала хорошо продуманная эргономика и возможность подключения дополнительных проводных наушников (т.е. они способны работать в качестве BT-приемника).

С появлением APTX, Low Latency, APTX HD передача звука через Bluetooth перестала ассоциироваться с возможностью для неискушенных и не требовательных к звуку людей. Сегодня именно эти технологии позволяют получить ту верность воспроизведения, которая была возможна только при проводной передаче сигнала, и убили один из последних мифов о “плохом цифровом звуке”.

К сожалению, остаются проблемы с поддержкой и совместимостью, особенно когда речь идет о бюджетных смартфонах, а также сравнительно небольшое количество устройств (например, у нас в каталоге их немногим более 60-ти). Искренне надеюсь, что мой материал поможет вам с выбором. Буду признателен за ваше мнение в комментариях.

Источник

SDK тебе, SDK мне, SDK всем! Как делать SDK и зачем это нужно

Наша компания делает сервис для хранения и обработки данных с промышленных устройств (насосы, буры и прочая промышленная техника). Мы храним данные наших клиентов и предоставляем функционал для их анализа: построение отчетов, графиков и еще много чего.

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

И тогда мы поняли, что лучшим решением в данной ситуации будет разработать SDK и предоставлять его клиенту. Сразу же начал искать лучшие практики и рассуждения на тему разработки SDK и сильно удивился — в рунете об этом практически ничего нет, а в басурманских интернетах очень мало информации и она разрознена. Ну что ж, задача понятна, обдумана и реализована.

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

Пора определяться

Начнем с того, что определим, что такое SDK и зачем он может быть нужен.

SDK (от англ. software development kit) — комплект средств разработки, который позволяет специалистам по программному обеспечению создавать приложения для определённого пакета программ, программного обеспечения базовых средств разработки, аппаратной платформы, компьютерной системы, игровых консолей, операционных систем и прочих платформ. SDK использует преимущества каждой платформы и сокращает время на интеграцию.
…
Инженер-программист обычно получает SDK от разработчика целевой системы.

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

Но, как и у любого подхода, у «Пути SDK» есть как преимущества, так и недостатки.

Преимущества

Высокая скорость интеграции нового клиента — вашим клиентам нужно писать меньше кода.

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

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

Качество кода — много где любят экономить на тестировании (жалко бюджета, горят сроки и прочие причины). Понятно, что в реальном мире покрыть тестами все участки проекта это учень трудоемкая задача. Но качественно протестировать все модули SDK, а затем использовать их — это путь повышения процента покрытия тестами, что приведет вас к снижению количества ошибок.

Документация — тот же сценарий, что и с тестами. Покрыть документацией весь проект достаточно проблематично. Переиспользование модулей SDK повышает процент покрытия документацией, что снижает порог вхождения новых сотрудников в проект и вообще помогает по жизни.

Все преимущества, по сути, это следствия самого главного — мы очень качественно пишем код один раз, а затем его переиспользуем.

Недостатки

Высокие требования к качеству кода SDK — следствие главного преимущества. Ошибка в SDK породит ошибки во всех системах, его использующих.

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

Dependency hell и обновления — при расширении функционала (например, кастомизации решения под конкретного клиента), вы выпустите новую версию библиотеки. Но существуют зависимости, различные наборы версий библиотек у разных клиентов, и нужно очень тщательно следить за обратной совместимостью или строгим версионированием.

Когда SDK действительно нужен

У вас есть несколько стандартных сценариев, которые реализуются заново из раза в раз — собственно, наш случай.

Внутренние разработки — в разных проектах вы используете системы логирования, конфигурирования систем, работу с HttpRequest, БД, файлами? Выработайте внутренний SDK — набор библиотек для внутреннего использования. Вы в любой момент можете расширить функционал SDK, но скорость разработки новых проектов, процент покрытия тестами и документацией вырастет, а порог вхождения новых разработчиков снизится.

Когда SDK скорее всего будет лишним

Сценарии использования не определены или постоянно меняются — оставьте реализацию кастомных решений клиентам и помогите им. Не надо городить вундервафлю, которая будет только мешать. Очень актуально для молодых компаний и стартапов.

Вы не умеете делать качественно — у меня для вас плохая новость: пора учиться. Но отдавать кривое решение клиенту это очень, очень неправильно. Клиентов надо уважать, в конце концов.

Итак, мы определились, что такое SDK, с его преимуществами и недостатками и когда он нам нужен. Если после этого вы поняли, что SDK действительно нужен — приглашаю вас встать на «путь SDK» и разобраться, а каким он должен быть и как его, черт подери, делать?

«А вы любите Lego?» — Модульность

Представим все возможные сценарии использования SDK (вы же уже определились, зачем он вам нужен, правда?) и сделаем по библиотеке на сценарий. Чем не выход? Но это плохой подход, и так мы делать не будем. А будем так:

• разобьем все сценарии на шаги
• выявим общие шаги
• построим список модулей, реализующих все возможные шаги (один модуль отвечает за реализацию чего-то конкретного, например, работы с конфигурациями)

Например, с учетом специфики задачи, нам необходимо, чтобы вся логика задавалась из конфигов. Реализуем модуль работы с конфигами (чтения, записи, обновления, валидации и обработки конфигураций) и будем использовать его во всех остальных модулях.

А для реализации стандартных сценариев мы действительно сделаем модули — этакие «управляющие» модули, каждый из которых реализуют один конкретный сценарий, используя другие модули того же SDK. Таким образом для реализации стандартных сценариев клиент должен лишь подключить управляющий модуль сценария (а он сам подтянет все зависимости), а для реализации нестандартных — используем базовые модули, так же переиспользуя код.

Именно этим обусловлено то, что SDK не должен быть одной библиотекой (хотя очень хочется, понимаю. Ведь когда весь SDK в одной библиотеке, можно забыть о зависимостях и всем, что с ними связано), а быть комплектом библиотек. Дополнительным плюсом данного подхода будет уменьшение «веса» программы клиента — он будет тянуть тяжеловесный SDK, а подтянет только необходимые модули.

Но не стоить плодить модули как попало, ведь чем больше модулей, тем больше головной боли от их зависимостей! Т.е. важно правильно разбить логику на модули, соблюдая баланс между решением «все в одном» и «на каждую функцию свой модуль».

«А что, так можно было?!» — Универсальность

Предоставьте клиенту различные интерфейсы для работы с вашей библиотекой. Приведу пример:

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

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

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

«Родитель 1, Родитель 2, Дети[ ]» — Именование

Что самое трудное в работе программиста? Выдумывать имена для переменных.

И тем не менее… Правильное именование модулей, классов, свойств и методов сильно помогут тем, кто будут с вашим SDK работать. Пример, не требующих комментариев:

Kinect 2.0 SDK example

Всё ясно из названий классов и методов. А если есть автодополнение кода в вашей IDE, то зачастую можно и в документацию не заглядывать, если и так все понятно.

«Уверен, если бы Смерть знала, что такое бюрократия, люди бы никогда не умирали, вечно стоя в очереди. » — Документация

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

Документация, в SDK, как правило, проста и лаконична. Она обычно делится на две части: Tutorial — пошаговый курс в стиле “Построим город за 10 минут” и раздел Reference — справочник по всему, что можно сделать с помощью данного SDK.

Мы выбрали самый простой путь — summary + articles. Мы добавляем Xml атрибуты для методов и классов, которые светятся в intellisense как подсказки. Используя Docfx мы строим документацию по этим атрибутам и получаем подробную и удобную документацию, которую дополняет статьями, описывающими сценарии использования и примеры.

«— Чтобы чисто было! — Как я буду вилкой-то чистить?» — Тестирование

Что можно сказать про тестирование в рамках обсуждения SDK… Must have! Лучшим решением будет TDD (несмотря на то, что я негативно отношусь к данному подходу, в данном случае я решил использовать именно его). Да, долго. Да, нудно. Но зато в будущем вы не повеситесь от постоянных падений SDK на стороне и следствий этого падения.

Основной сок ситуации заключается в том, что отдавая SDK клиенту вы теряете контроль: вы не можете быстро пофиксить ошибку, сложно эту самую ошибку найти, да и выглядеть в такой ситуации вы будете достаточно глупо. Поэтому — тестируйте. Тестируйте лучше. И еще раз. И, на всякий случай, протестируйте ваши тесты. И тесты тестов. Так, что-то я увлекся, но важность тестирования SDK, надеюсь, понятна.

«Жертва, которая не могла противостоять своему прошлому, была поглощена им» — Логи

Поскольку вы отдаете SDK сторонней компании, в следствие чего теряете контроль над ситуацией, в случае ошибки (на этапе тестирования вы все-так решили «и так сойдёт», да?) вас ждет достаточно долгий и болезненный процесс поиск этой самой ошибки. Именно тут вам на помощь придут логи.

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

«Alarm! Achtung! Attention!» — Ошибки

Долго размышляя на тему ошибок я пришел к интересному выводу — ни один метод в вашем SDK не должен отдавать ошибку, не описанную в документации. Согласитесь, очень неприятно, когда вы подключаете стороннюю библиотеку для работы с HttpRequest, а она вываливает на вас какой-нибудь NullPointerException и StackTrace, который уводит в недра библиотеки. И вам приходиться погружаться в эти самые «недра», пытаясь понять, насколько глубока кроличья нора, и в чем, собственно, проблема.

Поэтому я предлагаю следующее решение — декларируйте закрытый список возможных исключений и документируйте их. Но, т.к. нельзя быть увереннным, что вы предусмотрели все, оберните метод в try-catch, а пойманную ошибку — в задекларируему. Например, ConfigurationException, который будет содержать InnerException — пойманную ошибку. Это позволит стороннему разработчику поймать все возможные ошибки, но в случае чего быстро разобраться в чем дело.

Версии или «как не укусить себя за хвост»

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

«Паровозик, который смог» — Deploy

Необходимость актуальности документации и версий порождают требование к корректности деплоя. В своем решении мы используем следующее решение (костыли, но работают).
Когда надо выпустить нвый релиз, разработчик дергает bat’ник с указанием номера релиза, а затем батник:

• билдит релиз
• кладет все библиотеки в архив
• билдит свежую версию документации (docfx)
• указывает версию релиза в документации и в названии архива
• кладет всё самое свеженькое в гит-репозиторий
• WebApp на MS Azure подтягивает свежий коммит по гит хуку и публикует изменения

На выходе получаем обновленную версию сайта с документацией, откуда можно скачать архив с последней версией SDK.
В планах на будущее — упаковка всего в Nuget пакеты и публикация в локальный Nuget репозиторий.

Рекоммендую обратить внимание на этот пункт, ведь вы можете существенно снизить количество головной боли, вызванной отсутствием актуальной информации о новой версии библиотеки.

«-А так можешь? — Фигня. Смотри как надо!» — Примеры & toolkit

Важным пунктом документации являются примеры использования. Но помимо этого, зачастую требуется предоставить не библиотеку, а приложение, которое реализует самые стандартные сценарии. Рекомендую делать эти приложения с открытым и хорошо прокомментированным исходным кодом, что позволит убить двух зайцев разом — предоставить работающее приложение и предоставить пример использования SDK.

Заключение

Разработка SDK стало для меня интересной новой задачей, поднявшей много важных архитектурных вопросов. Многое описанное в статье является очевидными вещами (для меня), но считаю важным огласить даже очевидные вещи, чтобы получить четкую общую картину.

Спасибо за прочтение, буду рад вашим комментариям. Надеюсь, эта статья будет для вас полезной.

Источник