My focus for DevCamp was building an Android app that would interact with the presentation web app in realtime. For that we made use of a toolkit called Xamarin, as well as the ASP.NET SignalR library, and Git for source control.
Xamarin
Xamarin is a toolkit that allows you to use C# to write code for native Android and iOS apps. I had a good experience with this overall. I hit a small bug where changing the namespace caused a crash, but found an issue already raised for this on the Xamarin issue tracker. Other than that I found using it to be very easy.
Writing the code in C# required no knowledge of Java, though you do still need to know about the UI interfaces for the various devices. However, learning these would be much less work than learning the entire library system and back-ends.
We used Portable Class Libraries to allow us to write code that targeted both the ASP.NET MVC project and the Xamarin Android project. This worked perfectly, and meant we could share class structure changes and business logic without needing to recode anything. This demonstrated one of the major potential gains of using this kind of system.
The second major gain is that while the UI development needs some experience with each of the platforms, the back end can be written by existing C# developers without them having to learn additional skills. This could be a major saving even if only developing for a single platform.
I didn’t get to try adding an iOS front end to the application as this requires a Mac build server and an annual development fee to Apple (submitting to the Windows Store also requires an annual development fee). This isn’t a major drawback since these would be required for native development without the use of Xamarin, but it would be nice if the requirement for a Mac could be removed.
I’d like to try this at some point in the future to explore how well the multi-platform development works.
The only caveat I have is that the Xamarin license cost is high (around $999 per developer per platform per year). This would likely be recoverable for a medium sized project in the saved developer hours, but could cause support issues if we were not doing enough work in the area to keep at least one subscription running all the time.
Conclusion: Recommended
Notes on Android Development
Android VMs are very slow and getting a physical device ready for debugging can be a bit of a trial, needing various device drivers and options changing. Once it is set up it tends to run smoothly though.
Writing the activities for an Android UI requires some learning and does not translate directly from Windows/web UI design.
SignalR
SignalR is a real-time communication library for .Net applications. I found it easy to use, and the portable build worked fine on Android (with Xamarin) with little additional effort.
Writing the SignalR calls was straight forward. However, as with any multi-client system, serious consideration about the communication messages being transferred is required. We initially created a system where messages could end up triggering other messages that cascaded into a loop. Careful design would be able to eliminate these occasions, but they’re easy to miss.
Conclusion: Recommended
Git
We decided to use Git for our source control during DevCamp, it’s a distributed system, which means working with local repositories and pushing to / pulling from others. We use SVN in our usual day-to-day work and are pretty happy with it for the most part, but we were interested in trialling what’s becoming the go-to system for many developers our there.
GitHub
GitHub is the most popular hosted solution for Git projects and seems a decent repository for code. If I wanted a shared repository I’d have no issue using this. It allows access via SVN as well (though I didn’t try this), so this would allow continued use of SVN if required. Recommended.
Git GUIs
Visual Studio Tools for Git – I had a few issues with this. I didn’t find that it worked well compared to other versions, and had major issues with authentication. I didn’t find it added much over the other Git access methods. Not recommended.
TortoiseGit – This was a great interface to Git, though this may just be because I’m already familiar with TortoiseSVN. Recommended if you like TortoiseSVN.
Overall
I’m unsure about this. I like the local commits and branches, but I had a number of cases where local changes I made didn’t seem to get merged into the shared trunk, so that while I could see the changes in my local stream when the merge occurred they were ignored. This may be down to misunderstandings on my part, but I didn’t feel that this made the system reliable enough for production use.
Conclusion: Uncertain – further investigation needed