A progress report from the world of Xamarin
I've been neck-deep in Xamarin for a little over a week now. After many ups and downs I'm happy to say that — at least for the moment — it seems I'm on the right track.
Currently my goal is extending Tenterhook to Android devices, but I'm laying the groundwork for potential iOS support down the road. This involves quite a bit of planning to avoid messy and redundant code and Xamarin will help me get there. I can put shared code in a .NET Standard library while projects targeting Android and iOS focus on UI-specific implementations.
The conceptual architecture (all subject to change):
After an app is created in Tenterhook Studio, preparing it for Android would be a fairly straightforward process in Visual Studio:
- Generate an Android App (Xamarin) project from a template (perhaps automated by Yeoman?).
- Copy the app's manifest.json and assets (image/audio files) into subfolders under Assets.
- Change the app name and icons.
- Package and ship it!
The UI and shared logic would be handled by Tenterhook.Droid.Core.dll and Tenterhook.Core.dll, no custom code would be required if all goes according to plan.
Some initial thoughts on Xamarin
As of June 11 I'm very optimistic about where things are headed, but there was definitely pain in the early stages. Some random thoughts from the first week:
- Xamarin University has a few decent (and free with sign-in) self-guided courses that helped me ramp up on general Xamarin and Android concepts. Examples: Getting Started with Xamarin, Introduction to Xamarin.Android, and Activities and Intents.
- Setting up emulators is a colossal pain given all the Android SDK and Hyper-V requirements. This was compounded by confusing and outdated documentation, so I set aside emulation and opted to deploy/debug via my Android phone directly. However, I'm pleased to report those docs were updated in the last few days. I'll give emulation another shot.
- The Xamarin Layout Designer is horrendous. Even if you manage to dismiss the random errors, sluggish rendering, and overly aggressive caching, you'll run into cases where the Design and Source tabs inexplicably get out of sync. To "correct" this I've bounced Visual Studio countless times, and on Day 2 I legitimately considered ditching my cross-platform goals for Android Studio instead.
- The build/deploy experience is often slow and buggy. I'll often get a "Build failed" message with no further detail, only to build again with success. Every minor tweak repeats this cycle and results in lots of wasted time.
- Despite all of the above, when the stuff I've learned shows up on my phone it's very exciting. I'm glad I perservered through Xamarin's obvious flaws; the momentum is now building and my goals seem achievable.
The next phase of Tenterhook
Behold, the next phase is nigh!
In 2015 I started planning a platform for creating point-and-click adventures. Even in the early stages I knew it'd need to:
- Enable the creation of apps/adventures using only a browser, and
- Provide a way to extend those apps to other platforms/devices.
To convey it with a simple visual:
The second phase is ambitious and I'm about to dive into the world of Xamarin. I'm targeting Android for starters, and if all goes well I'll explore the feasibility of iOS.
How would it all work?
I haven't sorted it all out yet, but this is a general outline of how I see it unfolding:
- Create an app at tenterhook.net. (already available)
- Create a new project in Visual Studio [Code].
- Install a package with Tenterhook core functionality/dependencies. A Yeoman-generated project might also be a possibility.
- Copy the audio/visual assets into a specific project folder, tweak the app/author metadata, and ship it.
Extending apps from the web to Android should be friction-free and require no custom code/assets. It should all "just work."
When is this happening?
I'll post (brutally honest) updates along the way, but my tentative target for Android support is September 2018.
Sample adventure: The Path to Paradise
The Tenterhook platform is maturing to the point where it can produce adventures that are reasonably stable. There are still some bugs and features that must be addressed before I'm comfortable calling it a Beta, but we're getting close!
The Path to Paradise (screenshot below) is a sample mini-adventure built using Tenterhook. It was partially an exercise to help me test the platform, but who knows, some might enjoy the adventure on its own merits.
An adventure in development with Angular 2
Tenterhook development started in October 2015. It was an ambitious foray into Google's AngularJS (Angular 1.x), a completely different world from the Knockout and jQuery I was used to. I struggled with the same questions every other Angular newbie has: do I put my code in controllers, directives, or services? How should directives communicate with each other? Why am I having so much trouble wrapping my mind around $scope?
In May 2016, Angular 2 was gaining traction in beta. It was a dramatic departure from its predecessor and I wasn't thrilled at the prospect of converting everything yet again. Working with pre-release anything is essentially a guarantee of churn and false starts.
Long story short: I'm incredibly thankful that went all-in with Angular 2. Sure, there's a learning curve, but the combination of TypeScript and Angular 2 magic is powerful to say the least. The structure of the code is so clean and well-organized, infinitely more intuitive than wrestling with $scope in Angular 1.
An example of how Tenterhook reaped the benefits of Angular 2
Your typical Angular 2 application consists of many components which belong to a module. When I started building Tenterhook I realized I needed two distinct modules:
- A core module with all the components needed to play an app, e.g. the dashboard, viewport, scenes, characters, and so on.
- A studio module with all the components needed to define the app's manifest.
When you're building an app in Tenterhook Studio, both modules are in use. This allows you to preview your app as you build it.
When the app is finally ready to play, the studio module peels away and only the core module is needed:
This separation of core/studio modules was certainly possible in Angular 1 but it was much easier to achieve in Angular 2. As a result, I'm happy to say there's no "spaghetti code" in Tenterhook despite its many moving parts.