Neste artigo será apresentado o projeto que permite o desenvolvimento multiplataforma com Python utilizando o framework Kivy.

INTRODUÇÃO

Logo oficial do projeto Kivy

A biblioteca Kivy é um framework para desenvolvimento multiplataforma, escrito majoritariamente com a linguagem Python e/ou Cython e que permite o desenvolvimento de aplicações para diversos sistemas operacionais, tais com, Microsoft Windows, Linux, Mac, Android, iOS, Raspberry utilizando um mesmo código.

O projeto Kivy é composto por vários subprojetos, cada um especializado numa determinada tarefa, como por exemplo, gerar executável para determinada plataforma ou então, uma interface que permite o acesso ao hardware em várias dispositivos com diferentes sistema operacional utilizando um mesmo código.

É importante não confundir a projeto Kivy com a biblioteca Kivy. O projeto Kivy, cujo site é http://kivy.org é composto por vários subprojetos, dentre estes, a biblitoeca Kivy.

A BIBLIOTECA KIVY

A biblioteca Kivy contém o código de UI (User Interface) interface de usuário multiplataforma executado sob a biblioteca OpenGL. Toda parte gráfica da biblioteca é executado em cima da placa de vídeo, por essa razão, a performance em algumas situações chega a ser superior a renderização nativa de alguns sistemas operacionais.

Em vista de que a biblioteca OpenGL é multiplataforma, o projeto Kivy, construído em cima dessa camada, pode ser executado em qualquer dispositivo que possua suporte com a biblioteca OpenGL.

OpenGL 2.0

OpenGL é uma API e uma linguagem de programação multiplataforma e OpenGL é um acrônimo de Open Graphics Library`, numa tradução livre seria Biblioteca Gráfica Aberta. O seu uso permite o fácil desenvolvimento de aplicações gráficas, inclusive com ambientes 3D que podem ser executado em praticamente todos sistemas operacionais e nos principais dispositivos. A biblioteca é amplatamente utilizada em jogos e em tudo que esteja relacionado com gráficos.

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

Essa biblioteca tem como objetivo 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 harwares 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.

Sistema operacional LGE como item de fábrica em carros da Renault brasileiros. O sistema é comumente chamado de Media Nav.

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 utlizam a biblioteca OpenGL ES 2.0. Portanto, é comum falarmos que o projeto Kivy está contruído 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 operacinal 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 hospeiro, 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.

KIVY DESIGN

Imagem do editor Kivy Design

Kivy Design é um projeto de construção de uma IDE RAD para desenvolvimento de aplicações gráficas com Python utilizando a biblitoeca kivy. A proposta é a construção do sonho de todos programadores: um ambiente de completo, estável, para a construção de apliçõ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) multiplaforma e multidispositivo do mundo. O mais legal é que temos a oportunidade de participar do desenvolimento 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.

Segue o link do repositório no Github.

PROJETO Buildozer

O projeto Buildozer é uma ferramenta para facilitar a geração de App para as várias plataformas suportadas pelo projeto Kivy .

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 lingaugem 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() # --> Hello world

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 de telas, chamados de Widgets para fácil e rápida construção de janelas que interam gráficamente com o usuário. Todos widgets possuem excelente integração com os OS compatíveis.

De fábrica, encontramos os principais controles, como caixas para entrada de texto, botões, rótulos (label), imagem e etc. PORÉM, tratando de quantidade de recursos não há comparação com plataformas como VisualStudio, Embarcadero Delphi/C++, Qt5 ou Xamarin.

Mesmo assim, há bibliotecas de terceiros como o KivyMD, acrônimo de Kivy Material Design que entregam um conjunto bastante rico de elementos visuais seguindo a normatização definida oficialmente.

Por fim, é importante lembrar que o ponto forte do projeto Kivy é sua fácil integração com a API gráfica tornando uma ferramenta fácil para o desenvolvimento gráfico, seja de controles de telas ou mesmo de jogos.

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 de programação Python e o objetivo é converter código Python para código C (nativo). Cython é tanto um compilador como tamnbém uma linguagem de programação que estende a linguagem Python com a finalidade de mesclar as estruturas da linguagem C com as estrutura da linguagem Python.

O Cython compila qualquer código Python, ou seja, o mesmo transforma qualquer código Python para código C nativo. Em seguida, o GCC faz o restante do trabalho, compilando código C e gerando um executável nativo à plataforma onde está sendo executado.

A linguagem Cython trabalha com tipagem estática e dinâmica, porém, quando mais tipado for o código, mais otimizado será sua execução. Um código Python otimizado com a linguagem Cython pode rodar até 5000 vezes mais rápido. Na página do projeto você pode encontar mais gráficos e testes de permormances.

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 biblitoecas.

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 fabricamente 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"?

CONSUMO 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 utlizará aproximadamente 40mg 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.



Tags python, kivy, android, ios, kivy design, opengl, blog

Comentários

comments powered by Disqus