NativeScript 5.2 is here! Read on for a full list of features and improvements that are now part of NativeScript.
Vue.js users were the fastest growing part of the NativeScript community over the past year. As most of you probably remember, the NativeScript-Vue integration started as a community effort by Igor Randjelovic and turned out to be a huge success. For the past month (and a trend over the past year), NativeScript-Vue applications are the second most frequently created project types in our ecosystem, surpassing the "Pure JavaScript" and "Pure TypeScript" projects by far.
This drove the team to the decision to announce official support for Vue.js in NativeScript with the 5.2 release. This was the second-most voted feature in the last Community Survey from the entire NativeScript community. This sounds great, but what does it mean in practice?
NativeScript is continuing its effort to provide a fast and fluent development experience, especially when iterating over the development-test-debug cycle. For 5.2 we are bringing a series of improvements in the Hot Module Replacement (HMR) functionality that will make development a breeze. Here is a a full list of the changes in this release:
app.css are applied without restarting the app. You can see how this works by watching me destroying my details template with bright colors 😂:
tns debug now supports the --hmr flag and you can apply changes without interrupting the debugging session started in your Chrome DevTools. Support for debugging with HMR in Visual Studio Code is coming in the next release. Meanwhile, check out this basic debugging session, in which I try to fix the total goal count for the players:One of the toughest jobs after your mobile app is published in the stores and goes viral is monitoring the app’s health and troubleshooting problems that users are experiencing. This has been a pain point, as the default tooling provided in the App Store and the Google Play Store doesn’t play well with NativeScript apps, and same goes for error reporting services like Crashlytics for example.
Up to now only events that were causing crashes of the application had been reported. This was only a small subset of all exceptions that might happen in your application, and sometimes important information might not get to the error-reporting services. With this release, an exception will also be reported and it’s very easy to enable it:
var application = require("application");
application.on(application.discardedErrorEvent, function (args) {
console.log(error.message);
console.log(error.stackTrace);
console.log(error.nativeException);
//report the exception in your analytics solution here
});
As announced in the 5.1 release, we are on a continued effort to provide compatibility for the markingMode: none option. For this this release, we were focused on the community plugins and providing support for plugin authors to make their plugins compatible with this option. You can check out the markingMode: none article and a blog post on the matter is coming shortly.
With this release, the markingMode: none option is an officially supported mode for the Android runtime. We encourage all of you to try it out and let us know if any problems arise, especially in projects that are having performance issues on Android. Feedback from users who have already tried it out has been very positive and we are looking for even more projects benefiting from the performance boost.
In our team we have employed several practices for easier development of native code, both in plugins and applications. Recently, we decided it will be useful to share these with the whole community. Those are now packaged as a NativeScript dev plugin called nativescript-dev-debugging.
After an initial configuration, the plugin will offer you several workflows that will ease your work when it comes to developing and debugging native code. A blog post that walks through these workflows will come out shortly.
One feature of the NativeScript framework that we are very proud of is the 100% access to native code. This allows for high developer productivity and maximum reuse of existing materials and documentation for native libraries. Up to now there was one significant exception – namely consuming 3rd party native libraries (Pods) in iOS directly from the application. This was a design decision taken in the early days of the framework, which aimed to stimulate developers to create plugins and to share them with the community.
The NativeScript Marketplace now offers more than 1000 plugins and we feel that this constraint is no longer needed. That’s why with 5.2, the team decided to remove this restriction and allow for even greater flexibility and productivity when a native code development is needed. Now you can develop against native libraries without any overhead – just drop them in the App_Resouces/iOS folder and start writing your code.
The nativescript-dev-appium package provides an integration between Appium and NativeScript to provide the capability to build an extensive and reliable testing infrastructure. This package has been instrumental for ensuring the quality of the NativeScript framework itself and has been used by many NativeScript users to ensure the quality of their apps.
Recently, a new major version was released with the following improvements:
Next, our efforts will be focused on preparing extensive documentation and tutorials on how to make most of this functionality.