Added WP8 libary with podio model classes

[johnmcbride]

Added a WP8 library to the project. Also updated the program.cs file in the convert ruby models to auto create the WP8 model classes based on the ruby model. Last chage was adding a new config item on the app.config.sample for the newly created window phone 8 library.

FYI, this pull request should only have the updates, not like previous where it seemed to have touched the entire solution.

ping me on here or @johnmcbride on twitter :)

[RSpace]

John, again, this is a great contribution, but before I merge it in I really want to try and understand why it is necessary to duplicate all the model classes into the WP8 project. Why is it even necessary with a separate DLL? What dependencies are different in WP8? Can we do something to make the current code compatible with WP8 without having a separate project with duplicated code?

[johnmcbride]

Hey Casper, No Problem, I can try to explain the best i know :). I just wanted to get the pull request in a better shape so it wasn't showing every file as "replaced" :).

Currently, a windows class library cannot be added to a windows phone project. This is due to the fact that the windows phone OS is using a small subset of the .NET framework and to prevent from unknown issues MS put this limitation in the VS toolset when trying to add a regular class library to a WP project.

One way we might be able to use a single library for all projects (including say something like a windows 8 project) would be to create a portalable class library, but I'm not sure if we would then have to abstract things like the http connection calls. Another way might also to use #if blocks to load up separate class files (not really the optimal but workable). I like the portal library as something that would work across many project types but there may be some refactoring that we'll have to do.

I hope this helps. Maybe as an interim step, have the WP8 module and then work toward something more portable? Thoughts?

[RSpace]

Hey John, sorry for being slow on answering here.

I understand the need for a separate WP8 project that references different assemblies. But looking at your commits, you are "only" pushing the new WP8 project containing code-generated models identical to those in the Podio.API project. There is no code actually executing requests to the Podio API in the WP8 project, so it seems to me like the WP8 is not able to do anything?

I'd much prefer that we move the model classes to a separate class library with a minium set of references that also WP8 supports, and then let the WP8 project be about actually talking to the Podio API. What do you think?

[johnmcbride]

Hey Casper, I agree with pulling out the model classes into a separate library for mulitple "clients" to use. Like you said that way the specific client class can implement their own connection mechanism. Maybe even a portal library class or something alike. I did only pull out the model class and put them in the WP8 library mostly because without doing this you cannot use the podio library (even just for the model types) at all on WP8. I figured this would be a a good interim solution where devs could use the WP8 model classes for a WP8 project while this refactoring proceeds :). Plus i was working on a WP8 podio app and needed classes :)

[RSpace]

Hi John, I'm okay with merging in the duplicated classes as a temporary solution. As there is currently no active development on the .NET client from our side, it could be a while before someone splits out the models.

But I'd like to hear the answer to this question I asked earlier: There is no code actually executing requests to the Podio API in the WP8 project, so it seems to me like the WP8 is not able to do anything?