groumly a écrit 3296 commentaires

tu confirmes là qu'il faut un appli specifique, qui gere les deux resoltuions

Non. C'est gere par l'os, les applis ios sont un seul binaire, ya aucune difference dans le code.
La resolution quand a elle est unique: 320x480 points. Point. Pas pixels.
Quand c'est rendu sur du retina, chaque point est affiche sur 4 pixels. L'iphone 4 n'offre strictement aucune surface supplementaire.
Le caractere A en helvetica neue regular, 15 points, fait strictement la meme taille physique (en centimetres) sur un iphone 4 et un 3gs. Mais l'iphone 4 a 4 fois plus de pixels pour l'afficher. Ce qui fait que l'aliasing est imperceptible et le caractere apparait presque aussi precis que s'il etait imprime sur du papier.

ca cree des pixels intermediaires et donc du flou

Non. Aucun pixel n'est cree. Il n'ya aucun scaling.
Une image 50x50 affichee sur 50x50 pixels physiques a 160 dpi et la meme image sur 100x100 px physiques a 320 dpi ont exactement la meme apparence et font exactement la meme taille physique.
Parce que chaque pixel a 160dpi est parfaitement et identiquement reproduit par 4 pixels a 320dpi.
Dit autrement, 2x2 pixels a 320 dpi font strictement la meme taille physiqueet sont indifferenciable de 1x1 pixel a 160 dpi.
C'est la definition du dpi.

Encore dit autrement: prend un mbp retina et pas retina, cote a cote.
Affiche sur chacun une photo de 1440xwhatever. Prend une photo de chaque avec un argentique. Met les photos cote a cote, tu serais incapable de dire lequel est le lequel.
Fait les afficher une photo 2880xwhatever, tu vas pouvoir dire immediatement lequel est lequel.
Fait leur afficher le meme temps texte en helvetica neue 15, tu vas pouvor dire immediatement lequel est lequel.

Derniere tentative: prend une feuille de papier et dessines un grille 4x4 de 10cm de cote. Remplit les carres dans la diagonale.
Fait pareil avec 2 grille 8x8 de 10 cm de cote.
Sur la premiere, pour chaque carre de la 8x8, remplit 4 carre dans la 8x8: ta ligne est strictement la meme (aliasee a mort). C'est le cas des images non retina sur un ecran retina.
Sur la deuxieme, remplit la diagonale sur un carre de large. C'est le cas du texte sur un ecran retina, ou d'un asset retina sur un ecran retina.
Met les 3 cote a cote.

Je vais arreter la parce que je sais pas comment expliquer autrement.

mais si tu te tiens à 40cm de l'ecran, je ne suis pas sur que tu vois la difference entre les deux images si elles sont à remise à taille reelle.

Les deux sont a taille reelle. C'est precisement pour ca que la photo au dessus a ete prise avec un appareil photo et pas un simple screenshot, pour montrer la difference a taille reelle: les deux photos font strictement la meme taille physique, en centimetres.
Et contrairement a toi, je suis sur que tu vois la difference a 40cm de l'ecran parce que j'ai 2 ipads sous les yeux, affichant exactement le meme texte, et l'ipad1 parait flou par rapport au 4. Si tu me crois pas, va dans un apple store et met un ipad 2 a cote d'un ipad retina.

Ben voyons. Doit etre pour ca que la nexus 10 est sorti a 300 dpi.
Pis avoir du texte precis et pas aliase, ca sert a rien, c'est bien connu!

Non, pas du tout, en tout cas pas sur ios.
T'as pas d'etirement, le concept du retina c'est que tu quadruple le nombre de pixels (x2 dans chaque dimension) et que t'utilises les pixels en plus pour augmenter la finesse d'affichage plutot que pour faire de la place physique. Une fonte 15 point fera strictement la meme taille sur les 2 ecrans, juste que celle sur l'ecran retina sera achement plus precise. Un iphone 4 offre 320x480 points, tout comme un 3gs.

J'ai pas verifie le chrome machin, mais je suppute qu'ils font pareil que les mbp retina, ton desktop de base fait 1440 points et que les pixels en plus sont utilises pour ameliore la finesse.
Si les assets son qualite retina, chaque point est rendu sur un pixel, sinon un point = 2x2 pixels.

En clair, une image de 50x50 px affichee sur100x100 pixels physique a 320 dpi a exactement la meme apparence que la meme image affichee sur 50x50 px physiques a 160dpi.
Quand le reste autour est affiche a 320 dpi, ca saute mechamment aux yeux.

Ensuite, sur ios (puisqu'on y est), le concept c'est que tu fournis chaque image en double. Une normale (50x50 pour reprendre l'exemple ci dessus), et une doublee (100x100) avec le meme nom se terminant par @2x.
Ta vue est elle definie comme faisant 50x50 points, et aura exactement la meme taille physique sur les deux.
L'os fera rentrer la 100x100 dans les 100x100 pixels physiques sur un ecran retina, ce qui te donne une image vachement plus precise.

La difference est flagrante.
Quand je repasse sur l'ipad 1/2 pour tester mes applis sur des os/hard plus anciens, j'ai l'impression d'etre mal reveille et de voir trouble, c'est assez impressionant.
Ca choque moins sur un 3gs qui a un dpi un peu plus decent.

Dans le meme style, les agences de pub qui servent des pubs non retina, ca saute violemment aux yeux: ca parait tout flou. C'est tres flagrant sur le mbp retina aussi: le texte est super precis, et les images paraissent floues.

Un developeur talentueux qui connait bien cocoa peux te faire des merveilles extremement vite. Ca parait etonnant, mais cocoa permet justement de faire du prototypage tres rapidement.

La truc c'est qu'il faut quelqu'un de doue. En gros, bras casse cocoa contre bras casse js, le js sera ecrit plus rapidement, avec moins de bug et probablement ue meilleur UX globalement.

Dev talenteux cocoa contre dev talenteux js, je suis pas sur de parier sur le js, que ce soit au niveau de la performance/robustesse/maintenance que de la vitesse de development.

Des trucs tout cons, mes collegues bossant sur le site mobile en chient avec le flyweight pattern la et galerent a pas exploser la ram utilisee, la ou je te pond un truc identique en 10 minutes tout en bavassant a cote.
Merci le support de l'ide, ma base de code accumulee au fil des 2 dernieres annees et surtout, surtout, le fait que cocoa offre une reelle separation controlleur/vue/look avec une architecture en beton arme.

Le monde mobile est different. Personne ne veut utiliser une appli ios qui utilise le theme de base, toutes les applis revisitent au grand mininum les couleurs du chrome et se fadent des boutons textures d'une maniere ou d'une autre. Meme apple a laisse tombe le look de base sorti de mail et calendar.

A l'inverse, la mode des skins a la mord moi le zgeg sur le desktop est morte ya qq annees et tout le monde standardise plus ou moins sur le look de la plateforme.

Mon petit doigt me dit que la raison pour ca, c'est que les applis telephones/tablettes sont plein ecrans, toute seule a s'afficher, ce qui rend acceptable a l'oeil cette customization. Et on profite du coup des avantages de la customization - les applis sont tres differentiable, meme en regardant vaguement de loin.
Sur un deskopt, ca ressemble a une guirlande de noel.

Tout le prix passe clairement dans l'écran dont l'utilité est (très) discutable.

Toi, t'as jamais utilise du retina, que ca soit un iTruc, un andromachin ou un macbook pro retina.
En gros il suffit de qq heures d'utilisation pour s'habituer a la precision d'affichage et se mettre a hair tout les ecrans qui ne sont pas dans les 300dpi.

Alors que c'est bien connu qu'apple ne contribue en rien au libre, webkit, clang, libdispatch et j'en passe, ils se sont ecrit tout seuls…
Quand a google, tous les telephones android sont bien evidemment completement ouvert et pas verouille pour un sou.

Nan mais tu lit les conneries que t'ecris des fois?
T'as un probleme avec les drm, tres bien, c'est ton droit, mais venir expliquer qu'apple est achement pire que google la dessus, ca va quoi!!!

Ouais, alors l'ecran tactile, ca va te faire marrer 2 minutes, apres t'auras mal au bras a force de le tenir en hauteur, ou tout simplement t'en auras ras le cul de devoir faire de grand mouvements de bras et tu t'en serviras plus. Je passe sous silence les traces de doigts sur l'ecran. Les tablettes et telephones ont le bon gout de se nettoyer tout seuls quand on les met dans la poche ou ferme la cover. Et c'est un peu plus simple de frotter son telephone contre son t shirt que de devoir chopper un chiffon et frotter un ecran de 13".

Et j'aborde meme pas la probleme d'interface concues pour la souris inutilisable en tactile (ceux qui ont tente le mode desktop sur une surface me comprendront), ou du cote enervant d'une interface tactile utilisee a la souris (ceux qui ont passe un peu de temps sur un simulateur android/ios me comprendront aussi).

Tu veux du tactile, prend toi une tablette.

Entre une application Web et une application native, la plus lourde est bien souvent la première.

Quelle est la definition du poids pour une application? Le terme lourd/leger fait ici reference aux terminaux lourd/legers…

Parlons donc simplement d'applications Web et d'applications natives, termes qui ont l'avantage d'être exacts et univoques.

Ca se discute, vu la montee en puissance du js cote client pur, du fait que le js est maintenant compile JIT, comme du Java ou du c#, et encore plus avec le fait que ces applis n'ont pas forcement grand chose avec le web, hein monsieur web != internet.

où les logiciels natifs reviennent à la mode, y compris pour des usages pour lesquels ils sont hautement inappropriés, par exemple la lecture de contenus textuels.

En vertu de quel principe?
Ensuite, comment est ce qu'une appli comme instapaper, ou un ereader quelconque, dont l'essence meme est de lire du texte fonctionnerait sur le web? Juste par curiosite, hein…
Ou, toujours par curiosite, comment tu fait un layout complexe, genre du vrai multi colonnes, sur le "web" sans t'arracher les cheveux?

Maintenant, dans les dessin, il y a le gentil gentil contre le méchant méchant, et quand les enfants découvrent la réalité, ça fait mal.

Clair que mickey, babar et candy, ca envoyait du lourd niveau ecole de la vie, les gosses sortaient blindes du club dorothee , maintenant, c'est pu pareil, tous des tapettes ces momes.

Nan mais serieux, tu lis ce que t'ecris des fois?

Tu saoules avec ton hyper rationalisation.

Si tu vois pas la difference les copains qui disent qui pensent qu'ils savent comment on fait les bebes et un pti de 2 ans qui tmbe nez a nez avec russian institute 7 ou ouvres la fenetre que j'te mette 24, la scene de la faciale, evidemment, je sais pas quoi te dire.

Ouais, ya des trucs relou quand meme, notamment dur de trouver les properties/messages definies sur les super class.
Leur hierarchie est tres peu profonde, donc en pratique, ca va, mais quand tu cherches un truc un peu exotique sur nsresponder, ca peut devenir relou.

On trouve aussi quelques bijoux d'apple speak dedans, a base de "nscache peut ejecter des objets, ou pas, et chercher pas a savoir lesquels (ou pas)".

Les proramming guides notamment sont particulierement bien foutus, et ils ont pas mal de docs approfondies plutot poussees. Bref, ya de tout pour tout le monde, et c'est plutot bien organise.
Niveau qualite d'api, la par contre, ca poutre tout, objc est d'une elegance extreme pour tout ce qui est UI et NextStep avait tellement bien pense le bouzin que les autres sont encore loin derriere - mais on va me traiter de fan boy encore une fois.

Nan, mais vous pouvez aller vous rhabiller avec vos docs:
http://developer.apple.com/library/ios/ipad/#DOCUMENTATION/UIKit/Reference/UIButton_Class/UIButton/UIButton.html

J'en sais rien, tu peux demander a tim cook.

Bon. Tu trolles tout ce que tu veux, tout ce que je vois c'est que t'es pas foutu de me sortir l'article qui dit que c'est interdit. Ca devrait etre facile pourtant, non?
Si la regle est si explicite que ca.

Jusqu'à nouvel avis, les guidelines c'est tout ce qu'on a et si ils les donnent, c'est bien qu'ils se basent dessus.

Mais tu fumes quoi serieux? ce qu'on a, c'est le developer agreement, tres clair et detaille…

Ben d'un autre cote, le contrat est accessible en 5 minutes, suffit de s'enregistrer, c'est gratuit et immediat.
Mais pour faire ca, faut avoir envie d'admettre qu'apple n'interdit pas autre chose que WebKit, ce qui n'est visiblement pas le cas ici.

Arrete de raconter des conneries, j'arreterais de te dire de te taire.

Ta page de guidelines dit explicitement: "Ce document n'a rien de contractuel, ceci n'est pas la list officielle des regles, juste des conseils qui aident a se faire valider. Referez vous au contrat pour avoir les règles".
Et oui, ne pas implementer un moteur de rendu complet aide a se faire valider.

Je ne peux pas te citer de passage du contrat parce que le contrat ne dit pas "tu peux pas utiliser autre chose que WebKit", ce qui est precisement le sujet de la discussion. Et c'est pourquoi je demande, en vain, d'avoir la partie qui interdit d'utiliser autre chose que webkit. J'ai cherche, j'ai pas trouve, et visiblement personne d'autre n'a trouve vu qu'il aurait suffit de me citer l'article pour me clouer le bec.

Y'a même John Gruber qui explique que Apple ne laisse pas d'autres apps accéder au runtime javascript qui fait du JIT et que c'est une raison pour laquelle les autres browser iOS (chrome inclus) sont plus lents que Safari.

Oui, comme j'ai dit plus haut: iOS n'autorise pas des pages executables en ecriture. Ca empeche de fait d'implementer un JIT. Et c'est valable aussi pour les applis d'apple, c'est une limitation volontaire de la UIWebView.
Maintenant, je vois pas ce que ca a faire avec une interdiction d'utiliser autre chose que webkit, tout ce que ca dit, c'est que personne n'a acces a Nitro a moins de s'appeler Safari Mobile. Ca empeche pas de porter Gecko pour iOS et de l'utiliser pour Firefox Mobile.

Et entre nous, meme si je lit Gruber tout les jorus et que j'apprecie une bonne partie de ses commentaires, sur un point de vue technique, il est completement largue et ne comprends pas grand chose.

Alors maintenant, soit tu sors des faits qui contredisent ce que je dis, soit tu arrête de te cacher derrière ta "connaissance de l'app store" et un contrat qui ne dit probablement rien d'autre que Apple se réserve le droit de refuser une application qui ne respecte pas les guidelines.

Oh! tu vas te detendre la. Celui qui doit appuyer ses faits, c'est toi, tu pretends qu'Apple interdit explictement qq chose, montre moi la regle explicite. T'es pas foutu de le faire parce que cette regle n'existe pas.
Commence par lire le contrat, il est au contraire tres prolixe, il fait 50 pages. Il ne dit pas "probablement" rien, il est au contraire plutot precis. Mais pour savoir ca, faut prendre la peine de se renseigner, plutot que de colporter des mensonges.

Probablement parce que j'ai une obligation contractuelle de pas le distribuer.
Par contre, il est vraiment pas dur a trouver si tu te donnes la peine d'utiliser un email jetable.

Bon, ecoutes, c'est simple.

Tu t'enregistres chez apple, lit le contrat et reviens ici.
Tu peux citer toutes les pages que tu veux, chez apple et ailleurs, on s'en fout copieux, elles sont pas contractuelles, seul l'ios porgram agreement l'est.

Partant de la tu vas lire ce putain de contrat, ou tu las fermes.

Si t'avais de l'experience sur le store, tu saurais ce que tu peux ou pas faire, et t'aurais lu au mons en partie le developer agreement, plutot que de colporter des on dit mensongers.

Au hasard, le fait que tout doit utiliser les APIs d'Apple, ne pas embarquer de libs réutilsables et être ecrit en objective C.

Je vais me repeter, mais bon:
- j'utilise un paquet des libs, cocoapods devient meme plutot poplaire ces jours ci
- je me demande ce que font ces qq millers de lignes de code c/c++ dans mon projet actuel si tout doit etre ecrit en objc. A se demander pourquoi apple a cree l'objc++ d'ailleurs.

Alors je vais reiterer: pointe moi la clause du contrat exigeant ca. Ou ferme la une bonne fois pour toute.

Parce que c'est evidemment super simple a integrer a tous les workflows, et aucun developeur n'a jamais fait la moindre erreur ni ecrit le moindre bug, c'est bien connu!
C'est sur que si tu fait un site web a la papa, statique comme en 99, c'est plus facile, si tu commences a toucher au dom ou prendre du contenu utilisateurs ou qui voent d'ailleurs, ca devient plus tordu.

Le contrat, tu t'enregistres sur developer.apple.com et tu l'as. Je te filerais bien un lien, mais tu vas arriver sur une page de login.

Ensuite, j'aimerais bien savoir quelle experience tu as avec l'appstore, autre que les on dit de linuxfr.
Des pleureuses qui respectent pas les regles, yen a, des blaireaux qui cherchent leur minute de gloire sur internet et font du rafu, yen a aussi.
Des rejections fermes illegitimes, ca devient plutot rare, meme si c'etait un peu plus courant au debut. Ca fait 2 ans que je fais ca professionellement, 3 ans en tout, j'ai des dizaines d'updates dans les pattes, qq applis toutes neuves aussi, les rares rejections ont toujours ete argumentees et valides.

Et elles sont toujours basees sur le developer program agreeemnt, pas un document qui dit en premier lieu qu'il est pas contractuel et n'a aucune valeur.

Hello couillon!

Tistan nitot raconte parfois aussi des betises! Et je me fout de savoir ce que machin dit.
Bill gates a dit des choses aussi sur linux, et il etait ceo de msft usa, pas un gus dans un garage!

Je vais reiterer ma question un derniere fois.
Quelle clause du programm agreement interdit ca?
Pointes moi vers la regles de l'iOS program agreeement qui interdit de faire ca.
Tu peux t'enregistrer, c'est gratuit, t'as pas besoin de payer. Lit le contrat, montre moi la clause.

Malgré cela, Apple a trainé les pieds pour valider l'application a tel point qu'Opera a fait une page spéciale avec un compteur de jours depuis la demande de validation.

Booouuh! 3 semaines pour approuver un browser! Oh mon dieu! C'est un scandale!

Ben il permet de browser le web, donc il fait un rendu d'une facon ou d'une autre, et il utilise pas webkit, donc bon.