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Единственное что в них общего это ООП.
Нет. Последний (2-й) Метал даже скопировал те же стадии конвейера, что был в DirectX12 и концепция построения та же самая.
Реализацию DirectX12 ООП назвать можно только условно, там компонентная модель.
Те же самые стадии были и в OpenGL и скопированы в первую очередь от туда. Концепция работы с железом, внезапно, не может сильно отличаться, если нужно минимизировать всю абстракцию. Она определяется не дизайном DirectX или чего либо, а принципами работы железа.
Но опять-таки это схожесть концепций, а не API.
Реализацию DirectX12 ООП назвать можно только условно, там компонентная модель.Компонентная модель это COM? Как он противоречит ООП? COM построен как раз вокруг ООП.
Покажите мне наследование в COM, не включение (containment), а наследование (inheritance). Вот тогда и поговорим ;-)
В COM? Легко. Берете базовый интерфейс (да тот же Unknown) и наследуете класс от него. Вот вам и наследование.
А если у меня готовый компонент, то как ?
Хинт: ваш пример наследует в рамках языка, а не технологии.
Никак. Но ООП и не гарантирует возможность отнаследоваться от неизвестного класса. Такое сплошь и рядом в мире ООП API когда внутренние классы не доступны.
P.S. Вы можете отвечать одним комментарием на комментарий? Такая древовидная беседа изматывает.
По большому счету, наверное будет корректнее сказать, что единого определения что такое ООП нет.
Но я придерживаюсь старой концепции, согласно которой ООП это Полиморфизм, Инкапсуляция и Наследование.
Основываясь на этом, я не понимаю что такое "ООП и не гарантирует возможность отнаследоваться от неизвестного класса"
Почему ? Что за гарантия и откуда она берется (или не берется) ?
Я написал слово "гарантирует" потому что есть реализации ООП где можно использовать наследование на неизвестном классе.
Наличие чего-то в концепции не означает, что это применимо ко всему в рамках этой концепции. "Наследование" не означает что можно получить дочерний класс от любого используемого в программе класса или дочерний объект. Это всего лишь означает, что такая возможность есть при определенных условиях.
В некоторых языках есть final классы и от них нельзя отнаследоваться. Однако использование таких классов не противоречит ООП.
Более того, COM без наследования невозможен. Он работает только благодаря наследованию и полиморфизму. Даже инкапсуляция не обязательна.
Уважаемый Nikita, я спать, если что, готов продолжить завтра вечером.
Условно говоря, разберитесь чем COM отличается от C++
Как бы странно это моё предложение не звучало ;-)
Действительно странно. Где я писал про C++ или любой другой язык?
Вы разницу между спецификацией и реализацией понимаете, для начала ?
Если нет, то дискуссия будет непродуктивна.
Извините, но желания объяснять, что 2 x 2 = 4 у меня желания нет ;-)
"Спецификация" довольно неоднозначный термин. Вы "интерфейс" имеет в виду? Разница очевидна. Но как это относится к обсуждаемому вопросу?