Кто-нибудь знает, какой язык или технология используется для разработки рабочего стола Spotify? Это стабильно, красиво и легко.Какой язык или технология были использованы для разработки настольного приложения Spotify?
Учитывая, что он работает на окнах, явно не .NET (Process explorer говорит мне об этом), не выполнял процесс установки AIR, я бы сказал, что C++ использует библиотеки кросс-платформенных.
Все скомпилировано в один исполняемый файл, что указывает на то, что у них есть доступ к источнику всех зависимостей.
Wrt к техно ... я думаю, что они использовали Hardhouse Electronica
+1 для разъяснения техно – JPuge
компиляция до одного exe не означает, что у вас есть доступ к источнику всего, библиотеки могут быть предварительно скомпилированы с заголовком –
Вот список сторонних компонентов, которые они используют (в верхней части C++, конечно):
Интерфейс написан в FLEX, проверяет источники на вашем mac или окна машины. Вы увидите много xml-файла, который находится в формате файла flex.
Конечно, подключение к серверу и интеграция платформ, вероятно, написано изначально на языке C++. Но часть UI просто FLEX ...
Я не знаю, кто проголосовал за это, но это правда. – TjerkW
От их website:
Spotify построен в основном в Python и C++
Настольное приложение не использует Python. Это C++. Python используется на стороне сервера. –
По словам дизайнера Spotify:
http://twitter.com/#!/tobiasahlin/status/96483609799692288
«Некоторые из них находятся на C++, а некоторые из них находятся на языке разметки HTML-ish под названием Spider» «Он построен исключительно для использования в Spotify»
Spotify теперь использует Chromium Embedded Framework (CEF) для отображения веб-интерфейса, состоящего из HTML/CSS/JavaScript в настольном приложении.
Отсюда: http://www.quora.com/What-is-the-technology-behind-the-Spotify-desktop-app
Дата: 2014-09-09
Andreas Blixt, 5-летний Spotify сотрудник:
Ядром всех наших клиентов C++, но ядро с тех пор Сообщение Rasmus получило сжатый, с функциональностью, разделенной на модули. Как Spotify становится доступным на все более и более платформах, а также , получая богатый набор функций, мы должны убедиться, что «ядро» не станет «немного всего». Это означало разбить определенные функции, такие как управление воспроизведением, в свои собственные модули . Эти модули все еще C++, но достаточно автономны , что их логика теоретически может быть реализована на других языках . Мы называем интерфейсный уровень этими модулями «Космос», а работает не таким образом, как HTTP. Cosmos позволяет любой части клиента связываться с модулем с использованием произвольных путей и полезными нагрузками, что позволяет использовать гораздо более гибкую архитектуру. Некоторые очевидные преимущества - это интерфейсы с версией (пример: GET sp: // player/v1/main возвращает состояние игрока) и JSON для передачи данных. Это важно для другого изменения в нашем настольном клиенте.
В наши дни многие из наших пользовательских интерфейсов на самом деле используют Chromium Embedded Framework (CEF), что в основном означает, что наши представления рассчитаны на питание от JavaScript, HTML и CSS. Для всех наших функциональных команд, которые могут работать над своими функциями, не опасаясь нарушить чей-либо взгляд, каждый вид изолирован в собственном «браузере» (думаю, вы можете думать, что просмотров как вкладки в Chrome, кроме мы показываем больше одного на времени). Это приносит с собой одно ограничение: обмен данными между представлениями становится более сложным. Здесь приходит Cosmos, и действительно упрощает связь между ядром (C++) и JavaScript : клиенты JS могут выполнять произвольные запросы, и если есть привязка , этот запрос обрабатывается и откликается на него. Одним из примеров является конечная точка «сообщений», которая позволяет любому представлению выводить данные JSON на любой другой вид, который прослушивается (например, window.postMessage в HTML5, , за исключением того, что он также может взаимодействовать с модулями C++). Это также как все кнопки воспроизведения в клиенте знают, воспроизводится ли трек или , или доступен ли он в автономном режиме (другой модуль Cosmos), или , независимо от того, сохранили ли вы песню в своей музыке.
Еще одно важное изменение в нашем технологическом стеке состоит в том, что мы переместили еще одну «дополнительную» логику в службы агрегирования просмотров. Итак, где мы, , прежде делали бы почти всю логику клиентов, используя только бэкенд в качестве хранилища данных, теперь мы делаем гораздо больше работы на логическом уровне между хранилищами данных и клиентами, выставляя конечные точки очень , аналогичные Cosmos (на самом деле вы можете вызвать бэкэнд точно так же, как , вы вызываете модуль Cosmos, поэтому перемещение между слоями - это не проблема). Причина этого заключается в двух вариантах: одна, это позволяет нам быстрее расширять до более платформ, потому что существует меньше клиентской логики для реализации и двух, это действительно помогает нам поддерживать более постоянное поведение наших клиентов и обновлять потому что клиент более «глупый».Чтобы смягчить любое замедление , которое могло бы возникнуть в результате этого, мы обеспечили, что есть правила кэширования для всех данных, так что клиент все равно будет хранить данные локально, он просто не отвечает за столько бизнес-логики, сколько раньше было .
О, человек, звучит как идеальный случай для реактивов + Redux – ThatBrianDude
но это не делает, что окна оснастки ... иногда раздражает. – NimChimpsky
Версия для Linux-версии делает привязку: – Gagege
Windows оснащает меня сумасшедшим. – BentOnCoding