React-Native – First Impressions

During F8 2015, Facebook engineers announced a new platform for building native mobile apps – React-Native. Originally, only iOS support was released, but after a short delay Android support became available. React-Native extends the Flux/React libraries and architecture concepts with tools that produce native binaries. The language used to develop the code, just like with React.JS is the JavaScript. The ability to produce native-looking apps is achieved by combining JavaScript “glue-code” with plugins/controls developed with native code. In that perspective, React-Native is similar to Appcelerator.

Unlike Appcelerator, react-native has a better semantics for describing plugin interfaces, and more importantly as a React-platform react-native enforces better application architecture.

At this time, React-Native does not support Windows targets.

React-Native philosophy is upfront about the fact that no cross-platform tool is suitable for developing a single codebase for all platforms. Therefore, the React-Native team called their approach “learn once, write anywhere” instead of traditional “write once, run anywhere.” We discussed the issues that prevent apps of moderate and higher complexity to run off a single codebase while doing a practical Appcelerator overview.

At our client’s request, we used react-native developing a now top-rated financial services app, which won iTunes App of the Week upon release. We want to share our experiences with any developers thinking about giving react-native a go.

What are the requirements?

React-Native should be only considered when developers have both extensive experience developing native apps, as well as JavaScript expertise. Even if you are building a simple app, where no custom native controls will be required, it is possible that you will need to fix bugs in react-native itself. Hence, without native platform expertise, we do not recommend utilizing react-native for production apps.

What are the benefits?

  • React – Flux/React is a powerful architecture praised by leading software architects.
  • Glue code is shared between all platforms, making it easier to keep platform-specific parts synchronized.
  • App looks and feels native.
  • Tools such as Microsoft Codepush allows publishing some updates without having to wait for App Store approvals.

Is React Native ready for prime-time?

There is no simple answer to this question. There are lots of bugs in the platform, mainly in controls. Bugs are not terminal. An experienced engineer should be able to deal with those. React-Native community is rapidly growing, and often a bugfix may already exist somewhere online. In a little over one year, react-native community produced lots of open source modules offering functionality such as integration with third-party services, as well as user interface controls. If you don’t mind maintaining a custom react-native platform build, chances are that the bugs won’t stop your team. Apparently, core react-native team prioritizes features over stability. There is some UI responsiveness and snappiness degradation, on Android more than iOS.

While your mileage may vary, we believe that React-Native is a powerful platform worth at least observing.

Please follow and like us:

Practical Xamarin.Forms Introduction

The cross-platform Xamarin toolset is used by developers to share code between versions of apps written multiple platforms including Android, iOS and Windows Phone. In order to further simplify development of simple forms input -driven applications, Xamarin provides a special UI kit – Xamarin.Forms. In the past, we gave a short Xamarin.Forms overview. Today, we want to dive deeper, sharing practical Xamarin.Forms tips.

Xamarin.Forms is implemented above Xamarin.iOS, Xamarin.Android and Xamarin.WinPhone. If your app can be coded using only Xamarin.Forms UI, theoretically it should allow sharing of both application logic and presentation. The same project could be built for and used on multiple platforms, without platform specific customizations.


forms-architecture

The above image illustrates Xamarin.Forms architecture with Portable Class Libraries sitting above Xamarin.iOS, Xamarin.Android and Xamarin for Windows Phone. In a nutshell, Xamarin.Forms is a collection of editors, layout panels, navigation panels etc. In order to display controls, Xamarin utilizes a concept of a renderer. Renderer is essentially a platform-specific implementation of a cross-platform Xamarin.Forms primitive. In turn, platform-specific Xamarin controls are wrappers around native controls. For example, PCL layer’s class Button is backed by ButtonRenderer implemented in Xamarin.Android, Xamarin.iOS and Xamarin.WinPhone. A layer deeper, ButtonRenderer is rendered using a native button control – UIButton on iOS.

While learning Xamarin.Forms, we uncovered various limitations. Let’s review the issues that developers face and the strategies on mitigating some of those issues.

  • One of the first problems that we noticed while working Xamarin.Forms is the incomplete implementation of WPF templates used for defining the visual appearance of the controls.
  • Since platforms and their native controls often significantly differ, renderers have to hide some of the features in order to unify their PCL-level representation. For example, Android text field control can be styled for both single and multi -line appearance, while iOS includes two controls UITextField for single-line input and UITextView for multiline. Since one control is backed by a single renderer, Xamarin.Forms PCL text input control is always multiline.
  • Sometimes, a PCL control looks or behaves differently on each platform. For example, some Windows Phone controls, such as the Switch control have wide margins. On iOS and Android, this issue is not present. Xamarin.Forms apps using such vanilla controls will render quite differently on Android/iOS and WinPhone, which could be a problem – a view with such controls that looks perfectly fine on Android and iOS may simply not fit the screen on Windows Phone.
  • An additional abstraction layer plus aggressive re-drawing/re-rendering of the view with the contained elements makes Xamarin.Forms apps noticeably slower than their native counterparts.

While the above-mentioned problems are indeed real, Xamarin.Forms can be “tuned” to mitigate some the issues. In order to overcome limitations, we will dive into the Xamarin platform. Let us try to deal with the wide margin issue.

We make a test app displaying two switches with the look defined by the below grid.

<Grid RowSpacing=”0″>
   <Grid.RowDefinitions>
       <RowDefinition Height=”Auto” />
       <RowDefinition Height=”Auto” />
   </Grid.RowDefinitions>
   <Switch Grid.Row=”0“ />
   <Switch Grid.Row=“1“ />
</Grid>

On iPhone, our app will render as:

switch_ios

The appearance on Android will be similar, however on Windows Phone the app will look as:

switch_winphone

Windows Phone switch control has a lot wider margins. Since this issue is specific to Windows Phone, we have to solve it at the Windows Phone level. While we could create a new default Windows Phone style with narrow margins, this is not a good solution since the new style would be applied to all WinPhone controls. Instead, we will adjust appearance of the switch by creating a custom switch control renderer where we can tune the visual appearance as necessary.

Control switchControl = VisualTreeHelper.GetChild(Control, 0) as Control;
Border border = VisualTreeHelper.GetChild(switchControl, 0) as Border;
Grid grid = VisualTreeHelper.GetChild(border, 0) as Grid;
grid.Height = 40;

Now, we need to return the correct size.

public override SizeRequest GetDesiredSize(double widthConstraint, double heightConstraint) {
   SizeRequest result = base.GetDesiredSize(widthConstraint, heightConstraint);
   result.Request = new Size(result.Request.Width, 40);
   return result;
}

Now, the margin is slimmed and our app looks as below.

switch_winphone_tuned

Stay tuned for more Xamarin and Xamarin.Forms tips in upcoming posts.

Please follow and like us:

Developing native Appcelerator modules – Part I

A possibility of using native modules along with JavaScript is one of the reasons Appcelerator is selected for many projects. Modules narrow the gap between native and cross-platform development approaches. Sometimes, native modules are the only way to make your Appcelerator app do what is required.

Programming native Appcelerator modules is not difficult. At the same time, we felt that even with existing tutorials, the first time developers could use another detailed walk-through, based on a real project.

Enjoy the three-part blog post covering in detail implementation of a native Appcelerator module for the social network VKontakte, based on the VK SDK for iOS and Android.

VK

Part I –  Designing native Appcelerator modules for VK

Why/when is a native plugin necessary? In every situation the answer in different. In our case, the app was originally made with a JavaScript module. We found a free barebone JavaScript Titanium module called ti.vkontakte on GitHub and within a couple of hours extended it with the additional functionality that we needed. The resulting module correctly worked on all supported platforms. The problem was that users were complaining about having to enter username and password via VK web authentication, instead of authorizing through the standalone VK app. In fact, we discovered that majority of end-users often do not remember their credentials. A native plugin would allow users to interact with the VK social network using a session already running on the VK app. There would be no need to enter credentials separately.

Our extended ti.vkontakte JavaScript Appcelerator module supported methods: authorize(), deauthorize(), makeAPICall(), exposed properties: appid, permissions, token and user, plus the JavaScript plugin generated various events. We were happy with JavaScript module’s API. Our goal is to rewrite the VK module in the native code, supporting one platform at a time. We decided to reimplement the JavaScript vkontakte module API keeping all signatures. This way, we would get away with only one conditional JavaScript statement to utilize native modules where available.

Further, we found a working Appcelerator module with similar functionality – ti.facebook developed for the same purpose as our module, except for Facebook. In this tutorial, we will create a new module named ti.vk based on the JavaScript module’s API, VK SDK for Android and iOS, as well as the ti.facebook Appcelerator module.

Before we begin coding the native VK module, let’s prepare by configuring VK SDK. We already had made a standalone VK app used to authorize with JavaScript. To authorize through SDK, VK requires that developers configure the app bundle field of the standalone app. The last configuration task is to setup our app’s URL-schema. We add the below section to the tiapp.xml file.

<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleTypeRole</key>
<string>Editor</string>
<key>CFBundleURLName</key>
<string>vk1234567</string>
<key>CFBundleURLSchemes</key>
<array>
<string>vk1234567</string>
</array>
</dict>
</array>

For more information about developing for VK, see the relevant developer documentation. In the meantime, we are ready to start coding our iOS and Android native Appcelerator modules. To be continued in Part II.

Please follow and like us:

Xamarin.Android Performance Analysis

Ever wondered how Xamarin.Android performance stacks against code written in Java? We did.

As an introduction, let’s refresh Xamarin.Android architecture. While on Apple iOS Xamarin code is compiled into native code, on Android things work differently. Xamarin code runs inside a VM which works side-by-side with Java VM running Dalvik code. Hence, since Xamarin does not need to go through JVM, it could in theory work as quickly as even faster than Java. In reality, Xamarin apps will be larger than Java apps, since there is a need to bundle the Xamarin runtime.

  • Let’s examine overhead of Xamarin runtime. In order to do this, we built a simple “Hello World!” app. The app size is under 2 MB.
  • Startup time for native Java apps is better than for Xamarin. While a small Java application starts almost immediately, our Xamarin app takes a second.
  • Integer and floating multiplication written in Java are about 20% quicker.
  • Operations with collections are almost 10 times faster on Xamarin than on Java, because Java lacks struct value type.
  • String manipulations under Xamarin are about four (4) times faster than code written in Android-native Java.
Please follow and like us:

What we learned from using Xamarin.Forms

According to Xamarin using Xamarin.Forms can increase code-reuse for Android, iOS and Windows from 70% to 90%. 

Cons:

  • Number of available controls is still limited. Some supported controls are missing critical properties. For example, Picker is missing bindable.
  • Some XAML features are missing while others are implemented differently.
  • Documentation is often insufficient, sometimes limited to a list of properties and method signatures.

Pros:

  • Missing controls can sometimes be substituted with third-party plugins.
  • XAML allows specifying platform specific layouts with OnPlatform and OnIdiom.
  • Elegant publisher-subscriber implementation allows loose coupling between platform specific and shared code.
Please follow and like us:

Crossplatform Mobile App development with Xamarin

Now that Microsoft put its’ weight behind cross-platform C# development for Android and iOS with Visual Studio 2015, it makes even more sense to take a look at Xamarin.

Xamarin interacts with iOS and Android platforms via proxy libraries MonoTouch and Mono.Android.

Pros:

  • Crossplatform – Multiplatform support is provided by standard Mono/.NET libraries – System.Data, System.IO, System.Net etc.
  • Xamarin apps run Android, iOS and Windows.
  • Visual Interface Designer- InterfaceBuilder and Visual Studio add-on allow visually designing UI.
  • C# – Developers familiar with C# can build apps suitable for AppStore distribution without having to learn Objective-C or Java.

Cons:

  • Memory Leaks – Most classes implement IDisposable interface and memory leaks are a serious concern. Elements are often proxies to native objects and Dispose it required to memory leakage.
  • Exceptions – While Xamarin throws exceptions such by raising MonoTouch.Foundation.MonoTouchException and Java.Lang.Throwable, yet some exceptions only happen inside framework and never get to the app. Stack overflow, for example, crashes the app without even raising any exceptions.
  • Some native API calls are not supported. For example, MonoTouch.AddressBook.ABPerson.GetVCards is missing. Xamarin.Android does not generate events AnimationStart and AnimationEnd for ViewFlipper.
  • Support – there is a lot more information and help available for native development.

The shortcomings of Xamarin are manageable, but in some instances developers have to be ready to hack the Xamarin platform or engage a consultant to help with topical issues.
If you are planning to develop an app for just one platform, it probably makes sense to stay native, even if it requires learning a new platform.

Please follow and like us:

Crossplatform Mobile App development with Appcelerator Titanium

We would like to share lessons with learned from our experience developing mobile apps with Appcelerator Titanium. This information might be helpful to anyone selecting development tools for a new mobile app.

Pros:

  • JavaScript – an ability to code in JavaScript then run an app on multiple platforms including Apple iOS and Google Android allows developers familiar with web technologies to develop apps without having to learn native iOS and Android programming languages and tools.
  • Rapid development – prototypes can be developed quickly with little code in JavaScript.
  • Same sources work on multiple platforms – the same Titanium JavaScript code, with little optional minimal variants, runs on multiple mobile platforms including: iOS, Android, Blackberry and now Windows.
  • Community – large developer community with active forums and a marketplace with a multitude of modules extending built-in functionality.

Cons:

  • Double-clicking – An app developed on a native platform normally disables the element that generated an event while one is being processed. For example, a user presses on a button and while the app does what is necessary, the button becomes greyed. Appcelerator Titanium can send multiple events, which may be undesirable. Think of a user sending the same chat text multiple times.
  • Android memory management – Android memory management is a challenge even for native apps. An app will often receive only 16 MB of memory. Since each pixel is represented by four (4) bytes, one picture full-screen image with a resolution of 480×800 will take 1.5 MB. Given this reality, developers commonly have to monitor activity service for resource availability and exceptions to prevent apps from exhausting memory. Titanium does not provide this information to the app, and there is no simple way of getting it. In addition, Titanium has problems with memory leaks, which can be mitigated to a degree.
  • Conditional code for each platform – both API and screen resolutions require that developers create a variable or a function set to the platform and constantly include lines similar to the below:

    if(Titanium.Platform.name.indexOf(‘iPhone’) >= 0)
    {
        isIPhone = true;
        isAndroid = false;
    }

and

   var fontSize = hookup_utils.isAndroid() ? “6pt” : “10pt”;

or

    if (hookup_utils.isAndroid()) {
        winParam.exitOnClose = true;
    }

  • Lag behind native tools – Apple releases RC versions several months to releasing the OS to the end-users. This allows developers using native tools to submit apps for an approval in time for general availability. Titanium lags few months behind native tools and usually these no way to coordinate release with Apple. Depending on the marketing strategy, this can seriously impair your ability to piggy-back off Apple marketing campaign.
  • Bugs – Each Titanium release addresses some of the known bugs, yet comes with its’ own set of new problems. Since Appcelerator sits above the native platform, all of these bugs are in addition to iOS and Android bugs. For example, Titanium version 3.1.3 caused a significant regression with animations.

 

The above problems are solvable. Depending on technical requirements and developers’ experience, Titanium can be a great platform. The important part is to make an educated decision so that benefits clearly outweigh challenges.

Please follow and like us: