Synchro Labs has released its new solution that allows developers to create cross-platform native mobile apps using JavaScript and Node.js. All of the application code, including client interaction logic, runs in the cloud on Synchro Labs client-server platform.
Synchro is built on Node.js, and Synchro apps run in a Node environment. Developers create apps in JavaScript, with access to Node packages use in server apps.
The Synchro platform provides the following benefits:
- Fast App Build: The Synchro client-server platform puts client logic on the server, resulting in streamlined integration with server resources, and clients that are provably secure, in a fraction of the amount of code required by competing solutions.
- Native Apps on Every OS: Developers can write their app once on the server, then deploy it as a branded, native app on iOS, Android, Windows, and Windows Phone.
- Instant Updates: Mobile apps are created, managed, and hosted in the cloud, meaning that they can be modified, tested, and redeployed to their installed base instantly.
Developers can use Synchro free of charge for development and testing purposes. Applications deployed to end-users require a monthly subscription, with fees based on application scale.
The company explains the rationale for the platform in this way:
In order to run the client logic on the server, but still render native, responsive applications on mobile devices, we need a strong separation between the client view and the client application logic (since they're running on different devices). We were inspired by contemporary data binding techniques and the MVVM (Model-View-ViewModel) design pattern. We particularly liked MVVM Light in the DotNet world and Knockout.js in the JavaScript world as examples of cleanly separating presentation from data and interaction.
In this pattern, each page or screen is represented by a View that defines the presentation of the user interface, including controls and their layout, and a ViewModel that contains the data represented in the View, as well as commands to process user interactions with the View. The View definition also contains declarative bindings that describe the relationship between the View and the ViewModel (for example, which ViewModel elements are used to populate which View controls, and which ViewModel commands are launched when users interact with various controls in different ways, etc).
These declarative bindings allow us to fully automate the View, meaning that there is no need for you to write any procedural code to get or set View contents or state, and this is what allows us to render and run the View on the other site of a network connection from the ViewModel. Also, unlike many other MVVM or similar systems, we don't require you to do anything in your ViewModel implementation to make this happen (you don't have to notify anyone when you make a data change, and you don't have to tell us which data elements we need to observe - we just figure it out and handle it automatically).