Outro dia em Londres, a conferência droidcon foi realizada. Tópicos da moda, como Redux, MVI, otimização da velocidade de construção e recursos de Gradle não passaram. O evento foi aberto por um relatório de Chet Haase e Romain Guy sobre fragmentação de memória e as diferenças entre as versões do Android do Garbage Collector, e Jake Wharton fez uma apresentação sobre Dagger.
Nesta revisão, quero compartilhar minhas impressões sobre a conferência e os detalhes desses relatórios.
Ouvi muito sobre o droidcon de Londres, mas até agora não pude visitá-lo, pois sai muito mais caro do que, por exemplo, o droidcon Berlin, sem mencionar as conferências de Moscou. Ao mesmo tempo, o nível de conferências na Rússia, como droidcon, Mobius, AppsConf, aumentou significativamente nos últimos anos, e eu queria comparar a atmosfera, o nível de organização e os relatórios com colegas estrangeiros.
Mas as primeiras coisas primeiro.
Ingressos
Se você comprar um bilhete com antecedência, poderá comprá-lo por 230 libras + IVA. O preço final foi de cerca de 700 libras, incluindo IVA. É muito caro quando comparado aos ingressos para conferências russas, mas, em média, é um preço adequado para a Europa. Um voo custará cerca de 30 mil rublos, mas há uma oportunidade de economizar dinheiro, já que o Victory está voando para lá, e você pode comprar uma passagem por cerca de 6.000 rublos de uma maneira.
Alojamento
Moramos a 15 minutos a pé do local. O hotel é médio, cerca de 150 libras por dia. De fato, se você não é muito exigente, pode morar em algum albergue no centro da cidade por 20 libras por dia.
OrganizaçãoEm termos de organização, a conferência estava em um nível bastante alto. Gostei do site em si: uma espaçosa sala de comunicação e relaxamento moral, audiências confortáveis nas quais os relatórios foram lidos. No salão, havia muitos estandes de várias empresas onde você podia pegar um par de canetas e camisetas. Na noite do primeiro dia, os organizadores fizeram uma festa. Havia bebidas e música gratuitas, mas fomos passear por Londres.
RelatóriosO cronograma, na minha opinião, foi muito bem elaborado, pois a qualquer momento havia relatórios interessantes. Além disso, as oficinas eram realizadas constantemente.
Mas do nível dos relatórios eu esperava mais. Muitos deles estavam sem nenhum componente prático, por exemplo, apenas uma descrição de alguma API ou funcionalidade. O nível dos relatórios nas conferências de Moscou é pelo menos não inferior. Houve várias performances bastante fortes e relevantes. A seguir, escreverei sobre aqueles que me pareceram mais interessantes.
Mais sobre relatóriosKeynote - Trash Talk: A evolução da coleta de lixo no Android
Chet Haase e Romain Guy, GoogleA conferência começou com um relatório muito bom sobre o modelo de memória no Android. Os caras contaram como isso mudou de versão para versão, por que razões isso aconteceu. Não divulgarei detalhes aqui, mas recomendo assistir ao
vídeo .
Modularização - Quão difícil pode ser?
Elin Nilsson, SpotifyNão é muito técnico, mas mais motivacional, mas a partir deste relatório não menos interessante. Elin falou sobre os motivos que os fizeram pensar em dividir o aplicativo monolítico em módulos, o quão difícil e o que resultou dele em termos de quantidade de código, processos e velocidade de criação. Link para o
relatório .
Redux no Android
Nish Tahir, WillowTreeNão posso dizer que este relatório tenha aberto meus olhos para o Redux, mas, na minha opinião, o autor revelou bem a essência dessa solução, falou sobre os problemas e se vale a pena escolher o Redux como o principal padrão arquitetural e, em quais casos, se justifica. Link do
relatório
Ligação de dados moderna
Yigit Boyar e Jose Alcerreca, GoogleFoi interessante ouvir um relatório sobre ferramentas do Google nos lábios dos próprios desenvolvedores. Em princípio, eles não disseram nada de novo, o desejo de usar a Ligação de Dados também não apareceu, mas obrigado pela tentativa. Link do
relatórioMergulhe profundamente no plug-in Android Gradle
John Rodriguez, Square CashEste relatório foi um dos últimos da conferência e eu não estava pronto para receber informações interessantes e informativas, mas John saiu e fez um relatório bom e bastante incondicional sobre as nuances interessantes do Android Gradle Plugin. Eu também recomendo para
visualização .
Ajudando o Punhal a Ajudá-lo
Jake Wharton, GoogleUm bom relatório veio de Jack Wharton. Juntamente com o Square, eles criaram várias bibliotecas úteis para serem usadas com o Dagger que resolvem vários problemas dos desenvolvedores.
Em primeiro lugar, agora é dada muita atenção ao problema da velocidade de construção. Isso é especialmente verdadeiro para o Dagger e o ButterKnife, pois eles usam o processador de anotações e o kapt. Square apresentou uma solução na qual as implementações do Dagger e do ButterKnife trabalham com reflexão, em vez de geração de código. Isso reduz um pouco a velocidade do aplicativo de tempo de execução, mas economiza tempo em tempo de compilação e, dentro da estrutura de compilações de desenvolvedores, é bastante justificado, pois para os modelos mais recentes de Pixel e Samsung, esse trabalho é quase imperceptível.
É assim que as implementações do Binder aparecem na versão ButterKnife com reflexão@NonNull @UiThread public static Unbinder bind(@NonNull Object target, @NonNull View source) { List<Unbinder> unbinders = new ArrayList<>(); Class<?> targetClass = target.getClass(); if ((targetClass.getModifiers() & PRIVATE) != 0) { throw new IllegalArgumentException(targetClass.getName() + " must not be private."); } while (true) { for (Field field : targetClass.getDeclaredFields()) { int unbinderStartingSize = unbinders.size(); Unbinder unbinder; unbinder = parseBindView(target, field, source); if (unbinder != null) unbinders.add(unbinder); unbinder = parseBindViews(target, field, source); if (unbinder != null) unbinders.add(unbinder); unbinder = parseBindDrawable(target, field, source); if (unbinder != null) unbinders.add(unbinder); unbinder = parseBindString(target, field, source); if (unbinder != null) unbinders.add(unbinder); ... } for (Method method : targetClass.getDeclaredMethods()) { Unbinder unbinder; unbinder = parseOnCheckedChanged(target, method, source); if (unbinder != null) unbinders.add(unbinder); unbinder = parseOnClick(target, method, source); if (unbinder != null) unbinders.add(unbinder); ... } targetClass = targetClass.getSuperclass(); } return new CompositeUnbinder(unbinders); }
A biblioteca do ButterKnife pode ser encontrada neste link. A versão para Dagger está por aqui .
Em segundo lugar, às vezes é necessário injetar dependências em visualizações personalizadas declaradas em XML. Anteriormente, era necessário injetá-los através de métodos de conjunto e lançá-los através de classes de fora, por exemplo, em um apresentador, quando ele se anexa a uma exibição. Agora, há uma maneira conveniente para isso: dependências podem ser lançadas através do construtor imediatamente após os parâmetros necessários, e o LayoutInfater personalizado pode criar uma visualização com esses construtores complexos.
Como fica no código:
MainActivity.java public final class MainActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); MainComponent component = DaggerMainActivity_MainComponent.create(); InflationInjectFactory factory = component.getInjectFactory(); getLayoutInflater().setFactory(factory); setContentView(R.layout.main_activity); GalleryPresenter presenter = component.getGalleryPresenter(); GalleryView view = findViewById(R.id.gallery); presenter.attach(view); } @Component(modules = ViewModule.class) interface MainComponent { InflationInjectFactory getInjectFactory(); GalleryPresenter getGalleryPresenter(); } }
O GalleryView é escrito em xml.
GalleryView public final class GalleryView extends LinearLayout { private final ViewUpdater mViewUpdater; @InflationInject public GalleryView(@Assisted Context context, @Assisted AttributeSet attrs, ViewUpdater viewUpdater) { super(context, attrs); mViewUpdater = viewUpdater; } }
Em terceiro lugar, a Square, à sua maneira, abordou o problema que o AutoValue resolve, a saber, a criação de fábricas para classes com construtores pesados. Somente esta solução é maximamente integrada à lógica do Dagger.
Exemplo de uso:
UserPresenter.java public final class UserPresenter { private final LoadUserInteractor mLoadUserInteractor; private final String mUserId; @AssistedInject UserPresenter(@Assisted LoadUserInteractor loadUserInteractor, @Exclamation String userid) { mLoadUserInteractor = loadUserInteractor; mUserId = userid; } @AssistedInject.Factory public interface Factory { UserPresenter create(String greeting); } ... }
UserActivity.java public final class UserActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main_view); UserPresenter.Factory factory = DaggerUserActivity_ UserComponent.create().getUserPresenterFctory(); UserPresenter presenter = factory.create(getIntent().getStringExtra("user_id")); presenter.attach(); ... } @Component(modules = UserModule.class) interface UserComponent { UserPresenter.Factory getUserPresenterFctory(); } }
Gostei da aparência das implementações dessas soluções tópicas. Também aconselho a ver .
Sem dúvida, aprendi algo interessante para mim nos relatórios da conferência, conversei com colegas de diferentes empresas, o que é uma grande vantagem de uma conferência internacional, e vale a pena ir até eles para fazer contatos. Um bônus desta vez foi uma visita a Londres. Se falamos de relatórios, é mais fácil assisti-los on-line ou participar de uma das muitas conferências russas.