O grupo no qual você está postando é um grupo da Usenet. As mensagens postadas neste grupo farão com que o seu e-mail fique visível para qualquer pessoa na internet.
alguém já viu em algum documento (de preferência oficial), que fale a respeito do possível crescimento de memória e/ou processamento quando é utilizado muito (mas muito mesmo) o esquema de Bindable em objetos/propriedades?
-- Atenciosamente, Pergentino Araújo. Arquiteto Java/Flex MSc. Profissional - Engenharia de Software Adobe Certified Expert - Flex 3 with AIR
dei uma olhada em um dos links, e a diferença realmente é absurda:
now launch the script and in the output I have this result
total execution time: 2381 ms
memory usage: 5924 kb
NOW. Remove the *[Bindable]* property from the RGB class and launch again
the test script. See at the output console and the new results are:
total execution time: 236 ms
memory usage: 2720 kb
Agora, o cara lá fez 100.000 operacões/instanciações... aí também é
brincadeira né !? rsrsr
Eu me preocupo mais com memória do que com processamento, pois eu sei que a
qtd na minha app não vai chegar nem a metade da metade da metade disso ae
rsrsrs.
Alguém fez um teste na prática em uma app ?
[]'s
-- Atenciosamente, Pergentino Araújo.
Arquiteto Java/Flex
MSc. Profissional - Engenharia de Software
Adobe Certified Expert - Flex 3 with AIR
2009/11/4 Gabriela Trindade Perry <gabrielape...@hotmail.com>
> yeap.
> Uma vez eu até me lembro de ter quetsionado o porqeu de tanto bindable
> pra todo lado... Até constantes são bindables, embeds são bindable....
Sinceramente... no final - e em um caso real - a diferença é tao pqna q
estou mais me preocupando com UX da app doq alguns bits de memoria, ou
milisegundos de processamento.
> dei uma olhada em um dos links, e a diferença realmente é absurda:
> now launch the script and in the output I have this result
> total execution time: 2381 ms
> memory usage: 5924 kb
> NOW. Remove the *[Bindable]* property from the RGB class and launch again
> the test script. See at the output console and the new results are:
> total execution time: 236 ms
> memory usage: 2720 kb
> Agora, o cara lá fez 100.000 operacões/instanciações... aí também é
> brincadeira né !? rsrsr
> Eu me preocupo mais com memória do que com processamento, pois eu sei que a
> qtd na minha app não vai chegar nem a metade da metade da metade disso ae
> rsrsrs.
> Alguém fez um teste na prática em uma app ?
> []'s
> --
> Atenciosamente, Pergentino Araújo.
> Arquiteto Java/Flex
> MSc. Profissional - Engenharia de Software
> Adobe Certified Expert - Flex 3 with AIR
> 2009/11/4 Gabriela Trindade Perry <gabrielape...@hotmail.com>
>> yeap.
>> Uma vez eu até me lembro de ter quetsionado o porqeu de tanto bindable
>> pra todo lado... Até constantes são bindables, embeds são bindable....
Eu não me preocupo tanto com isso, acredito que seja procurar pelo em ovo
.... Tem mais detalhes para levar em consideração do que o Binding, como por
exemplo: usar da melhor forma a RSL....
Abraços
Stefan Horochovec
Engenheiro de Software
Adobe User Group Manager - FlexDuck
Blog: http://www.horochovec.com.br/ Use Java, Flex e Linux
> Sinceramente... no final - e em um caso real - a diferença é tao pqna q
> estou mais me preocupando com UX da app doq alguns bits de memoria, ou
> milisegundos de processamento.
>> dei uma olhada em um dos links, e a diferença realmente é absurda:
>> now launch the script and in the output I have this result
>> total execution time: 2381 ms
>> memory usage: 5924 kb
>> NOW. Remove the *[Bindable]* property from the RGB class and launch again
>> the test script. See at the output console and the new results are:
>> total execution time: 236 ms
>> memory usage: 2720 kb
>> Agora, o cara lá fez 100.000 operacões/instanciações... aí também é
>> brincadeira né !? rsrsr
>> Eu me preocupo mais com memória do que com processamento, pois eu sei que
>> a qtd na minha app não vai chegar nem a metade da metade da metade disso ae
>> rsrsrs.
>> Alguém fez um teste na prática em uma app ?
>> []'s
>> --
>> Atenciosamente, Pergentino Araújo.
>> Arquiteto Java/Flex
>> MSc. Profissional - Engenharia de Software
>> Adobe Certified Expert - Flex 3 with AIR
>> 2009/11/4 Gabriela Trindade Perry <gabrielape...@hotmail.com>
>>> yeap.
>>> Uma vez eu até me lembro de ter quetsionado o porqeu de tanto bindable
>>> pra todo lado... Até constantes são bindables, embeds são bindable....
Hm... realmente o uso do Binding pode ser perigoso. O principal
problema é usar DTOs grandes e complexos que cujos dados aninhamos são
renderizados por diferentes telas. Neste caso, quando seu DTO chegar
ao Flash Player todo lugar que tiver usando Binding com esta cara vai
ser executado, ou seja, mesmo telas ocultas que renderizam um trecho
do seu complexo DTO consumirá processamento. Já vi aplicações ficarem
bem lenta pelo uso excessivo do Binding. Além disso, use Binding com
States se quiser cometer suicídio.
[]'s
Beck Novaes
On 4 nov, 15:07, Pergentino Araújo <jpergent...@gmail.com> wrote:
> alguém já viu em algum documento (de preferência oficial), que fale a
> respeito do possível crescimento de memória e/ou processamento quando é
> utilizado muito (mas muito mesmo) o esquema de Bindable em
> objetos/propriedades?
> --
> Atenciosamente, Pergentino Araújo.
> Arquiteto Java/Flex
> MSc. Profissional - Engenharia de Software
> Adobe Certified Expert - Flex 3 with AIR
Sabe, acho que a gente tem que pensar que tem pessoas que nos leem e
que não tem tanta experiencia/conhecimento quanto nós (autores desta
thread). Neste post, por exemplo, todo os autores sabem muito Flex/
AS3. Eu me preocupo com um menino que começou a programar anteontem e
lê o Mario ou o Stephan - que são duas pessoas que têm o maior
respeito do pessoal daqui - e que vai começar a colocar bindable em
constante, porque leu que os gurus "não se preocupam tanto com isso".
Ainda mais porque Flex é tão fácil, mas tão facil, que qualquer um
consegue criar uma appzinha básica (e depois não consegue fazer nem um
substr, basta olhar outros posts aqui...).
Então, pra quem está seguindo essa thread: pras apps do Stephan e do
Mario - que mesmo que eu não tenho visto tenho certeza que estão bem
projetadas - ficar catando binding desnecessário é mesmo "procurar
pelo em ovo". Até porque não deve ter binding sobrando ali.
Quem está começando deveria sim se preocupar com isso.
Concordo com o Beck. Um dos principais problemas do Bindable é que utiliza o default PropertyChangeEvent que é feito o dispatch sempre que o setter é executado (e o seu valor é diferente do que estava actualmente). Existem várias formas de optimizar o código, a simples substituição de
[Bindable] public var prop1:String;
por [Bindable(event="prop1ChangeEvent")] public function get prop1():String{} public function set prop1(value:String):void{}
Entendo sua preocupação, e acho válida.. então, deixa eu tentar reformular
minha resposta.
Obviamente que não faço tudo com Bindable ... por exemplo, constantes e
embeds realmente são toscos usar Bindable. Outra coisa legal é oq o Joao
Fernandes disse, sobre usar customEvents para detectar mudanças nas
propriedades e não o "default" PropertyChangeEvent (q por default é usado
pelo ObjectProxy... esse cara sim precisa ter muito cuidado.)
Outra questão é com relação a criação dos componentes, principalmente com os
commitProperties e UpdateDisplayList ... já vi gente querer criar filhos de
algo no updateDisplayList qnd uma propriedade é alterada... tá errado e isso
gera um consumo violento.
Com relação a Bindable e States.. o Beck já deu um bom exemplo de quando
usá-los (só em caso de suicidio).
Outra coisa q pode ajudar, pra quem usa o esquema do ModelLocator é nao
torna-lo totalmente [Bindable] mas, extender (com "x" mesmo =P) de
EventDispatcher e usar o mesmo esquema q o Joao falou, colocando o um
[Bindable(event="minhaPropriedadeChanged")] no getter e fazer o
dispatchEvent(new Event("minhaPropriedadeChanged")) no setter. Com isso vc
torna "bindavel" só as propriedades q precisa e nao todo seu modelLocator.
Enfim.. são cudiados q já tomo "por default" e que nem me faz pensar muito
sobre consumo de memória e milisegundos de processamento. Agora... se em
algum momento eu precisar criar na minha view um [Bindable] var algumaCoisa
... e que ela seja crucial para algum behavior de algum componente qualquer
q melhore a UX do meu usuario.. não vou exitar.. não mesmo!!! =D Vou lá e
coloco mesmo... não vou medir qnts bytes ou qnts ms ela pesou na app, CLARO
QUE aí entra o "feeling" de saber qnd o desempenho foi prejudicado. É uma
balança... e o ponto de medida as vezes depende da experiencia do
desenvolvedor.
Realmente... para aqueles que estao começando agora, preocupam-se sim com
processamentos e consumo de memoria, mas não foquem só no uso (ou nao uso)
do [Bindable] corram atras de life-cycle UIComponent... lazy
instantiation... elastic racetrack .. marshalled slice.. deferment.. etc.
Pesquise por esse termos... já tem bons conteudos em PT.
Abraços!
2009/11/5 João Fernandes <joaopedromartinsfernan...@gmail.com>
> Concordo com o Beck. Um dos principais problemas do Bindable é que
> utiliza o default PropertyChangeEvent que é feito o dispatch sempre que
> o setter é executado (e o seu valor é diferente do que estava
> actualmente). Existem várias formas de optimizar o código, a simples
> substituição de
> [Bindable]
> public var prop1:String;
> por
> [Bindable(event="prop1ChangeEvent")]
> public function get prop1():String{}
> public function set prop1(value:String):void{}
> Entendo sua preocupação, e acho válida.. então, deixa eu tentar reformular
> minha resposta.
> Obviamente que não faço tudo com Bindable ... por exemplo, constantes e
> embeds realmente são toscos usar Bindable. Outra coisa legal é oq o Joao
> Fernandes disse, sobre usar customEvents para detectar mudanças nas
> propriedades e não o "default" PropertyChangeEvent (q por default é usado
> pelo ObjectProxy... esse cara sim precisa ter muito cuidado.)
> Outra questão é com relação a criação dos componentes, principalmente com os
> commitProperties e UpdateDisplayList ... já vi gente querer criar filhos de
> algo no updateDisplayList qnd uma propriedade é alterada... tá errado e isso
> gera um consumo violento.
> Com relação a Bindable e States.. o Beck já deu um bom exemplo de quando
> usá-los (só em caso de suicidio).
> Outra coisa q pode ajudar, pra quem usa o esquema do ModelLocator é nao
> torna-lo totalmente [Bindable] mas, extender (com "x" mesmo =P) de
> EventDispatcher e usar o mesmo esquema q o Joao falou, colocando o um
> [Bindable(event="minhaPropriedadeChanged")] no getter e fazer o
> dispatchEvent(new Event("minhaPropriedadeChanged")) no setter. Com isso vc
> torna "bindavel" só as propriedades q precisa e nao todo seu modelLocator.
> Enfim.. são cudiados q já tomo "por default" e que nem me faz pensar muito
> sobre consumo de memória e milisegundos de processamento. Agora... se em
> algum momento eu precisar criar na minha view um [Bindable] var algumaCoisa
> ... e que ela seja crucial para algum behavior de algum componente qualquer
> q melhore a UX do meu usuario.. não vou exitar.. não mesmo!!! =D Vou lá e
> coloco mesmo... não vou medir qnts bytes ou qnts ms ela pesou na app, CLARO
> QUE aí entra o "feeling" de saber qnd o desempenho foi prejudicado. É uma
> balança... e o ponto de medida as vezes depende da experiencia do
> desenvolvedor.
> Realmente... para aqueles que estao começando agora, preocupam-se sim com
> processamentos e consumo de memoria, mas não foquem só no uso (ou nao uso)
> do [Bindable] corram atras de life-cycle UIComponent... lazy
> instantiation... elastic racetrack .. marshalled slice.. deferment.. etc.
> Pesquise por esse termos... já tem bons conteudos em PT.
> Abraços!
> 2009/11/5 João Fernandes <joaopedromartinsfernan...@gmail.com>
> > Concordo com o Beck. Um dos principais problemas do Bindable é que
> > utiliza o default PropertyChangeEvent que é feito o dispatch sempre que
> > o setter é executado (e o seu valor é diferente do que estava
> > actualmente). Existem várias formas de optimizar o código, a simples
> > substituição de
> > [Bindable]
> > public var prop1:String;
> > por
> > [Bindable(event="prop1ChangeEvent")]
> > public function get prop1():String{}
> > public function set prop1(value:String):void{}
Falando em RSL, no Flex 4 os RSL vem assinado digitalmente e se a data
estiver errada não carrega a app. *
Eduardo Kraus*
Desenvolvedor
eduardokr...@gmail.com
blog.mxml.com.br
www.twitter.com/EduardoKraus
2009/11/5 Stefan Horochovec <stefan.horocho...@gmail.com>
> Eu não me preocupo tanto com isso, acredito que seja procurar pelo em ovo
> .... Tem mais detalhes para levar em consideração do que o Binding, como por
> exemplo: usar da melhor forma a RSL....
> Abraços
> Stefan Horochovec
> Engenheiro de Software
> Adobe User Group Manager - FlexDuck
> Blog: http://www.horochovec.com.br/ > Use Java, Flex e Linux
> Sinceramente... no final - e em um caso real - a diferença é tao pqna q
>> estou mais me preocupando com UX da app doq alguns bits de memoria, ou
>> milisegundos de processamento.
>>> dei uma olhada em um dos links, e a diferença realmente é absurda:
>>> now launch the script and in the output I have this result
>>> total execution time: 2381 ms
>>> memory usage: 5924 kb
>>> NOW. Remove the *[Bindable]* property from the RGB class and launch
>>> again the test script. See at the output console and the new results are:
>>> total execution time: 236 ms
>>> memory usage: 2720 kb
>>> Agora, o cara lá fez 100.000 operacões/instanciações... aí também é
>>> brincadeira né !? rsrsr
>>> Eu me preocupo mais com memória do que com processamento, pois eu sei que
>>> a qtd na minha app não vai chegar nem a metade da metade da metade disso ae
>>> rsrsrs.
>>> Alguém fez um teste na prática em uma app ?
>>> []'s
>>> --
>>> Atenciosamente, Pergentino Araújo.
>>> Arquiteto Java/Flex
>>> MSc. Profissional - Engenharia de Software
>>> Adobe Certified Expert - Flex 3 with AIR
>>> 2009/11/4 Gabriela Trindade Perry <gabrielape...@hotmail.com>
>>>> yeap.
>>>> Uma vez eu até me lembro de ter quetsionado o porqeu de tanto bindable
>>>> pra todo lado... Até constantes são bindables, embeds são bindable....
vendo esse post aqui, fiquei realmente preocupado.
Parece mentira, mas criei a 2 dias uma nova classe (singleton) que
contem todas as imagens comuns que uso em praticamente todas as view
do sistema, como:
Pensei justamente o contrário do que foi dito aqui, mas pelo jeito
perdi um enorme tempo alterando os embed de cada view pela classe em
questão.
Meu raciocínio foi economizar memória carregando somente uma vez essas
images e compartilhando-as onde precisar.
agora pergunto, é melhor usar essa solução que abaixo, ou voltar
declarar em cada view seus embed?
segue abaixo a classe.
package
{
public class ImageCollection
{
[Embed(source="images/png/16x16/add.png")]
[Bindable] public var addIcon:Class;
[Embed(source="images/png/16x16/ok.png")]
[Bindable] public var okIcon:Class;
[Embed(source="images/png/16x16/remove.png")]
[Bindable] public var removeIcon:Class;
[Embed(source="images/png/16x16/new.png")]
[Bindable] public var newIcon:Class;
[Embed(source="images/png/16x16/edit.png")]
[Bindable] public var editIcon:Class;
[Embed(source="images/png/16x16/delete.png")]
[Bindable] public var deleteIcon:Class;
[Embed(source="images/png/16x16/left.png")]
[Bindable] public var leftArrowIcon:Class;
[Embed(source="images/png/16x16/right.png")]
[Bindable] public var rightArrowIcon:Class;
[Embed(source="images/png/16x16/up.png")]
[Bindable] public var upArrowIcon:Class;
[Embed(source="images/png/16x16/down.png")]
[Bindable] public var downArrowIcon:Class;
[Embed(source="images/png/16x16/search.png")]
[Bindable] public var searchIcon:Class;
[Embed(source="images/png/16x16/search_form.png")]
[Bindable] public var searchFormIcon:Class;
[Embed(source="images/png/16x16/print.png")]
[Bindable] public var printIcon:Class;
[Embed(source="images/png/16x16/keys.png")]
[Bindable] public var keysIcon:Class;
[Embed(source="images/png/16x16/open_padlock.png")]
[Bindable] public var openPadlockIcon:Class;
[Embed(source="images/png/16x16/close_padlock.png")]
[Bindable] public var closePadlockIcon:Class;
private static var images:ImageCollection;
public static function getInstance():ImageCollection
{
if (images == null)
{
images = new ImageCollection();
}
return images;
}
public function ImageCollection()
{
if (images != null)
{
throw new Error( "Já existe uma instância criada!" );
}
}
Eu tenho uma classe parecida, mas no meu caso não uso Bindable.Só
deixo o Embed.
Porque Bindable é para obter todas modifcações/transformações (manter
atualizado todos lugares que dependem dessa instância) que algo obteve
durante o uso do sistema (minha visão sobre Bindables), e o caminho
dessas imagens e as imagens em si não sofrem alterações o Bindable se
torna desnecessário no meu ponto de vista.
On 5 nov, 19:51, Daniel Vitor <dvluc...@gmail.com> wrote:
> vendo esse post aqui, fiquei realmente preocupado.
> Parece mentira, mas criei a 2 dias uma nova classe (singleton) que
> contem todas as imagens comuns que uso em praticamente todas as view
> do sistema, como:
> Pensei justamente o contrário do que foi dito aqui, mas pelo jeito
> perdi um enorme tempo alterando os embed de cada view pela classe em
> questão.
> Meu raciocínio foi economizar memória carregando somente uma vez essas
> images e compartilhando-as onde precisar.
> agora pergunto, é melhor usar essa solução que abaixo, ou voltar
> declarar em cada view seus embed?
> segue abaixo a classe.
> package
> {
> public class ImageCollection
> {
> [Embed(source="images/png/16x16/add.png")]
> [Bindable] public var addIcon:Class;
> [Embed(source="images/png/16x16/ok.png")]
> [Bindable] public var okIcon:Class;
> [Embed(source="images/png/16x16/remove.png")]
> [Bindable] public var removeIcon:Class;
> [Embed(source="images/png/16x16/new.png")]
> [Bindable] public var newIcon:Class;
> [Embed(source="images/png/16x16/edit.png")]
> [Bindable] public var editIcon:Class;
> [Embed(source="images/png/16x16/delete.png")]
> [Bindable] public var deleteIcon:Class;
> [Embed(source="images/png/16x16/left.png")]
> [Bindable] public var leftArrowIcon:Class;
> [Embed(source="images/png/16x16/right.png")]
> [Bindable] public var rightArrowIcon:Class;
> [Embed(source="images/png/16x16/up.png")]
> [Bindable] public var upArrowIcon:Class;
> [Embed(source="images/png/16x16/down.png")]
> [Bindable] public var downArrowIcon:Class;
> [Embed(source="images/png/16x16/search.png")]
> [Bindable] public var searchIcon:Class;
> [Embed(source="images/png/16x16/search_form.png")]
> [Bindable] public var searchFormIcon:Class;
> [Embed(source="images/png/16x16/print.png")]
> [Bindable] public var printIcon:Class;
> [Embed(source="images/png/16x16/keys.png")]
> [Bindable] public var keysIcon:Class;
> [Embed(source="images/png/16x16/open_padlock.png")]
> [Bindable] public var openPadlockIcon:Class;
> [Embed(source="images/png/16x16/close_padlock.png")]
> [Bindable] public var closePadlockIcon:Class;
> private static var images:ImageCollection;
> public static function getInstance():ImageCollection
> {
> if (images == null)
> {
> images = new ImageCollection();
> }
> return images;
> }
> public function ImageCollection()
> {
> if (images != null)
> {
> throw new Error( "Já existe uma instância criada!" );
> }
> }
Realmente Rafael, retirei os [Bindable] de cada embed, funcionou
normalmente. Porém se eu retirar a [Bindable] da decalaração da
variável, ai não funciona, exemplo:
[Bindable] private var images:ImageCollection; -> Funciona
private var images:ImageCollection; -> NÃO Funciona
Ficou assim a classe:
package
{
public class ImageCollection
{
[Embed(source="../../../../../images/png/16x16/add.png")]
public var addIcon:Class;
[Embed(source="../../../../../images/png/16x16/ok.png")]
public var okIcon:Class;
[Embed(source="../../../../../images/png/16x16/remove.png")]
public var removeIcon:Class;
[Embed(source="../../../../../images/png/16x16/new.png")]
public var newIcon:Class;
[Embed(source="../../../../../images/png/16x16/edit.png")]
public var editIcon:Class;
[Embed(source="../../../../../images/png/16x16/
delete.png")]
public var deleteIcon:Class;
[Embed(source="../../../../../images/png/16x16/left.png")]
public var leftArrowIcon:Class;
[Embed(source="../../../../../images/png/16x16/right.png")]
public var rightArrowIcon:Class;
[Embed(source="../../../../../images/png/16x16/up.png")]
public var upArrowIcon:Class;
[Embed(source="../../../../../images/png/16x16/down.png")]
public var downArrowIcon:Class;
[Embed(source="../../../../../images/png/16x16/search.png")]
public var searchIcon:Class;
[Embed(source="../../../../../images/png/16x16/
search_form.png")]
public var searchFormIcon:Class;
[Embed(source="../../../../../images/png/16x16/print.png")]
public var printIcon:Class;
[Embed(source="../../../../../images/png/16x16/keys.png")]
public var keysIcon:Class;
[Embed(source="../../../../../images/png/16x16/
open_padlock.png")]
public var openPadlockIcon:Class;
[Embed(source="../../../../../images/png/16x16/
close_padlock.png")]
public var closePadlockIcon:Class;
private static var images:ImageCollection;
public static function getInstance():ImageCollection
{
if (images == null)
{
images = new ImageCollection();
}
return images;
}
public function ImageCollection()
{
if (images != null)
{
throw new Error( "Já existe uma instância criada!" );
}
}
> Realmente Rafael, retirei os [Bindable] de cada embed, funcionou
> normalmente. Porém se eu retirar a [Bindable] da decalaração da
> variável, ai não funciona, exemplo:
> [Bindable] private var images:ImageCollection; -> Funciona
> private var images:ImageCollection; -> NÃO Funciona
> Ficou assim a classe:
> package
> {
> public class ImageCollection
> {
> [Embed(source="../../../../../images/png/16x16/add.png")]
> public var addIcon:Class;
> [Embed(source="../../../../../images/png/16x16/ok.png")]
> public var okIcon:Class;
> [Embed(source="../../../../../images/png/16x16/remove.png")]
> public var removeIcon:Class;
> [Embed(source="../../../../../images/png/16x16/new.png")]
> public var newIcon:Class;
> [Embed(source="../../../../../images/png/16x16/edit.png")]
> public var editIcon:Class;
> [Embed(source="../../../../../images/png/16x16/
> delete.png")]
> public var deleteIcon:Class;
> [Embed(source="../../../../../images/png/16x16/left.png")]
> public var leftArrowIcon:Class;
> [Embed(source="../../../../../images/png/16x16/right.png")]
> public var rightArrowIcon:Class;
> [Embed(source="../../../../../images/png/16x16/up.png")]
> public var upArrowIcon:Class;
> [Embed(source="../../../../../images/png/16x16/down.png")]
> public var downArrowIcon:Class;
> [Embed(source="../../../../../images/png/16x16/search.png")]
> public var searchIcon:Class;
> [Embed(source="../../../../../images/png/16x16/
> search_form.png")]
> public var searchFormIcon:Class;
> [Embed(source="../../../../../images/png/16x16/print.png")]
> public var printIcon:Class;
> [Embed(source="../../../../../images/png/16x16/keys.png")]
> public var keysIcon:Class;
> [Embed(source="../../../../../images/png/16x16/
> open_padlock.png")]
> public var openPadlockIcon:Class;
> [Embed(source="../../../../../images/png/16x16/
> close_padlock.png")]
> public var closePadlockIcon:Class;
> private static var images:ImageCollection;
> public static function getInstance():ImageCollection
> {
> if (images == null)
> {
> images = new ImageCollection();
> }
> return images;
> }
> public function ImageCollection()
> {
> if (images != null)
> {
> throw new Error( "Já existe uma instância criada!" );
> }
> }
[Bindable] private var images:ImageCollection; -> Funciona
images = ImageCollection.getInstance();
private var images:ImageCollection; -> NÃO Funciona
images = ImageCollection.getInstance();
Devido a pratica de programação adotado, fazemos as delarações dos
objetos/variaveis antes do construtor da classe e no construtor ou
dentro de creationComplete (quando é o caso) a instanciação. Por isso
esqueci de postar a parte da instância.
Agora sim está tudo ai, a classe e a forma de instancia:
O Bindable está diretamente relacionado aos colchetes no icon do
botão, indicando que esses ícones são chamados de uma forma bindada
por isso a necessidade do Bindable na variável.
Agora deixo para a galera mais experiente uma dúvida que vai te ajudar
e também fico em dúvida ás vezes: No seu caso se você deixasse apenas
images.editIcon o compilador iria entender isso como uma string? ou
como a propriedade do mesmo modo que bindable?
Qual a diferença e quais casos que posso utilizar uma propriedade de
forma não bindável?
On 5 nov, 20:58, Daniel Vitor <dvluc...@gmail.com> wrote:
> private var images:ImageCollection; -> NÃO Funciona
> images = ImageCollection.getInstance();
> Devido a pratica de programação adotado, fazemos as delarações dos
> objetos/variaveis antes do construtor da classe e no construtor ou
> dentro de creationComplete (quando é o caso) a instanciação. Por isso
> esqueci de postar a parte da instância.
> Agora sim está tudo ai, a classe e a forma de instancia:
Pq nao usa logo static dentro da classe e abandona de vez esse singleton?
class ImageCollection {
[Embed(source=".../meuIcone.png")]
public static var meuIcone:Class;
}
<button icon="{ImageCollection.meuIcone}" />
Pronto! Nada de [Bindable] ... nada de getInstance()... simples assim.
Daniel, qnd a sua primeira thread rolou no grupo a Gabriela e eu ainda
ficamos nos perguntando o porque disso, querer usar singleton para
economizar memoria mas sendo q a instancia nunca é destruida... nao faz
sentido.. acho q ela ainda chegou a te avisar no tópico.
> O Bindable está diretamente relacionado aos colchetes no icon do
> botão, indicando que esses ícones são chamados de uma forma bindada
> por isso a necessidade do Bindable na variável.
> Agora deixo para a galera mais experiente uma dúvida que vai te ajudar
> e também fico em dúvida ás vezes: No seu caso se você deixasse apenas
> images.editIcon o compilador iria entender isso como uma string? ou
> como a propriedade do mesmo modo que bindable?
> Qual a diferença e quais casos que posso utilizar uma propriedade de
> forma não bindável?
> On 5 nov, 20:58, Daniel Vitor <dvluc...@gmail.com> wrote:
> > Desculpe,
> > private var images:ImageCollection; -> NÃO Funciona
> > images = ImageCollection.getInstance();
> > Devido a pratica de programação adotado, fazemos as delarações dos
> > objetos/variaveis antes do construtor da classe e no construtor ou
> > dentro de creationComplete (quando é o caso) a instanciação. Por isso
> > esqueci de postar a parte da instância.
> > Agora sim está tudo ai, a classe e a forma de instancia:
Mario, saberia explicar porque {ImageCollection.meuIcone} e não
ImageCollection.meuIcone dentro da propriedade? Porque se faz uso dos
colchetes (else não sabem apenas para váriaveis bindáveis?)
On 5 nov, 22:14, Mário Júnior <juninho...@gmail.com> wrote:
> Pq nao usa logo static dentro da classe e abandona de vez esse singleton?
> class ImageCollection {
> [Embed(source=".../meuIcone.png")]
> public static var meuIcone:Class;
> }
> <button icon="{ImageCollection.meuIcone}" />
> Pronto! Nada de [Bindable] ... nada de getInstance()... simples assim.
> Daniel, qnd a sua primeira thread rolou no grupo a Gabriela e eu ainda
> ficamos nos perguntando o porque disso, querer usar singleton para
> economizar memoria mas sendo q a instancia nunca é destruida... nao faz
> sentido.. acho q ela ainda chegou a te avisar no tópico.
> > O Bindable está diretamente relacionado aos colchetes no icon do
> > botão, indicando que esses ícones são chamados de uma forma bindada
> > por isso a necessidade do Bindable na variável.
> > Agora deixo para a galera mais experiente uma dúvida que vai te ajudar
> > e também fico em dúvida ás vezes: No seu caso se você deixasse apenas
> > images.editIcon o compilador iria entender isso como uma string? ou
> > como a propriedade do mesmo modo que bindable?
> > Qual a diferença e quais casos que posso utilizar uma propriedade de
> > forma não bindável?
> > On 5 nov, 20:58, Daniel Vitor <dvluc...@gmail.com> wrote:
> > > Desculpe,
> > > private var images:ImageCollection; -> NÃO Funciona
> > > images = ImageCollection.getInstance();
> > > Devido a pratica de programação adotado, fazemos as delarações dos
> > > objetos/variaveis antes do construtor da classe e no construtor ou
> > > dentro de creationComplete (quando é o caso) a instanciação. Por isso
> > > esqueci de postar a parte da instância.
> > > Agora sim está tudo ai, a classe e a forma de instancia:
"No seu caso se você deixasse apenas
images.editIcon o compilador iria entender isso como uma string? ou
como a propriedade do mesmo modo que bindable?"
O compilador irá ver como string, se não me engano, dando erro.
Em complemento ao código anterior poderia setar a propriedade icon no
método createChildren.
> Mario, saberia explicar porque {ImageCollection.meuIcone} e não
> ImageCollection.meuIcone dentro da propriedade? Porque se faz uso dos
> colchetes (else não sabem apenas para váriaveis bindáveis?)
> On 5 nov, 22:14, Mário Júnior <juninho...@gmail.com> wrote:
> > Pq nao usa logo static dentro da classe e abandona de vez esse singleton?
> > class ImageCollection {
> > [Embed(source=".../meuIcone.png")]
> > public static var meuIcone:Class;
> > }
> > <button icon="{ImageCollection.meuIcone}" />
> > Pronto! Nada de [Bindable] ... nada de getInstance()... simples assim.
> > Daniel, qnd a sua primeira thread rolou no grupo a Gabriela e eu ainda
> > ficamos nos perguntando o porque disso, querer usar singleton para
> > economizar memoria mas sendo q a instancia nunca é destruida... nao faz
> > sentido.. acho q ela ainda chegou a te avisar no tópico.
> > > O Bindable está diretamente relacionado aos colchetes no icon do
> > > botão, indicando que esses ícones são chamados de uma forma bindada
> > > por isso a necessidade do Bindable na variável.
> > > Agora deixo para a galera mais experiente uma dúvida que vai te ajudar
> > > e também fico em dúvida ás vezes: No seu caso se você deixasse apenas
> > > images.editIcon o compilador iria entender isso como uma string? ou
> > > como a propriedade do mesmo modo que bindable?
> > > Qual a diferença e quais casos que posso utilizar uma propriedade de
> > > forma não bindável?
> > > On 5 nov, 20:58, Daniel Vitor <dvluc...@gmail.com> wrote:
> > > > Desculpe,
> > > > private var images:ImageCollection; -> NÃO Funciona
> > > > images = ImageCollection.getInstance();
> > > > Devido a pratica de programação adotado, fazemos as delarações dos
> > > > objetos/variaveis antes do construtor da classe e no construtor ou
> > > > dentro de creationComplete (quando é o caso) a instanciação. Por isso
> > > > esqueci de postar a parte da instância.
> > > > Agora sim está tudo ai, a classe e a forma de instancia:
> "No seu caso se você deixasse apenas
> images.editIcon o compilador iria entender isso como uma string? ou
> como a propriedade do mesmo modo que bindable?"
> O compilador irá ver como string, se não me engano, dando erro.
> Em complemento ao código anterior poderia setar a propriedade icon no
> método createChildren.
> On 5 nov, 23:32, RafaelViana <rfl.vi...@gmail.com> wrote:
> > Mario, saberia explicar porque {ImageCollection.meuIcone} e não
> > ImageCollection.meuIcone dentro da propriedade? Porque se faz uso dos
> > colchetes (else não sabem apenas para váriaveis bindáveis?)
> > On 5 nov, 22:14, Mário Júnior <juninho...@gmail.com> wrote:
> > > Pq nao usa logo static dentro da classe e abandona de vez esse
> singleton?
> > > class ImageCollection {
> > > [Embed(source=".../meuIcone.png")]
> > > public static var meuIcone:Class;
> > > Pronto! Nada de [Bindable] ... nada de getInstance()... simples assim.
> > > Daniel, qnd a sua primeira thread rolou no grupo a Gabriela e eu ainda
> > > ficamos nos perguntando o porque disso, querer usar singleton para
> > > economizar memoria mas sendo q a instancia nunca é destruida... nao faz
> > > sentido.. acho q ela ainda chegou a te avisar no tópico.
> > > > O Bindable está diretamente relacionado aos colchetes no icon do
> > > > botão, indicando que esses ícones são chamados de uma forma bindada
> > > > por isso a necessidade do Bindable na variável.
> > > > Agora deixo para a galera mais experiente uma dúvida que vai te
> ajudar
> > > > e também fico em dúvida ás vezes: No seu caso se você deixasse apenas
> > > > images.editIcon o compilador iria entender isso como uma string? ou
> > > > como a propriedade do mesmo modo que bindable?
> > > > Qual a diferença e quais casos que posso utilizar uma propriedade de
> > > > forma não bindável?
> > > > On 5 nov, 20:58, Daniel Vitor <dvluc...@gmail.com> wrote:
> > > > > Desculpe,
> > > > > private var images:ImageCollection; -> NÃO Funciona
> > > > > images = ImageCollection.getInstance();
> > > > > Devido a pratica de programação adotado, fazemos as delarações dos
> > > > > objetos/variaveis antes do construtor da classe e no construtor ou
> > > > > dentro de creationComplete (quando é o caso) a instanciação. Por
> isso
> > > > > esqueci de postar a parte da instância.
> > > > > Agora sim está tudo ai, a classe e a forma de instancia:
> > > > > e nos objetos (ex: button) é feito assim:
Complementando... pode ser q o compilador lance um Warning avisando q não
poderá detectar mudanças na variavel por ela nao ser [Bindable]. É só
ignorar. Como já falamos antes, o fato dela ser static / const / embed nunca
fará com q ela mude mesmo, então não faz sentido que ela seja [Bindable].
>> "No seu caso se você deixasse apenas
>> images.editIcon o compilador iria entender isso como uma string? ou
>> como a propriedade do mesmo modo que bindable?"
>> O compilador irá ver como string, se não me engano, dando erro.
>> Em complemento ao código anterior poderia setar a propriedade icon no
>> método createChildren.
>> On 5 nov, 23:32, RafaelViana <rfl.vi...@gmail.com> wrote:
>> > Mario, saberia explicar porque {ImageCollection.meuIcone} e não
>> > ImageCollection.meuIcone dentro da propriedade? Porque se faz uso dos
>> > colchetes (else não sabem apenas para váriaveis bindáveis?)
>> > On 5 nov, 22:14, Mário Júnior <juninho...@gmail.com> wrote:
>> > > Pq nao usa logo static dentro da classe e abandona de vez esse
>> singleton?
>> > > class ImageCollection {
>> > > [Embed(source=".../meuIcone.png")]
>> > > public static var meuIcone:Class;
>> > > Pronto! Nada de [Bindable] ... nada de getInstance()... simples assim.
>> > > Daniel, qnd a sua primeira thread rolou no grupo a Gabriela e eu ainda
>> > > ficamos nos perguntando o porque disso, querer usar singleton para
>> > > economizar memoria mas sendo q a instancia nunca é destruida... nao
>> faz
>> > > sentido.. acho q ela ainda chegou a te avisar no tópico.
>> > > > O Bindable está diretamente relacionado aos colchetes no icon do
>> > > > botão, indicando que esses ícones são chamados de uma forma bindada
>> > > > por isso a necessidade do Bindable na variável.
>> > > > Agora deixo para a galera mais experiente uma dúvida que vai te
>> ajudar
>> > > > e também fico em dúvida ás vezes: No seu caso se você deixasse
>> apenas
>> > > > images.editIcon o compilador iria entender isso como uma string? ou
>> > > > como a propriedade do mesmo modo que bindable?
>> > > > Qual a diferença e quais casos que posso utilizar uma propriedade de
>> > > > forma não bindável?
>> > > > On 5 nov, 20:58, Daniel Vitor <dvluc...@gmail.com> wrote:
>> > > > > Desculpe,
>> > > > > private var images:ImageCollection; -> NÃO Funciona
>> > > > > images = ImageCollection.getInstance();
>> > > > > Devido a pratica de programação adotado, fazemos as delarações dos
>> > > > > objetos/variaveis antes do construtor da classe e no construtor ou
>> > > > > dentro de creationComplete (quando é o caso) a instanciação. Por
>> isso
>> > > > > esqueci de postar a parte da instância.
>> > > > > Agora sim está tudo ai, a classe e a forma de instancia:
>> > > > > e nos objetos (ex: button) é feito assim:
[Embed(source="images/png/16x16/add.png")]
public *const* addIcon:Class;
Lembre-se, constantes não podem ser alteradas. Também não precisam de
Bindable.
*
Eduardo Kraus*
Desenvolvedor
eduardokr...@gmail.com
blog.mxml.com.br
www.twitter.com/EduardoKraus
> vendo esse post aqui, fiquei realmente preocupado.
> Parece mentira, mas criei a 2 dias uma nova classe (singleton) que
> contem todas as imagens comuns que uso em praticamente todas as view
> do sistema, como:
> Pensei justamente o contrário do que foi dito aqui, mas pelo jeito
> perdi um enorme tempo alterando os embed de cada view pela classe em
> questão.
> Meu raciocínio foi economizar memória carregando somente uma vez essas
> images e compartilhando-as onde precisar.
> agora pergunto, é melhor usar essa solução que abaixo, ou voltar
> declarar em cada view seus embed?
> segue abaixo a classe.
> package
> {
> public class ImageCollection
> {
> [Embed(source="images/png/16x16/add.png")]
> [Bindable] public var addIcon:Class;
> [Embed(source="images/png/16x16/ok.png")]
> [Bindable] public var okIcon:Class;
> [Embed(source="images/png/16x16/remove.png")]
> [Bindable] public var removeIcon:Class;
> [Embed(source="images/png/16x16/new.png")]
> [Bindable] public var newIcon:Class;
> [Embed(source="images/png/16x16/edit.png")]
> [Bindable] public var editIcon:Class;
> [Embed(source="images/png/16x16/delete.png")]
> [Bindable] public var deleteIcon:Class;
> [Embed(source="images/png/16x16/left.png")]
> [Bindable] public var leftArrowIcon:Class;
> [Embed(source="images/png/16x16/right.png")]
> [Bindable] public var rightArrowIcon:Class;
> [Embed(source="images/png/16x16/up.png")]
> [Bindable] public var upArrowIcon:Class;
> [Embed(source="images/png/16x16/down.png")]
> [Bindable] public var downArrowIcon:Class;
> [Embed(source="images/png/16x16/search.png")]
> [Bindable] public var searchIcon:Class;
> [Embed(source="images/png/16x16/search_form.png")]
> [Bindable] public var searchFormIcon:Class;
> [Embed(source="images/png/16x16/print.png")]
> [Bindable] public var printIcon:Class;
> [Embed(source="images/png/16x16/keys.png")]
> [Bindable] public var keysIcon:Class;
> [Embed(source="images/png/16x16/open_padlock.png")]
> [Bindable] public var openPadlockIcon:Class;
> [Embed(source="images/png/16x16/close_padlock.png")]
> [Bindable] public var closePadlockIcon:Class;
> private static var images:ImageCollection;
> public static function getInstance():ImageCollection
> {
> if (images == null)
> {
> images = new ImageCollection();
> }
> return images;
> }
> public function ImageCollection()
> {
> if (images != null)
> {
> throw new Error( "Já existe uma instância
> criada!" );
> }
> }
O problema de usar const para isso é quando estamos usando o asdoc para
documentar. Ele não consegue documentar porque está definido como constante
mas não tem um valor padrão já atribuido. Chato né? :\
> [Embed(source="images/png/16x16/add.png")]
> public *const* addIcon:Class;
> Lembre-se, constantes não podem ser alteradas. Também não precisam de
> Bindable.
> *
> Eduardo Kraus*
> Desenvolvedor
> eduardokr...@gmail.com
> blog.mxml.com.br
> www.twitter.com/EduardoKraus
>> vendo esse post aqui, fiquei realmente preocupado.
>> Parece mentira, mas criei a 2 dias uma nova classe (singleton) que
>> contem todas as imagens comuns que uso em praticamente todas as view
>> do sistema, como:
>> Pensei justamente o contrário do que foi dito aqui, mas pelo jeito
>> perdi um enorme tempo alterando os embed de cada view pela classe em
>> questão.
>> Meu raciocínio foi economizar memória carregando somente uma vez essas
>> images e compartilhando-as onde precisar.
>> agora pergunto, é melhor usar essa solução que abaixo, ou voltar
>> declarar em cada view seus embed?
>> segue abaixo a classe.
>> package
>> {
>> public class ImageCollection
>> {
>> [Embed(source="images/png/16x16/add.png")]
>> [Bindable] public var addIcon:Class;
>> [Embed(source="images/png/16x16/ok.png")]
>> [Bindable] public var okIcon:Class;
>> [Embed(source="images/png/16x16/remove.png")]
>> [Bindable] public var removeIcon:Class;
>> [Embed(source="images/png/16x16/new.png")]
>> [Bindable] public var newIcon:Class;
>> [Embed(source="images/png/16x16/edit.png")]
>> [Bindable] public var editIcon:Class;
>> [Embed(source="images/png/16x16/delete.png")]
>> [Bindable] public var deleteIcon:Class;
>> [Embed(source="images/png/16x16/left.png")]
>> [Bindable] public var leftArrowIcon:Class;
>> [Embed(source="images/png/16x16/right.png")]
>> [Bindable] public var rightArrowIcon:Class;
>> [Embed(source="images/png/16x16/up.png")]
>> [Bindable] public var upArrowIcon:Class;
>> [Embed(source="images/png/16x16/down.png")]
>> [Bindable] public var downArrowIcon:Class;
>> [Embed(source="images/png/16x16/search.png")]
>> [Bindable] public var searchIcon:Class;
>> [Embed(source="images/png/16x16/search_form.png")]
>> [Bindable] public var searchFormIcon:Class;
>> [Embed(source="images/png/16x16/print.png")]
>> [Bindable] public var printIcon:Class;
>> [Embed(source="images/png/16x16/keys.png")]
>> [Bindable] public var keysIcon:Class;
>> [Embed(source="images/png/16x16/open_padlock.png")]
>> [Bindable] public var openPadlockIcon:Class;
>> [Embed(source="images/png/16x16/close_padlock.png")]
>> [Bindable] public var closePadlockIcon:Class;
>> private static var images:ImageCollection;
>> public static function getInstance():ImageCollection
>> {
>> if (images == null)
>> {
>> images = new ImageCollection();
>> }
>> return images;
>> }
>> public function ImageCollection()
>> {
>> if (images != null)
>> {
>> throw new Error( "Já existe uma instância
>> criada!" );
>> }
>> }
|
