The Gentleman and the Tramp

Hiker’s Log, Stardate -304174.27809487574.  

It’s been a full few months of amazing views and incredible ankle sprains.  I don’t know about you, but I love a good hike. Luckily for us, Christchurch is a hiking trail gold mine!  Christchurch City Council even has a page with all the well-maintained tracks mapped out for your planning pleasure.  A few other sites exist with similar information:

Looking for an epic, “everything” tramp?  Check out the Christchurch 360 Trail. It’s a walk with a lot of variety, but at 135 km, not something you can squeeze into a weekend.  More of a series of hikes over a couple of months.

Why shove on a pair of hiking shoes and struggle up the side of a mountain you may ask?  Well, if the exercise isn’t your cup of tea, surely the views will entice…

Mount Pleasant

Hiking during dusk can be quite the visual buffet.  It’s one of the few times I prefer a cloudy sky over a clear one.  It gives the sun an enormous canvas. If you live in a city with its fair share of smog, this can add a dramatic effect as well…it’s the only benefit of air pollution.

 

Camp Bay

Anywhere on the Banks Peninsula will have amazing views.  The peaks bordering the water will have the best views and usually has the most trails.

 

Camp Bay

If you have a couple of days to spend hiking I can personally recommend staying at Te Pohue Farm Stay Trails.  Plenty of trails and a couple of historic sites to discover in that area. Most notably, Little Port Cooper School House.

 

Harry Ell Walkway

Some of the trails you will have to share with mountain bikers.  Thankfully, the Harry Ell Walkway is adjacent to Christchurch Adventure Park.  This means most of the mountain bikers in the area will be braving the trails you can see in the distance, rather than sharing this trail.

 

Quarry Rim Track

The Quarry Rim track is a great short tramp if you only have 20 minutes or so to get out into the fresh air.  It has a few nicely maintained lookout points as well.

 

Waimakariri Walkway

If you’re wanting some beach time to listen to the waves and stick your feet in the sand, you are in luck.  Most of the Christchurch coastline has trails up and down the seashore.

 

Blue Coastal Track

One of my favourite activities is going for a ride on the immaculate Bottle Lake Forest Park mountain bike trails and ending with a walk along the beach.  Lots of twists and turns and jumps followed by a leisurely stroll to cool down.

 

Godley Head mountain bike trail

Some of the area trails are marked as only mountain bike tracks or only walking tracks.  So, if you want to experience them all you’re going to need a decent bike.

 

Godley Walkway

Being up high and looking down on the water can be a good way to see marine life and underwater geography.  Don’t worry, that is seaweed and not an oil spill in the photo above.

 

Faulkners Track

Don’t forget to slap on some sunscreen before going out into that New Zealand sun!  We have some of the quickest burn times during the summer months and the highest rate of skin cancers in the world.  So, even if you have naturally brown skin, you’re still going to want some sunscreen.

 

Eastenders Track

The lion’s share of trail infrastructure is in good condition and well maintained. However, there are some trails with precarious bits. For example, the stairway to the big cave on Eastenders Track can be particularly tricky.  Feel free to ride the line of your comfort zone, but stay safe!

 

Eastenders Track

A lot of times the risk, however small, is worth the reward.  The Eastenders cave is great if you like having more than just a view as your destination.

 

Frog Pond Track

Hiking has improved my sense of direction in leaps and bounds.  If someone asks me to point them to the nearest track, I no longer need to pull up the maps app on my phone (usually).

 

Rapaki Track

Dogs like a good hike too. Probably more so than their human counterparts. Just look at that face!

 

Frog Pond Track

If you do bring along your furry friend, be sure to take a leash in case you happen upon some friendly (or not so friendly) sheep.

 

Eastenders Track

Discovery is a big part of hiking.  With a bit of off-track exploring on the secondary Eastenders track (right side trail) you can find what looks to be a haven for climbers hidden on the mountain side.

 

Crater Rim Track

Wandering off the Crater Rim Track you can find some great spots to press pause on the exertion.

 

Godley Head Track.

The Godley Head track has a few gems from World War II with expansive views to the ocean.

My original motivation for hiking was the exercise, but it has been an incredible way to get to know the area.  I moved here in April (2018) and already feel at home in Christchurch. Of course, hiking wasn’t the only reason for my feeling of comfort, but it definitely helped.

Now to decide which trail to tackle next!  

Got a favourite walk or hiking track? Let us know in the comments below.

Mobile development made easy

You’ve Come a Long Way, Baby

Technology comes in cycles.

In the early days of smartphones, the best (and perhaps only) choice for mobile applications was native code – writing in the language and using the APIs provided by the phone’s Operating System.  Then HTML5 and WebView looked like the future, but as Facebook found (to their chagrin), it couldn’t exhibit the fluidity and interaction behaviours that we’ve come to love on our phones.

So we wrote native apps again.

Hybrid apps (e.g. React Native) or compile to Native (e.g. Xamarin and Flutter) are currently very popular.  Still, there’s been some push back recently regarding the difficulty in debugging a transpiled language, or one in which code execution is passed between multiple contexts (e.g. AirBNB dropping React Native Support).

If you can afford it, you write native.

In all this time, web technologies have been slowly adding capability and support for the modern, mobile environment on which it is run.  These features are often bundled together and called a Progressive Web Application (PWA).

Wikipedia describes a PWA as:

Progressive Web Apps (PWAs) are web applications that load like regular web pages or websites but can offer the user functionality such as working offline, push notifications, and device hardware access traditionally available only to native mobile applications. PWAs are an emerging technology that combine the open standards of the web offered by modern browsers to provide benefits of a rich mobile experience.

It’s definitely not a panacea for all of your mobile application requirements.  It does provide a well supported, carefully controlled and well established common platform for single development across all devices and form-factors.  Native applications are under no threat for performance heavy applications. However, with a little bit of upfront thinking (and perhaps a little compromise) you can develop cross-platform apps that are easier to write, easier to maintain, easier to deploy and better supported than any of the solutions available.  Not for all types of application, but perhaps a larger subset than is immediately obvious.

Don’t Be Evil

Google gets a lot of flak these days for being just another Evil Big Tech Company.  Not without some justification – Google have a dubious history of illicit data collection, supporting state-sponsored censorship and other moral misdemeanours.  However, it is worth noting that the work they do in pushing web standards forward is unparalleled. With the possible exception of Mozilla, no other company make anything like the same investment – even when it seems like it may be at odds with some of their existing income streams.

Apple has been accused of dragging its feet when implementing PWA technologies.  It would no doubt reduce the number of apps that need to be downloaded and controlled via it’s App Store.  No money will flow into Apple’s coffers if someone downloads a free PWA and makes in-app purchases, cutting off their handsome 30% fee.

Google, with their Play Store, have the same revenue model.  Yet they are driving the PWA standards as hard as they can. Chrome on the desktop and on Android offers the most complete support of the various standards, whereas Apple either have critical gaps or “interesting” implementations that definitely handicap the PWA’s range of functionality.

Despite all of Apple’s reluctant conformance with the latest web standards, progress is being made.  Let’s take a look at what you can now achieve…

What Can We Do With a PWA?

Note: Stated support of the various features is assuming the latest versions of operating systems and browsers at the time of writing.

Offline Support

Offline Support is the key enabling technology for PWAs, provided by a Service Worker.  A Service Worker is able to intercept network requests from your web site (e.g. when fetching an image from the server) and determine how to fulfil them.  If it already has a matching resource it can return that from the local cache and save the long round trip over the internet.

It can do the same thing for API requests, and is able to support different caching strategies. For example, with API requests it is preferable to fetch from the cache only if the application is offline under most circumstances.

Service Worker caching is where we start to see some discrepancies between Google and Apple in their implementations.  The Service Worker specification, and Chrome, support Background Sync – the ability to synchronise any offline data when a connection is available without interaction required from the user.  Microsoft Edge and Firefox are currently in development with this feature. Apple’s Safari browser does not, and looks unlikely to do so in the foreseeable future.

The amount of data we can save for offline usage also varies.  Most browsers support “up to” 2Gb of data per domain – though it depends on the size and free space of the disk.  If you only have an 8Gb disk, you’re only likely to get about 20Mb. With Safari on an iOS device, you’ll never be allowed more than 50Mb.  This is enough for most normal web applications, but woefully short if you are hoping to provide an offline cache of photos, captured videos, or map base-tiles.

Apple’s current policy is to remove unused Service Workers and caches after “a few weeks”.  Maybe this seems reasonable, but it would indicate that the Background Sync, and Push Notifications (see below) are not priorities either.

 

Further reading:

Save To Desktop

PWAs can be saved to the desktop of your device; looking and behaving like a normal, native app.  Using a Web App Manifest file allows you to specify the page that will be loaded when the user clicks on the icon, and how state should be preserved if the user closes and reopens the app.

Apple’s implementation on mobile Safari is closer this time, though still lacking a few features.  It ignores the Manifest’s instructions to open in a specified device orientation, uses a non-standard link for the app icon, does not support splash screens, and a few other minor frustrations.  Perhaps most significantly, application state is lost when re-opening from the icon on the Home Screen. If the user was in the middle of an action, switched to another application and then re-opened the PWA from the icon on the home screen, then they would be returned to the entry page.

On the whole though, not a bad showing from Cupertino on this one, but once again showing they don’t quite care enough about user experience on this technology to smooth the rough edges.

Further reading:

Push Notifications

Push Notifications allow messages to be pushed from the server to client. Due to Service Worker support, this should be possible even when the site is not currently open in the browser.

Unfortunately, support for this is really limited to Firefox and Chrome.  Safari desktop has it’s own entirely custom implementation, but iOS Safari doesn’t even have that.  It’s clear that Apple is in no rush to implement this feature, and their decision to unregister Service Workers after a period of time leads to the conclusion that they don’t see it as a valid strategic direction.

Push Notifications are an ‘icing on the cake’ PWA feature anyway, so their lack of cross vendor support is no fatal blow.  It is, however, annoying and indicative of Apple’s begrudging adoption of these new standards.

Further reading:

Geolocation

The HTML5 Geolocation API allows the web application to determine the user’s location from wi-fi and, if the device supports it, GPS look-up.  As with many of the technologies that fall under the PWA umbrella, the user will be prompted to grant permission the first time a location is required.

Documented support for Geolocation looks strong across all browsers and platforms, with Microsoft Edge being the stand-out exception. Given the low usage of this browser on mobile, this won’t be of any concern to PWA developers.

Further reading:

Sensors (Magnetometer, Accelerometer, Gyroscope)

Access to the phone’s orientation and motion has been available for some time on Chrome and iOS Safari.  Fair enough that it’s not supported on desktop Safari; the use-case of waving your laptop around to pull out some motion data has to be fairly niche.

It’s a complimentary technology.  Reasonably useless on its own, but when combined with other functionality it adds a new dimension onto what is possible.  The existing Device Orientation and Motion API is enough to tell you, for instance, which direction the phone is pointing when a photograph is taken. Coupled with a GPS location, this gives excellent data for use in monitoring scenarios.

The same orientation and motion data could, in theory, be used to support Augmented Reality.  Knowing where you are and what direction the camera is pointing will allow the phone to render items (hazards, information, Pokémon…) in your field of view.  In practice, following on from some research carried out here at Media Suite Towers, the variability of data provided by the sensors makes for very tricky real-time calculations of what to overlay on the image.

There are some cross-browser inconsistencies in this existing API; differing coordinate systems are the big one.  Partly to address that, and also to have a more generic-cross sensor API, Google is proposing a new API. This has hardly any support right now, so we’ll have to wait a little longer for a unified and consistent future of sensor data.

The differing coordinate systems are not a deal breaker, and the existing widely supported APIs are good enough for now to make some interesting applications.  You’d probably have to re-write a chunk of code in a few years, but given the speed of development in this space – both on the web and in native applications – that is pretty likely regardless of what you’d like to achieve.

Further reading:

Camera and Audio

Access to the camera and audio is now possible across the whole range of browsers, and it’s pretty exciting.  Recording a whole video, or capturing a single frame, adding it to an HTML canvas and marking up the image are now all perfectly possible.

Unfortunately Apple step up again here with possibly their worst miss in this gamut of technologies.  Once a PWA is added to the homescreen it stops running in Safari and instead runs inside an iOS WebView.  The WebView technology is older, more integrated with the OS and does not share data (such as a cookies) with Safari.  WebView also does not support the navigator.mediaDevices.getUserMedia API at all.

What this means is, once the user has ‘Added to Homepage’ on an iDevice, they can no longer access their phone’s audio or cameras.  If they only access from Safari, or the app author mandates in the Manifest to open in Safari, then everything works fine. What both of these solutions mean however, is that the user loses that lovely ‘feels like an app’ experience that a PWA should ordinarily be able to provide.

Further reading:

Are PWAs For You?

On Android devices, you can write a PWA that will have very close feature parity with native apps, with exceptions around touch interactions, animation smoothness* and cache size.  Apple is still letting us down however.  While rudimentary caching and functionality is present, the killer features of a PWA only really become apparent when you start to join everything together into a combinatory experience.

Building native, or even hybrid, applications can be frustrating.  Managing each type of device’s quirks is incredibly difficult to entirely abstract away, though this is exactly what browsers have been doing for over 20 years.  Deployment to the Play Store or App Store is an exercise in arbitrarily applied pain – especially for Apple where it seems the terms and conditions around what the app needs to do, or not do, to be successfully submitted to the App Store is a silently moving set of goal posts.

PWAs remove these frustrations entirely – it’s true write-once-deploy-anywhere, the Holy Grail of application development.  Any device, mobile or desktop, can use some or all of the PWA feature-set for far cheaper build and maintenance costs.

While Apple’s casual disregard for web standards continue, it seems that PWAs will not be killing off the App Store just yet.  However, where a quick prototype is needed, or if you can be sure that your users will be primarily using Chrome, then I’d reach for a PWA first every time.

 

  • Native applications get a separate thread to handle animations, and web technologies don’t yet have that option.  As result, animation can be a little janky if happening alongside other thread blocking activities.

 

Private properties in Javascript: how es-next is making life better

Javascript (ecmascript) is an extremely global and dynamic language.  It is possible to overwrite any globally defined variable, and you can easily replace the prototype of any object. For the audience who are working with strongly typed language, it can be surprising to see the patterns we use for hiding internal state. A proposal for supporting private fields on a class has been progressing since July 2017, and it will likely be included in the next version of the language.

To understand the proposal, let’s take a comprehensive look at the patterns for hiding internal state.

_topsecret pattern

The convention in javascript is to use a the “_” as a prefix on the field to denote a private field. The field will remain publicly accessible. We see this pattern used in many frameworks and libraries. Another common variation is to have one special field that contains all the private state. React does this using the aggressively named “__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED” field.

The _topsecret pattern is what you will most commonly see across, the corpus of javascript. Using this pattern today makes sense. It will make your life easy when upgrading to the new private field syntax, and embraces the open and dynamic nature which the language affords.

Using a closure to encapsulate variables

You might see this pattern used in javascript from the 2000’s. The idea is to use function scope to encapsulate the internal state of objects. It provides a high level of privacy for the state. The state can’t be accessed by any function or object outside the scope of the function. However, you might not use this pattern because it does not allow any overriding or sharing of private state between classes of the same type.

Ecmascript 6 classes

In this example, we use the new class syntax, but encapsulate our internal state using the constructor function. This approach smells a bit, as all the methods need to be defined dynamically in the constructor, which heavily resembles the approach we used in our original closure example.

Symbol

A symbol is a special type added in es6. The main purpose of a symbol is as a unique key for objects. To use this technique, we still need to use a closure to ensure that our Symbol instance needs to be hidden in function or module scope. Exposing it would allow people to use that symbol for accessing the private state of the object. This approach smells slightly better, because not all methods need to be attached to the object in the constructor, as in our es6 class example.

Weakmap

The Weakmap class is a way of associating an object with a value. We can leverage this for private state by associating our object instance “this”, with an object of private keys that relate to the instance. The approach here resembles the symbol technique in that not all methods need to be defined within the constructor.

A weakmap is a memory efficient way for storing private objects against an object instance. The Babel transpiler uses them for the implementation of private fields.

The future

Private fields are denoted by the # character as a prefix to the field name. This makes the usage of private variables look a lot like the _topsecret pattern.  Migrating your codebase should be significantly easier thanks to this.

The proposal for class fields will likely be arriving in the next major release of ecmascript. You can use this today with Babel, by enabling this plugin. React devs using create-react-app have this plugin enabled, so you can start experimenting with it in your class and component definitions today.  The online Babel REPL can be used to experiment with the syntax, try it out.

Why was a # sigil used instead of a keyword approach as in Java-like languages? Because javascript is a dynamic language, the metadata associated with a property is much more simplistic. If a “private” keyword was used, the semantics of property access on the “this” object would need to change significantly. The result would be a more complicated and risky code change for ecmascript runtime developers. Furthermore, “this” is already a complicated concept in the language. A sigil based approach allows an obvious differentiation between public and private property access within object methods, which is desirable for code comprehension.

Summing it all up

Programming language, like natural language, must change in order to survive. We see the adoption of es6 classes across many frameworks and libraries in the universe of javascript code. An addition of private field semantics will be beneficial to the frameworks and libraries, and is a natural progression of the syntax. The timing is right, with several years of the es6 class syntax being used.

Our recommendation is to consider using the private class field syntax on client side projects that are using Babel for transpilation.  You could use Babel with Node projects, but our recommendation is to wait for the LTS release which includes the spec.

For more detail on the proposal for class fields, check it out on github.