groumly a écrit 3293 commentaires

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.

T'as rate le point 1.1:

The following rules and examples are intended to assist you in gaining acceptance for your app in the App Store, not to amend or remove provisions

Je viens de verifier le vrai contrat, celui que j'ai signe, pas le blabla marketing qu'apple a sorti pour calmer les esprits ya deux ans, ils ne disent pas que tu dois utiliser webkit.

Clair que forcer le monde entier a generer du XML 100% valide sous peine de tout peter, c'etait une idee grandiose et super realiste.

Ce que j'ai critiqué c'est de se contenter de la première partie sans chercher à standardiser les choses. C'est le genre de trucs qui donne flash, silverlight, les activeX et les applets java. Je ne crois pas qu'il y ai grand monde pour dire du bien de ces techno aujourd'hui.

D'un autre cote, le w3c a gache pas loin de dix ans sur le xhtml avec le resultat grandiose qu'on lui connait. Pendant que d'autre bossaient sur des trucs qui interessaient les gens.

C'est facile de beugler contre le w3c aujourd'hui alors qu'on était bien content qu'il soit là lors de la première guerre des navigateur et après.

C'est facile aussi de dire que le w3c c'est parfait parce qu'ils ont pondu des standards ya 10 ans. Force est de constater que le w3c a merde sur le xhtml, a persiste sur le xhtml2.0 et que si c'etait pas pour le whatwg, ils y seraient encore ces cons. Et encore, va falloir attendre 2014 pour qu'ils en fassent une recommendation.

Je préfère quelque chose qui respecte un standard que quelque chose de libre.

Ben moi je prefere un truc libre qui met tout le monde d'accord qu'un truc qui respecte un standard juste pour le principe de respecter un standard.