Cross Platform Biz Logic Development

With emerging technologies such as Internet of Things (IoT), wearable devices, contactless payment, and robot-driven experiences, the face of modern software are poised for a dramatic overhaul. Mobile devices are becoming the standard in computing. Irrespective of new touch points and channels that continue to emerge, its will remain relevant due to their ability to provide real-time, offline and the sensory experience that cannot be easily matched by other channels. As it will continue to evolve. a cross platform development platform might just be the answer for business stake holders aspiring to offer a seamless and consistent omni-channel experience. It is expected to be agile and can easily adapt to any device ecosystem and environment through a common set of enterprise-level services deployed across channels and touchpoints. Therefore, it is necessary to support as many platforms as possible to increase market penetration and visibility.

 The main challenge with building individual apps for each platform is the platforms themselves.

• Need expertise in the native development environment of each platform
• Requires additional development time as apps need to be developed for each type of platform.
• Having UI specific to mobile device say Objective-C leads to double efforts
• Handling User experience doubles– Fix for iOS does not mean fix for android or web browser

 Development, maintenance, and testing cost

Each platform relies on its own SDKs and tools in order to build “native” applications. Each SDK also has its own dependencies. 

Let’s say you want to develop native apps for 3 different platforms—android, iOS, and Windows. Your app will be written in 3 different languages—Java for Android, Swift or Objective C for iOS, and C# for Windows.

Naturally, you will need 2-3 different coding teams. Or possibly, 3 different app developments out sourcing partner team. The cost will shoot up and so will the time! Also, how about the maintenance since we cannot have a single codebase, need to maintain than three or four. In the longer run, you will be spending way more on maintenance as well.

Another we need to pay attention is on Testing. Testing! is another often neglected part of development. It will be a QA manager often nightmare for testing same code against each of the platform.

How about UX- User experience? A normal user might not be comfortable with different layouts of the app whenever he switches the software platform.

No matter what mobile operating system is running your mobile app, it is needed to set the same user experience on all mobile platforms. A normal user might not be happy with diverse layouts of the mobile app if he/she move the software platform (iOS/Android/Windows).

The same functions and layout helps a user quickly identify and use your app, also it can show the unique values of your app. Different layout and navigation flow will force a user to learn the new ways to use your app and he might not like it. Therefore, it is necessary to keep the app navigation and design consistent on all platforms.

Most importantly, the user interaction with your mobile app will be the same across all different smartphone operating systems

 So, all in all, developers are forced to commit not only to developing for both platforms, but also maintaining both apps in parallel. That means budgeting 160% to 180% of the single-platform cost in order to target just two platforms. From this perspective, developing for multiple platforms appears to be impractical. And even if, you will be burning a lot on development, maintenance and testing as well.

 Now, let us put up our thinking cap on and list down what ideally, we need to overcome this..

Leaning bit towards to the pragmatic  edge, one may thinking on the following 80/20 tuple (but not limited)

 #1. Keep “Business Logic” Cross-Platform : The goal with cross-platform development is to enable the maximum reuse of code that can be common, without sacrificing any of the end-user experience. The least reusable code is generally the GUI layer. In a cross-platform system, the GUI elements are typically abstracted away from the system-dependent calls so that a unified interface is available to the “business logic” code. The rendering layer can easily be abstracted away to a platform independent layer, and the common logic code can be shared. Additional areas that can require an abstraction layer are file systems, network connectivity and device communication.

 #2. Use Abstracted Types, Not Platform-Specific Types. It is not safe to assume that all processors and compilers will generate or require the same size variables. For example, an “int” may take four bytes on a Windows machine, but may only take two bytes on a small mobile device. By abstracting these common types, it is ensured that operations will return expected results and function properly.

Using these abstractions ensures that the common “business logic” code will exchange correct values with libraries regardless of the platform.

 #3. Use Single Unicode. UTF-8 is supported on all platforms and is the universal standard for representing textual data. A nice property of UTF-8 is that it is backward- compatible with U.S. ASCII code, while fully supporting all international languages. Also, English markets are no longer dominant. If UTF-8 is included early, supporting international characters will be trivial.

 And the list can go on..  we can be in the ivory tower and impose lots of architectural blueprints.. But in short, what we want is an true Cross-Platform where dev team will write code in a single code base and then platform does the magic of making it available across Android, iOS, webOS ..

“Build One & Run on All”

 

which means “…One codebase for all platforms?”… is it a some kind of joke?

But, let us not lose hope.. as someone whispers every cloud has a silver lining.. we still have couple of options in this space

#1 . Use Isomphoric Javascript application using Javascript, Nashorn and React

Single Engine: For every peace of HTML you need to decide if you want to render it on the Server, on the Client or both. Rendering it on the Server makes it harder to modify for the Client. Rendering it on the Client requires JavaScript, Rendering it on Client and the Server would be optimal, but most likely means duplicated code.

 This is where Facebook ReactJS comes handy. React helps to abstract the DOM structure from the actual DOM in the browser by providing a virtual (in memory) DOM, so it enables you to render a page on the server side and just pass the HTML to the client where the same JavaScript code can further Work on the real DOM. So we end up with a single view engine, that works as soon as we can execute JavaScript on our Server. With Java 8 and Nashorn this is possible.

 so, what is this..Nashorn? ..unicorn’s big brother?

Let start with JSR-223 specs. JSR-223 request for scripting support on the Java platform. The specification describes how scripting engines such as are located, retrieved and how bindings between variables in the scripting language and Java objects are created. he eighth version of Java ships with a JavaScript engine named Nashorn. Nashorn is available through the JSR-223 scripting APIs and can be used in any Java 8 application with a few lines of code.

The following listing shows the classic Hello World example with Nashorn. Note that it can be executed without any configuration or additionally libraries.

While it is an option.. let us relook at this.. is there anything wrong with Javascript as a compile target? Especially business logic development… meeting the demands of modern computing. Something fundamental.. Javascript doesn't even have integers? it doesn't support C-style malloc/free heap-based allocation? Any the runtime is garbage collected like java? doesn't properly support threads (a huge deal given the demands of modern computing), or sharing of memory between WebWorkers and the main thread? In short, Javascript wastes petawatt-hours of energy per year across the spectrum due to its computational inefficiency. That means your power bill is higher than it could be, your mobile device battery doesn't last as long as it could

#2. Source translation functionality – Juniversal 

JUniversal as another alternative, which allows you to write shared, cross platform code in Java. The vision of JUniversal came from some guys at Nokia who possess considerable expertise both in Java and in building cross-platform apps. They built this tool to provide an elegant way to translate source code and make it useful across multiple platforms. JUniversal offers you the freedom to write your shared code in Java and then translate it to C# (available now) or to C++/Objective C++. You can also combine JUniversal with Google’s j2objc translator to translate Java to Objective-C for iOS.JUniversal lets you write code in Java (like you probably already do if you develop for Android) and take that code to places you never thought it could go. It’s primarily targetted to sharing code across mobile apps, but the technology can extend to non-mobile scenarios as well.

There is two core pieces of technology behind the JUniversal approach to cross platform: source code translators (sometimes called transpilers) and a set of cross platform Java programmer friendly libraries, called JSimple. 

 Google’s j2objc is the approach how Google developed Gmail, gdrive. Team had long release cycles. Increased difficulty maintaining feature parity across platforms for example, there was point in time when Google Drive iOS SpreadSheets used to be read-only

Google dev team put forward following key requirements

Lightning fast, Feature parity across clients, Quick prototyping and iteration, Share code as much as possible

And they went around with a 70% shared client code approach - GWT compilation of Java code to JS, Js Interop annotations mark which classes visible to JS, Specialized linker generates Closure JsDoc header, Closure Compiler type-checks and optimizes JS and transpiled JS together

But still it’s hard to write/rewrite compute-intensive libraries

• Operational Transforms
• Formula/Statistical Calculation Engines
• Syncing layers
• Cryptography Libraries, Codecs, et al

J2ObjC allows developers to write all of the business logic and data model handling in Java (Android) and then convert it to ObjC (iOS). J2ObjC also forces the developers to think differently and follow MVC pattern more closely.

With JUniversal, the process is pretty simple

1. Pick the code that you want to share cross platform. It can be a little bit of code (maybe some hairy algorithm) or a lot (everything in your app except the UI). Develop that in Java, with your favorite Java IDE. To keep things tidy, you probably want to separate out shared code to a separate modules/JARs. Ideally, create JUnit tests for it too.
2. In your build script invoke JUniversal to dosource code translation, converting Java to C# (for Windows/Windows Phone) or, coming soon, C++/Objective C++ (for iOS or performance critical code on Android NDK/Windows). You can also use Google’s j2objc converter, to produce Objective-C.
   JUniversal translated source is very human friendly, preserving comments and formatting. It’s intended to look almost like a human being wrote it manually. That’s handy when debugging and has other advantages. Unit tests are translated as well.
3. Source translation is half the technology here, handling the Java language proper. The other half is the JSimple libraries, providing core functionality needed by most mobile apps (OAuth, JSON, network & file I/O, logging, unit testing, etc), in a way that’s familiar to Java developers but also cross platform friendly.
   For a typical mobile app, the intention is those libraries should provide enough support to share core app logic, server communication, and persistent client state cross platform, with just the UI native.
   Check out the JSimple Javadoc for details.
4. For non-shared parts of your code, write those in the native platform language (C#, Swift/Objective-C, etc.). JUniversal doesn’t provide any support for UI today—the intention is that you write it natively. That gives the best UX anyway.

On the spectrum of cross platform technology, JUniversal is arguably among the lightest weight and most native-like, as it uses the native platform programming language (via translation), native compiler, native debugger, native UI design tools, etc. As for the UI, the intention is that it is hand written natively, to provide the best user experience.

 #3. HaXe  Haxe is an emerging open source programming language which is universal, powerful and easy-to-use. HaXe principle follows Write once, reuse everywhere, always native, no wrapper.

The purpose is to give developers a single language to develop all kinds of applications.  The    HaXe compiler    translates    source    code    into    native    source    and/or    bytecode

? Source    code    like    ActonScript, JavaScript, C++, PHP   

? Byte    code    like    Flash,    NekoVM

It's a good attempt to solve cross-platform development problems. Because it can be compiled into different kinds of codes, so it's should very easy to target to different platforms such as iOS, Android or Windows Phone. While Haxe is a truly multiplatform language, it can also be used to develop web applications, it can be used on server side, also it can be used to develop general desktop applications.

With Haxe, your program can be compiled into :

It provides high level programming language that mixes features of object oriented languages and functional ones. At a high level HaXe programming language offers :

• Single    Language    and    syntax    across    client, server    and    command    line    Standard    cross    platform    libraries    work    across    all    client    and    server    targets    (like    Date, Xml, Math, HTTP etc)       
• Access    full    target    platform APIs
• Interface    with    existing    platform    libraries    (e.g.    SWCs, Away3D, JQuery, Raphael etc)   
• Conditional    compilation    flags    for    targeting    specific    platforms    (#if    js....    #elseif    flash    ...    #else)   
• 3rd    Party    HaXe    libraries    via    HaxeLib    (great    open    source    community). HaXe    makes    targeting    new    platforms    is    just    looking    up    additional    APIs rather    than    having    to    learn    additional    languages   

Instead of porting one platform at a time, you can access them all at once from the same code base, at a low incremental cost per platform, and keep one unified codebase so any updates or bug fixes will instantly propagate to all of your supported targets.

Summary: Companies are experiencing extreme pressure mobilization. They face a number of issues including: The high cost of maintaining an application portfolio that is aging with tens or hundreds of applications that have redundancies or bad code picked up throughout the years; The decreasing number of IT professionals that have expertise in more traditional applications and compounded by the lack of available developers for today’s enterprise mobile needs; The growing interest in updating existing applications and bridging the old with the newer technologies. Multi Platform programming language will be an answer to these and also future projects will be able to benefit from this development in various ways. Starting from simple things like validation to an increasing amount of business logic which could be modeled in such Multi Platform programming language and shared between client and server. Movements such as offline first will become much more viable.