Quando a Kony está sendo utilizada para o desenvolvimento de uma aplicação, quase sempre a intenção é criar versões do app para diferentes sistemas operacionais. Este é, inclusive, um dos <a style="color: #ff6600;" href="https://dtidigital.com.br/blog/kony-a-desenvolvedora-multiplataforma-de-apps-mobile-lider-no-quadrante-magico-do-gartner/">principais atrativos da plataforma</a>.
A portabilidade, contudo, pode ser muito trabalhosa, a menos que alguns cuidados sejam tomados. Algumas das dores de cabeça mais comuns que ocorrem durante a portabilidade podem ser evitadas ou solucionadas com as dicas de portabilidade listadas neste post.
<div id="toc_container" class="toc_white no_bullets">Sum&aacute;rio<ul class="toc_list"><li><a href="#CONSTRUCAO-DO-LAYOUT-O-PERIGOSO-FORK-DE-SKINS">1 CONSTRUÇÃO DO LAYOUT: O PERIGOSO FORK DE SKINS</a></li><li><a href="#O-PROBLEMA-DAS-FONTES">2 O PROBLEMA DAS FONTES</a></li><li><a href="#CUIDADO-COM-AS-FFIs-FOREIGN-FUNCTION-INTERFACES">3 CUIDADO COM AS FFIs (FOREIGN FUNCTION INTERFACES)</a></li><li><a href="#AINDA-NAO-ESTA-FUNCIONANDO">4 AINDA NÃO ESTÁ FUNCIONANDO?</a><ul><li><ul><li><a href="#Por-Silverio-Vale">4.0.1 Por: Silvério Vale</a></li><li><a href="#Revisao-Jessica-Saliba">4.0.2 Revisão: Jéssica Saliba</a></li></ul></li></ul></li></ul></div>
<h3 style="text-align: justify;">CONSTRUÇÃO DO LAYOUT: O PERIGOSO FORK DE SKINS</h3>
Talvez a grande maioria dos problemas encontrados durante a portabilidade da aplicação estejam relacionados com o layout. Alguns exemplos são:
<ul style="text-align: justify;">
<li>Letras grandes, pequenas, com cores e fontes diferentes do esperado;</li>
<li>Botões azuis, vermelhos, tão diferentes daqueles presentes na versão original;</li>
<li>Componentes distorcidos;</li>
</ul>
Estes e vários outros problemas podem ser causados e/ou solucionados pela mesma funcionalidade: o fork de skins – o chaveamento do estilo dos componentes de acordo com o sistema operacional.
Este chaveamento pode, muitas vezes, ser não intencional e provocar comportamentos inesperados, como os listados acima. Para evitar que isso ocorra é preciso conferir, sempre que se estiver criando uma skin que não seja específica para nenhuma plataforma, se a propriedade Platform está definida como Common. A Figura 1 destaca a propriedade mencionada.
<figure id="attachment_406" aria-describedby="caption-attachment-406" style="width: 234px" class="wp-caption aligncenter"><a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/09/kon1.png"><img fetchpriority="high" decoding="async" class="size-full wp-image-406" src="https://dtidigital.com.br/wp-content/uploads/2015/09/kon1.png" alt="Figura 1 - Skin Platform" width="234" height="217" /></a><figcaption id="caption-attachment-406" class="wp-caption-text">Figura 1 &#8211; Skin Platform</figcaption></figure>
Muitas vezes a propriedade é alterada sem que o usuário perceba, chaveando a skin para um sistema específico. Quando a aplicação é portada para outro sistema, aquela skin não é utilizada, fazendo com que o componente fique com o layout distorcido.
Em outras situações, o chaveamento de skins pode ser a solução para problemas visuais de portabilidade. Um exemplo comum é o tamanho das fontes. Muitas vezes, as letras ficam muito grandes ou pequenas em diferentes sistemas operacionais. A solução é chavear a skin daquele componente, definindo um tamanho específico para cada sistema.
<h3>O PROBLEMA DAS FONTES</h3>
Um problema que pode causar muita dor de cabeça é quando algum sistema operacional não reconhece uma fonte que está sendo utilizada pela aplicação. A fonte foi importada, está selecionada para a plataforma em questão, mas simplesmente não aparece quando o app está rodando.
A solução para este problema é bastante simples, mas não tão intuitiva: O arquivo da fonte deve ser renomeado de acordo com uma nomenclatura específica, levando em conta o nome e o tipo da fonte.
Por exemplo: Deseja-se utilizar uma fonte em negrito chamada Minha Fonte. O arquivo da fonte deve ter o nome MinhaFonte-Bold. Se um nome diferente for utilizado – como minhafonte-bold, minhafontebold ou minha_fonte_bold – a fonte não será reconhecida em todos os sistemas operacionais.
<h3>CUIDADO COM AS FFIs (FOREIGN FUNCTION INTERFACES)</h3>
Às vezes vale a pena reforçar o óbvio. As FFIs são módulos desenvolvidos em linguagem nativa, utilizadas para adicionar ao app alguma funcionalidade que o Kony não disponibiliza. Sendo assim, as FFIs devem ser desenvolvidas para cada um dos sistemas operacionais que deverão suportar a aplicação.
Por este motivo, sempre que se deseje fazer uso de uma FFI, é preciso verificar de antemão se as APIs nativas que ela utiliza existem e são acessíveis em todos os sistemas operacionais.
Por exemplo: A API nativa de speech-to-text (reconhecimento de voz) pode ser utilizada livremente na plataforma Android. Já no iOS, as aplicações não possuem permissão completa para utilizar este componente. Imagina-se, então, o quão grande será a dor de cabeça de um desenvolvedor que projetou um app que utiliza speech-to-text e só descobriu este “detalhe” no momento de efetuar a portabilidade para o iOS.
<h3>AINDA NÃO ESTÁ FUNCIONANDO?</h3>
É possível que o comportamento de algumas APIs seja diferente em cada sistema operacional. Um exemplo é a API de notificações push. Também é possível que existam bugs específicos para determinada plataforma, ou até mesmo que a intenção do desenvolvedor seja obter um resultado diferente para cada sistema.
Nestes casos, sempre se pode recorrer ao pré-compilador. O Kony Studio permite que sejam inseridos trechos no código que só serão compilados para uma plataforma específica. Isto pode ser feito com //#ifdef como exemplificado a seguir:
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/09/kon2.png"><img decoding="async" class="size-full wp-image-407 aligncenter" src="https://dtidigital.com.br/wp-content/uploads/2015/09/kon2.png" alt="kon2" width="489" height="217" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2015/09/kon2.png 489w, https://www.cms.dtidigital.com.br/wp-content/uploads/2015/09/kon2-300x133.png 300w" sizes="(max-width: 489px) 100vw, 489px" /></a>
No exemplo acima, o primeiro alerta é compilado para dispositivos Android enquanto o segundo alerta é compilado para dispositivos iOS. Estes //#ifdef podem ser inseridos em qualquer parte dos módulos javascript, permitindo o chaveamento do código em função do sistema operacional.
Com estas dicas em mente, a portabilidade da aplicação fica mais rápida e menos dolorosa, permitindo que mais tempo seja gasto desenvolvendo o app do que portando ele para outras plataformas. Agora, se estiver interessado em <a style="color: #ff6600;" href="https://dtidigital.com.br/blog/como-fazer-seu-app-se-comunicar-com-o-mundo/">fazer seu aplicativo se comunicar com o mundo</a> por meio de serviços, veja como funciona <a style="color: #ff6600;" href="https://dtidigital.com.br/blog/como-fazer-seu-app-se-comunicar-com-o-mundo/">aqui</a>.  Ainda tem alguma dúvida sobre portabilidade e desenvolvimento mobile? Entre em <a style="color: #ff6600;" href="http://www.dtisistemas.com.br/#contato">contato</a> com a gente.
<h5 style="text-align: justify;">Por: Silvério Vale</h5>
<h5 style="text-align: justify;">Revisão: Jéssica Saliba</h5>

O que é a Plataforma Kony: Dicas e Portabilidade

Desbloqueie o futuro do seu negócio

Confira outros artigos