Bloomberg: Apple запланировала объединить приложения для iOS и Mac в 2018 году Статьи редакции
По словам источников, разработчики смогут создавать приложения, которые будут подстраиваться под iPhone, iPad и Mac.
Apple планирует объединить магазины приложений для iOS и Mac в 2018 году. Об этом пишет Bloomberg со ссылкой на собственные источники.
По данным издания, с 2018 года разработчики ПО смогут создавать приложения, которые одинаково хорошо будут взаимодействовать с сенсорными экранами iPhone и iPad и мышью и тачпадом Mac.
Сейчас создатели приложений вынуждены разрабатывать два разных приложения для продукции Apple: одно для iOS, второе — для macOS. Клиенты компании регулярно жалуются на устаревающие приложения для Mac, отмечает Bloomberg. Например, Twitter для iPhone и iPad обновляется регулярно, в отличие от версии для Mac.
Проект по изменению систем iOS и macOS получил название Marzipan. Apple может представить его летом на ежегодной конференции разработчиков, считают источники. Пресс-секретарь Apple отказался от комментариев.
Подобная система работает у Microsoft, которая создала Universal Windows Platform — платформу, которая позволяет создавать приложения для Windows, Windows Phone, Xbox, HoloLens и Surface Hub.
Интересно как это будет реализовано технически. Например, концепция и API для UI у двух систем совершенно разные. Будут ли они унифицированы?
Скорее всего нет, не полностью. Будет что-то общее, а что-то отдельное. У Микрософта именно такой подход.
.... который не очень работает. Когда это Apple слизывала API у MS?
Он работает и еще как работает. Более того, UWP - это второе уже поколение технологии.
Когда это Apple слизывала API у MS?Metal ни что иное как вольная интерпретация DirectX12
Работает в смысле исполняется на процессоре? Это да. А вот в остальных смыслах - нет. Это не удобно.
Metal ни что иное как вольная интерпретация DirectX12Единственное что в них общего это ООП.
Работает в смысле концепция (подход к проектированию приложений) доказал свою жизнеспособность. То есть, что "так делать можно" и поддержка инструментами/методологией разработки тоже появилась.
Если вы про концепцию фиксированного базового API, то эта концепция работала всегда и везде. Делать фреймворки это естественное желание.
Если же вы про подход MS к интерфейсам на разных девайсах, то работает он не очень. Интерфейс для тача который нужно использовать мышкой это ужас.
Почта, Скайп и еще пачка приложений одинаково удобны и на телефоне и на десктопе и тачем и мышкой. Кассовым приложением, над которым я работаю, например, одинаково пользуются и на планшетах и на ПК. Не стоит сравнивать гайдлайны UWP и гайдлайны предыдущих поколений приложений.
Хорошо выглядит, мне нравится.
мышкой это ужас.
С этим никто не спорит. Но вроде бы все идёт к таскринам по умолчанию - ведь технологическая база позволяет их устанавливать уже везде (везде-везде).
Как-то выходные провозился с маршрутным компьютером с перьевым вводом (на Windows NT) ... не выдержал, побежал купил USB хаб, USB клаву и мышку, ну невозможно было сделать ничегошеньки совсем :(
Нет. Последний (2-й) Метал даже скопировал те же стадии конвейера, что был в DirectX12 и концепция построения та же самая.
Реализацию DirectX12 ООП назвать можно только условно, там компонентная модель.
Те же самые стадии были и в OpenGL и скопированы в первую очередь от туда. Концепция работы с железом, внезапно, не может сильно отличаться, если нужно минимизировать всю абстракцию. Она определяется не дизайном DirectX или чего либо, а принципами работы железа.
Но опять-таки это схожесть концепций, а не API.
Реализацию DirectX12 ООП назвать можно только условно, там компонентная модель.Компонентная модель это COM? Как он противоречит ООП? COM построен как раз вокруг ООП.
Это ошибочное суждение. Я сравнивал все графические API в динамике развития. OpenGL давно отстал и догоняет DirectX и стадии там далеко не одинаковые.
Концепция работы с железом, внезапно, не может сильно отличаться, если нужно минимизировать всю абстракцию. Она определяется не дизайном DirectX или чего либо, а принципами работы железа.Это тоже ошибочное суждение.
Иначе бы не было "Совместимых с DirectX9" видеокарт, например.
Что именно ошибочное? Да, OpenGL отставал из-за того, что сам API давно устарел, с этим я вроде не спорю.
Иначе бы не было "Совместимых с DirectX9" видеокарт, например.Этот пример не опровергает, а подтверждает то, что я написал. Архитектура железа меняется, а с ним и концепция работы с ним. Есть карты, которые в поддерживают старые подходы архитектурно и на них может работать DirectX9.
"Этот пример не опровергает, а подтверждает то, что я написал. Архитектура железа меняется, а с ним и концепция работы с ним. "
Нет, посмотрите что появилось вперед API или железо.
И почему железо GPU стало именно таким (почитайте про совместную работу Микрософта с вендорами и т.п.)
Это не противоречит. API может появляться до железа, потому что от разработки прототипа до массового выпуска готовой железки проходит больше времени чем на реализацию API.
почитайте про совместную работу Микрософта с вендорамиВы думаете вендоры железа подстраивались под прихоти программистов API? Даже банальная логика говорит об обратном.
Ошибочно вот это
"Те же самые стадии были и в OpenGL"
Не все.
Покажите мне наследование в COM, не включение (containment), а наследование (inheritance). Вот тогда и поговорим ;-)
В COM? Легко. Берете базовый интерфейс (да тот же Unknown) и наследуете класс от него. Вот вам и наследование.
А если у меня готовый компонент, то как ?
Хинт: ваш пример наследует в рамках языка, а не технологии.
Никак. Но ООП и не гарантирует возможность отнаследоваться от неизвестного класса. Такое сплошь и рядом в мире ООП API когда внутренние классы не доступны.
P.S. Вы можете отвечать одним комментарием на комментарий? Такая древовидная беседа изматывает.
По большому счету, наверное будет корректнее сказать, что единого определения что такое ООП нет.
Но я придерживаюсь старой концепции, согласно которой ООП это Полиморфизм, Инкапсуляция и Наследование.
Основываясь на этом, я не понимаю что такое "ООП и не гарантирует возможность отнаследоваться от неизвестного класса"
Почему ? Что за гарантия и откуда она берется (или не берется) ?
Я написал слово "гарантирует" потому что есть реализации ООП где можно использовать наследование на неизвестном классе.
Наличие чего-то в концепции не означает, что это применимо ко всему в рамках этой концепции. "Наследование" не означает что можно получить дочерний класс от любого используемого в программе класса или дочерний объект. Это всего лишь означает, что такая возможность есть при определенных условиях.
В некоторых языках есть final классы и от них нельзя отнаследоваться. Однако использование таких классов не противоречит ООП.
Более того, COM без наследования невозможен. Он работает только благодаря наследованию и полиморфизму. Даже инкапсуляция не обязательна.
Уважаемый Nikita, я спать, если что, готов продолжить завтра вечером.
Условно говоря, разберитесь чем COM отличается от C++
Как бы странно это моё предложение не звучало ;-)
Действительно странно. Где я писал про C++ или любой другой язык?
Вы разницу между спецификацией и реализацией понимаете, для начала ?
Если нет, то дискуссия будет непродуктивна.
Извините, но желания объяснять, что 2 x 2 = 4 у меня желания нет ;-)
"Спецификация" довольно неоднозначный термин. Вы "интерфейс" имеет в виду? Разница очевидна. Но как это относится к обсуждаемому вопросу?