Neste artigo será apresentado o projeto que permite o desenvolvimento multiplataforma com Python utilizando o framework Kivy. |
INTRODUÇÃO

A biblioteca Kivy é um framework para desenvolvimento multiplataforma escrito majoritariamente com a linguagem Python e, com alguns trechos escritos em Cython (explicaremos melhor a seguir). O framework permite o desenvolvimento de aplicações para os sistema operacional Microsoft Windows, Linux, Mac OSX, Android, iOS e Raspberry utilizando um mesmo código Python.
O projeto é composto por vários subprojetos, cada um especializado numa determinada tarefa, como por exemplo, a geração de executáveis para determinada plataforma, uma API genérica para o fácil acesso ao hardware em plataformas diferentes, desenvolvimento de games e etc.
É importante não confundir o projeto Kivy com a biblioteca Kivy. O projeto Kivy, cujo site é http://kivy.org é composto por vários subprojetos, dentre estes, a biblioteca Kivy.
A eXcript, junto a comunidade brasileira, traduziu a documentação oficial do framework e o mesmo pode ser baixado aqui em nosso site.
A BIBLIOTECA KIVY
Uma aplicação desenvolvida com a biblioteca Kivy será executada diretamente em cima da biblioteca gráfica OpenGL que normalmente é executado em cima da placa gráfica. O OpenGL possui suporte nativo para as principais plataformas, e, estando o Kivy desenvolvido em cima do mesmo, toda plataforma que oferece suporte ao OpenGL poderá executar uma aplicação escrita com o framework Kivy.
Em outras palavras, todo o código será executado em cima dos processadores da placa de vídeo, e é por essa razão que em muitos casos, é possível que aplicações Kivy tenham performance igual, ou então superior a aplicações nativas!
Como o OpenGL é multiplataforma, o projeto Kivy, construído em cima dessa camada, pode ser executado em qualquer dispositivo que suporte a biblioteca e, como praticamente todos dispositivos oferecem suporte devido a sua amplitude, a quantidade e a complexidade de trabalhar com o hardware e aplicações gráficas, aplicações Kivy são compatíveis com uma grande quantidade de dispositivos.
OpenGL 2.0
OpenGL é uma API de desenvolvimento de aplicações gráficas e, ao mesmo tempo, o nome de uma linguagem de programação semelhante ao C++. A palavra OpenGL é um acrônimo de Open Graphics Library`, que, numa tradução livre teríamos Biblioteca Gráfica Aberta. O seu uso permite o fácil desenvolvimento de aplicações gráficas, inclusive com ambientes 3D pondendo ser executado em praticamente todos sistemas operacionais e nos principais dispositivos. A biblioteca é amplamente utilizada na construção de jogos, ferramentas 3D ou qualquer aplicação que faça uso intensivo do hardware gráfico.
OpenGL é um conjunto de padrões de processamento de alto desempenho de gráficos 2D e 3D na unidade de processamento (GPU) para vários aplicativos. O OpenGL permite a renderização rápida de visualizações (modo Rascunho rápido). https://helpx.adobe.com/br/after-effects/using/rendering-opengl.html
A construção da biblioteca OpenGL era definir um padrão entre os desenvolvedores de hardware e os desenvolvedores de software, de forma a permitir a evolução contínua do hardware sem entrar em conflito com o software. Dessa forma, a API OpenGL faz o "meio de campo" entre o programador que utiliza as funções da API e os mais variados hardwares de vídeo. Então, nós programadores de linguagens de alto nível (alto nível pois estamos longe do hardware) não precisamos nos preocupar se a placa de vídeo é Intel, NVidia ou Xingling, pois a compatibilidade é trabalho da equipe que desenvolve e implementa a API.
O núcleo do OpenGL é conhecido como "rendering pipeline" ou dutos de renderização. Podemos utilizar a biblioteca tanto para desenhos vetoriais, definidos por vértices, ou mapas de bits, desenhos construídos pixel-a-pixel.
Os desenvolvedores de hardware conseguem criar extensões, inovando e diferenciando seus produtos, sem a necessidade de alterar a biblioteca e as atualizações, raramente obrigam os usuários da API OpenGL a alterarem os seus códigos.
As extensões fornecem aos desenvolvedores de aplicativos os novos recursos de renderização e permite ir além das características especificadas na norma oficial do OpenGL (o padrão). Extensões da OpenGL mantém a API atual com as últimas inovações em hardware gráfico e algoritmos de processamento.
Por fim, a biblioteca OpenGL é vastamente utilizada, seja por navegadores, seja por sistemas operacionais ou Engines de Games. Na foto abaixo, temos um sistema utilizado em automóveis brasileiros de nome LGE sendo utilizado como biblioteca gráfica.

Tirei a foto no carro do meu amigo Daniel Mello quando esperavamos a pizza ficar pronta. O sistema operacional a princípio parece ser proprietário e é desenvolvido pela LG, porém, o código fonte está disponível segundo a documentação oficial, porém, não encontrei onde. No Brasil o sistema vem sendo chamado de Media Nav.
OpenGL, OpenGL ES 2.2 e Desktop GL
O framework Kivy está construido sob a API OpenGL ES 2.0 e possui muito do seu código-fonte escrito com a linguagem OpenGL que possui sintaxe identica a linguagem C. Os módulos de integração com a API OpenGL podem ser considerados o núcleo da biblioteca Kivy e também, o código mais complexo a ser estudado.
OpenGL® ES is a royalty-free, cross-platform API for full-function 2D and 3D graphics on embedded systems - including consoles, phones, appliances and vehicles. It consists of well-defined subsets of desktop OpenGL, creating a flexible and powerful low-level interface between software and graphics acceleration. OpenGL ES includes profiles for floating-point and fixed-point systems and the EGL™ specification for portably binding to native windowing systems. OpenGL ES 1.X is for fixed function hardware and offers acceleration, image quality and performance. OpenGL ES 2.X enables full programmable 3D graphics. OpenGL SC is tuned for the safety critical market. https://www.khronos.org/opengles/
Atualmente há vários subsets (versões derivadas) da biblioteca OpenGL. Por padrão (convenção), os principais Sistemas Operacionais voltados a dispositivos móveis utilizam a biblioteca OpenGL ES 2.0. Portanto, é comum falarmos que o projeto Kivy está construido sob a arquitetura OpenGL, porém, a biblioteca utiliza de fato uma versão derivada de OpenGL ES 2.0 e que é um acrônimo de OpenGL for Embedded Systems que numa tradução livre seria:
A seguir, temos os acrônimos seguido de seus nomes completos:
- OpenGL: Open Graphic Library - OpenGL ES: OpenGL for Embedded Systems - Desktop GL: Desktop Graphic Library
É comum nos referirmos ao OpenGL ES 2.0 como GLES2 e ao Desktop GL como OpenGL 2.0 minimum, então temos que:
- GLES2 = OpenGL ES 2.0 - Desktop GL = OpenGL 2.0 minimum)
GLES2 é um subset de OpenGL 2.0, com alguns poucos simbolos diferentes. O Kivy utiliza somente instrução instrução GLES2 que é compatível com GL.
- On Desktop (Win/Linux/OSX), a compilação é feita com Desktop GL (salvo se os cabeçalhos do GLES2 forem encontrados). Utilizamos PyGame e SDL somente para inicializar uma janela em sistemas Desktop como Mac e Windows, isso porque, o Kivy possui a sua própria Engine gráfica.
- No Android, temos o Java bootstrap que inicializa o contexto da janela/GLES2.
- No iOS, utilizamos o SDL 2.0, que suporta o contexto do iOS e do GLES2.
O Kivy não utiliza funções gráficas do sistema operacional hospedeiro, logo, os componentes/Widgets são desenhados do zero e portanto, aplicações Kivy, terão o mesmo visual em todas as plataformas. Essa é a parte boa. A parte ruim é que se desejarmos que o nosso App utilize o leiaute do sistema operacional hospedeiro, teremos que desenvolver por conta própria.
Existe versões em desenvolvimento que implementam o padrão gráfico do Material Design, e muito provavelmente, alguém já está desenvolvendo uma versão que utilize os padrões do iOS. Porém, é importante saber que esses são projetos de terceiros, por isso, não há suporte oficial.
É importante dizer que a biblioteca Kivy utiliza a API OpenGL ES 2.0, porém, está não é a última versão disponibilizada pela fabricante.
Para consultar a documentação do projeto OpenGL utilize este link.
A biblioteca Kivy é multiplataforma devido principalmente a biblioteca OpenGL. |
O PYTHON
A biblioteca inicialmente foi escrita para a versão 2x do Python e recentemente (2016) foi publicado o suporte experimental à versão 3x . Ainda que o suporte seja experimental, há casos de sucesso utilizando a versão 3x.
Mesmo assim, a versão do Python amplamente suportada ainda é a 2x e algumas plataformas, como por exemplo o Mac OSX, ainda não possuem suporte para gerar executáveis utilizando as últimas versões.
O desenvolvimento utilizando a versão 2x e 3x são iguais, salvo a manipulação de String que, na versão 2x do Python possui um tratamento diferente, ou seja, as cadeias de caracteres não são Unicode por padrão.
Projetos escritos com a versão 3x do Python podem ser convertidos para a versão 2x utilizando utilitários como por exemplo o 2to3 que, mesmo não sendo perfeito, resolve a maioria dos problemas de conversão.
Por fim, é importante dizer que o buildozer, projeto que gera executáveis para as mais diversas plataformas pode ser baixado junto com uma versão do Lubuntu para as versões 2x, ou seja, a forma mais utilizada na geração de executáveis ainda é a versão 2x.
A LINGUAGEM KIVY OU ENTÃO A kvlang
O projeto Kivy desenvolveu uma linguagem especializada e semelhante a linguagem Python para a construção de interfaces gráficas. O objetivo é facilitar a adição e remoção de Widgets (componentes visuais) ao mesmo tempo que separa o código utilizado para construção gráfica (View) do código Python, ou a lógica de negócios.
Num primeiro momento é impossível não pensarmos se realmente existe a necessidade de criar mais uma linguagem sendo que já existem tantas. Talvez somente na prática é que conseguimos perceber o quão útil foi o estabelecimento dessa nova linguagem que de fato não passa de uma linguagem de marcação, haja vista que somente pequenas expressões podem ser utilizadas.
Abaixo temos um trecho de código utilizando a kvlang e em seguida a tela que iremos obter quando executarmos.
FloatLayout:
TextInput:
text: "eXcript"
height: "30px"
width: 350
top: 100
size_hint: None, None
pos_hint: {'center_x': 0.5,}
Button:
text: "Confirmar"
height: 30
top: 60
size_hint: None, None
pos_hint: {'center_x': 0.5,}

A IDE Kivy Design

Kivy Design é um projeto de construção de uma IDE RAD para desenvolvimento de aplicações gráficas com Python utilizando a biblioteca kivy. A proposta é a construção do sonho de todos programadores: um ambiente de completo, estável, para a construção de aplicações, seja para o Prompt de Comando, seja para aplicações gráfica para Desktop, Mobile e Web.
O projeto Kivy Design objetiva fazer jus a todo o trabalho e esforço empreendido na construção da biblioteca Kivy e fornecer um ambiente para a construção de aplicações gráfica que tenha tanta qualidade como a biblioteca Kivy.
A IDE vem sendo desenvolvido, obviamente, com o framework Kivy, então, talvez este venha a ser a primeira IDE RAD (Rapid Application Development) multiplataforma e multidispositivo do mundo. O mais legal é que temos a oportunidade de participar do desenvolvimento da IDE e assim, trabalhar para construir uma ferramenta que seja como sempre desejamos que ela fosse.
Uma das razões do código do Kivy Design ser tão simples é que tudo ainda está no começo, por isso tanta simplicidade. E, essa é a parte boa, ou seja, temos a oportunidade de acompanhar o crescimento do código e ir assimilando naturalmente e participando da construção de um grande software!
ESTADO DO PROJETO Kivy Design
Neste momento, ainda que seja possível executar o projeto Kivy Design, não é recomendável sua utilização, até porque, o mesmo está caindo (travando) a todo momento.
Caso queiras se divertir, toda vez que Kivy Design travar, é impresso o local em que ocorreu o problema, logo, poder ir até lá e tentar corrigir. O interessante é que a maior parte das vezes em que o Kivy Design trava, o problema não está em seu código, mas sim, no código da biblioteca Kivy.
Falando de maneira geral, o framework Kivy não faz um forte tratamento e verificação quando novos valores são atribuido para propriedades de um Widget. Se a propriedade estiver esperando uma Tupla e for enviado um dicionário, ocorre um erro na biblioteca, o que acaba por derrubar toda a IDE. A princípio, e, pelo que entendi, os desenvolvedores não tem interesse de fazer esse tipo de tratamento por questões de performance.
PROJETO garden
O Projeto Garden centraliza componentes não oficiais de código-fonte aberto e distribuido sob a licença MIT desenvolvido por terceiros. Pense neste projeto como um centralizador de códigos de diferentes usuários cuja finalidade é distribuir e compartilhar módulos prontos para ser utilizado.
Todos os pacotes Garden estão armazenados no Github, dentro do projeto Kivy, ou seja, no mesmo local em que baixamos o código fonte da biblioteca Kivy.
O projeto Garden não está mais sendo entregue junto com o código do framework Kivy, por isso, agora, é necessário instala-lo manualmente. Para isso, vá no Terminal e digite:
pip install kivy-garden
Vale dizer que todos são incentivados a colaborar com os pacotes existentes ou então, pela criação de novos módulos independentes. Inclusive, existe um sistema de premiação simbólica para aqueles que tenham colaborado.
PROJETO Buildozer
O objetivo deste projeto, segundo a própria documentação oficial, é, através de um arquivo de nome "buildozer.spec" que contém uma lista de parâmetros que devemos definir, como por exemplo, título, ícone, módulos de terceiros (pacotes Python) e etc, gerar executáveis para as plataformas suportadas pelo projeto. Assim, definimos num único local as configurações do nosso App e em seguida, geramos um executável para a plataforma desejada.
É importante dizer que o projeto Buildozer não implementa como o App será gerado, o que o mesmo faz, é servir como uma aplicação comum que analisará as informações e passará ao projeto especializado na geração.
Então, não devemos pensar no Buildozer como um mega projeto que gera executáveis para várias plataformas, o seu principal objetivo é ler os valores definidos no arquivos "buildozer.spec" e envia-las ao projeto python-for-android ou ao projeto kivy-ios.
O suporte a outras plataformas está previsto, porém, não existe qualquer informação adicional publicada, muito menos data prevista.
PROJETO python-for-android
O projeto python-for-android é um subprojeto do projeto Kivy e seu objetivo é gerar executáveis para a plataforma Android.
Este projeto utiliza várias linguagens de programação, como por exemplo, C, C++, Cython, Python e Java. O C e o C++ são utilizados para trabalhar nativamente com a API do Android, o Android NDK . O Cython faz a conversão do código Python para código C nativo e o código Java é utilizado para acessar a API nativa do Android.
O App para a plataforma Android é gerada através de um projeto construído com o AndroidStudio onde uma parte é nativa, ou seja, escrita com C e C++, outra parte utiliza a linguagem Java, outra parte utiliza o projeto PyJNIus e claro, tudo isso está integrado com a linguagem Python.
Por essa razão, é correto dizer que o App gerado para a plataforma Android é nativo, até porque, o mesmo é construído através de um projeto nativo fornecido pela empresa desenvolvedora (a Google).
O código Python por nós escrito é compilado com o Cython, ou seja, um projeto que converte código Python para código C nativo, portanto, não é possível a terceiros ler, entender ou robar nossa implementação (facilmente).
Dentro do App gerado (*.apk) contém uma VM do Python modificada, ou seja, todo aplicativo gerado com o Python-for-Android irá contér uma versão do Python modificada, por isso, é possível enviar código Python que será interpretado no dispositivo ou então, o que é o padrão, enviar o código compilado em C otimizado para processadores ARM.
É incorreto dizer que aplicações escritas com a biblioteca Kivy são lentas ou então, que possuem baixa performance! Até porque, o Cython é um projeto amplamente respeitado por sua capacidade em converter código Python para código C puro altamente performático. E também, toda a parte gráfica é executada em cima da placa de vídeo, o que podemos facilmente deduzir, que a performance, algumas vezes, será superior ao código executado pelo processador na geração da parte gráfica.
Talvez, o lado negativo é o tamanho do App que neste momento está ficando em torno de 44 megas, o que é grande se comparado ao tamanho de um App desenvolvido com Java, porém, pequeno, se comparado a capacidade de armazenamento e processamento dos dispositivos móveis atuais.
Por fim, temos que TODA a API escrita em Java pode ser facilmente acessada via Python através do projeto PyJNIus que será explicado em seguida.
PROJETO PyJNIus
O projeto PyJNIus permite acessar a API nativa do Android disponibilizada em classes escritas em Java e que por detrás utiliza a linguagem C++. O PyJNIus acessa as classes em Java, portanto, podemos criar uma class Java e "mapea-la" com o projeto PyJNIus para ser utilizada com a linguagem Python.
Este projeto é semelhante ao JNI (Java Native Interface) que permite o acesso às classes escritas em Java por outras linguagens.
Dessa forma, conseguimos por exemplo, acessar a classe Intent do Android, ou então, a classe Activity e inclusive, conseguimos desenvolver uma aplicação que rode nativamente em cima da API Java do Android.
A seguir, temos um exemplo, retirado da documentação oficial do PyJNIus em que é feito o acesso a Activity do Android.
from jnius import cast
from jnius import autoclass
# import the needed Java class
PythonActivity = autoclass('org.renpy.android.PythonActivity')
Intent = autoclass('android.content.Intent')
Uri = autoclass('android.net.Uri')
# create the intent
intent = Intent()
intent.setAction(Intent.ACTION_VIEW)
intent.setData(Uri.parse('http://kivy.org'))
# PythonActivity.mActivity is the instance of the current Activity
# BUT, startActivity is a method from the Activity class, not from our
# PythonActivity.
# We need to cast our class into an activity and use it
currentActivity = cast('android.app.Activity', PythonActivity.mActivity)
currentActivity.startActivity(intent)
Observe que estamos utilizando a linguagem Python para trabalhar com classes escritas em Java!
Assim concluímos que a capacidade de desenvolvimento é ilimitada, até porque, podemos acessar nativamente tudo que a plataforma Android disponibiliza, seja através das classe em C++ pelo acesso via NDK,
PROJETO kivy-for-iOS
O projeto Kivy for iOS é semelhante ao projeto Python for Android a diferença é o suporte à plataforma iOS.
O App gerado para iOS é feito através de um projeto desenvolvido com o Xcode, portanto, no final, teremos uma aplicação nativa, da mesma forma que temos com o Android.
Internamente, o executável gerado também carregará uma versão otimizada o Python e por isso, é possível executar código Python no dispositivo em que a nossa aplicação estiver sendo executada. Normalmente, o nosso código será compilado com o Cython o que impedirá terceiros de ler e entender nossos códigos (facilmente), até porque, será gerado código C nativo.
O suporte a plataforma iOS não acompanha a plataforma Android, ou seja, uma aplicação híbrida construída com Python e Kivy conseguirá acessar melhor a API do Android do que do iOS (por enquanto).
Como dito anteriormente, não há suporte ao Python 3x para iOS, portanto, temos que converter nosso código escrito com Python 3x para 2x manualmente ou então, utilizando ferramentas como 2to3 disponibilizada oficialmente pelo projeto Python.
PROJETO PyObjus
O projeto PyObjus permite o acesso às classes escritas em Objective-C pelo Python. Desta forma, conseguimos o acesso nativo a toda a API do iOS através do código Python.
A seguir, temos um simples exemplos extraído da documentação oficial da PyObjnus.
from pyobjus import autoclass
NSString = autoclass('NSString')
text = NSString.alloc().initWithUTF8String_('Hello world')
print( text.UTF8String())
Como podemos ver, é importado a classe NSString e em seguida é armazenado o texto Hello World na mesma. Ou seja, desta forma, estamos trabalhando com a API nativa do iOS utilizando a linguagem Python! Portanto, conseguimos desenvolver aplicações que utilizam toda a API nativa da plataforma utilizando código Python.
COMPONENTES (WIDGET)
O framework Kivy contém um conjunto de componentes gráficos para a construção das telas de interação com o usuário. A documentação do Kivy chama os componentes de Widgets, ou seja, um botão é um Widget, um caixa de entrada de texto é um Widget e assim por diante.
Existe um conjunto de Widgets bastante amplo que vem de fábrica. Os componentes visuais estão em pleno desenvolvimento e portanto, a cada nova versão, muitos recursos são adicionados. Neste momento, se compararmos os recursos da biblioteca Kivy com plataformas comerciais e consagradas tais como o Embarcadero Delphi (Rad Studio), Qt5 ou Xamarin, o Kivy fica numa posição bem inferior, porém, isso é uma questão de tempo e de desenvolvimento. A capacidade para que o Kivy disponha de componentes visuais tais como o Xamarin ou então o Embarcadero Delphi é uma questão de tempo!
O Kivy seguiu o estilo utilizado pelo Sistema Operacional Moblin e, a verdade, é que estetícamente a biblioteca ainda deixa a desejar.
Aparentemente, a equipe do Kivy dedica seus esforços à construção do núcleo do framework o que é muito bom, pois, a complexidade para melhorar a aparência visual é mínima se comparada com a implementação dos módulos que interagem com os periféricos.
Há iniciativas de construção de bibliotecas gráficas independentes como por exemplo o KivyMD, acrônimo de Kivy Material Design. Essa biblioteca está construída em cima do framework Kivy e entrega um conjunto de componentes ricos em recursos e propriedades utilizando o visual nativo do Android, no caso, o Material Design.
Por fim, é importante lembrar que o foco dos grupo que desenvolve o framework Kivy é, num primeiro momento, fornecer total compatibilidade com as plataformas suportadas. Por essa razão, o foco do desenvolvimento não está direcionado com a aparência dos Widgets e nem na quantidade de recursos que cada componente possui. Ao que tudo indica, o principal objetivo é fazer com que todos os recursos de todas as plataformas funcionem sem quaisquer problema - o que é excelente!

GAMES
O framework Kivy, como já dito várias vezes, foi desenhado para ser executado sob a placa gráfica e inclusive, no modo de aceleração gráfica. A biblioteca entrega um módulo para a construção gráfica bastante completo estando assim, uma camada acima da API OpenGL.
O módulo gráfico que fornece as classes e funções para o desenho vetorial 2D pode ser utilizado com a linguagem Kivy, o que nos permite por exemplo, declarar um círculo e definir a propriedade raio. Ou seja, criamos imagens vetoriais facilmente e com uma linguagem de marcação, semelhante ao que temos com o formato de imagem SVG (Scalable Vector Graphics).
O suporte a renderização de imagem é excelente e, tendo como aliado bibliotecas gráficas como OpenCV (Open Source Computer Vision Library) é possível tratar imagem sendo o limite a imaginação.
ÁUDIO E VÍDEO
O suporte a áudio e a vídeo são implementações estáveis e bastante testadas. Há inclusive player musicais construidos só com as bibliotecas nativas do Python. Inclusive, há suporte a Stream, tanto de áudio como de vídeo.
Um exemplo interessante é o Widget Image que renderiza imagens no Path local ou remoto, abstraindo todo o donwload e abertura dos desenvolvedores finais.
PROJETO KivEnt
O projeto KivEnt é um subprojeto do projeto Kivy voltado para o desenvolvimento de games e aplicações gráficas interativas em tempo real.
Esse é uma projeto que vem sendo desenvolvido, principalmente, por outro grupo de desenvolvedores, porém, é um repositório do projeto Kivy.
Toda a biblioteca vem sendo construida com a linguagem Python e os módulos que normalmente são responsáveis pelos gargalos, utilizam a linguagem Cython, conseguindo assim, performance semelhante ao que temos com a linguagem C.
O núcleo do KivEnt é a biblioteca Kivy, ou seja, a parte principal da Engine não possui dependencias.
Alguns módulos em especifico utilizam a biblioteca Chipmunk2D que é um uma simples, leve e rápida plataforma para corpos 2D rígido e que facilita a implementação da matemática, ou seja, a física do game.
Sendo o Chipmunk2D escrito em C, há uma versão em Cython disponibilizando um bind fácil e rápido para utilização com Python. A plataforma está disponibilizada com a licença MIT.
A MÁGICA DO CYTHON
Cython é um superconjunto da linguagem Python e seu objetivo é a conversão de código Python para código C (nativo). Cython é o nome de uma linguagem e também, o nome do compilador. A linguagem Cython estende a linguagem Python utilizando a mesma sintaxe, porém, trazendo um conjunto de instruções que otimizam a conversão para código C, aumentando a performance em alguma situações em dezenas, centenas e até, acredite, milhares de vezes! O principal objetivo da linguagem Cython é a otimização de trechos especificos que requerem alta performance sem quebrar a compatibilidade. Como o código Python nativo é reconhecido pelo compilador Cython, é possível a conversão de módulos ou mesmo funções sem perder a compatibilidade.
O Cython fornece suporte a versão 2x e 3x do Python, ou seja, conseguimos facilmente transformar as estruturas simplificadas do Python para código C nativo e sendo capaz de otimizar trechos especificos através de um processo muito semelhante a refatoração de código. A refatoração neste caso deve ser entendida como a alteração de instruções, tipagem de variáveis e parâmetros e etc.
Após converter o código de Python para C, o resultado é enviado para o GCC e o mesmo produz o executável compatível com a plataforma em que estiver sendo utilizada, pela simples compilação de código C, de forma semelhante e com performance que chega muito próxima a um código que foi de fato escrito nativamente em C.
Como principais características, podemos citar que a linguagem Cython utiliza tipagem estática e dinâmica, e, como sabemos, quando mais tipado for, mais otimizado a execução será.
Por fim, conseguiremos em algumas situações uma melhora na performance de até 5000 vezes! Inclusive, na página do projeto é possível encontrar várias ferramentas e códigos para que possamos mensurar em nosso computador.
A seguir, temos um exemplo de um simples trecho de código utilizando somente a linguagem Cython.
DECLARAÇÃO DE VARIÁVEIS COM CYTHON
cdef int i, j, k
cdef float f, g[42], *h
cdef struct Grail:
int age
float volume
DECLARAÇÃO DE CLASSE E FUNÇÃO EM CYTHON
cdef class A:
cdef foo(self):
print "A"
ALOCAÇÃO DE MEMÓRICA EM CYTHON
import random
from libc.stdlib cimport malloc, free
def random_noise(int number=1):
cdef int i
# allocate number * sizeof(double) bytes of memory
cdef double *my_array = <double *>malloc(number * sizeof(double))
if not my_array:
raise MemoryError()
try:
ran = random.normalvariate
for i in range(number):
my_array[i] = ran(0,1)
return [ my_array[i] for i in range(number) ]
finally:
# return the previously allocated memory to the system
free(my_array)
O KIVY E O CYTHON
A biblioteca Kivy está debruçada sobre o Cython e todo código que escrevemos será compilado para código C. Os principais módulos da biblioteca estão escritos com Cython e utilizando tipagem estática com a finalidade e obter máxima performance.
Porém, a maior parte da biblioteca não possui qualquer otimização, até porque, o objetivo é utilizar a linguagem Python. Por isso, podemos melhorar a performance das aplicações construídas com Kivy, bastando somente, converter as principais estruturas da biblioteca Kivy para código Cython.
Converter código Python para Cython com a finalidade de obter uma melhor performance é uma atividade relativamente simples e pouco sujeito a erros, é uma solução para aqueles momento em que realmente precisamos de muita performance e, acredito que num futuro breve, várias partes da biblioteca serão convertidas a cada nova versão se houver empresas interessas em obter uma excelente performance.
Essa é mais uma das vantagens de trabalhar com a biblioteca Kivy! Temos a capacidade de melhorar a performance facilmente da nossa aplicação, o que normalmente não acontece com outras bibliotecas.
CÓDIGO-FONTE
Uma das principais dúvidas em relação ao uso da biblioteca Kivy é o acesso e eventual roubo do código-fonte da nossa aplicação por terceiros. A resposta a essa dúvida é: o código Python ou o bytecode gerado (código otimizado) não precisa ser distribuído junto com a sua aplicação, pois o projeto Kivy disponibiliza ferramentas que geram executáveis nativo - código binários e otimizado para cada plataforma. Resumidamente, temos que o Python foi concebido como sendo uma linguagem interpretada, ou seja, todo computador capaz de rodar um Script Python, precisa antes instalar o interpretador. Um interpretador, como o nome sugere, é um programa nativo, especializado no reconhecimento de código Python, é executado em segundo plano (background), inicializado junto com o sistema operacional, por padrão fica inativo esperando o recebimento de código. Essa é a forma tradicional de execução de programas ou Scripts Python.
Comumente dizemos que o interpretador do Python executado código Python, mas isso não é verdade. Por padrão, o código Python é transformado numa estrutura hierarquica otimizada chamada de bytecode. A geração de bytecode é realizada na primeira execução do Script e armazenada numa pasta que será criada no mesmo diretório em que o arquivo que contém código Python está armazenado.
A metodologia de gerar bytecode com a finalidade de otimização e armazena-lo num arquivo no mesmo diretório é um padrão utilizado por diversos interpretadores de outras linguagens. Ainda que essa prática melhore significativamente o desempenho, fica muito distante se comparado com a execução de código nativo.
Como dito, as aplicações Kivy são executadas pelos processadores de aceleração gráfica e portanto, é preciso converter todos os nossos códigos para o "idioma" do mundo gráfico.
É importante dizer que o fato do código Python ser interpretado se deve a uma opção de projeto e não de uma imposição inerente a tecnologia ou a linguagem! Simplesmente, num primeiro momento, optou-se por interpretar, ao invés de gerar um executável. Portanto, conforme a linguagem foi sendo desenvolvida e sua sintaxe criada, o pessoal do projeto foi desenvolvendo com a C uma aplicação capaz de interpretar as instruções e a sintaxe da linguagem.
O tempo passou, a linguagem se popularizou, e surgiram propostas de, ao invés de interpretar o código, porque não transformar o mesmo em executáveis?
Ao desenvolvermos com Kivy, temos que o nosso código é interpretado durante o desenvolvimento, porém, quando formos distribuir a nossa aplicação, por exemplo, para a plataforma Android, o código Python que escrevemos e código Python/Cython do framework Kivy serão transformados em código C puro!
Concluído a conversão, o código C produzido poderá ser compilado por qualqauer compilador C de sua preferência.
Por fim e reafirmando o que já foi dito, a biblioteca Kivy possui ferramentas para que o código seja ocultado naturalmente.
LIVROS PUBLICADOS
- *Creating Apps in Kivy - Mobile with Python* (Dusty Phillips) (2014) (O'Reilly Media)
- *Kivy Blueprints* (Mark Vasilkov) (2015) (PacktPub)
- *Kivy Cookbook* (Hugo Solis) (2015) (PacktPub)
- *Kivy: Interactive Applications in Python* (Roberto Ulloa) (2013) (PacktPub)
- *Kivy - Interactive Applications and Games in Python* (Second Edition) (Roberto Ulloa) (2015) (PacktPub)
PONTOS NEGATIVOS
Há inúmeros pontos negativos no framework Kivy e o objetivo da eXcript não é em momento algum mascara-los ou então, promover cegamente determinada tecnologia. A seguir, pretendemos discutir e sempre mostrar os 2 lados da discussão.
O QUE SIGNIFICA APLICAÇÃO NATIVA?
Executáveis gerados com ferramentas do projeto Kivy realmente são aplicações nativas, até porque, o sistema operacional para o qual o executável foi gerado executa o arquivo sem a necessidade de qualquer outro aplicativo.
Talvez seja importante nos perguntarmos o que é uma aplicação nativa e quais seriam as características que essas aplicações deveriam ter para serem assim classificadas.
Uma aplicação pode ser considerada nativa somente porque seu executável é reconhecido pelo SO hospedeiro?
Uma aplicação para ser considerada nativa, deve utilizar as bibliotecas e recursos do SO hospedeiro?
QUÃO NATIVO SÃO OS EXECUTÁVEIS GERADOS PELO PROJETO KIVY?
Visando o desenvolvimento de aplicações multiplataforma, a biblioteca Kivy NÃO utiliza a maior parte das bibliotecas fornecidas pelo SO hospedeiro. Até porque, cada plataforma disponibiliza uma interface de acesso diferente e assim, o projeto Kivy precisaria conhecer e se adaptar a cada SO a fim de utilizar suas bibliotecas.
Utilizar as bibliotecas nativas de cada plataforma, normalmente é, a melhor forma de construção de aplicações para a mesma. Ou seja, a melhor forma de criarmos aplicações para o SO Microsoft Windows é utilizando, por exemplo, suas bibliotecas gráficas, o seu sistema de arquivo, as suas caixas de diálogo nativas e etc.
O projeto Kivy raramente utiliza as ferramentas disponibilizadas pela plataforma hospedeira! Em cada executável gerado pelas ferramentas do projeto Kivy, é adicionado TODAS AS ferramentas que a aplicação precisará ou possa vir a precisar. Isso é comumente chamado de "reinvenção da roda", até porque, pra que refazer o que já está pronto? Pra que tornar o executável mais "pesado" adicionando implementações que podem ser acessadas diretamente na plataforma?
Na minha opinião, este é o maior problema do projeto Kivy, até porque, podemos dizer que estamos utilizando uma gambiarra! Pois, ao invés dos nossos programas funcionarem como o fabricante do Sistema Operacional determinou, estamos fazendo tudo ao nosso modo e da nossa maneira.
MAS CALMA AI! TODO DESENVOLVIMENTO híbrido é por natureza, definição e implementação uma gambiarra. Portanto, o Kivy é somente mais uma gambiarra, tecnologias como Xamrian, Sencha Touch, Phonegap, Intel XDK e tantas outras opções...
Podemos dizer que a melhor forma de usar um produto é seguindo as normas do fabricante, como também, utilizar as ferramentas por ele disponibilizado. Ainda que essa ideia não possa ser considerado um regra, na maior parte dos caso é. As ferramentas produzidas pelo fabricante foram feitas pelas mesmas pessoas ou por uma equipe próxima ao engenheiros responsáveis da plataforma e estes são, sem qualquer duvida, especialistas no funcionamento da tecnologia.
Portanto, isso é uma verdade que não podemos ignorar! A melhor maneira de construir aplicações para uma plataforma é utilizando as ferramentas nativas ou seguindo as especificações e diretrizes oficiais do fabricante.
Então, quando dizemos que é gerado um executável nativo, estamos realmente falando a verdade, porém, de nativo há somente a tela inicial, pois o restante, trata-se de simulação e emulação.
Gigantes como Microsoft, Adobe e Intel possuem suas próprias "gambiarras" e comercializam ferramentas que geram executáveis híbridos da mesma forma, mas de uma maneira diferente que o projeto Kivy o faz!
A pergunta que devemos responder é: "uma aplicação pra ser realmente nativa, deve gerar um executável através da ferramenta do fabricante e utilizar as bibliotecas por este disponibilizado"?
UTILIZAÇÃO DE RECURSO
Aplicações escritas com o framework Kivy utilizam mais recursos do dispositivo e aplicações que precisam ser executadas em background devem realizar testes de consumo de energético antes de iniciar o desenvolvimento.
A biblioteca Kivy é executada em cima da placa de vídeo com a aceleração de vídeo ligada. Se o código fosse executado em cima do processador do dispositivo, haveria garga-los na renderização e é graças a aceleração de vídeo que há tantas ferramentas de desenvolvimento híbridas.
Por fim, uma aplicação construída com o Kivy irá consumir maior carga energética e utilizará aproximadamente 20 mega de memória RAM. Com relação a memória RAM não há preocupação, até porque, a maior parte dos dispositivos atuais possuem quantidades generosas de memória RAM. Porém, o uso da bateria deve ser considerado e a única forma que você possui pra realmente ter certeza se o seu projeto pode ser construído com o Kivy será através da realização de testes.
TEMPO DE ABERTURA
Aplicações Kivy possuem um tempo de carregamento maior quando comparado a aplicações nativas. A razão pelo tempo adicional se deve ao carregamento de bibliotecas e a inicialização de uma Máquina Virtual Python, ou seja, uma versão compacta do interpretador do Python.
O tempo de abertura da aplicação tende a desaparecer com o tempo em vista da evolução do hardware
WIDGETS NATIVOS
A biblioteca Kivy, ao contrário de outras biblioteca gráficas, não disponibiliza um conjunto de Widgets amplo e robusto para a construção de telas que permitam a entrada de dados pelo usuário.
O foco da equipe é disponibilizar um framework que possas ser executado em várias plataformas nativamente e uma interface para acesso ao hardware simples e padronizada. Por isso, num primeiro momento, alguns usuários podem se decepcionar ao conhecer o catalogo de componentes.
Há alguns projetos paralelos como o KivyMD que estão construindo mega pacotes de componentes seguindo um esquema de cores e estilos como por exemplo, o Material Design da Google.
Portanto, a pequena quantidade de Widgets e a sua simplicidade não são um problema, mesmo assim, num primeiro momento, muitos usuários acabam frustrados com a pequena gama de opções.
O KIVY É UM PROJETO EXPERIMENTAL?
É comum que algumas pessoas sugiram que o framework Kivy seja um trabalho experimental ou então, um projeto que ainda está no início e ninguém sabe exatamente o seu futuro.
O Kivy não pode mais ser considerado um projeto experimental! Nesse momento, a única coisa que o projeto não possui é uma grande empresa por detrás financiando-o (ainda).
Na atual conjuntura, softwares desenvolvidos com o framework Kivy rodam em todas as plataformas que possuem suporte e nenhum problema de ordem maior vem sendo relatado. Obviamente que ainda existe muito a ser feito, principalmente em relação a compatibilidade entre todas as plataformas igualmente. No entanto, o desenvolvimento é contínuo e estável e, para ter certeza disso, basta analisar a lista de Commits do projeto no Github e analisar a quantidade de problemas relatados.
O autor entende por experimental aquilo que não possui um funcionamento estável e previsível e portanto não deveria ser utilizado em projetos comerciais e sérios.
Inclusive, neste momento, há grandes aplicações escritas em Kivy e que estão funcionando perfeitamente, vide o projeto TriFusion .
DEMAIS
O blog Caderno de Laboratório foi o primeiro blog brasileiro a disponiblizar vários tutorias e diversos exemplos sobre como utilizar a biblioteca Kivy. O pessoal continua produzindo mais artigos sobre o Kivy e em Português, por isso, vale a pena conferir!
CASOS DE SUCESSO
A seguir temos uma breve lista de alguns projetos que servem para demonstrar o poder ilimitado do framework Kivy.
RaceCaptureApp ´´´´´´´´´´´´´´
site: | https://www.autosportlabs.com/tag/race-capture-app/ |
---|---|
source: | https://github.com/autosportlabs/RaceCapture_App |
playstore: | https://play.google.com/store/apps/details?id=com.autosportlabs.racecapture |


O aplicativo RaceCaptureApp é uma aplicação embarcada que envia os dados dos pilotos em uma corrida e exibindo em uma outra aplicação em tempo real.
Este aplicativo é amplo, possui dezenas de aperfeiçoamentos, faz uso direto das API dos vários dispositivos e é amplamente utilizado.
https://github.com/autosportlabs/RaceCapture_App
Kognitivo ´´´´´´´´´
site: | http://cheparev.com/kognitivo-challenge-your-brain/ |
---|---|
source: | https://github.com/eviltnan/kognitivo |
playstore: | https://play.google.com/store/apps/details?id=org.kognitivo.kognitivo |

O Kognitivo é um jogo bastante inteligente e a aplicação na época do seu lançamento trouxe bastante implementações e integrações que nenhuma outra aplicação havia realizado.
No final do ano de 2017 seu código fonte foi liberado no Github de forma que possamos estudá-lo.
https://github.com/eviltnan/kognitivo.git
TriFusion ´´´´´´´´´
site: | http://odiogosilva.github.io/TriFusion/ |
---|---|
source: | https://github.com/ODiogoSilva/TriFusion |

Este talvez seja o projeto de código aberto utilizando o Kivy de maior relevância. Segundo a própria descrição do projeto que, mesmo sendo desenvolvido por um instituto de pesquisa Português e o desenvolvedor principal também ser Português, toda a documentação do software está em Inglês.
A seguir, temos uma tradução adaptada de como o próprio projeto se descreve.
TriFusion é uma GUI moderna e uma aplicação de linha de comando projetada para facilitar a vida de qualquer pessoa com dados de sequência de proteoma e/ou alignment sequence data mais prazerosos. Independentemente da sua experiência em bioinformática, o TriFusion é fácil de usar e oferece uma grande variedade de recursos poderosos para ajudá-lo a lidar com seus dados. Ao mesmo tempo, foi desenvolvido para lidar com a enorme quantidade de dados gerados hoje em dia.
No site do projeto é possível baixar toda a documentação e possuir instalador para Windows, Linux e Mac.
KIVY 3D
O Kivy possui excelentes recursos para trabalhar com imagens em 3D. Inclusive, existe uma versão especializada e destinada somente para essa finalida. Nos links a seguir, você encontra mais informações.

LINKS EXTERNOS
- Site do projeto Kivy (en)
- Repositório no Github do projeto Kivy (en)
- Código-Fonte da biblioteca Kivy (en)
- OpenGL (en)
- Projeto KivyMD: Kivy Material Design (en)
- Android NDK (en)
- Repositório Buildozer
- Repositório Plyer
- Repositório PyJNIus
- Repositório PyObjus
- Repositório Python for Android
- Repositório Kivy for iOS
- Repositório Audiostream
- Repositório Kivy Designer
- Repositório KivEnt
- Repositório Garden
- PyCharm (en)
- AndroidStudio (en)
- Xcode (en)
- Cython (en)
- JNI (Java Native Interface) (en)
- 2to3: Conversor de código escrito em Python2x para Python3x (en)
Tags python, kivy, android, ios, kivy design, opengl, blog
Comentários
comments powered by Disqus