{"id":9841,"date":"2016-05-26T11:52:19","date_gmt":"2016-05-26T15:52:19","guid":{"rendered":"http:\/\/www.analystik.ca\/blogue\/?p=9841"},"modified":"2019-01-23T16:52:05","modified_gmt":"2019-01-23T21:52:05","slug":"analystik-approach-to-cross-platform-application-development","status":"publish","type":"post","link":"https:\/\/analystik.ca\/blogue\/language\/en\/analystik-approach-to-cross-platform-application-development\/","title":{"rendered":"Analystik’s Approach to Cross-Platform Application Development"},"content":{"rendered":"

The new cross-platform application development paradigm has confronted developers with a multi-OS and multi-device heteroclite environment (iOS, Android, PC, Web). And of course, everyone was looking for high-performance cross-platform multi-device deliverables!<\/p>\n

Saying that the application development landscape has greatly evolved over the last few years would definitely be an understatement, be it mobile or back-end and front-end. And always the performance challenge remained central over time, both in terms of development (to develop the fastest possible at the lowest cost) and in terms of application performance.<\/p>\n

<\/p>\n

From Mobile to Multi-device to Cross-platform Application Development<\/h2>\n

Before, the developer would code according to its expertise and programming philosophy and its deep knowledge of a specific environment, you were either Java, Open Source, Windows, iOS or BlackBerry, for example; in short, you would code mostly for one platform \/ environment.<\/p>\n

But with the BYOD phenomenon, the Mobility rage and the tsunami of mobile applications that came along with it; developers found themselves confronted with a multiplicity of OS\u00a0and had to choose a deployment \/ coding strategy because they would have to code for 2-3-4 different OS and their respective UIs, of course. Two thoughts of school were facing each other: native versus mobile web (and different browsers).<\/p>\n

Developers were also facing a steep price challenge thanks to overseas and over-continent competition, still while coding\u2026 2-3 times more code!<\/p>\n

And let\u2019s not forget that with Mobility came a new business model in the market, the free software programs became the new standard even though you would have to come up with a way to monetize your traffic (subscriptions \/ downloads) somewhere down the road which many have overestimated, never finding a way just to cover expenses or make profits.<\/p>\n

Hence, the \u00ab\u00a0Mobile Puritans\u00a0\u00bb often opted for a mixed strategy, that is to develop and deploy a comprehensive native application for the main target market OS and a lighter application version for the secondary target market OS; which would have you abandoned some markets but would in theory deliver higher-performance mobile applications. The less puritan ones would go with a mobile web development for which many regret its lack of appeal in terms of design as a counterpart for its multi-OS adaptability!\u00a0\u00a0 However, mobile web development comes with an undeniable advantage in terms of development cost and deployment cost.<\/p>\n

\"before-after\"<\/a><\/h4>\n

Target large and code small<\/strong><\/h3>\n

So, in this context, face with the challenge of coding at the best possible cost while reaching all platforms (OS), some started looking for a new solid base upon which building their cross-platform application development without harming application performance; in this particular case, the server.<\/p>\n

That\u2019s the point of view Analystik adopted, or if you prefer, the asset we decided to bet on; hence in our cross-platform application design, we keep all enterprise business logics, main calculus and process as well as data on the \u00ab\u00a0server\u00a0\u00bb side. Yes, it\u2019s true, we really are talking about the good old Server \/ Client architecture just like when the characters displayed were green\u2026 but hey, the thing is, today there\u2019s a huge difference in how we talk to different Clients. You need an adequate communications protocol in sync with your business requirements, for different Clients (OS and platforms), that is.<\/p>\n

Once this choice was made, we started looking for an adequate communications protocol meeting all requirements, between Server and Clients; hence, different UIs on different OS & devices.<\/p>\n

For the Server to Client communications, Analystik chose REST (Representational State Transfer), a high performance HTTP protocol but also versatile, which enables it to \u00ab\u00a0exchange\u00a0\/ interpret \u00bb Java, JavaScript, C#, Swift, Objective C, HTML, etc.; in short, we targeted large<\/em><\/strong>! REST<\/strong> is highly performing because it transfers data in a non-verbal fashion, contrary to SOAP.<\/p>\n

Consequently, in our applications\u2019 design philosophy, we have chosen to code small <\/em><\/strong>on the Client UIs\u2019 side, to restrict the nature and quantity of instructions to display, color, etc.<\/p>\n

In a word, what is unique to each Client is being coded on the \u00ab\u00a0Client\u00a0\u00bb side and what is common to all Clients is being coded on the \u00ab\u00a0Server\u00a0\u00bb side.<\/p>\n\"server-rest-en\"<\/a>\n

Example<\/strong>: For taxes and shipping fees on an eCommerce website, the data will be downloaded on the Server and the calculus (sums and taxes) will be executed on the Server, data will then be put into cache and displayed on the Client only when required.<\/p>\n

Own\u00a0your choices\u2026<\/strong><\/h3>\n

This approach demanded to be resourceful since it relies heavily on the REST communications protocol by sometimes commanding a heavy load of data\u00a0circulating back and forth between Server and Clients, which would have been impossible just a few years ago. So, we had to take that into account and, adapt.<\/p>\n

\u2026and develop best practices<\/strong><\/h3>\n

Consequently, we have learned from our mistakes and developed a few best practices:<\/p>\n