Oui, effectivement, ca parle de gui, c'est un peu 80% d'une appli mobile.
Ça serait bien de préciser de quoi tu parles ... Le reste de ton commentaire est précis, sauf ce morceau, c'est étrange. Enfin apparemment tu parles de GUI, que je ne connais pas du tout, donc bon.
Ca va etre dur d'etre plus precis commencer a regarder du code.
En gros, android anime des properties, specifiees par du texte, place entre 2 appels.
En gros:
View.setDuration(5);// static
View.beginAnimation()
View.animate(maView, "origin", 100, 100);
View.endAnimation()
Thread.sleep(5)
System.out.println("a y est!"); // devrait etre fait avec un timer, mais t'as l'idee
La version iOS4+
La syntxe des blocks est assez vilaine, un typedef dessus est assez indispensable.
void(^block)(void) = ^{
view.frame.origin = CGPointMake(100, 100);
}
void(^completion)(void) = ^{
NSLog(@"a y est!");
}:
[UIView animateWithDuration: 5 animation: block completion: completion];
// ou une variante avec un delai ou autre.
Je pense que l'exemple parle de soi.
En commence a faire des animations qui s'enchainent les unes aux autres. Tu vas vite comprendre ta douleur.
Même si on l'a attendu TRÈS longtemps, il y a bien un système de push dans Android: C2DM. Sauf que là encore, les devs préfèrent en général utiliser leur propre solution, ce qui explose effectivement la batterie, et ceux qui utilisent C2DM ne savent pas l'utiliser correctement, mais c'est une autre histoire.
Et dispo uniquement sur 2.2+, c'est pour ca que tout le monde se fade tout a la main.
Sinon, c'est sorti du google labs c2dm? La derniere fois que j'ai verifie, c'etait assez experimental quand meme.
Sous android, la conception même du système fait que ça marche comme ça: le GC supprime les activités en arrière plan si y a besoin de RAM.
Comment tu notifies les applis que ca commence a etre chaud, la memoire?
Comment est ce que les vues non affichees, mais toujours en ram, sont droppees quand tu commences a etre profond dans ta navigation?
Comment est ce que tu les recrees quand tu reviens sur ces controlleurs?
Sur ios, c'est simple.
didReceiveMemoryWarning, tu droppes les donnees qui peuvent etre recrees par ton controlleur.
viewDidUnload, tu droppes TOUTES tes vues, tu gardes les donnees.
viewDidLoad, tu recreees tes vues et tu les remets dans l'etat ou elles doivent etre (scroll offset etc ou autre).
Là par contre, je n'ai aucun doute, c'est uniquement de la faute des développeurs (d'applis externes principalement, mais pas que) qui font n'importe quoi, à foutre des wakelocks ou des alarmes à tour de bras, alors que ça ne sert à rien. Après, c'est probablement lié à un manque de dissuasion un peu partout dans la doc.
Ca change pas grand chose au probleme, dans un cas, ca rame, dans l'autre pas.
mais vu d'ici je vois pas trop l'interêt des closures
Tu vois pas l'interet des closures dans un environnement asynchrones ou tu passes ton temps a repondre a des evenements "plus tard"?
Genre comment tu geres une connexion http asynchrones? Et quand t'as 10 connexions qui partent en meme temps, genre galleries photos?
Une classe anonymes?
Et la reponse a un touch sur un bouton? Encore classe anonyme?
E les gestures? Encore des classes anonymes?
Et tes blocks d'animations, encore des classes anonymes?
A ce compte la, la moitie de ton code va etre anonyme...
ARC est un GC
Certainement pas. ARC est gere au moment de la compilation, llvm se "contente" d'evaluer les portees des variables et tout le tralala pour inserer lui meme les retain/release/autorelease qui vont bien(et d'autres truc sexy au runtime, genre nilling des weaks reference), mais ya rien de Gc la dedans, ca reste le bon vieux reference counting d'obj c tel qu'il existe depuis des annees.
La plus grosse limitation c'est les cycles ou il faut penser marquer le cote child comme weak pour le casser. Cela dit, Instruments te gueulera dessus que t'as un cycle et te montrera ou il est.
peut mener à des problèmes pire qu'un GC Java (un GC Java on peut le borner en temps, ARC pas)
1) quels problemes?
2) depuis quand le gc java est predictible?
3) bien sur que si, je peux predire quand la variable sera liberee. Exactement au moment ou un appel a release fera tomber son retain count a 0.
Reste le cas des autorelease, et la encore, je peux predire: a la fin de la run loop courante, ie a la fin de la stack en cours.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bravo
Posté par pasScott pasForstall . En réponse au journal Barnes & Noble résiste à M$. Évalué à 0.
Oui, effectivement, ca parle de gui, c'est un peu 80% d'une appli mobile.
Ca va etre dur d'etre plus precis commencer a regarder du code.
En gros, android anime des properties, specifiees par du texte, place entre 2 appels.
En gros:
View.setDuration(5);// static
View.beginAnimation()
View.animate(maView, "origin", 100, 100);
View.endAnimation()
Thread.sleep(5)
System.out.println("a y est!"); // devrait etre fait avec un timer, mais t'as l'idee
La version iOS4+
La syntxe des blocks est assez vilaine, un typedef dessus est assez indispensable.
void(^block)(void) = ^{
view.frame.origin = CGPointMake(100, 100);
}
void(^completion)(void) = ^{
NSLog(@"a y est!");
}:
[UIView animateWithDuration: 5 animation: block completion: completion];
// ou une variante avec un delai ou autre.
Je pense que l'exemple parle de soi.
En commence a faire des animations qui s'enchainent les unes aux autres. Tu vas vite comprendre ta douleur.
Et dispo uniquement sur 2.2+, c'est pour ca que tout le monde se fade tout a la main.
Sinon, c'est sorti du google labs c2dm? La derniere fois que j'ai verifie, c'etait assez experimental quand meme.
Comment tu notifies les applis que ca commence a etre chaud, la memoire?
Comment est ce que les vues non affichees, mais toujours en ram, sont droppees quand tu commences a etre profond dans ta navigation?
Comment est ce que tu les recrees quand tu reviens sur ces controlleurs?
Sur ios, c'est simple.
didReceiveMemoryWarning, tu droppes les donnees qui peuvent etre recrees par ton controlleur.
viewDidUnload, tu droppes TOUTES tes vues, tu gardes les donnees.
viewDidLoad, tu recreees tes vues et tu les remets dans l'etat ou elles doivent etre (scroll offset etc ou autre).
Ca change pas grand chose au probleme, dans un cas, ca rame, dans l'autre pas.
Tu vois pas l'interet des closures dans un environnement asynchrones ou tu passes ton temps a repondre a des evenements "plus tard"?
Genre comment tu geres une connexion http asynchrones? Et quand t'as 10 connexions qui partent en meme temps, genre galleries photos?
Une classe anonymes?
Et la reponse a un touch sur un bouton? Encore classe anonyme?
E les gestures? Encore des classes anonymes?
Et tes blocks d'animations, encore des classes anonymes?
A ce compte la, la moitie de ton code va etre anonyme...
Certainement pas. ARC est gere au moment de la compilation, llvm se "contente" d'evaluer les portees des variables et tout le tralala pour inserer lui meme les retain/release/autorelease qui vont bien(et d'autres truc sexy au runtime, genre nilling des weaks reference), mais ya rien de Gc la dedans, ca reste le bon vieux reference counting d'obj c tel qu'il existe depuis des annees.
La plus grosse limitation c'est les cycles ou il faut penser marquer le cote child comme weak pour le casser. Cela dit, Instruments te gueulera dessus que t'as un cycle et te montrera ou il est.
1) quels problemes?
2) depuis quand le gc java est predictible?
3) bien sur que si, je peux predire quand la variable sera liberee. Exactement au moment ou un appel a release fera tomber son retain count a 0.
Reste le cas des autorelease, et la encore, je peux predire: a la fin de la run loop courante, ie a la fin de la stack en cours.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.