PropertyCross Android Implementation Shootout

Overview

TrackAbout is evaluating cross-platform mobile application development frameworks for the next version of our mobile software. There are more than a dozen competing frameworks, with more appearing every week. It’s daunting to place a bet in a marketplace with this much flux.

Recognizing the confusion in the marketplace and choosing to do something about it are the people behind the PropertyCross web site. You can read about their goals on their web site, but the short version is that they’ve published a spec for a modest mobile application and are soliciting developers to implement the spec using as many frameworks as possible. This is an invaluable resource for those trying make sense out of the options.

Source code for all implementations is available on Github as is the specification for the PropertyCross example application.

In February 2013, I downloaded all of the Android implementations published on the PropertyCross site and sideloaded them onto my Verizon Galaxy Nexus. I then used every feature of each app in an effort to get a feel of the differences between the cross-platform mobile application frameworks.

The PropertyCross implementations reviewed (in no particular order) were:

“Methodology” (Caveats)

This was not a rigorously controlled experiment. I didn’t make any special efforts to install each app onto a factory-reset stock device with no other apps or background services running. Unrelated background processes can impact the perceived performance of apps. Whenever I sensed a slowdown, I looked for bad actors in the background. I repeated the same activity to raise my confidence that what I was seeing was due to the app itself.

I did not test on multiple devices or OSes. I don’t have an iOS device to test with, but even if I did, the PropertyCross applications are not code signed. I’d have to go about signing them myself to load them, making such an endeavor considerably more time consuming.

This was a comparative review in which I tested multiple implementations on the same device to get a feel for how they differed. This was sufficient for my needs. Because some of the implementations use webview frameworks, they rely on the built-in WebKit browser on the device. Anyone attempting a similar exercise should be aware of this, and that the older the version of the OS, the older the built-in WebKit engine is going to be and the slower the webview frameworks will perform.

I worry that this blog post will inevitably grow stale or misleading. Issues I report here may be resolved in future PropertyCross releases or by the framework providers. Therefore, please note the date of this blog post and try the latest builds of the apps on the frameworks you care about before arriving at your own conclusions. At the time of writing, the team was not publishing version numbers of the apps, so the publishing date is going to be your best marker.

Each PropertyCross implementation had its shortcomings. In many cases it was difficult to tell which issues were due to developer choices versus framework limitations. I enlisted the help of PropertyCross site founder Colin Eberhardt, Sam Hogarth, and other members of the PropertyCross team to help me better understand my observations and incorporated their feedback. They were forthcoming and helpful.

On “View Bouncing”: In several of the implementations, if you swipe a view up or down, the whole screen bounces. It’s the iOS overscroll effect intended for lists, but it makes no sense in certain contexts like static forms. I made a note of wherever I saw this effect when I thought it didn’t belong.

On “Overscroll Glow”: This is the expected Android overscroll effect. When scrolling to the beginning or end of a list, the top or bottom edge glows.

See examples of both iOS and Android overscroll effects here and here.

I have categorized all issues I noticed thus:

[FRM] – The issue being noted is due to the underlying framework.
[DEV] – The issue being noted is due to a choice by the developer.
[?] – Could not determine.


Native (Java)

clip_image002[4]

Source code: 1,383 KB
APK size: 607 KB

clip_image004[4]clip_image006[4]clip_image008[4]

Initial Load Time

  • Fast, under 2 seconds.

List Scrolling:

  • Very responsive scrolling, no touch delays.
  • Implemented the overscroll glow.
  • There’s no accidental highlighting of list items touched while scrolling as occurs in several webview frameworks reviewed.

View Bouncing:

  • None (I’d only expect this in a webview app)

Button Responsiveness:

  • Excellent

View Transition Speed and Quality:

  • [DEV] View transitions are very fast, but images on property view should be preloaded before showing the screen.

Of Note:

  • Upon clicking Go to start a search, the Go and My Locations are disabled, signaling (1) that a search is underway and (2) that additional taps are not necessary (or possible). This disabling of input buttons was also done when clicking on a recent search in the recent searches list.
  • [DEV] Upon the start of the application, the cursor was in the search textbox, and the on-screen keyboard was presented automatically. On one hand, this is nice if my first action is to perform a new search. If I wish to access Recent Searches, then the keyboard is in my way. On my Galaxy Nexus, the onscreen keyboard obscures the Recent Searches block. The search view does not support scrolling to allow me to access Recent Searches without first hiding the keyboard.

Shortcomings:

  • [DEV] The Recent Searches are not being remembered from run to run.
  • [DEV] Property images are not being pre-loaded or cached. Scrolling down in the list view reveals images being loaded on-demand. Scrolling back up to properties already viewed, I notice images that were shown previously are now lost and must be reloaded. That is wasteful.
  • [DEV] Defect: I searched on “London ” with a trailing space. Clicking on “Go” button, nothing happens. Delete the space, the search is conducted successfully. Trimming input is very important because most predictive text keyboards (I use Swiftkey) automatically insert a space after each word.
  • [DEV] On the list view, there is no visual feedback when tapping “Tap to load more…” area — can’t tell if it’s working or not, and can’t discern what area is technically tappable.
  • [DEV] Clicked My Location — app was unable to determine my location. GPS and wifi are both on. I’m in the United States, and the properties are not. Ideally, the application would report that there are no properties available in my region.

Final Thoughts:

As the Native implementation, this should be the “gold standard” implementation against which the multi-platform development frameworks are compared. All the shortcomings expressed are developer issues to resolve, not framework issues. I’d like to see all the shortcomings resolved and then see if the team can bring the rest of the implementations up to this standard.


jQuery Mobile (PhoneGap)

clip_image010[4]

Source code: 7,724 KB
APK size: 1,523 KB

clip_image012[4]clip_image014[4]clip_image016[4]

Initial Load Time:

  • [FRM] Slow, 4-5 seconds.

List Scrolling:

  • [FRM] List view takes several hundred milliseconds to register a swipe before it starts scrolling. JQTouch Phonegap implementation doesn’t seem to suffer from this.
  • [FRM] Swiping the list view up or down causes a highlight on a list item. This is likely a shortcoming of the webview framework being bad at determining a tap/double-tap/swipe.
  • [FRM] List does not implement the Android overscroll glow. Instead it bounces like iOS.

View Bouncing:

  • [FRM] All views bounce up or down when swiped. Likely an artifact of the webview nature of the framework.

Button Responsiveness:

  • [FRM] Poor. There’s a responsiveness delay when hitting any button: back, favorite. Colin pointed out this is most likely due to the way mobile browsers handle tap events, delaying to determine if a tap will become a double-tap. For more info, see https://developers.google.com/mobile/articles/fast_buttons

View Transition Speed and Quality:

  • Search to List View: Always going to be slow due to the query. Would need to do profiling to determine how much is due to the framework vs. the query.
  • List to Property View: Fast
  • Property View back to List View: Slower, probably due to a large list being displayed. Not outrageous.
  • Search to Favorites: Fast enough

Shortcomings:

  • [FRM] Menu button image in the navigation row, even though it does nothing. Apparently this is difficult or impossible to hide in Phonegap.
  • [?] I left the app while viewing the Property View, then returned later and was left staring at a blank canvas. I tapped the screen and the Property View appeared instantly.
  • [DEV] “Load more” in the list view doesn’t provide feedback when tapped.
  • [?] Android “Back” button behavior acts more like a browser than an app. I expect that when on the search screen, back would exit the app, but it keeps going back through screen history.

Final Thoughts:

This implementation isn’t competitive as-is. Probably jQuery Mobile could be made better through tricks, tweaks and different javascript library choices. There are many ways to make an app using PhoneGap or other webview frameworks. A lighter weight library like Zepto.js could be used in place of jQuery, perhaps. Knockout.js was used in both this implementation and JQTouch, but there can be bad choices made using any framework or library which can make an app slow.


JQTouch (PhoneGap)

clip_image020[4]

Source code: 1,526 KB
APK size: 1,507 KB

clip_image022clip_image024[4]clip_image026[4]

Initial Load Time:

  • Around or under 3 seconds. Quicker than jQuery Mobile. Shows a splash screen. Acceptable speed. Since both this and the jQuery Mobile rely on the WebKit browser engine, I am guessing the speed delta is due to differences in the javascript libraries and UI frameworks being used.

List Scrolling:

  • Smooth. Increases my confidence that a webview framework can deliver on performance.
  • Android overscroll glow was implemented.

View Bouncing:

  • No bouncing of views when swiped. Good.

Button Responsiveness:

  • [DEV] Acceptable speed, but somewhat variable amount of visual feedback provided throughout the app. The Back button on the Property View doesn’t provide any tap feedback. In other places, buttons flash green.

View Transition Speed and Quality:

  • Search to List View: Always going to be slow due to the query. Would need to do profiling to determine how much is due to the framework vs. the query.
  • List to Property View: Fast
  • Property View back to List View: Pretty fast.
  • Search to Favorites: Fast enough

Shortcomings:

  • [FRM] Menu button image in the navigation row, even though it does nothing. Apparently this is difficult or impossible to hide in Phonegap.
  • [DEV] Styling and colors are pretty bad in this implementation. Black text on dark grey? Skeuomorphic faux-leather background? Colin tells me this may be the default style of JQTouch, and where possible, they wanted to use whatever default styling the framework provided. I’ll call this a DEV shortcoming because it could be modified and therefore shouldn’t count against the framework.
  • [FRM] List items flash/highlight when swiped. JQuery Mobile did this too, but it’s much more pronounced and noticeable with JQTouch.

Final Thoughts:

Overall I’d be satisfied with this level of performance, minus the style choices. This implementation shows me that a webview framework can deliver on performance.


RhoMobile

clip_image028[4]

Source code: 2,223 KB
APK size: 3,348 KB

clip_image030[4]clip_image032clip_image034

Initial Load Time:

  • Around or under 3 seconds.

List Scrolling:

  • [FRM] There’s the tell-tale slight delay in registering a swipe to scroll. Seems faster than the jQuery implementation, but still not instantaneous or even close to the JQTouch implementation.
  • [FRM] Scrolling is not smooth. Jittery, jumpy.

View Bouncing:

  • None.

Button Responsiveness:

  • [FRM] Buttons seem responsive when they work. But intermittently, they don’t work.
  • [FRM] Odd artifact: When tapping on a list view item, first it changes style slightly (inversion of 3D perspective) indicating the tap, then it highlights in blue, then the view changes. Odd.

View Transition Speed and Quality:

  • [?] Views have a slide transition, making them seem slower than other implementations.
  • [FRM] Transition from list to property view has a slight delay following a tap. Likewise going back from property view to list.

Shortcomings:

  • [?] This app runs “full screen” and makes it impossible to access the Android notifications area at the top of the screen. I hope this is configurable by the developer.
  • [DEV] In places, the app lacks progress indicators (spinners) letting you know it’s doing something.
  • [?] On search view, typed in London, hit Go, saw a brief “Searching” message then nothing. Tried Liverpool, then got some results.
  • [?] Several times, the search the query has not worked. Almost like the web request timeout is too short by default and the developer isn’t providing feedback on failures.
  • [?] Intermittent loss of button clicks. Sometimes button presses just seem to get swallowed, lost. Looking at a single property, hit the Back button, it flashed registering the tap, then nothing happened. Clicked the Fave button, it didn’t change status. Went all the way back, looked at my faves and the property was there. Clicked it to go to property view and now the Fave button reflects that it’s a fave.
  • [DEV] When I went back from a property view to the list view, the properties I’d loaded using a Load More action were gone and I was back to the original list, having to do Load More again. The state of the list view is not being maintained.
  • [DEV] Menu button image actually does something in this implementation. It brings up a menu containing: Home, Refresh, Sync, Options, Log and Close. Home and Refresh work. Sync does nothing. Options throws a 404 Not Found and hitting Back exits the app. Log shows a console log. Close does what you’d think. My money says this is a default Rho menu structure which all Rho apps would have if not hidden or modified.

Final Thoughts:

This is the worst implementation of the bunch. I suspect it’s largely the developer’s fault. If I were Motorola Solutions, I’d be trying to get this implementation improved

Side Note: Spoke to three reps from Motorola Solutions on Feb 21, 2013, suggested they get someone to contribute.

Side Note 2: Colin tells me the developers who built this version would be submitting updates. Not in time for publication, however.


Xamarin

clip_image037[4]

Source code: 12,456 KB
APK size: 6,756 KB

clip_image039[4]clip_image041[4]clip_image043[4]

Initial Load Time:

  • Around 2 seconds.

List Scrolling:

  • Smooth.
  • Implemented the Android overscroll glow.
  • [DEV] Loading of property images in the list view is not optimal. Images are being loaded on-demand as the user scrolls instead of prefetched. There appears to be no caching of images. If you scroll down then back up, images are being reloaded over and over again. Sam told me there are options for improving this implementation, so it’s not a framework limitation.
  • List memory was maintained when returning from a single property view.

View Bouncing:

  • None

Button Responsiveness:

  • Excellent overall
  • [DEV] Good touch feedback on the Go search button. Switched to a “loading” spinner which let me know something was happening, but then dropped back to the Search view for a moment before loading the property lists. Sam later told me he’d remove the search spinner in favor of an implementation that more closely follows that of other frameworks.
  • Excellent touch responsiveness on the Fave button. Good implementation with the star metaphor.

View Transition Speed and Quality:

  • Nice fade effect when switching between screens. Fast and not annoying.
  • [DEV] Failure to prefetch and cache the property images is hurting the property view.

Shortcomings:

  • [DEV] The app forgot my recent searches between launches. This was a bug and will be fixed in a new release.

Final Thoughts:

App is responsive. Even while simultaneously loading list view images, clicking on a property immediately changes to the property view. Nice.

Overall, excellent implementation and speeds are comparable to Native.


Titanium

clip_image045[4]

Source code: 315 KB
APK size: 7,552 KB

clip_image047[4]clip_image049[4]clip_image051[4]

Initial Load Time:

  • Around 3 seconds.

List Scrolling:

  • [FRM] Scrolling is jittery.
  • Android overscroll glow was implemented.
  • Property images appear to be getting cached and reused for the property view, which is good.

View Bouncing:

  • None

Button Responsiveness:

  • Excellent. In some cases, from the list view, the property view is shown even before the list item tap highlight can be rendered.

View Transition Speed and Quality:

  • Switching between list view and property view is fast.
  • View to view navigation is smooth and quick everywhere.

Shortcomings:

  • [?] App force-quit the first time I launched it. Launched successfully the second time. Can’t say it’s the framework’s fault, but it’s the only time this happened in all my testing.
  • [DEV] I typed “London ” with a trailing space by accident. It wasn’t recognized. Sloppy programming on the part of the developer who didn’t bother to trim the input, and on the web service provider who also didn’t bother to trim the input. UI showed a lat/long in the text box after the failed request.
  • [DEV] Favorites feature is hidden behind the Android Menu button, which is a different implementation than all the others.

Final Thoughts:

Overall, snappy app. Competitive.


Sencha Touch 2 (PhoneGap)

clip_image053

Source code: 18,259 KB (most of this is an sdk folder)
APK size: 645 KB

clip_image055clip_image057clip_image059

Initial Load Time:

  • 4-5 seconds. A bit slow.

List Scrolling:

  • [FRM] Scrolling is not smooth, jumpy.
  • [DEV] Developer implemented pull-to-load more in the property list view — the only implementation to do that. Colin tells me the developers did it because it was easy with Sencha. There’s debate on the PropertyCross team as to whether it should be left as-is, or whether the implementation of “Load more” for the list view should be standardized.

View Bouncing:

  • [FRM] Every view bounces when swiped, including the list view.

Button Responsiveness:

  • [FRM] Bad touch feedback. Slow to register touches. Typical of webview implementations.

View Transition Speed and Quality:

  • [FRM] Really slow to go back from list to search view. So slow I’m not sure whether I hit the button or not.
  • [FRM] Sliding view transition makes view changes seem slower than other implementations. This is the framework default.

Shortcomings:

  • [FRM] Menu button image in the navigation row, even though it does nothing. Apparently this is difficult or impossible to hide in Phonegap.
  • [FRM] Seems that some button presses are registered but just lost. I hit the Back button, I’m sure I did, but nothing happened. Likewise with Fave. Next time, it worked.
  • [FRM] By default, Sencha seeks to provide the look and feel of an iOS native app. This is apparent in the shape of the Back button and in the transparent progress spinner overlay which looks exactly like many I’ve seen on iOS. This will undoubtedly look foreign to users on other platforms.

Final Thoughts:

This implementation is roughly on par with the jQuery Mobile implementation, which is to say it’s not particularly impressive.


Adobe Air

clip_image062

Source on disk: 547 KB
APK size: 9,584 KB

clip_image064clip_image066clip_image068

Initial Load Time:

  • Slow, around 7-8 seconds. 5 seconds just to show the splash screen. Likely due to the overhead of starting the Air runtime.

List Scrolling:

  • Scrolling is a little jittery.
  • Android overscroll glow was not implemented.

View Bouncing:

  • [FRM] The contents of the Recent Searches list box bounces when swiped. There’s no utility in this.
  • [FRM] The list view bounces when swiped at the top or bottom.

Button Responsiveness:

  • Snappy. Excellent touch feedback.

View Transition Speed and Quality:

  • Fairly quick from list view to property view.
  • [?] Slow coming back from property view to list view. However, the quantity of loaded properties and their images were remembered and maintained.
  • [?] Slow navigating back from list view to search view.

Shortcomings:

  • [DEV] Clicking “My location” on search view did nothing.
  • [DEV] Clicking “Go” with an empty search box resulted in an error: “No converter registered for converting class Error to class mx.rpc::Fault”. This also rendered the Recent Searches inaccessible until a successful search is conducted, at which point it re-appears.

Final Thoughts:

  • Overall, a respectable implementation, although the APK size is is ten times that of the smallest implementations. Colin tells me the size of the APK is mainly due to the one-time hit of the AIR runtime, but the use of the Flex framework (and to a lesser extent the Parsley framework) also contribute one-time hits to the APK size.
  • Startup time is the worst of the bunch.
  • Noticeable delays coming “back” from the various views.

Conclusions

I wasn’t planning on publishing the results of this exercise, but I was encouraged to by Colin Eberhardt. He felt it made “interesting reading” and might benefit others. Colin and his team have been very receptive to my feedback and they are actively working on improving and normalizing all of the implementations.

I’d like to see the shortcomings resolved in the Native Android implementation so that it can truly be the “gold standard” by which the other implementations are judged. The rest of the implementations should be brought as close to the Native implementation as possible. This would give the community the most insight into what level of performance and parity is possible with each framework.

The PropertyCross specification could be more prescriptive. There are several differences in how features were implemented. For example:

  • The Titanium implementation relies on using the Android Menu button to add Favorites and view them later, where every other implementation uses dedicated on-screen buttons.
  • The “load more properties” implementation at the bottom of the properties list view is implemented slightly differently by one app, supporting a pull-to-load-more paradigm.
  • The use of button labels versus icons for the favorites feature varied.
  • Things like input trimming, validation and how to best handle error conditions should be explicitly defined. Without consistency in error handling, it’s difficult to determine whether the framework flaked out or the developer did.

There are tricks upon tricks developers can employ to make non-native frameworks perform closer to native levels. For example, webview frameworks like PhoneGap and RhoMobile suffer from a 300 ms delay whenever the user taps the screen. This delay exists to help a web browser determine the user’s intent — is the user scrolling? pinching? double-tapping? This issue doesn’t exist in native frameworks and as a result, native apps feel more responsive. There’s a popular javascript library which can nearly eliminate this 300ms delay called FastClick. Should all PropertyCross HTML-based frameworks implement FastClick or something similar? I leave it to Colin and his team to decide that based on their goals for PropertyCross.

It would be valuable to the developer community to understand how much extra effort, study and experimentation it takes to get a non-native app to approach native levels of performance. I recognize that new tricks are being explored and exploited every day to improve the end user experience for non-native frameworks, so this is a bit of a tall order. Understanding the ins and outs of any particular framework in order to maximize performance is a full time job. Knowing that coding tricks are needed to make a framework truly perform is valuable.

I would have liked to read about each developer’s experience working with each framework. What were the challenges? How long did it take to figure it out? Did you take advantage of the developer community for that particular framework, and how helpful were they? Obviously this would be subjective and based on each developers’ level of experience. Nonetheless, I’d find it interesting reading.

There are wide variations in the size of each APK (the Android application package file, or basically, the installer). For example, there is a 10x difference in size between the smallest packages (Native and Sencha) and the largest (Titanium and Air). Colin explained that some frameworks require the inclusion of a run-time or virtual machine engine. Users routinely install games on their smartphones that consume tens of megabytes. Regardless, when making an enterprise application, my preference (as I’m sure is everyone’s) is to keep the package size to a minimum so that future upgrades will not consume significant bandwidth and waste users’ time.

In summary, I commend Colin, Sam and the rest for undertaking PropertyCross. It’s a fantastic idea and a valuable resource for everyone out there trying to make sense of the dozens of choices in mobile application frameworks out there. I hope my work has contributed to their goals in a useful way.