Комментарии 56
И опять на схеме не видны классические десктоп приложения.
А куда их пихать то? На двух платформах из четырех (xbox one и win phone) понятия «десктоп приложение» вообще не существует. Windows On Devices пока в этом плане под вопросом. (если еще не было точно сказано о том что оно из себя представляет, тут я не в курсе)
Десктопные приложения остаются на десктопе.
Десктопные приложения и весь win32 это теперь легаси
Вперед, в прекрасное юниверсал-будущее.
Вперед, в прекрасное юниверсал-будущее.
Помним уже судьбу Win8, вышедшей с этим тезисом. Ох, успешная получилась ОС.
Я как пользователь не понимаю, в чем принципиальная разница первого и второго приложения?
скрины
Сравните Steam из Windows Store с Desktop.
Так же сравните OneNote из Windows Store с тем, что на Desktop.
Так же сравните OneNote из Windows Store с тем, что на Desktop.
Steam из WindowsStore?
Legacy OneNote плохо адаптируется к высокому разрешению, плохо дружит с touch.
UAP OneNote пока не поддерживает Drag'n'Drop. И?
Legacy OneNote плохо адаптируется к высокому разрешению, плохо дружит с touch.
UAP OneNote пока не поддерживает Drag'n'Drop. И?
> Steam из WindowsStore?
Exactly. Догадываетесь почему его нет? Сколько еще приложений будет ограничено?
По поводу OneNote — сравните по функционалу, а не багам. То, что OneNote team по запросу работает над UAP OneNote и не фиксит баги OneNote на Desktop — проблема только OneNote team. Как легко сделать screenshot из UAP OneNote?
Exactly. Догадываетесь почему его нет? Сколько еще приложений будет ограничено?
По поводу OneNote — сравните по функционалу, а не багам. То, что OneNote team по запросу работает над UAP OneNote и не фиксит баги OneNote на Desktop — проблема только OneNote team. Как легко сделать screenshot из UAP OneNote?
Exactly. Догадываетесь почему его нет? Сколько еще приложений будет ограничено?
Денис, ты выбрал неудачный пример: потому что оно выглядит аппендиксом на текущей экосистеме.
Сколько не будет работать на UAP? Все твики системы, вроде punto switcher. Хотя это на самом деле сервис и он выходит за рамки UAP.
Как легко сделать screenshot из UAP OneNote?
Если ты имеешь ввиду Win+N, то это снова вопрос сервиса, выходящий за рамки UAP.
Тут есть только один вопрос, как UAP может взаимодействовать с сервисами в ОС, который следует поднимать. Но это не отменяет того, что будущее пользовательских приложений за новыми API.
> Денис, ты выбрал неудачный пример: потому что оно выглядит аппендиксом на текущей экосистеме.
Дима, спешу напомнить, что ты его выбрал :D
> Тут есть только один вопрос, как UAP может взаимодействовать с сервисами в ОС, который следует поднимать. Но это не отменяет того, что будущее пользовательских приложений за новыми API.
Пользователей нельзя просто так взять и переучить. Особенно тогда, когда ты не можешь предоставить весь набор функций, которые пользователь использовал раньше. Мы все помним пример Office с Ribbon. А это было всего одно приложение, и сколько времени заняло пользователей пересесть на новую версию? Так там, притом, все старое было, просто было сложно найти.
Попробую поставить и раскрыть свою мысль с другой стороны.
* Что мы пытаемся решить при помощи Windows Store приложений на Desktop?
* Какая выгода пользователя со всего этого? Покупать одно приложение везде и будет дешевле — так все переходят на подписки и на freemium, какой смысл? Использовать один и тот же UI — так неудобно, touch на Desktop не прижился. Использовать convertible laptop/tablet — может быть, но dual boot не был бы лучше? Все что мы даем пользователю сейчас — это «Ты не можешь теперь сделать X так как ты привык». В общем, что мы пытаемся решить этим?
* Какая выгода разработчика со всего этого? Проще писать приложения? Демо/тестовые/одноразовые приложения, вроде как, да, а что-то сложнее? Убедите меня сразу, как только покажите одно приложение от Microsoft в Windows Store, которое Universal. Для indie разработчиков, так, вообще, не понимаю, где выгода. Тратить времени, как на два приложения (тестирование, оптимизация UI), а продавать как одно.
Дима, спешу напомнить, что ты его выбрал :D
> Тут есть только один вопрос, как UAP может взаимодействовать с сервисами в ОС, который следует поднимать. Но это не отменяет того, что будущее пользовательских приложений за новыми API.
Пользователей нельзя просто так взять и переучить. Особенно тогда, когда ты не можешь предоставить весь набор функций, которые пользователь использовал раньше. Мы все помним пример Office с Ribbon. А это было всего одно приложение, и сколько времени заняло пользователей пересесть на новую версию? Так там, притом, все старое было, просто было сложно найти.
Попробую поставить и раскрыть свою мысль с другой стороны.
* Что мы пытаемся решить при помощи Windows Store приложений на Desktop?
* Какая выгода пользователя со всего этого? Покупать одно приложение везде и будет дешевле — так все переходят на подписки и на freemium, какой смысл? Использовать один и тот же UI — так неудобно, touch на Desktop не прижился. Использовать convertible laptop/tablet — может быть, но dual boot не был бы лучше? Все что мы даем пользователю сейчас — это «Ты не можешь теперь сделать X так как ты привык». В общем, что мы пытаемся решить этим?
* Какая выгода разработчика со всего этого? Проще писать приложения? Демо/тестовые/одноразовые приложения, вроде как, да, а что-то сложнее? Убедите меня сразу, как только покажите одно приложение от Microsoft в Windows Store, которое Universal. Для indie разработчиков, так, вообще, не понимаю, где выгода. Тратить времени, как на два приложения (тестирование, оптимизация UI), а продавать как одно.
Дима, спешу напомнить, что ты его выбрал :D
В качестве примера приложения схожего по функционалу. Два приложения для игровых сетей, оба позволяют работать с соцсоставляющей и библиотекой игр, запускать эти игры. Единственное отличие — стим сам устанавливает игры, xbox — через Store. Два приложения с похожим функционалом написанные на разных технологиях. И я не понимаю, чем приложение написанное на базе UAP принципиально хуже.
Особенно тогда, когда ты не можешь предоставить весь набор функций, которые пользователь использовал раньше.
Для таких приложений пока остаётся старое API. Но в реальности их не так уж и много.
Что мы пытаемся решить при помощи Windows Store приложений на Desktop?
кто мы?
> И я не понимаю, чем приложение написанное на базе UAP принципиально хуже.
Оттуда не поставить Half Life. Туда не перенести уже купленные игры.
> Для таких приложений пока остаётся старое API. Но в реальности их не так уж и много.
Но их нельзя использовать из Windows Store приложений.
> кто мы?
Я, ты, Microsoft и другие разработчики.
Оттуда не поставить Half Life. Туда не перенести уже купленные игры.
> Для таких приложений пока остаётся старое API. Но в реальности их не так уж и много.
Но их нельзя использовать из Windows Store приложений.
> кто мы?
Я, ты, Microsoft и другие разработчики.
Оттуда не поставить Half Life. Туда не перенести уже купленные игры.
А в steam не купить Halo. И, что интересно, вопрос запуска Source на WinRT больше политический.
Но их нельзя использовать из Windows Store приложений.
Нельзя на прямую, хотя даже в windows 8 были варианты. И это действительно больной вопрос, который сводится к взаимодействию с desktop сервисами. И этот вопрос нужно поднимать, тут я не спорю.
Какая выгода пользователя со всего этого? Покупать одно приложение везде и будет дешевле — так все переходят на подписки и на freemium, какой смысл? Использовать один и тот же UI — так неудобно, touch на Desktop не прижился. Использовать convertible laptop/tablet — может быть, но dual boot не был бы лучше? Все что мы даем пользователю сейчас — это «Ты не можешь теперь сделать X так как ты привык». В общем, что мы пытаемся решить этим?
Что ты подразумеваешь под всем этим? От магазина приложений выгода в том, что понятно где есть приложения без троянов и вирусов.
Использовать один и тот же UI? при чем тут пользователи?
Как пользователь, я ожидаю, что смогу взаимодействовать с приложением любым доступным мне способом. А от самого популярного Decktop twitter клиента мне пришлось отказаться именно потому, что без мышки им пользоваться невозможно.
Какая выгода разработчика со всего этого?
От Store выгода очевидна — удобный способ дистрибьюции приложений. И никто не мешает сделать два разных приложения для десктопа и телефона и продавать отдельно.
От UAP плюс для меня, как разработчика в том, что я в большинстве случаев могу не задумываться о том, как пользователь будет взаимодействовать с моим приложением: мышь, сенсор, перо. Я знаю, что элементы интерфейса (как заявлено) будут подстраиваться под способ вода. Пример: контекстное меню на taskbar и в пуске на крайней сборке 10ки.
Вот смотри, ты везде защищаешь Store, против которого я не имею ничего плохого, и считаю это просто необходимым на любой платформе. И даже удивительно, что на Windows (на самой популярной ОС) это появилось в последнюю очередь.
Пользователям нужен Store.
Пользователям нет дела до Windows Store приложений.
> И никто не мешает сделать два разных приложения для десктопа и телефона и продавать отдельно.
Мешает, я не могу распространять нормальные Desktop приложения через Windows Store.
Пользователям нужен Store.
Пользователям нет дела до Windows Store приложений.
> И никто не мешает сделать два разных приложения для десктопа и телефона и продавать отдельно.
Мешает, я не могу распространять нормальные Desktop приложения через Windows Store.
Пользователям нет дела до Windows Store приложений.
Пользователям нет дела до того, на чем написано приложение, если оно работает. Не вижу проблемы написать качественное приложение на анонсированном SDK. Подавляющему большинству приложений его хватит.
Мешает, я не могу распространять нормальные Desktop приложения через Windows Store.
Нормальные это какие? Я, как пользователь, понимаю это как приложения с нужным мне функционалом и качественным UI. Любое приложение не завязанное на системный сервис можно качественно сделать на UAP.
Популярные приложения, которые не сделать без потери функционала:
DropBox, Яндекс.Диск и подобные
Punto Switcher
Антивирусы
Приложения которым требуются очень длительные фоновые задачи.
Больше сходу не вспоминается. А эти ребята всегда могли и договаривались с МС о предоставлении необходимого функционала.
> Не вижу проблемы написать качественное приложение на анонсированном SDK.
Я вижу. Как уже внизу сказали, у нас было нормальное Skype приложение, стало ужасное Skype Windows Store приложение. Тоже самое случиться и со всеми остальными приложениями. Вопрос в том, зачем Microsoft заставляет всех писать новые приложения, когда старые отлично справлялись со своими задачами? Пользователи страдают.
> Любое приложение не завязанное на системный сервис можно качественно сделать на UAP.
Зачем делать, если они есть?
> Больше сходу не вспоминается.
А по мне так, нормально вписываются в Windows Store приложения только а) приложения заменители Web сайтов, тут как раз приоритет Microsoft с JS приложениями понятен б) игры.
Все остальные приложения будут на Desktop.
Я вижу. Как уже внизу сказали, у нас было нормальное Skype приложение, стало ужасное Skype Windows Store приложение. Тоже самое случиться и со всеми остальными приложениями. Вопрос в том, зачем Microsoft заставляет всех писать новые приложения, когда старые отлично справлялись со своими задачами? Пользователи страдают.
> Любое приложение не завязанное на системный сервис можно качественно сделать на UAP.
Зачем делать, если они есть?
> Больше сходу не вспоминается.
А по мне так, нормально вписываются в Windows Store приложения только а) приложения заменители Web сайтов, тут как раз приоритет Microsoft с JS приложениями понятен б) игры.
Все остальные приложения будут на Desktop.
Как уже внизу сказали, у нас было нормальное Skype приложение, стало ужасное Skype Windows Store приложение.
Прости, как левой пятки, видимо, из под палки написанное приложение говорит о проблемах UAP, там более, что написано оно на более старом API?
Есть пример вполне вменяемого приложения Mail, функционала которого мне хватает за глаза и реализовывает оно его вполне хорошо. Есть отличное приложение ВКонтакте, которым я пользуюсь наравне с веб версией. Прекрасное приложение Book Viser. Качественные приложения делать можно.
Вопрос в том, зачем Microsoft заставляет всех писать новые приложения, когда старые отлично справлялись со своими задачами?
Вопрос безопасности, в частности. Проверять managed приложения все же проще.
> Любое приложение не завязанное на системный сервис можно качественно сделать на UAP.
Зачем делать, если они есть?
Есть, например, tweetdeck, которым я не могу нормально пользоваться на моем Surface, ибо не могу даже залогиниться без мыши и клавиатуры. Есть множество других приложений с проблемами, которых не было бы, будь они написаны на UAP. И да, были бы совершенно другие проблемы.
Я не призываю бездумно переписывать все существующие приложения. Но, строго говоря Лексикон тоже был и работал.
Все остальные приложения будут на Desktop.
Зачем?
Вот есть то же приложение Steam — по сути web-приложение. При необходимости(которой по понятным причинам нет) его можно спокойно реализовать на UAP.
Есть Slack — туда же. Вообще все мессенджеры следует переписать на современном API, чтоб батарейку не жрали.
Аудио/Видеопроигрователи — есть пример VLC.
Фото, видео, аудио редакторы? Первым, кроме огромного количества legacy кода ничего не мешает быть написанными на UAP. Вторые и третьи завязаны на кодаки, но все это не мешает существовать профессиональными приложениям на iPad. У windows тут проблемы в другом.
Пример офисного пакета МС сейчас разрабатывает.
Остаются средства разработки. Какой ещё класс приложений я упустил?
> Вопрос безопасности, в частности. Проверять managed приложения все же проще.
Откуда вы это взяли? Хотите сказать, что я могу написать Windows Store приложение на C++, и тогда его нельзя будет проверить? Делать sandbox и ограничивать права на API можно и без UAP, а дорабатывая уже существующую платформу.
> Остаются средства разработки. Какой ещё класс приложений я упустил?
Вы, мне кажется, просто не читаете, что я пишу. Skype — это отличный пример. Если у Microsoft, у которой ресурсов намного больше, чем у разработчиков TweetDeck не может нормально переписать Skype с desktop на UAP, то что мы можем ожидать от TweetDeck?
Простым языком: хреново написанные приложения на Desktop — будут хреново написано на UAP. Годами отполированные приложения на Desktop — будут иметь аналогичные проблемы при выпуске на UAP и потребуются те же самые годы, чтобы отполировать их на Desktop. И они так же будут батарейку жрать. Кто вам сказал, что нет?
> Пример офисного пакета МС сейчас разрабатывает.
А могли в это время чем-то полезным заняться ;)
Откуда вы это взяли? Хотите сказать, что я могу написать Windows Store приложение на C++, и тогда его нельзя будет проверить? Делать sandbox и ограничивать права на API можно и без UAP, а дорабатывая уже существующую платформу.
> Остаются средства разработки. Какой ещё класс приложений я упустил?
Вы, мне кажется, просто не читаете, что я пишу. Skype — это отличный пример. Если у Microsoft, у которой ресурсов намного больше, чем у разработчиков TweetDeck не может нормально переписать Skype с desktop на UAP, то что мы можем ожидать от TweetDeck?
Простым языком: хреново написанные приложения на Desktop — будут хреново написано на UAP. Годами отполированные приложения на Desktop — будут иметь аналогичные проблемы при выпуске на UAP и потребуются те же самые годы, чтобы отполировать их на Desktop. И они так же будут батарейку жрать. Кто вам сказал, что нет?
> Пример офисного пакета МС сейчас разрабатывает.
А могли в это время чем-то полезным заняться ;)
Хотите сказать, что я могу написать Windows Store приложение на C++, и тогда его нельзя будет проверить?
Да, тут слегка нагнал, думал, что CX — управляемый, но нет. В общем-то RT это как раз пример sandbox и так далее. Если его впихивать в legacy api, то куча приложений тупо посыпится. Яркий тому пример — внедрение UAC, когда большое количество приложение перестало работать, без повышения прав до админских.
Если у Microsoft, у которой ресурсов намного больше, чем у разработчиков TweetDeck не может нормально переписать Skype с desktop на UAP, то что мы можем ожидать от TweetDeck
Ты же знаешь структуру МС. Я вот не уверен, что у Skype на одну платформу приходится значительно больше ресурсов, чем у TweetDeck.
хреново написанные приложения на Desktop — будут хреново написано на UAP… И они так же будут батарейку жрать. Кто вам сказал, что нет?
1) Запрет асинхронных вызовов. На UAP написать приложение фризящее UI сложнее.
2) Ограничение работы в фоне. Что заставляет лучше продумывать архитектуру приложения, и не дает постоянно держать открытым сокет.
3) Автоматическая поддержка HDPI. На UAP приложения не расползутся на моем SP3 и не будут мелкими.
4) Как заявлено, автоматическая оптимизация стандартных контролов под Touch, когда это необходимо. Хотя на том же WPF эта проблема не стоит так остро, как на sdk использующих свои собственный контролы, как в случае с TweetDeck. Но если подобные мелочи будут решаться системой, это пвысит общее качество приложений.
Ну и почему многое из этого нельзя реализовать в старом API — legacy приложения. Хотя тот же WPF вроде собираются развивать дальше.
НЛО прилетело и опубликовало эту надпись здесь
Сравните Skype из Store и обычный Skype.
На пример WP8 видит все мои контакты.
А Win8 не видит мои контакты.
И это продукт Микрософт (уже). С акком у микрософт.
На пример WP8 видит все мои контакты.
А Win8 не видит мои контакты.
И это продукт Микрософт (уже). С акком у микрософт.
Давайте я напишу говноприложение на любом API и начну ругать API на его примере? У меня, кстати, нет проблем с контактами в приложении из стора.
Вопрос в том, что принципиально, большинство приложений быстрее и качественнее писать на UAP: они будут работать на нескольких платформах, поддерживать несколько способов пользовательского взаимодействия и работать с различными плотностями экранов. И это без каких-то сверх затрат.
Как я написал выше, основная проблема — сервисы, работающие на уровне системы и их взаимодействие с UAP, но есть пример хрома, фф, для которых эту проблему сняли. Есть пример антивирусных приложений, которым разрешили пользоваться системными пушами. и т.д.
А говноприложения можно спроектировать на любом API.
Вопрос в том, что принципиально, большинство приложений быстрее и качественнее писать на UAP: они будут работать на нескольких платформах, поддерживать несколько способов пользовательского взаимодействия и работать с различными плотностями экранов. И это без каких-то сверх затрат.
Как я написал выше, основная проблема — сервисы, работающие на уровне системы и их взаимодействие с UAP, но есть пример хрома, фф, для которых эту проблему сняли. Есть пример антивирусных приложений, которым разрешили пользоваться системными пушами. и т.д.
А говноприложения можно спроектировать на любом API.
> Десктопные приложения и весь win32 это теперь легаси
ИМХО, как-то глупо переводить в legacy то, чем пользуется большинство.
ИМХО, как-то глупо переводить в legacy то, чем пользуется большинство.
Вопрос ведь не в том, пользуются или нет, а вопрос будет ли win32 (а также wpf, winforms и все этом основанное ) дальше развиваться, или нет. Опыт лет десяти последних показывает что нет. Значит — легаси.
Впрочем, Вы же из DevDiv вроде бы, вот и расскажите как оно на самом деле:)
Впрочем, Вы же из DevDiv вроде бы, вот и расскажите как оно на самом деле:)
> Опыт лет десяти последних показывает что нет.
А учитывая то, что пофиксили MFC баги, а так же воссоздали WPF команду говорит, что нет. Либо говорит, что Microsoft сам запутался.
> Впрочем, Вы же из DevDiv вроде бы, вот и расскажите как оно на самом деле:)
В Microsoft есть одно огромное правило «работает, не трогай». Видимо, из-за этого и возникает такое количество новых фреймворков и платформ. А за полтора года много чего там изменилось, то что я знаю теперь я рассказывать не могу, чтобы никого не подставлять, а то, что я могу рассказать — уже не имеет значение ;)
А учитывая то, что пофиксили MFC баги, а так же воссоздали WPF команду говорит, что нет. Либо говорит, что Microsoft сам запутался.
> Впрочем, Вы же из DevDiv вроде бы, вот и расскажите как оно на самом деле:)
В Microsoft есть одно огромное правило «работает, не трогай». Видимо, из-за этого и возникает такое количество новых фреймворков и платформ. А за полтора года много чего там изменилось, то что я знаю теперь я рассказывать не могу, чтобы никого не подставлять, а то, что я могу рассказать — уже не имеет значение ;)
в 2030г какой-нибудь студент напишет для Metro эмулятор десктопа и тогда будут у вас десктопные приложения, где-нибудь на виртуальном экране повешенном на виртуальную стену.
Теперь вы сможете писать одинаково неудобные приложения для всех 4х платформ.
НЛО прилетело и опубликовало эту надпись здесь
У меня сейчас немного другой профиль, у моих приложений можно сказать интерфейса вообще нет, если не считать таковым поток байт в I2C.
НЛО прилетело и опубликовало эту надпись здесь
Почему в какой то степени интересует, просто меня смущает идея одно SDK под все платформы, да ещё и достаточно сильно отличающиеся типом управления. Если у них это получится то я буду только рад, но пока лично у меня настрой скептический, его я и высказал.
Вы, должно быть, с большой радостью готовы взяться за изучение четырех платформ под свое приложение, которое должно работать с I2C, RS232, RS485 и USB. А может просто одно приложение на одном фреймворке и четыре интерфейсных модуля?
Честно это ситуация последнего месяца, нужно было сделать универсально чтобы и I2C и UART как интерфейсы платформозависимые, а основной модуль читающий данные был переносим. Так вот я бы в разы быстрей и проще написал оба варианта по отдельности, чем пытаться сделать универсально, потому как всплыла большая куча маленьких различий I2C и UART с которыми процентов 80 времени и было потрачено. А по началу выглядело всё замечательно.
НЛО прилетело и опубликовало эту надпись здесь
Если задача простая и разовая (с циклом разработки в день или несколько дней), можно сделать четыре разных проекта. Но если проект длительный, он живет, в него вносится новый функционал и правки, то синхронизировать правки в четырех проектах разных платформ еще тот кошмар. Так что объединение нескольких фреймворков в один это большой плюс.
Windows давно стоило пересмотреть инструменты для написания приложений, чтобы разработчики не писали каждый раз велосипеды для установки, обновлений, синхронизации, сохранения состояния при включении/выключении и прочего.
Одна из ключевых задач Windows 10 — предоставить возможность использовать единый UI, который сможет масштабироваться на разных экранах
Я не совсем понимаю, зачем это нужно пользователю. Разные экраны предполагают разные способы взаимодействия. Десктопный экран предполагает точное управление мышью. Экран телевизора для XBOX предполагает управление с помощью пульта или игрового контроллера. Экран мобильного устройства предполагает управление пальцами. В чем выгода от создания единого UI, если он будет удобным только в том случае, если разработчик позаботится сделать его разным? Мы ведь уже проходили притягивание планшетного интерфейса на десктоп в Windows 8. Пользователи «заботу» не оценили.
Никто не говорит, что UI одинаково выглядит. Речь о том, что вы создаете единое решение, которое адаптируется под разные экраны и разные способы ввода.
НЛО прилетело и опубликовало эту надпись здесь
Меня в этом больше смущает трактовка «одна из ключевых задач». Зачем и кому это может пригодиться, вполне ясно. Непонятно, почему это преподносится, как нечто важное и ключевое. Это всего лишь архитектурная фича, которая, как мне кажется, никакого существенного влияния на жизнь разработчиков не окажет, а пользователи ее вообще не смогут оценить.
Я несколько далек от современной инфраструктуры MS, поэтому прошу прощения за обывательский вопрос: Что это дает конечному пользователю?
Разработчик пишет одно приложение, которое одинаково работает на всех платформах? Например, возможно будет запускать полнофункциональный MS Office какой-нибудь 2015 версии? И запускать GTA VI на PC с Windows 10 вместо XBox?
Или для каждого типа устройств все равно потребуется отдельное лицензирование?
MS наконец сделало единую инфраструктуру для сопровождения ПО? Аналог линуксовых репозиториев или Google.Play, где установка и обновление ПО централизовано?
Разработчик пишет одно приложение, которое одинаково работает на всех платформах? Например, возможно будет запускать полнофункциональный MS Office какой-нибудь 2015 версии? И запускать GTA VI на PC с Windows 10 вместо XBox?
Или для каждого типа устройств все равно потребуется отдельное лицензирование?
MS наконец сделало единую инфраструктуру для сопровождения ПО? Аналог линуксовых репозиториев или Google.Play, где установка и обновление ПО централизовано?
1. Простую синхронизацию данных между приложениями.
2. Купил раз — используешь везде (разработчик может ограничить).
3. MS наконец ДЕЛАЕТ единую инфраструктуру для сопровождения ПО — Windows Store
4. Установка и обновление ПО централизовано (и даже автоматическое).
Ну и для разработчиков:
5. Можно выкинуть всю логику в расшаренную библиотеку базовых визуальных элементов.
6. Один язык для описания интерфейсов и кода (XAML & C#), а можно и F# (и еще много чего).
2. Купил раз — используешь везде (разработчик может ограничить).
3. MS наконец ДЕЛАЕТ единую инфраструктуру для сопровождения ПО — Windows Store
4. Установка и обновление ПО централизовано (и даже автоматическое).
Ну и для разработчиков:
5. Можно выкинуть всю логику в расшаренную библиотеку базовых визуальных элементов.
6. Один язык для описания интерфейсов и кода (XAML & C#), а можно и F# (и еще много чего).
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Превью инструментов и SDK для разработки приложений под Windows 10