Windows 10 : tester une application sans même l'installer

Le par  |  61 commentaire(s)
Windows-10-logo

Microsoft souhaite retrouver les faveurs des développeurs et annonce leur proposer prochainement un module qui leur permettra de proposer aux clients de tester une application sans avoir à l'installer.

Dans certaines des tuiles de l'interface de Windows 10 laissées vides par l'utilisateur, Microsoft diffuse parfois de la publicité pour des applications, tout en redirigeant vers son Windows Store afin de les télécharger. Une procédure en plusieurs étapes qui pourrait être d'un autre âge avec le nouveau module que Microsoft s'apprête à déployer.

Ainsi, au lieu d'aller télécharger l'application, il pourrait être proposé de la tester directement, et ce, sans même avoir à l'installer. L'objectif serait de proposer à l'utilisateur une sorte de démonstration afin qu'il puisse définir ou non de l'intérêt de l'application avant même de la télécharger.

Pour ce faire, Microsoft proposera prochainement aux développeurs de créer des publicités interactives pour leurs applications. Le streaming sera alors à l'oeuvre pour permettre aux utilisateurs d'interagir pendant trois minutes maximum avec l'appli comme si elle était installée sur leur machine. À la fin de la session, l'utilisateur sera invité à se rendre sur le marché applicatif pour installer l'application.

Playable-Ads

Il s'agit véritablement d'une bonne idée qui devrait permettre de tester une foule d'application sans encombrer son système tout en sélectionnant uniquement les applications véritablement utiles en fonction de chaque utilisateur.

Microsoft n'a toutefois rien inventé ici, puisque le système rappelle celui des Instant Apps sous Android, à ceci près que ces dernières ne sont bridées par aucune limite de temps.

Complément d'information

Vos commentaires Page 1 / 7

Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le #1956562
"Microsoft souhaite retrouver les faveurs des développeurs" depuis quand il les a perdu ?
Le C# est de loin l'un des langages les plus agréable et les plus complet que je connaisse. Surtout en terme de gestion de l'asynchrone.
Le #1956567
Je vois de l'avenir à ce procédé. Espérons que ce soit un jour possible de faire ça sur Android/IOS surtout pour les apps payantes afin d'éviter les déceptions.
Le #1956578
Safirion a écrit :

"Microsoft souhaite retrouver les faveurs des développeurs" depuis quand il les a perdu ?
Le C# est de loin l'un des langages les plus agréable et les plus complet que je connaisse. Surtout en terme de gestion de l'asynchrone.


Chaque langage possède ses points forts et ses lacunes. Faut juste savoir lequel prendre suivant le besoin. Dans ma jeunesse, c'était déjà une règle : On avait le Fortran pour le calcul et le Cobol pour la gestion Sur ce :

PERFORM ULYSSE_VA_BOSSER.
Le #1956591
Safirion a écrit :

"Microsoft souhaite retrouver les faveurs des développeurs" depuis quand il les a perdu ?
Le C# est de loin l'un des langages les plus agréable et les plus complet que je connaisse. Surtout en terme de gestion de l'asynchrone.


Le C# répond à certains besoins et pas à d'autres.

Personnellement il ne répond pas à mes attentes. Tu parles de "l'asynchrone" et sur ce plan ce n'est franchement pas un modèle de rigueur en particulier pour tout ce qui est process temps réel, il y a des problèmes avec le C#.

Par exemple, quand tu alloues un gros tableau en C#, tu ne sais pas si tu l'alloues sur la pile ou sur le tas. Or, si tu l'alloues sur le tas, c'est l'OS qui fait un appel caché à malloc dont on ne peut pas majorer le temps d'exécution (c'est l'OS qui te donnera une adresse quand il aura trouvé le temps de le faire). Donc ton compilo ne peut pas majorer le temps d'allocation comme s'il le faisait en statique (là c'est estimable à l'avance).

Conclusion il ne peut pas te garantir qu'il n'y aura pas de phénomène de dérive temporelle (c'est à toi de jouer avec l'horloge système si tu veux l'éviter).

Si tu veux faire de l'asynchrone sur des process temps réel, il faudra faire de l'Ada et le coupler éventiuellement à Spark: http://perso.telecom-paristech.fr/~pautet/sar/fset/supports/LangageAdaTempsReel.pdf

De même si tu fais du calcul scientifique, tu peux abandonner C#, si tu as des exigences fortes au niveau typage (pour éviter certains bugs sournois liés au castnig faits par le compilo), tu peux abandonner C#, si tu veux utiliser des clauses de représentation mémoire (décrire une structure donnée bit à bit à haut niveau pour programmer un driver par exemple), tu peux encore abandonner C#, et j'en passe.

La force de C# n'est pas le langage en lui-même (qui est mal foutu à plein de niveaux par rapport à d'autres langages compilés) mais sa force c'est l'ensemble du SDK qui est très utilisé dans des domaines assez généralistes.

Ce n'est pas parce que beaucoup de monde pratique un langage que ce langage est super ou qu'il s'adapte à tout. Ce n'est pas parce que beaucoup de monde regarde Hanouna, que son émission est super ou qu'elle convient à tout le monde.
Le #1956594

Il s'agit véritablement d'une bonne idée qui devrait
permettre de tester une foule d'application sans
encombrer son système tout en sélectionnant
uniquement les applications véritablement utiles
en fonction de chaque utilisateur.



C'est vraiment très intéressant cette option.
Moi qui doit regarder les applications du store afin d'essayer de déterminer quelle application est vraiment intéressante, ça m'éviterait de mettre le souk dans ma machine et devoir remettre une image ensuite.
Le #1956605
dotto a écrit :

Safirion a écrit :

"Microsoft souhaite retrouver les faveurs des développeurs" depuis quand il les a perdu ?
Le C# est de loin l'un des langages les plus agréable et les plus complet que je connaisse. Surtout en terme de gestion de l'asynchrone.


Le C# répond à certains besoins et pas à d'autres.

Personnellement il ne répond pas à mes attentes. Tu parles de "l'asynchrone" et sur ce plan ce n'est franchement pas un modèle de rigueur en particulier pour tout ce qui est process temps réel, il y a des problèmes avec le C#.

Par exemple, quand tu alloues un gros tableau en C#, tu ne sais pas si tu l'alloues sur la pile ou sur le tas. Or, si tu l'alloues sur le tas, c'est l'OS qui fait un appel caché à malloc dont on ne peut pas majorer le temps d'exécution (c'est l'OS qui te donnera une adresse quand il aura trouvé le temps de le faire). Donc ton compilo ne peut pas majorer le temps d'allocation comme s'il le faisait en statique (là c'est estimable à l'avance).

Conclusion il ne peut pas te garantir qu'il n'y aura pas de phénomène de dérive temporelle (c'est à toi de jouer avec l'horloge système si tu veux l'éviter).

Si tu veux faire de l'asynchrone sur des process temps réel, il faudra faire de l'Ada et le coupler éventiuellement à Spark: http://perso.telecom-paristech.fr/~pautet/sar/fset/supports/LangageAdaTempsReel.pdf

De même si tu fais du calcul scientifique, tu peux abandonner C#, si tu as des exigences fortes au niveau typage (pour éviter certains bugs sournois liés au castnig faits par le compilo), tu peux abandonner C#, si tu veux utiliser des clauses de représentation mémoire (décrire une structure donnée bit à bit à haut niveau pour programmer un driver par exemple), tu peux encore abandonner C#, et j'en passe.

La force de C# n'est pas le langage en lui-même (qui est mal foutu à plein de niveaux par rapport à d'autres langages compilés) mais sa force c'est l'ensemble du SDK qui est très utilisé dans des domaines assez généralistes.

Ce n'est pas parce que beaucoup de monde pratique un langage que ce langage est super ou qu'il s'adapte à tout. Ce n'est pas parce que beaucoup de monde regarde Hanouna, que son émission est super ou qu'elle convient à tout le monde.


Certes aucun langage n'est parfait, je dis juste qu'il est agréable à utiliser, que de nombreux développeurs en sont satisfait et dire que Microsoft doit reconquérir les devs, c'est un peu exagéré. C'est tout

Pas de guerre please
Le #1956607
Safirion a écrit :

dotto a écrit :

Safirion a écrit :

"Microsoft souhaite retrouver les faveurs des développeurs" depuis quand il les a perdu ?
Le C# est de loin l'un des langages les plus agréable et les plus complet que je connaisse. Surtout en terme de gestion de l'asynchrone.


Le C# répond à certains besoins et pas à d'autres.

Personnellement il ne répond pas à mes attentes. Tu parles de "l'asynchrone" et sur ce plan ce n'est franchement pas un modèle de rigueur en particulier pour tout ce qui est process temps réel, il y a des problèmes avec le C#.

Par exemple, quand tu alloues un gros tableau en C#, tu ne sais pas si tu l'alloues sur la pile ou sur le tas. Or, si tu l'alloues sur le tas, c'est l'OS qui fait un appel caché à malloc dont on ne peut pas majorer le temps d'exécution (c'est l'OS qui te donnera une adresse quand il aura trouvé le temps de le faire). Donc ton compilo ne peut pas majorer le temps d'allocation comme s'il le faisait en statique (là c'est estimable à l'avance).

Conclusion il ne peut pas te garantir qu'il n'y aura pas de phénomène de dérive temporelle (c'est à toi de jouer avec l'horloge système si tu veux l'éviter).

Si tu veux faire de l'asynchrone sur des process temps réel, il faudra faire de l'Ada et le coupler éventiuellement à Spark: http://perso.telecom-paristech.fr/~pautet/sar/fset/supports/LangageAdaTempsReel.pdf

De même si tu fais du calcul scientifique, tu peux abandonner C#, si tu as des exigences fortes au niveau typage (pour éviter certains bugs sournois liés au castnig faits par le compilo), tu peux abandonner C#, si tu veux utiliser des clauses de représentation mémoire (décrire une structure donnée bit à bit à haut niveau pour programmer un driver par exemple), tu peux encore abandonner C#, et j'en passe.

La force de C# n'est pas le langage en lui-même (qui est mal foutu à plein de niveaux par rapport à d'autres langages compilés) mais sa force c'est l'ensemble du SDK qui est très utilisé dans des domaines assez généralistes.

Ce n'est pas parce que beaucoup de monde pratique un langage que ce langage est super ou qu'il s'adapte à tout. Ce n'est pas parce que beaucoup de monde regarde Hanouna, que son émission est super ou qu'elle convient à tout le monde.


Certes aucun langage n'est parfait, je dis juste qu'il est agréable à utiliser, que de nombreux développeurs en sont satisfait et dire que Microsoft doit reconquérir les devs, c'est un peu exagéré. C'est tout

Pas de guerre please


Attends ... monsieur fait un hors-sujet pour dire que ce qu'il utilise est ce qu'il y a de mieux ... c'est parti pour 10 pages ...

Adresse Web :
https://postimg.org/image/artc3tge1/


Le #1956609
FRANCKYIV a écrit :

Safirion a écrit :

dotto a écrit :

Safirion a écrit :

"Microsoft souhaite retrouver les faveurs des développeurs" depuis quand il les a perdu ?
Le C# est de loin l'un des langages les plus agréable et les plus complet que je connaisse. Surtout en terme de gestion de l'asynchrone.


Le C# répond à certains besoins et pas à d'autres.

Personnellement il ne répond pas à mes attentes. Tu parles de "l'asynchrone" et sur ce plan ce n'est franchement pas un modèle de rigueur en particulier pour tout ce qui est process temps réel, il y a des problèmes avec le C#.

Par exemple, quand tu alloues un gros tableau en C#, tu ne sais pas si tu l'alloues sur la pile ou sur le tas. Or, si tu l'alloues sur le tas, c'est l'OS qui fait un appel caché à malloc dont on ne peut pas majorer le temps d'exécution (c'est l'OS qui te donnera une adresse quand il aura trouvé le temps de le faire). Donc ton compilo ne peut pas majorer le temps d'allocation comme s'il le faisait en statique (là c'est estimable à l'avance).

Conclusion il ne peut pas te garantir qu'il n'y aura pas de phénomène de dérive temporelle (c'est à toi de jouer avec l'horloge système si tu veux l'éviter).

Si tu veux faire de l'asynchrone sur des process temps réel, il faudra faire de l'Ada et le coupler éventiuellement à Spark: http://perso.telecom-paristech.fr/~pautet/sar/fset/supports/LangageAdaTempsReel.pdf

De même si tu fais du calcul scientifique, tu peux abandonner C#, si tu as des exigences fortes au niveau typage (pour éviter certains bugs sournois liés au castnig faits par le compilo), tu peux abandonner C#, si tu veux utiliser des clauses de représentation mémoire (décrire une structure donnée bit à bit à haut niveau pour programmer un driver par exemple), tu peux encore abandonner C#, et j'en passe.

La force de C# n'est pas le langage en lui-même (qui est mal foutu à plein de niveaux par rapport à d'autres langages compilés) mais sa force c'est l'ensemble du SDK qui est très utilisé dans des domaines assez généralistes.

Ce n'est pas parce que beaucoup de monde pratique un langage que ce langage est super ou qu'il s'adapte à tout. Ce n'est pas parce que beaucoup de monde regarde Hanouna, que son émission est super ou qu'elle convient à tout le monde.


Certes aucun langage n'est parfait, je dis juste qu'il est agréable à utiliser, que de nombreux développeurs en sont satisfait et dire que Microsoft doit reconquérir les devs, c'est un peu exagéré. C'est tout

Pas de guerre please


Attends ... monsieur fait un hors-sujet pour dire que ce qu'il utilise est ce qu'il y a de mieux ... c'est parti pour 10 pages ...

Adresse Web :
https://postimg.org/image/artc3tge1/




Non, j'explique comme Ulysse qu'un langage n'est pas meilleur qu'un autre même s'il est beaucoup utilisé. Un langage sert à résoudre un problème et chaque problème oriente le langage à choisir si on est ouvert et cultivé.

Safirion dit que C# c'est super pour l'asynchrone et je dis que ce n'est pas le langage que je choisirais si je devais gérer de l'asynchrone pour des raisons informatiques concrètes que je décris précisément.

Si parler de programmation ou de développement ne t'intéresse pas, tu n'as qu'à passer la lecture des commentaires.

Tu es franchement lourd. Est-ce que je te prends la tête avec tes "tests" de logiciels moi ? Donc fous moi la paix et continue à "tester".

PS à Safirion

En C# tu n'as pas non plus de type modulaire (type modulo un entier naturel non nul), tu n'as pas non plus de notion de sous type, tu ne peux pas non plus indexer un tableau sur un type modulaire etc.
C'est un langage très utilisé mais les raisons pour lesquelles il est très utilisé ne viennent pas de ses qualités propres (plutôt de son écosystème).
Le #1956610
dotto a écrit :

FRANCKYIV a écrit :

Safirion a écrit :

dotto a écrit :

Safirion a écrit :

"Microsoft souhaite retrouver les faveurs des développeurs" depuis quand il les a perdu ?
Le C# est de loin l'un des langages les plus agréable et les plus complet que je connaisse. Surtout en terme de gestion de l'asynchrone.


Le C# répond à certains besoins et pas à d'autres.

Personnellement il ne répond pas à mes attentes. Tu parles de "l'asynchrone" et sur ce plan ce n'est franchement pas un modèle de rigueur en particulier pour tout ce qui est process temps réel, il y a des problèmes avec le C#.

Par exemple, quand tu alloues un gros tableau en C#, tu ne sais pas si tu l'alloues sur la pile ou sur le tas. Or, si tu l'alloues sur le tas, c'est l'OS qui fait un appel caché à malloc dont on ne peut pas majorer le temps d'exécution (c'est l'OS qui te donnera une adresse quand il aura trouvé le temps de le faire). Donc ton compilo ne peut pas majorer le temps d'allocation comme s'il le faisait en statique (là c'est estimable à l'avance).

Conclusion il ne peut pas te garantir qu'il n'y aura pas de phénomène de dérive temporelle (c'est à toi de jouer avec l'horloge système si tu veux l'éviter).

Si tu veux faire de l'asynchrone sur des process temps réel, il faudra faire de l'Ada et le coupler éventiuellement à Spark: http://perso.telecom-paristech.fr/~pautet/sar/fset/supports/LangageAdaTempsReel.pdf

De même si tu fais du calcul scientifique, tu peux abandonner C#, si tu as des exigences fortes au niveau typage (pour éviter certains bugs sournois liés au castnig faits par le compilo), tu peux abandonner C#, si tu veux utiliser des clauses de représentation mémoire (décrire une structure donnée bit à bit à haut niveau pour programmer un driver par exemple), tu peux encore abandonner C#, et j'en passe.

La force de C# n'est pas le langage en lui-même (qui est mal foutu à plein de niveaux par rapport à d'autres langages compilés) mais sa force c'est l'ensemble du SDK qui est très utilisé dans des domaines assez généralistes.

Ce n'est pas parce que beaucoup de monde pratique un langage que ce langage est super ou qu'il s'adapte à tout. Ce n'est pas parce que beaucoup de monde regarde Hanouna, que son émission est super ou qu'elle convient à tout le monde.


Certes aucun langage n'est parfait, je dis juste qu'il est agréable à utiliser, que de nombreux développeurs en sont satisfait et dire que Microsoft doit reconquérir les devs, c'est un peu exagéré. C'est tout

Pas de guerre please


Attends ... monsieur fait un hors-sujet pour dire que ce qu'il utilise est ce qu'il y a de mieux ... c'est parti pour 10 pages ...

Adresse Web :
https://postimg.org/image/artc3tge1/




Non, j'explique comme Ulysse qu'un langage n'est pas meilleur qu'un autre même s'il est beaucoup utilisé. Un langage sert à résoudre un problème et chaque problème oriente le langage à choisir si on est ouvert et cultivé.

Safirion dit que C# c'est super pour l'asynchrone et je dis que ce n'est pas le langage que je choisirais si je devais gérer de l'asynchrone pour des raisons informatiques concrètes que je décris précisément.

Si parler de programmation ou de développement ne t'intéresse pas, tu n'as qu'à passer la lecture des commentaires.

Tu es franchement lourd. Est-ce que je te prends la tête avec tes "tests" de logiciels moi ? Donc fous moi la paix et continue à "tester".


Excuse moi de réagir à la news et non aux commentaires sans même avoir lu celle-ci ...
Le #1956613
Fais ce que tu veux. Moi j'ai le droit de réagir à une discussion en cours (qui n'a pas été entamée par moi). Fous moi la paix et fais tes tests (ça nous intéresse à fond). Y a pas une fonction pour m'ignorer ? Surtout ne t'en prive pas.
Suivre les commentaires
Poster un commentaire
Anonyme
:) ;) :D ^^ 8) :| :lol: :p :-/ :o :w00t: :roll: :( :cry: :facepalm:
:andy: :annoyed: :bandit: :alien: :ninja: :agent: :doh: :@ :sick: :kiss: :love: :sleep: :whistle: =]