Seja bem vind@, se você é um debiano (um baiano que usa debian) faça parte de nossa comunidade!


Um Trabalho a Troco de nada? A resposta da comunidade GNOME para Jô Soares e Bill Gates à luz da teoria da Dádiva

11 de Outubro de 2014, por Desconhecido - 0sem comentários ainda

Sete anos após uma  apresentação feita no IV Fórum GNOME em 2007 com esse mesmo título, finalmente, eu consegui publicar, em parceria com Genauto França Filho (meu orientador de Doutorado), o resultado da pesquisa que tentou responder uma questão que ronda o ecossistema dos projetos de software livre: "quem pode se permitir fazer um trabalho profissional a troco de nada?"  Mais especificamente, esse artigo foi publicado na revista (acadêmica) Sociologias - uma publicação quadrimestral do Programa de Pós-Graduação em Sociologia da UFRGS, destinada a promover intercâmbio entre cientistas sociais.

No entanto, é importante ressaltar que essa questão norteadora da nossa pesquisa foi, inicialmente, levantada por Biil Gates na histórica "Carta Aberta aos Hobbistas" escrita em 1976  - um ano depois da fundação da então "Micro-Soft". Além dele, quatro décadas depois, mais especificamente em outubro de 2006, ela foi "remixada" por Jô Soares, no seu programa de televisão. Em uma de suas entrevistas, ao ser informado pelo Sérgio Amadeu (Prof. da UFABC) e pelo Júlio Neves (Prof. da UNiRio) sobre um possível engajamento voluntário de hackers ligados ao projetos de software livre, Jô Soares ressalta que, na visão dele, "por trás do fato do que é dado (software) de graça há uma intenção de ser vendido. (...) ou é um pessoal que é tudo monge Franciscano?"

O ponto de partida desse artigo que escrevemos na Sociologias é que ainda são poucos os estudos que procuram analisar as características e a natureza desse novo contexto digital (de relações mediadas por dispositivos móveis como computadores, tablets e celulares) para além de um entendimento que tem como base apenas as noções de uma racionalidade utilitária ou do simples interesse econômico. Afinal, podemos dizer que mais recorrente do que esse tipo de pergunta é o tipo de resposta comum (e apressada) que diz que "ninguém trabalha de graça" ou que "sempre há um interesse financeiro nisso tudo".

Para evitar os limites de uma única forma de resposta "apressada" (para não dizer "equivocada") e, com isso, restringir a compreensão sobre a ação dos hackers nesses projetos, avaliamos que era importante respondê-la com um olhar mais científico e aprofundado. Assim, realizamos uma análise mais qualitativa sobre esse "fenômeno" que se apoiou em uma pesquisa de dois anos na comunidade do Projeto GNOME. Essa pesquisa resultou então na minha dissertação de mestrado na UFBA, em um dos capítulos do livro "Software Livre, Cultura Hacker e Ecossistema da Colaboração" e agora nesse artigo publicado na Revista Sociologias.

Membros da Comunidade GNOME por Louis Villa

Em termos de publicação, o diferencial então dessa edição v. 16, n. 36 (2014) da Revista Sociologias é o resgate da obra maussiana que fundamentou conceitualmente essa pesquisa sobre o Projeto GNOME - e, agora, serve também de base do meu projeto de Doutorado. Esse resgaste se dá no contexto de surgimento de uma crítica anti-utilitarista dentro do universo das ciências sociais contemporâneas, a qual foi concretizada pela fundação do MAUSS (Movimento Anti-Utilitarista nas Ciências Sociais).

Contudo, vale ressaltar que esse paradigma sociológico da dádiva busca ir além: mais do que a importância da sua vertente analítica, o MAUSS demonstra ser uma corrente sociológica implicada com a produção de pesquisas que se desenvolve a partir de um paradigma basilar, não apenas nas sociedade tradicionais como também para a sociedade contemporânea: a vida associativa e, em especial, a tripla ação de compartilhar, receber e retribuir. Vale então conferir essa edição da Sociologia da Dádiva na íntegra. 



Probing with Gradle

7 de Outubro de 2014, por Desconhecido - 0sem comentários ainda

Up until now, Probe relied on dynamic view proxies generated at runtime to intercept View calls. Although very convenient, this approach greatly affects the time to inflate your layouts—which limits the number of use cases for the library, especially in more complex apps.

This is all changing now with Probe’s brand new Gradle plugin which seamlessly generates build-time proxies for your app. This means virtually no overhead at runtime!

Using Probe’s Gradle plugin is very simple. First, add the Gradle plugin as a dependency in your build script.

buildscript {
    ...
    dependencies {
        ...
        classpath 'org.lucasr.probe:gradle-plugin:0.1.3'
    }
}

Then apply the plugin to your app’s build.gradle.

apply plugin: 'org.lucasr.probe'

Probe’s proxy generation is disabled by default and needs to be explicitly enabled on specific build variants (build type + product flavour). For example, this is how you enable Probe proxies in debug builds.

probe {
    buildVariants {
        debug {
            enabled = true
        }
    }
}

And that’s all! You should now be able to deploy interceptors on any part of your UI. Here’s how you could deploy an OvermeasureInterceptor in an activity.

public final class MainActivity extends Activity {
   @Override
   protected void onCreate(Bundle savedInstanceState) {
       Probe.deploy(this, new OvermeasureInterceptor());
       super.onCreate(savedInstanceState);
       setContentView(R.id.main_activity);
   }
}

While working on this feature, I have changed DexMaker to be an optional dependency i.e. you have to explicitly add DexMaker as a build dependency in your app in order to use it.

This is my first Gradle plugin. There’s definitely a lot of room for improvement here. These features are available in the 0.1.3 release in Maven Central.

As usual, feedback, bug reports, and fixes are very welcome. Enjoy!



New Features in Picasso

23 de Setembro de 2014, por Desconhecido - 0sem comentários ainda

I’ve always been a big fan of Picasso, the Android image loading library by the Square folks. It provides some powerful features with a rather simple API.

Recently, I started working on a set of new features for Picasso that will make it even more awesome: request handlers, request management, and request priorities. These features have all been merged to the main repo now. Let me give you a quick overview of what they enable you to do.

Request Handlers

Picasso supports a wide variety of image sources, from simple resources to content providers, network, and more. Sometimes though, you need to load images in unconventional ways that are not supported by default in Picasso.

Wouldn’t it be nice if you could easily integrate your custom image loading logic with Picasso? That’s what the new request handlers are about. All you need to do is subclass RequestHandler and implement a couple of methods. For example:

public class PonyRequestHandler extends RequestHandler {
    private static final String PONY_SCHEME = "pony";

    @Override public boolean canHandleRequest(Request data) {
        return PONY_SCHEME.equals(data.uri.getScheme());
    }

    @Override public Result load(Request data) {
         return new Result(somePonyBitmap, MEMORY);
    }
}

Then you register your request handler when instantiating Picasso:

Picasso picasso = new Picasso.Builder(context)
    .addRequestHandler(new PonyHandler())
    .build();

Voilà! Now Picasso can handle pony URIs:

picasso.load("pony://somePonyName")
       .into(someImageView)

This pull request also involved rewriting all built-in bitmap loaders on top of the new API. This means you can also override the built-in request handlers if you need to.

Request Management

Even though Picasso handles view recycling, it does so in an inefficient way. For instance, if you do a fling gesture on a ListView, Picasso will keep triggering and canceling requests blindly because there was no way to make it pause/resume requests according to the user interaction. Not anymore!

The new request management APIs allow you to tag associated requests that should be managed together. You can then pause, resume, or cancel requests associated with specific tags. The first thing you have to do is tag your requests as follows:

Picasso.with(context)
       .load("http://example.com/image.jpg")
       .tag(someTag)
       .into(someImageView)

Then you can pause and resume requests with this tag based on, say, the scroll state of a ListView. For example, Picasso’s sample app now has the following scroll listener:

public class SampleScrollListener implements AbsListView.OnScrollListener {
    ...
    @Override
    public void onScrollStateChanged(AbsListView view, int scrollState) {
        Picasso picasso = Picasso.with(context);
        if (scrollState == SCROLL_STATE_IDLE ||
            scrollState == SCROLL_STATE_TOUCH_SCROLL) {
            picasso.resumeTag(someTag);
        } else {
            picasso.pauseTag(someTag);
        }
    }
    ...
}

These APIs give you a much finer control over your image requests. The scroll listener is just the canonical use case.

Request Priorities

It’s very common for images in your Android UI to have different priorities. For instance, you may want to give higher priority to the big hero image in your activity in relation to other secondary images in the same screen.

Up until now, there was no way to hint Picasso about the relative priorities between images. The new priority API allows you to tell Picasso about the intended order of your image requests. You can just do:

Picasso.with(context)
       .load("http://example.com/image.jpg")
       .priority(HIGH)
       .into(someImageView);

These priorities don’t guarantee a specific order, they just tilt the balance in favour of higher-priority requests.


That’s all for now. Big thanks to Jake Wharton and Dimitris Koutsogiorgas for the prompt code and API reviews!

You can try these new APIs now by fetching the latest Picasso code on Github. These features will probably be available in the 2.4 release. Enjoy!



Introducing Probe

16 de Setembro de 2014, por Desconhecido - 0sem comentários ainda

We’ve all heard of the best practices regarding layouts on Android: keep your view tree as simple as possible, avoid multi-pass layouts high up in the hierarchy, etc. But the truth is, it’s pretty hard to see what’s actually going on in your view tree in each UI traversal (measure → layout → draw).

We’re well served with developer options for tracking graphics performance—debug GPU overdraw, show hardware layers updates, profile GPU rendering, and others. However, there is a big gap in terms of development tools for tracking layout traversals and figuring out how your layouts actually behave. This is why I created Probe.

Probe is a small library that allows you to intercept view method calls during Android’s layout traversals e.g. onMeasure(), onLayout(), onDraw(), etc. Once a method call is intercepted, you can either do extra things on top of the view’s original implementation or completely override the method on-the-fly.

Using Probe is super simple. All you have to do is implement an Interceptor. Here’s an interceptor that completely overrides a view’s onDraw(). Calling super.onDraw() would call the view’s original implementation.

public class DrawGreen extends Interceptor {
    private final Paint mPaint;

    public DrawGreen() {
        mPaint = new Paint();
        mPaint.setColor(Color.GREEN);
    }

    @Override
    public void onDraw(View view, Canvas canvas) {
        canvas.drawPaint(mPaint);
    }
}

Then deploy your Interceptor by inflating your layout with a Probe:

Probe probe = new Probe(this, new DrawGreen(), new Filter.ViewId(R.id.view2));
View root = probe.inflate(R.layout.main_activity, null);

Just to give you an idea of the kind of things you can do with Probe, I’ve already implemented a couple of built-in interceptors. OvermeasureInterceptor tints views according to the number of times they got measured in a single traversal i.e. equivalent to overdraw but for measurement.

LayoutBoundsInterceptor is equivalent to Android’s “Show layout bounds” developer option. The main difference is that you can show bounds only for specific views.

Under the hood, Probe uses Google’s DexMaker to generate dynamic View proxies during layout inflation. The stock ProxyBuilder implementation was not good enough for Probe because I wanted to avoid using reflection entirely after the proxy classes were generated. So I created a specialized View proxy builder that generates proxy classes tailored for Probe’s use case.

This means Probe takes longer than your usual LayoutInflater to inflate layout resources. There’s no use of reflection after layout inflation though. Your views should perform the same. For now, Probe is meant to be a developer tool only and I don’t recommend using it in production.

The code is available on Github. As usual, contributions are very welcome.



Introducing dspec

8 de Setembro de 2014, por Desconhecido - 0sem comentários ainda

With all the recent focus on baseline grids, keylines, and spacing markers from Android’s material design, I found myself wondering how I could make it easier to check the correctness of my Android UI implementation against the intended spec.

Wouldn’t it be nice if you could easily provide the spec values as input and get it rendered on top of your UI for comparison? Enter dspec, a super simple way to define UI specs that can be rendered on top of Android UIs.

Design specs can be defined either programmatically through a simple API or via JSON files. Specs can define various aspects of the baseline grid, keylines, and spacing markers such as visibility, offset, size, color, etc.

Baseline grid, keylines, and spacing markers in action.

Baseline grid, keylines, and spacing markers in action.

Given the responsive nature of Android UIs, the keylines and spacing markers are positioned in relation to predefined reference points (e.g. left, right, vertical center, etc) instead of absolute offsets.

The JSON files are Android resources which means you can easily adapt the spec according to different form factors e.g. different specs for phones and tablets. The JSON specs provide a simple way for designers to communicate their intent in a computer-readable way.

You can integrate a DesignSpec with your custom views by drawing it in your View‘s onDraw(Canvas) method. But the simplest way to draw a spec on top of a view is to enclose it in a DesignSpecFrameLayout—which can take an designSpec XML attribute pointing to the spec resource. For example:

<DesignSpecFrameLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:designSpec="@raw/my_spec">
    ...
</DesignSpecFrameLayout>

I can’t wait to start using dspec in some of the new UI work we’re doing Firefox for Android now. I hope you find it useful too. The code is available on Github. As usual, testing and fixes are very welcome. Enjoy!