Game development is what got many developers into programming. But how many of us actually ever learned how to create games? Creating games can be challenging, but it doesn’t have to be that way! MonoGame is a cross-platform gaming framework based on Microsoft’s XNA framework that’s extremely easy to learn …

One of the biggest challenges in Cross Platform Mobile App Development is implementing a mechanism of performing simple tasks on each diverse platform, such as reading a config file on app launch, when you know that each platform will store this file in a different location, have a preference for different file formats, and have different permission mechanisms for reading and writing. This plugin helps nail most of those issues.

Most mobile applications need to interact with the underlying file system. Be it building a database or caching data, some understanding of how file systems work on target platforms is required. If you’re working with multiple platforms, not only does this require understanding of how each individual file system works, but also how to work with the file system from shared code.

The File System Plugin for Xamarin and Windows reduces the underlying file system complexities for each platform into a cross-platform file IO API for iOS, Android, and Windows, making it extremely easy to work with the file system from shared code. In this blog post, you will learn how to use the File System Plugin for Xamarin and Windows to create, edit, and delete files and directories from shared code.

Introduction to the File System Plugin for Xamarin and Windows

Similar to desktop operating systems, mobile operating systems each have their own file system. Building applications that target multiple operating system requires knowledge of not just one file system, but the underlying file system for each platform. Another barrier when working with file systems is the inability to use code that talks to individual file systems in shared code. A common solution to this problem is to use preprocessor directives (#ifdefs) to access platform-specific features, but this won’t work with PCLs and results in messier code.

Exploring the APIs

The IFileSystem interface represents an abstracted file system at the highest level. The platform-specific implementation can be accessed via the FileSystem.Current property. The file system is made up of a collection of folders and individual files, which are abstracted via the IFolder and IFile interfaces. When creating folders and files, we are also given maximum control over collision detection preferences with theCreationCollisionOption enumeration, which allows us do everything from create an alternative name, replace the existing directory/file, open the existing directory/file, or throw an exception. Of course, all of these APIs are also async/await compatible as well.

Where we don't have to build out some sort of bespoke mobile app sync, this is pretty much the standard way for us to sync files between cross platform and multi platform apps

In a mobile world, network outages are frequent. Devices are constantly moving and connectivity can vary from great to barely connected to offline, with users expecting your app to continue to function properly. For example, field technicians need the ability to log notes in their field service app, no matter the connection state. Apps can support offline usage by …

Been listening to this on the way in to work, am not sure it's right for the office, can't decide on which punishments ;-)

Scott sits down with software developer and development manager Louise Elliott about her ideas around "Punishment Driven Development." Why is this such a common way to run a project? Does it work and is it ever appropriate?

A few months later, we added a UI shell for this on Linux and used Gtk's text widget to add support for embedding rich content into the responses. It was able to render images inline with the responses:

and it seems like they are both inspired to some extent by Mathematica's interactive window.

Re-interact in particular introduced a brilliant idea, which was that users could go back in history, edit the previous expressions and the entire buffer would be re-evaluated. This idea lives on in Apple's Playgrounds for Swift.

In the meantime, the IPython project grew and they added one of my favorite features: it was now possible to blend text, explanations and code into workbooks. You can see a sample of this here. For years, I have desired an IPython for C#.

The Xamarin Years

In the meantime, at Xamarin, we experimented with the idea of bringing sometehing like Re-interact/Playgrounds to Xamarin Studio and we shippedSketches:

But while these were interesting for trying out ideas and learning C#, they are not very useful for day to day work. We found that what our developers needed was a full C# REPL that was connected to the application they were running on, so they could experiment with their UI live. This is when we introduced Xamarin's Inspector. We took the existing engine and changed the way you interacted with C#.

The inspector was originally planned as a debugging aid, one that you could use to attach to a live Android/iOS/WPF process and use to examine:

While Sketches used the IDE editing surface and a custom renderer view for results, with the Inspector we took a different route. Our interactive surface was an HTML canvas, and our results are rendered using HTML. This allowed us to do some pretty visualizations for results.

We have only started to explore what is possible in this space, and our last release included various data renderers. In particular, we added support for pretty printing collections and a handful of native Android and iOS results.

Up until now, we had been powered by Mono's C# compiler and while it has served us well for many years, it pales in comparison with the services that we could get out of Microsoft's Roslyn. Our code completion and error reporting were limited and the model did not translate too well to F#.

With this release, we ended up with an Inspector that can now be used either to debug/analyze a running app (very much like a web inspector), or one that can be used to experiment with APIs in the same spirit as other shells.

Continuous

In the meantime, Frank Krueger took the iOS support that we introduced for the compiler as a service, and wrote Continuous, a plug-in for Xamarin Studio and Visual Studio that allowed developers to live-code. That is, instead of using this as a separate tool, you can modify your classes and methods live and have your application update as you change the code:

Frank also added support for evaluating values immediately, and showing some values in comments, similar in spirit to his

The Glorious Future

But now that we have a powerful HTML rendering engine to display our results and we upgraded our compiler engine, we are ready to take our next steps.

One step will be to add more visualizers and rendering capabilties to our results in our Inspector.

The second step is to upgrade Sketches based on this work. We will be changing the Sketches UI to be closer to IPython, that is, the ability of creating workbooks that contain both rich HTML text along with live code.

To give you a taste of what is coming up on our next release, check out this screenshot: