.NET APIs for Metro style apps

239 views
Skip to first unread message

David Churchland

unread,
Oct 28, 2012, 11:15:05 PM10/28/12
to servic...@googlegroups.com
I am part way through a rough port of ServiceStack to work with .NET APIs for Metro style apps.

Firstly, has there already been some effort put towards this that I have missed?

Secondly, I have never contributed to a GitHub project before.  What is the best way to approach it?  I imagine I will want some review/discussion before merging anything.  Do I do a Fork and then speak to one of the core team re merging?

thanks,


David


Demis Bellot

unread,
Oct 29, 2012, 12:57:39 AM10/29/12
to servic...@googlegroups.com
Hi David,

I'm not aware of any current effort to add support for Metro. There was some mention of someone attempting it a long time ago, but I've never heard back from them so I don't expect that effort still exists.

For contributing to GitHub, you basically just want to fork the repository you want to work on. 
Add your changes on your own fork, and then when the changes have been tested and are ready for merging, just issue a pull-request:

GitHub provides a good guide on how to do this here:

Basically if you want to do any disruptive changes or are unsure whether a feature should be added to the main project, you should consult this list. Most new features should ideally be added via plugins.

If you want to add support for a different platform, then we just use #define build symbols, there's plenty of examples in the ServiceStack.Text and ServiceStack.Common code-bases. Basically each new platform should take a copy of the project file in its own directory, and the VS.NET project should include the build symbol for your platform, see the different platforms in ServiceStack.Text as an example:

Only the client libraries (e.g. ServiceStack.Text + ServiceStack.Common) are needed in order to call ServiceStack services.

Thanks,

David Churchland

unread,
Oct 29, 2012, 1:14:37 AM10/29/12
to servic...@googlegroups.com
I have followed just the approach you suggest, using Monotouch etc as a guide.

Unfortunately I don't think much can be done using plugins as the .Net Reflection classes have changed, for example there are many places where Type.GetTypeInfo() is required, for example type.GetTypeInfo().IsEnum rather than type.IsEnum.

I will play with it and dro pyou a note if I need clarification on anything in particular.

Mikkel Fishman

unread,
Nov 5, 2012, 4:00:32 PM11/5/12
to servic...@googlegroups.com
Perhaps I'm dense, but what is the use scenario for having support for metro? I'm planning on making a metro app soon so may be able to contribute.

David Churchland

unread,
Nov 13, 2012, 5:27:06 PM11/13/12
to servic...@googlegroups.com
Sorry, I did not notice this reply.

The use scenario for Metro (or more accurately Windows Store App) is so that I can consume a service stack service using the servicestack client from a Windows Store App.  The Windows Store .Net framework is a much reduced version of the .Net 4.5 framework.

Am I being dense?  I assumed this would be just as obvious a use case as MonoTouch?  Is there some reason I have missed that there seems to be relatively little interest in this?

Demis Bellot

unread,
Nov 13, 2012, 6:10:24 PM11/13/12
to servic...@googlegroups.com
Most of the support for the different platforms have been contributed to by the community of different platforms wanting to see support for it.
So far there have been little interest to add support Windows 8, I think @gshackles is having a go at supporting it, although I'm not sure how far he's got.

Mikkel Fishman

unread,
Nov 13, 2012, 7:19:03 PM11/13/12
to servic...@googlegroups.com
Ah now it makes sense, for some reason I had it in my head that you wanted to have a service on Metro, not a client. Feel free to contact me and we'll chat -- I have a pretty in depth understanding of both the .NET framework and dynamic generation, but haven't looked at the clients much, so hopefully we can figure out an attack plan pretty quickly.

Shawn Hinsey

unread,
Nov 13, 2012, 7:19:24 PM11/13/12
to servic...@googlegroups.com
The terminology is so confusing here. What sort of Windows Store App are you talking about? My company has a WSA/HTML5 app that uses a servicestack API and it required nothing special. I expect you're talking about XAML/C#?

David Churchland

unread,
Nov 13, 2012, 7:32:06 PM11/13/12
to servic...@googlegroups.com
As is often the way my attention had been diverted by other priorities   Shawn's post has caused me to re-consider what I am doing.  I assume that the WSA approach will mean that networking and serialization etc. will be handled by the web stack.

This may well be our preferred approach, I have not experimented with web stack support in Win 8 yet.  In my wildest dreams we might be able to share some of our code between a web stack app and a pure web app.

More thought and experimentation required from me.

thanks guys.

Mikkel Fishman

unread,
Nov 13, 2012, 7:36:17 PM11/13/12
to servic...@googlegroups.com
Yeah I agree, the HTML5 apps need nothing special. That said, my particular app is going to target XAML initially due to performance concerns about rich JS/HTML5 apps so I'll probably be looking into making a client at some point. After looking at the .NET framework for the store apps it shouldn't be too bad of a port at all.

Shawn Hinsey

unread,
Nov 13, 2012, 7:46:44 PM11/13/12
to servic...@googlegroups.com
Ours was a port from an existing mobile web app and we were basically able to reuse everything. There is definitely a learning curve due to the uncanny valley not-quite-the-HTML-you're-used-to nature of it, but I was able to reuse core API level JS code without modification.
Reply all
Reply to author
Forward
0 new messages