No horizonte, mudan\u00e7as est\u00e3o se manifestando. E essas mudan\u00e7as tornar\u00e3o o desenvolvimento de UI5 uma habilidade bastante obsoleta.<\/p>\n\n\n\n
Para muitos desenvolvedores, o desenvolvimento freestyle UI5 \u00e9 a abordagem preferida para criar um novo app UI5. \u00c9 uma escolha popular entre os desenvolvedores UI5 por v\u00e1rias raz\u00f5es. Primeiro, o desenvolvimento freestyle UI5 \u00e9 a maneira original de criar apps UI5. Outra raz\u00e3o \u00e9 que a experi\u00eancia geral do desenvolvedor para apps freestyle aumentou drasticamente na \u00faltima d\u00e9cada. As ferramentas dispon\u00edveis hoje ajudam enormemente. Muitas tarefas que tornavam o desenvolvimento de UI5 bastante complicado foram quase eliminadas. Isso torna o desenvolvimento freestyle UI5 bastante agrad\u00e1vel. Um motivo importante \u00e9 a qualidade do servi\u00e7o OData fornecido pelo back-end. Ou a falta de qualidade. Podem faltar associa\u00e7\u00f5es a entidades, filtros, classifica\u00e7\u00e3o ou leitura de uma entidade diretamente, batch ou deep insert n\u00e3o s\u00e3o implementados. Em tais casos, o desenvolvedor UI5 era capaz de cobrir a falta de qualidade no back-end. No entanto, a falta de qualidade nos servi\u00e7os OData est\u00e1 chegando ao fim. O ABAP RESTful Programming Model (RAP) est\u00e1 superando muitos problemas que o desenvolvimento baseado em SEGW permitiu acontecer. RAP e CAP garantem que o desenvolvedor siga um framework mais de perto. Para o desenvolvimento Fiori, ele alinha o app front-end e back-end mais pr\u00f3ximos, fazendo dos Fiori Elements a primeira escolha para o app.<\/p>\n\n\n\n
As mudan\u00e7as nas ferramentas, frameworks e roadmaps ter\u00e3o um impacto no desenvolvimento de UI5.<\/p>\n\n\n\n
Mudan\u00e7as constantes<\/strong><\/p>\n\n\n\n A tecnologia est\u00e1 em constante mudan\u00e7a e, assim, as habilidades necess\u00e1rias tamb\u00e9m. O desenvolvimento de websites evoluiu de HTML e CSS b\u00e1sicos para apps din\u00e2micos. No in\u00edcio dos anos 2000, era comum desenvolver apps Java empresariais usando J2EE. Hoje, apps Java s\u00e3o implantados em alguma nuvem, incluindo alta disponibilidade, sem precisar ter um conhecimento profundo de infraestrutura. JSP j\u00e1 foi uma habilidade importante para apps web. Hoje, apps web s\u00e3o desenvolvidos usando Angular, React ou Vue. As tecnologias SAP podem estar sujeitas a um ritmo diferente aqui, mas obviamente n\u00e3o s\u00e3o imunes. A tecnologia b\u00e1sica NetWeaver ainda far\u00e1 parte do S\/4HANA em 2040, assim como outras tecnologias como servi\u00e7os web SOAP ou at\u00e9 mesmo IDocs. Voc\u00ea poderia testemunhar nos \u00faltimos 20+ anos como as tecnologias foram promovidas, adotadas, usadas e, posteriormente, declaradas obsoletas. Tecnologias que focam no usu\u00e1rio t\u00eam uma frequ\u00eancia de mudan\u00e7a maior. Por exemplo, Web Dynpro Java, Visual Composer, Duet, SAP Portal, SUP, Kapsel, SMP, etc. Pense em todos os frameworks JavaScript dispon\u00edveis que prometem facilitar o desenvolvimento de apps.<\/p>\n\n\n\n Ter que aprender algo novo n\u00e3o \u00e9 ruim e, pelo menos fora do universo SAP, \u00e9 comum. Essa renova\u00e7\u00e3o constante \u00e9 prova de que h\u00e1 inova\u00e7\u00e3o. Tecnologias antigas s\u00e3o assimiladas ou substitu\u00eddas. Raramente ficam completamente obsoletas de uma vez. A mudan\u00e7a leva tempo e normalmente as ideias, ou pressupostos b\u00e1sicos, do que ser\u00e1 substitu\u00eddo, continuam. Apps low code iniciais como Visual Composer n\u00e3o sobreviveram \u00e0s mudan\u00e7as na tecnologia web. A ideia b\u00e1sica de permitir que um usu\u00e1rio construa seu pr\u00f3prio app baseado em servi\u00e7os, sim. Outros, como o SAP Portal, evolu\u00edram ao longo do tempo para produtos modernos como Work Zone. A ideia de fornecer um ponto de entrada \u00fanico com acesso transparente a apps para os usu\u00e1rios finais ainda \u00e9 importante.<\/p>\n\n\n\n Demanda por apps Fiori<\/strong><\/p>\n\n\n\n O que isso tem a ver com o desenvolvimento UI5? Existem muitos apps UI5 desenvolvidos para atender aos requisitos do usu\u00e1rio e oferecer uma UX moderna. Por que o desenvolvimento UI5 deve se tornar obsoleto? As empresas precisam entregar apps Fiori e tamb\u00e9m dependem do UI5 para fazer isso. Em todos os lugares voc\u00ea pode ver a demanda por apps e desenvolvedores UI5. As empresas est\u00e3o migrando para o S\/4HANA e uma maneira f\u00e1cil de se preparar para isso \u00e9 oferecer apps Fiori. A quest\u00e3o \u00e9: os desenvolvedores acreditam que habilidades em UI5 s\u00e3o necess\u00e1rias para atender \u00e0 demanda da empresa por apps Fiori. E a\u00ed est\u00e1 o erro: os usu\u00e1rios querem um app que os ajude a resolver uma tarefa. As empresas querem que esses apps funcionem com SAP. Portanto, esses apps devem ser Fiori. A demanda \u00e9 por apps Fiori. N\u00e3o apps UI5.<\/p>\n\n\n\n O UI5 \u00e9 uma das muitas alternativas para entregar um app Fiori. Existem outras maneiras de entregar um app que siga as diretrizes de design Fiori. Da SAP voc\u00ea obt\u00e9m MDK, Fiori para iOS\/Android. Existe o SAP Build Code ou SAP Build Apps. Aqui o foco est\u00e1 no resultado, o app, n\u00e3o em como obter o app. Talvez em alguns anos, esbo\u00e7os, notas e requisitos sirvam para obter um app Fiori gerado por IA. Enquanto funcionar e puder ser aprimorado e mantido, as empresas n\u00e3o se importar\u00e3o se a tecnologia subjacente \u00e9 um app UI5 freestyle ou outra coisa. Ao contr\u00e1rio disso, atualmente, a maioria dos apps UI5 freestyle s\u00e3o entregues por desenvolvedores. Isso n\u00e3o mudar\u00e1 t\u00e3o cedo, pois os desenvolvedores que aprenderam Fiori e desenvolvimento UI5 nos \u00faltimos anos fizeram isso principalmente escrevendo apps UI5 freestyle. Smart controls facilitaram o desenvolvimento de apps UI5. N\u00e3o s\u00f3 tornam o desenvolvimento mais r\u00e1pido, mas tamb\u00e9m alinhado automaticamente com as diretrizes Fiori. E: a falta de qualidade dos servi\u00e7os OData \u00e9 revelada. Enquanto smart controls s\u00e3o um acelerador para o desenvolvimento freestyle e ajudam a ter um servi\u00e7o OData melhor, o desenvolvedor ainda deve cuidar de muitas coisas como navega\u00e7\u00e3o, layout de p\u00e1gina, posicionamento de informa\u00e7\u00f5es, fluxos de a\u00e7\u00f5es etc. Ferramentas ajudam, mas no final, ainda \u00e9 tarefa do desenvolvedor garantir que o app funcione e siga as diretrizes Fiori. Este \u00e9 um processo intensivo em trabalho e demorado.<\/p>\n\n\n\n O fato de que um app Fiori n\u00e3o \u00e9 necessariamente um app UI5 \u00e9 cada vez mais aceito. Afinal, UI5 freestyle \u00e9 apenas uma alternativa para desenvolver um app Fiori. Olhando alguns anos no futuro, Fiori Elements ser\u00e1 o padr\u00e3o para o desenvolvimento de apps Fiori. Fiori Elements substituir\u00e1 apps UI5 freestyle.<\/p>\n\n\n\n Fiori Elements<\/strong><\/p>\n\n\n\n Existem dois componentes envolvidos que trabalham juntos e dependem um do outro: Fiori Elements no front-end (UI5) e o servi\u00e7o OData no back-end (RAP). Ambos os frameworks evolu\u00edram drasticamente nos \u00faltimos anos. \u00c9 poss\u00edvel desenvolver apps Fiori complexos apenas usando anota\u00e7\u00f5es. Um app Fiori Elements imp\u00f5e algumas regras tanto no front-end quanto no back-end que facilitam para as empresas se beneficiarem.<\/p>\n\n\n\n Back-end: o servi\u00e7o deve ter alta qualidade. O modelo de dados deve estar completo. As anota\u00e7\u00f5es fornecidas devem ser boas o suficiente para entregar um app funcional. Isso significa que coisas como ajuda de valor, tabelas, p\u00e1ginas de objetos ou edi\u00e7\u00e3o funcionam e mostram todas as informa\u00e7\u00f5es necess\u00e1rias para o usu\u00e1rio final.<\/p>\n\n\n\n Front-end: uma coisa boa sobre Fiori Elements \u00e9: no melhor caso, o app \u00e9 realizado em tempo real usando as anota\u00e7\u00f5es do back-end. O app segue automaticamente as diretrizes Fiori. Atualiza\u00e7\u00f5es tornam-se um n\u00e3o-evento. Quanto menos mudan\u00e7as forem feitas pelo desenvolvedor front-end, melhor. Isso implica que: mudan\u00e7as exigidas pelos neg\u00f3cios devem ser justificadas e mudan\u00e7as desnecess\u00e1rias podem ser recusadas referindo-se aos Fiori Elements.<\/p>\n\n\n\n OData<\/strong><\/p>\n\n\n\n A qualidade do servi\u00e7o OData aumentar\u00e1. Servi\u00e7os OData v4 ser\u00e3o comuns. Servi\u00e7os oferecer\u00e3o recursos avan\u00e7ados como draft handling. OData v4 \u00e9 a melhor escolha para apps Fiori Elements. OData v4 atualmente n\u00e3o \u00e9 t\u00e3o usado quanto OData v2. Novamente, isso se deve ao passado. Quando o desenvolvimento UI5 come\u00e7ou, a \u00fanica op\u00e7\u00e3o era OData v2. Em vers\u00f5es anteriores do S\/4HANA, OData v2 era usado. O mesmo para RAP: OData v4 est\u00e1 dispon\u00edvel e recomendado recentemente (em termos SAP). Isso foi diferente para CAP, onde OData v4 era o padr\u00e3o desde cedo. Mas ent\u00e3o CAP carece de ado\u00e7\u00e3o e a maioria dos apps Fiori nos clientes s\u00e3o baseados em ABAP. OData v4 \u00e9 o futuro para servi\u00e7os. Realizar servi\u00e7os OData v4 com RAP \u00e9 f\u00e1cil. A qualidade entregue por um servi\u00e7o RAP \u00e9 normalmente superior \u00e0 de SEGW. Embora servi\u00e7os OData v2 estejam dispon\u00edveis por anos, novas implementa\u00e7\u00f5es devem usar OData v4. Isso traz algumas mudan\u00e7as para os desenvolvedores de back-end e suas habilidades SEGW se tornar\u00e3o obsoletas. O compromisso da SAP com RAP \u00e9 uma realidade. Considerando o ciclo de vida dos produtos SAP \u2013 aqui: S\/4HANA ou NW ABAP \u2013 e os ciclos de suporte, RAP ficar\u00e1 conosco at\u00e9 2040. Olhando para a nuvem, nos \u00faltimos anos a SAP nos trouxe muitas op\u00e7\u00f5es diferentes para desenvolver algo com OData. A \u00faltima itera\u00e7\u00e3o aqui sendo CAP. Meu conselho: escolha RAP como a maneira de desenvolver servi\u00e7os (ou extens\u00f5es), especialmente quando seus desenvolvedores s\u00e3o principalmente desenvolvedores ABAP e voc\u00ea tem um sistema S\/4HANA dispon\u00edvel em algum lugar ou tem acesso ao BTP Steampunk.<\/p>\n\n\n\n Modelo de Dados<\/strong><\/p>\n\n\n\n Relacionado ao servi\u00e7o OData est\u00e1 o modelo de dados. A tarefa mais importante \u00e9 definir o modelo de dados. Com ele, o resto vem quase automaticamente. O tempo em que servi\u00e7os OData estavam apenas expondo um BAPI est\u00e1 chegando ao fim. Come\u00e7ando rigorosamente o servi\u00e7o a partir do modelo de dados, vis\u00f5es CDS (entity), associa\u00e7\u00f5es e construindo a partir da\u00ed o servi\u00e7o. Isso fechar\u00e1 muitas lacunas na qualidade do servi\u00e7o OData constru\u00eddo no modelo de dados. Um efeito colateral disso: os servi\u00e7os OData ser\u00e3o mais f\u00e1ceis de consumir em outros frameworks, como MDK ou low code.<\/p>\n\n\n\n RESTful Application Programming Model<\/strong><\/p>\n\n\n\n RAP \u00e9 o equivalente ABAP do CAP. De ambos os frameworks voc\u00ea deve esperar um servi\u00e7o OData de alta qualidade. Ambos garantem que o desenvolvedor siga de perto o framework resultando em um servi\u00e7o de alta qualidade. RAP, no entanto, vem com v\u00e1rios benef\u00edcios prontos para uso que o CAP n\u00e3o pode oferecer. O mais importante \u00e9: RAP roda em ABAP. O principal benef\u00edcio \u00e9 simplesmente: todo cliente SAP usando S\/4HANA tem acesso ao RAP. Empresas e seus desenvolvedores obt\u00eam RAP com S\/4HANA e com BTP, ambiente ABAP. Como a probabilidade de um cliente S\/4HANA ter desenvolvedores ABAP dispon\u00edveis \u00e9 maior do que ter desenvolvedores CAP dispon\u00edveis, serve como uma indica\u00e7\u00e3o razoavelmente boa de que esses clientes adotar\u00e3o RAP. Desenvolver apps Fiori Elements com RAP \u00e9 super simples. Especialmente on-stack. Nenhuma configura\u00e7\u00e3o de conta, conectividade ou configura\u00e7\u00e3o de implanta\u00e7\u00e3o necess\u00e1ria. Basta usar. Acessar dados via RAP e anotar o servi\u00e7o \u00e9 feito pela pessoa que definiu o modelo de dados e normalmente tem um conhecimento muito bom do processo de neg\u00f3cios.<\/p>\n\n\n\n Anota\u00e7\u00f5es<\/strong><\/p>\n\n\n\n As anota\u00e7\u00f5es fazem parte de um projeto RAP ou CAP. Em vez de t\u00ea-las no projeto SEGW ou sobrescrev\u00ea-las na codifica\u00e7\u00e3o, elas s\u00e3o mais vis\u00edveis no projeto. Tamb\u00e9m \u00e9 \u201cmais f\u00e1cil\u201d para o desenvolvedor escrev\u00ea-las. Importante aqui: os desenvolvedores que definiram o modelo de dados, a implementa\u00e7\u00e3o, tamb\u00e9m est\u00e3o escrevendo as anota\u00e7\u00f5es. Eles se tornam os propriet\u00e1rios. O cen\u00e1rio onde o desenvolvedor UI5 escreve elas no front-end ser\u00e1 cada vez menos. Ou usado apenas para pequenos ajustes.<\/p>\n\n\n\n Essas mudan\u00e7as resolver\u00e3o um problema antigo: qualidade do servi\u00e7o. As empresas se beneficiar\u00e3o disso n\u00e3o apenas no desenvolvimento mais r\u00e1pido de apps Fiori. Como mencionado acima, existem v\u00e1rias ferramentas fornecidas pela SAP para criar apps. Quando o servi\u00e7o oferece os recursos necess\u00e1rios, fica f\u00e1cil construir apps sobre eles. Seja um app m\u00f3vel, low code, gerado por IA ou um app Fiori Elements.<\/p>\n\n\n\n Fiori Elements<\/strong><\/p>\n\n\n\n J\u00e1 foi mencionado v\u00e1rias vezes acima: o futuro do desenvolvimento UI5 \u00e9 Fiori Elements. Muitas tarefas necess\u00e1rias para um app UI5 freestyle n\u00e3o s\u00e3o necess\u00e1rias. A maior parte do trabalho \u00e9 feita pelo framework Fiori Elements e pelas anota\u00e7\u00f5es.<\/p>\n\n\n\n Fiori Elements j\u00e1 \u00e9 poss\u00edvel com um servi\u00e7o OData v2. Portanto, por v\u00e1rios anos. No entanto, o uso de Fiori Elements n\u00e3o era generalizado. Nem mesmo nos apps Fiori fornecidos pela SAP. Os problemas mencionados acima em rela\u00e7\u00e3o \u00e0 qualidade eram uma das raz\u00f5es. As ferramentas e recursos que o Fiori Elements com OData v2 oferecem eram bons, mas logo atingiram seus limites. Isso muda com o Fiori Elements e o OData v4. O modelo de programa\u00e7\u00e3o flex\u00edvel (FPM) permite desenvolver um app Fiori Elements e ainda ser capaz de ajust\u00e1-lo quando necess\u00e1rio. E com os FPM Macros, controles de UI complexos podem ser usados e controlados via anota\u00e7\u00f5es. O ponto de partida para um app Fiori com UI5 ser\u00e1 o Fiori Elements. O foco do conhecimento mudar\u00e1. De UI5 freestyle para Fiori Elements com FPM. Essa mudan\u00e7a \u00e9 o que tornar\u00e1 o conhecimento de desenvolvimento UI5 em uma habilidade obsoleta. Seguir a abordagem mais rigorosa dos Fiori Elements significa: menos tempo necess\u00e1rio para um app, melhor alinhamento com as diretrizes Fiori, melhores servi\u00e7os, mais recursos prontos para uso. Com Fiori Elements como base, o Flexible Programming Model ser\u00e1 a base das extens\u00f5es de apps personalizados. O conhecimento dos controles UI5 como responsive table, input field, panel, etc. ser\u00e1 substitu\u00eddo pelo conhecimento de como usar os FPM Macros. O conhecimento de como a responsive table funciona ainda ser\u00e1 usado, mas a primeira coisa a saber \u00e9 como usar o Macro para table em um app FPM aprimorado Fiori Elements.<\/p>\n\n\n\n A ado\u00e7\u00e3o do OData v4 tamb\u00e9m tornar\u00e1 o desenvolvimento UI5 freestyle menos atraente. Usar OData v2 no UI5 \u00e9 super f\u00e1cil. Como os smart controls s\u00f3 funcionam com OData v2, desenvolver um app UI5 freestyle com OData v4 que usa os controles UI \u00e9 trabalhoso. O OData v4 exige trabalho adicional do desenvolvedor, pois seu uso n\u00e3o \u00e9 realmente destinado a apps freestyle.<\/p>\n\n\n\n Isso agora significa que o desenvolvimento UI5 \u00e9 uma habilidade obsoleta? Claro que n\u00e3o se tornar\u00e1 completamente obsoleta. Os fundamentos ainda ser\u00e3o necess\u00e1rios. Ajustar apps Fiori Elements ainda precisa de habilidades de desenvolvimento UI5. Mas n\u00e3o confunda isso com o mesmo n\u00edvel de habilidades e conhecimento de UI5 para um app UI5 freestyle. Escrever uma extens\u00e3o de controlador ou fragmento de visualiza\u00e7\u00e3o n\u00e3o \u00e9 o mesmo que criar um app do zero. Conhecimento profundo de como o rooting funciona, como aplicar um layout de p\u00e1gina, trabalhar com FCL, etc. n\u00e3o ser\u00e1 necess\u00e1rio.<\/p>\n\n\n\n Desenvolvimento UI5 de Pr\u00f3ximo N\u00edvel<\/strong><\/p>\n\n\n\n A mudan\u00e7a para habilidades de Fiori Elements liberar\u00e1 recursos no lado do desenvolvimento front-end do app. Hoje, muitas vezes criar um app UI5 do zero, mesmo com os assistentes e ferramentas, \u00e9 uma tarefa demorada. E o freestyle sempre vem com o risco do \u201cclaro que podemos\u201d. O freestyle \u00e9 \u00f3timo porque o app pode ser desenvolvido de uma maneira que faz tudo o que o consultor funcional deseja. \u00c9 dif\u00edcil para um desenvolvedor rejeitar um requisito quando \u00e9 poss\u00edvel implementar. Afinal: tecnicamente \u00e9 poss\u00edvel e h\u00e1 um requisito, ent\u00e3o por que n\u00e3o fazer? E todos ficam felizes. Se o or\u00e7amento estiver dispon\u00edvel, por que n\u00e3o us\u00e1-lo para implementar esses desejos e depois em manter esses apps? Adicionar draft handling, collaborative editing, view management, fica complicado. Com Fiori Elements \u00e9 mais f\u00e1cil. Portanto, o foco do desenvolvimento UI5 mudar\u00e1. Talvez para validar melhor se os apps seguem as diretrizes Fiori? Mais no usu\u00e1rio final e nos apps, independentemente se um UI5, Fiori Elements, MDK, Low Code, qualquer app? Mais no teste? Ou apenas em entregar mais apps? Uma coisa \u00e9 certa: para o desenvolvedor UI5, as coisas mudar\u00e3o. A demanda por UI5 freestyle n\u00e3o desaparecer\u00e1 completamente. Sempre haver\u00e1 demanda por alguns apps que exigem ser freestyle. No entanto, ser\u00e1 apenas uma pequena porcentagem da demanda geral por Fiori.<\/p>\n\n\n\n Os desenvolvedores UI5 precisam aprender Fiori Elements. O foco \u00e9 em Fiori Elements com OData v4 e FPM. A quantidade de apps Fiori Elements com OData v4 fornecidos pela SAP aumentar\u00e1. Eles precisam saber como ajustar esses apps. Quais s\u00e3o as possibilidades e limita\u00e7\u00f5es. Aprender anota\u00e7\u00f5es e melhores pr\u00e1ticas sobre onde coloc\u00e1-las: melhor no back-end ou no front-end, e por qu\u00ea? Validar apps UI5 freestyle \u201cantigos\u201d e verificar se eles est\u00e3o realmente seguindo as diretrizes Fiori. Testar ser\u00e1 importante. Usar ferramentas que permitem testar apps da perspectiva do usu\u00e1rio final. Assim como dados fict\u00edcios e como gerenci\u00e1-los. O servi\u00e7o OData ser\u00e1 consumido talvez n\u00e3o apenas por um app, mas por muitos. Esses apps depender\u00e3o de anota\u00e7\u00f5es e demandar\u00e3o alta qualidade do servi\u00e7o. Esta \u00e9 uma mudan\u00e7a para o desenvolvedor de back-end, mas tamb\u00e9m para o desenvolvedor UI5, j\u00e1 que a tarefa de cobrir erros no back-end desaparecer\u00e1.<\/p>\n\n\n\n A habilidade de desenvolvimento Fiori Elements parece ser a mesma que UI5 freestyle. Mas n\u00e3o \u00e9. Fiori Elements vem com uma mentalidade diferente. Com uma abordagem diferente para todo o processo de cria\u00e7\u00e3o de apps. \u00c9 mais disruptivo do que voc\u00ea imagina.<\/p>\n\n\n\n Web Components<\/strong><\/p>\n\n\n\n Uma \u00e1rea onde habilidades UI5 freestyle podem ser consideradas importantes \u00e9 para controles de UI personalizados. Atualmente, voc\u00ea precisa saber como desenvolver um controle UI5, e isso inclui um bom entendimento de como o UI5 funciona. O futuro para controles UI5 s\u00e3o os Web Components. Com isso, as habilidades de desenvolvimento UI5 s\u00e3o substitu\u00eddas por saber como desenvolver Web Components. E com isso, o foco do desenvolvedor muda. De um controle UI para UI5, para um controle UI para uma ampla gama de frameworks. Isso ser\u00e1 mais do que interessante. Se a SAP fizer certo com os Web Components, isso tem uma grande chance de mudar como o Fiori \u00e9 usado e adotado em uma empresa. E n\u00e3o apenas para a \u00e1rea SAP. Escreverei sobre isso em um post futuro no blog.<\/p>\n\n\n\n Deixe o mundo saber.<\/p>\n","protected":false},"excerpt":{"rendered":" No horizonte, mudan\u00e7as est\u00e3o se manifestando. E essas mudan\u00e7as tornar\u00e3o o desenvolvimento de UI5 uma habilidade bastante obsoleta. Para muitos desenvolvedores, o desenvolvimento freestyle UI5 \u00e9 a abordagem preferida para criar um novo app UI5. \u00c9 uma escolha popular entre os desenvolvedores UI5 por v\u00e1rias raz\u00f5es. Primeiro, o desenvolvimento freestyle UI5 \u00e9 a maneira original […]<\/p>\n","protected":false},"author":1,"featured_media":683,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-646","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sem-categoria"],"_links":{"self":[{"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/posts\/646","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/comments?post=646"}],"version-history":[{"count":2,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/posts\/646\/revisions"}],"predecessor-version":[{"id":649,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/posts\/646\/revisions\/649"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/media\/683"}],"wp:attachment":[{"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/media?parent=646"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/categories?post=646"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/tags?post=646"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}