Comparing React Native to Axway Titanium

Comparing React Native to Axway Titanium

Here at Shockoe we often use cross-platform tools to build our apps. Using a cross-platform tool allows us to have one code base for apps that run on multiple platforms. There will be some platform specific code, but most things can be shared. Our cross-platform tool of choice is Axway Titanium. It used to be that cross-platform tools heavily leveraged WebViews. Tools like Cordova (ex PhoneGap) allow the developer to write a mobile website using HTML, CSS, and JavaScript. Then PhoneGap handles showing this content to the user inside of a native WebView. Instead of the WebView approach, Titanium gives you a JavaScript context and provides a bridge that handles interactions between the JavaScript environment and native components. Titanium stood out because it actually interacted with native components. But now Titanium is not the only framework out there that takes this approach. A couple years ago Kyle took an early look at React Native. Let’s take another look and see how React Native has come along.

Getting Started

Start off by heading over to the React Native Getting Started page. They offer two options: Quick Start and Building Projects with Native Code. I have not tried the, now default, Quick Start option. Several documentation pages refer to needing to “eject” your application if it was created from the Quick Start. For that reason alone I have only used the Building Projects with Native Code option.

There are a few dependencies to install, but the guide walks you through what you need. You will need NodeJS and the watchman package for observing changes. You will also need to install the react native cli. Additionally, you will need Xcode if building for iOS and Android Studio if building for Android.

Once you’ve got the dependencies installed you create a new project with the CLI:
react-native init AwesomeProject

Running the App

With no changes to the code base, you can immediately build the app you just created. In a Titanium project, all builds are handled through the Axway Appcelerator CLI or Axway Appcelerator Studio. This is not the case with React. It seems you can only build to an iOS simulator, Android emulator, or Android device with the React Native CLI. To do this you use either:
react-native run-ios
To target iOS simulator. Or:
react-native run-android
To target an Android device or emulator.

The options provided with these commands are a little lacking compared to the options with the Axway Appcelerator CLI. In my time with React Native, every simulator build chose the iPhone 6 simulator. I could not find an option to specify a different simulator with the CLI. Additionally, the CLI does not handle multiple connected Android devices well. You need to only have a single connected Android device or running emulator.

So how do you target other iOS simulators or build to an iOS device? Open Xcode! From there you use the same build options that a native developer would use. This is a huge difference from Titanium that basically discourages the use of Xcode for anything but building native modules. If you’ve never done native iOS development this can be a little daunting at first. It’s simple enough to find the play button and drop-down to select your build target. But what if you want to do an adhoc distribution build? Fortunately, there are plenty of resources out there for learning Xcode.

How about Android builds? This is an area that I am not as familiar with. Because the React Native CLI is capable of building to a device, I haven’t tried to build the project with Android Studio. I have generated a signed APK. The React Native documentation has a guide, but it comes down to using gradle.

Editing the App

React Native does not provide an IDE like Axway Appcelerator Studio. The documentation does suggest taking a look at Nuclide. Nuclide is a package for Atom that claims to setup an environment for developing React Native. I found I wasn’t taking advantage of its features, so I uninstalled it after a couple days in favor of just Atom.

So you can open the code in a text editor, where do you go from there? With a Titanium project, at least an alloy one, the entry point is alloy.js. From there the index controller has loaded first automatically. React Native provides entry points at index.android.js and index.ios.js. From there you can load whatever components you wish. The simplest thing to do is to edit some of the text provided with the sample project. Once you’ve made an update you can easily see your changes without rebuilding your app!

Axway Titanium provides a live view feature to see your app update as code changes. React Native offers a similar feature. On simulator you can press command + R to reload the code from the React Native packager. On an android emulator you can achieve the same thing by tapping R twice. Reloading can also be accessed from a built-in developer menu! To access the developer menu simply shake your device. You will see options to reload, enable remote JS debugging, enable live reload, and more.

Debugging Your Code

Axway Titanium attaches a console to builds made directly to a device, emulator, or simulator. The React Native process ends as soon as a build is installed and does not attach a console. Instead, you can enable remote debugging through the developer menu and debug your app in Google Chrome. You do not see a DOM representation of the app, but you do get access do the console and debugging tools! The debugging is done over TCP, so you don’t need to have built on a device connected to your computer. Inside the developer menu, you can change the URL used for remote debugging so you can debug as long as the device and machine running Google Chrome are on the same network.

Moving Forward

This has only been a brief look at getting started with React Native. In the future, I would like to revisit this topic to discuss more configuration, component driven design, and interacting with native code. React Native is very young, but it has come a long way in a short period of time. I am very excited to see how it matures as a cross-platform framework.

How technology leveled the playing field among drivers

How technology leveled the playing field among drivers

Most people may agree that there are two types of drivers – the confident and the not so confident. With the help of technological advancement, the automotive industry is leveling these playing fields, making it difficult to categorize drivers. One of my favorite commercials in the past year is the State Farm Safe Driver which depicted a female receiving a “safe driver refund” check. State Farm not only showed off their refund policy for their Safe Driver program, but highlighted that it was a female who got the refund instead of her husband who was helplessly confused possibly because of the oddly popular female driver stereotype.

Technology has always been able to make our lives easier. Safe driving is not excluded from the list of the daily tasks positively affected by technology. Today, the “not so confident” drivers can rely on an array of technologies to not only make us a tad more confident but ultimately safer drivers. So just how is the automobile industry leveling the playing field? We cannot answer that question without taking a high level look at how automobiles have evolved in recent years specifically with a technology in mind.

First there’s the navigation systems. Ten years ago, having a navigation system in your car cost about 10% of the price of your vehicle. Instead, drivers relied on printable directions from sources like MapQuest to get from point A to point B. Reports show that printed maps were a huge distraction for drivers resulting in safety concerns. If you think texting while driving is a major distraction, try reading a map while driving. Today, the majority of new cars have a navigation system—usually a touch screen—that comes standard. Additionally, the navigation has been voice enabled meaning drivers don’t even need to look at the screen for directions.

After a few more technological leaps came self aware cars. It’s mind blowing to know that your car has a sense of self-awareness. Augmented Reality allows cars to visually project directions, dashboard gauges, and more, in front of the driver’s view eradicating the need to look away. The windscreen of cars are now a massive digital screen with endless opportunities. The navigation, the voice commands, even the auto parallel parking really leveled the playing field for various drivers. AR is usually considered to be a live view of the real world, onto which extra data – usually pulled from the internet – is layered or superimposed. In recent years, we’ve seen more automobile brands incorporate AR to their offerings with a promise to make drivers less distracted, thus being able to focus more on what’s on the road ahead. I’ve driven recent models of luxury automobile equipped with AR used to project the dashboard gauges, current speed, maps, directions and other basic dashboard-like information onto the windscreen. The informative data had the amount of opacity not to impair the driver’s view of the what is on the road while at the same time keeping head and eyes straight ahead, nullifying the need to glance away to a navigational or any other screen(s). Once this becomes mainstream, one may argue we will have no need for street signs, since of course pedestrians will be wearing Google glasses with similar AR technology available.

Distractions are said to be the number one cause of accidents in recent years and reducing driver distraction has been one of the major goals of the automobile industry. First we were given Voice Recognition which meant I can tell my car to “take me home” and navigational guidance to my configured home address would be started automatically and now instead of glancing away to a screen I can now see the directions, current speed and a whole lot more right on my dashboard. This is the kind of technology that invigorates us at Shockoe.

We started 2017 with a focus on Voice Recognition, Augmented and Virtual Reality and I must add that it feels great to be a part of a company that has always been on the cutting edge of technology but even better, a company that is always ahead of the curve on the next big idea in this ever changing industry. So when you’re using your enhanced car windows that allow you to to zoom in on places and objects of interest that you are passing, when the back seat of your car appears transparent while reversing so you can see everything around you, just remember, Shockoe will be right there with you, working with those same technologies that are turning us all into confident drivers.

Making a great app takes time

Making a great app takes time

Hey all, I’m Bruce.  I’m a new hire at Shockoe.com.  I’m very excited to be here on the front lines of the mobile revolution!

Building a mobile application involves much more than just making the app.  There’s extensive design work, development time, and testing that goes into every mobile application that you ever use.  To further complicate things, not every app is created equal, and many projects have specific needs that can be difficult for a non-technical user to understand.  As part of Shockoe’s mission of helping you tame the mobile monster, we’ve put together a few things worth considering when you’re trying to design your mobile application.

Making apps takes time.  Making a great app takes more.

 Creating an app that suits both your company’s and users’ needs takes time.  Time needs to be spent on coming up with a design that catches the eye and conveys all of your information, and time needs to be spent with the code behind the application to make sure that it can actually do everything that your customers need it to do.  Then there’s testing.  Though often overlooked, testing is the difference between an app that ‘works’ and an app that you can’t live without.  A little bit of extra time on the testing of your app can make a world of difference when it gets into your customer’s hands, and make the all important first impression that much more memorable.

Cross platform support: a whole new can of worms

 Take a look around any public space and you’ll see dozens of different devices.  Apple, Google, BlackBerry, and Microsoft each have their flagship lines of phones, each with their own operating systems, and frankly it’s extraordinarily difficult to support them all.  Here at Shockoe we make use of Appcelerator’s Titanium API, which allows us to share a great deal of code between different versions of our applications, but even that doesn’t come for free.  Each OS has its different quirks, different UI themes, and different modes of use, and every different device will take debug, design, and development time, no matter how awesome your tools are.

 Servers: out of sight but not out of mind

 People don’t tend to think about servers when they’re thinking about mobile applications, and for good reason.  If a server is doing its job, the users will never even know it exists.  However, when you’re thinking about making the next hit mobile application server needs are something you absolutely need to keep in mind.  Will your users need an account to make use of your app?  Will you need to be able to send updates out to your users?  Will you need to store information from various users’ phones for your app to really be useful? In any of these cases, you’ll need some kind of server.

Long term maintenance: How long will you be living with this app?

After your app is finished, it enters into a new phase of its life.  As devices change, other software gets updated, and user feedback is received, it is important to continue to update your application to address these changing concerns.  UI elements may need to be updated to work with the hottest new version of iOS, you may need to fix an error introduced by an update to Google Maps, or your friendly neighborhood hackers might find a security vulnerability in some library that is critical to your application and require an update or complete rewrite of the problematic code, or your app could become so wildly popular that your old servers just don’t cut it anymore.  You need to be prepared to deal with all of these things when you start planning for your application.

** Image source : Kinvey