Native To Hybrid And Back Again

I was recently attending NativeScript Developer Day 2017 in New York City, which is Telerik’s very own NativeScript conference.

This was a fantastic conference where I was not only a participant, but also a speaker at the event. At this event I had given a fresh presentation titled, Native to Hybrid and Back Again, where I had discussed my own personal experiences when it came to mobile application development.

I want to take the opportunity to summarize what I discussed during this event and share the slides that went with my presentation.

Developing Native Android Applications with Java

Back in 2011, shortly after I graduated from college with a degree in Computer Science and Engineering, I had started developing Android applications. There were a few reasons why I chose Android versus another platform:

• I knew Java through my Computer Science degree.
• I had an Android device.
• I was financially broke exiting school, but could afford the one-time Google Play fee of $25.00.

At the time, Windows Phone wasn’t really a thing and BlackBerry was already approaching its death. That left us with the leader, at the time, being iOS, and then Android.

Fast forward a bit and I released my first Android applications. I had released an application called Spyfi, which allowed me to view and control my home security cameras remotely, an application called SQLTool, which acted as a remote database client for the popular relational databases, and an application called NetTool, which allowed me to monitor the uptime of my remote web servers.

All three of these applications performed well in terms of downloads, ratings, and revenue. However, developing them did not come without obstacles:

• Each application used the network which required the use of threading or asynchronous tasks in Android and Java. Creating multi-threaded applications in Java is no simple task.
• Managing orientation changes in Android is a lot of work because every change restarts the current activity, destroying all content including incomplete threads.
• Android has a lot of fragmentation, both in hardware and software.

Powering through each of the obstacles got me a published application in roughly six months.

At a certain point I began looking for a better way to develop Android applications. This brought me to Ionic Framework and hybrid web application development.

Developing Hybrid Web Applications for Android and iOS with Ionic Framework

Ionic Framework, at the time, was nearing its first stable release and it promised a lot when it came to fixing the problems with mobile application development. I chose Ionic Framework as the next phase of my development journey for the following reasons:

• Ionic Framework offered beautiful, minimal effort, application designs, something I had minimal skill in.
• The complexity behind threading, orientation changes, and other Java complexity was removed from the equation.
• I knew JavaScript through web development.
• I wanted to support iOS as well as Android to cash in on the larger audience.

Fast forward a bit and I released a few new mobile applications, this time for both Android and iOS. I had released Snapper for Digital Ocean, which controlled Digital Ocean VPS droplets via HTTP requests, and I had released OTP Safe, which managed time-based one-time passwords for Android and iOS.

Just like with my other Android with Java applications, these Ionic Framework applications performed well in terms of downloads, ratings, and revenue. The best part, they only took me two weeks to build in comparison to the six months it took me for the Java alternatives.

However, these Ionic Framework applications were not without obstacles:

• Apache Cordova, which Ionic Framework runs on, has a plugin problem where not enough exist and many are no longer maintained.
• The framework was constantly changing which resulted in projects breaking between minor releases.
• The performance was unpredictable, more so on Android.

I was developing native Android applications with Java which were buttery smooth. This was not the case with Ionic Framework because of how things were rendered. Apache Cordova applications render inside a WebView component, which is a native component. However, the components rendering inside this native component were not native. Think of it as components inside of components. At the end of the day you had a packaged web application. Remember the Android hardware and software fragmentation I mentioned? As a result of this, the WebView component performed differently across the board.

This lead me on a search for a better solution. I needed a solution that would solve my Android with Java problems as well as my Ionic Framework problems. This lead me to NativeScript.

Developing Native Android and iOS Applications with NativeScript

NativeScript came around the same time as React Native, both offering to be native mobile development frameworks that shared a single set of code. This removed the WebView from the equation, mapping framework components to native platform components. As a result, Android and iOS applications are very fast.

So why did I choose NativeScript versus another native framework?:

• I already new AngularJS from Ionic Framework and I wanted to stay invested in the next version, Angular.
• I heard good things from other users about framework stability.
• It promised what Ionic Framework and Android with Java promised.

Fast forward a bit and I released my first NativeScript mobile application for Android and iOS. I had released Solar Flare for Cloudflare, which leveraged the Cloudflare RESTful APIs to control accounts.

Again, this NativeScript application performed just as well as the Ionic Framework and Android with Java applications that I had previously released. Like with the Ionic Framework applications, this application only took me two weeks to deliver which is still a huge step up from Android with Java. The catch here is that Solar Flare is a native application with native performance and a beautiful UI. It is not a slow performing hybrid web application.

Does this mean NativeScript is without problems? Absolutely not! However, the obstacles I faced with NativeScript were minimal compared to the previous methods of development that I had chosen.

Conclusion

After having spoken with many attendees of the conference, they told me I hit the nail on the head, as in they shared my frustrations both when developing for Android with Java and when using Ionic Framework. Do I regret going down the road I did? Absolutely not, because at the time, each of these technologies were the best available.

The slide deck I used for this event can be found below.

Nic Raboy

Nic Raboy is an advocate of modern web and mobile development technologies. He has experience in C#, JavaScript, Golang and a variety of frameworks such as Angular, NativeScript, and Unity. Nic writes about his development experiences related to making web and mobile development easier to understand.