locked
Shared libraries not accessable from portable libraries.

    Question

  • In my experience of code architecture it's best to divide up the classes as much as possible to facilitate reuse. I'm running into a limitation that unfortunately looks like it will necessitate going regular windows 8 app instead of a universal app. Really a shame since all the u-app hype.

    Here is my situation: (By Projects)

    PRJ.1 = MY_TEST1 (windows 8 app) // Main Windows 8 App

    PRJ.2 = MY_TEST2 (windows phone 8 app) // Main Windows Phone 8 App

    PRJ.3 = MY_CONTROLS (portable library) // XAML based controls for windows 8 or phone 8 projects above...

    PRJ.4 = MY_WIN8_SERVICE_REF (windows 8 class library) This project contains a service reference from internet since windows phone can't.

    PRJ.5 = MY_WINPHONE8_SERVICE_REF (windows phone 8 class library) Will contain some network implementation on phone API.

    PRJ.6 = MY_SHARED (SHARED PROJECT) // Things get interesting here.

    Now how this works is MY_CONTROLS would have some user control in it, that needs to call the client that would exist in MY_SHARED. MY_SHARED in turn crafts a client response base on the calling executable being a windows app or windows phone app using the 'compilation constants' #if WINDOWS_APP & #if WINDOWS_PHONE_APP.

    This would seemingly work fine should it launch MY_TEST1 referencing a control in MY_CONTROLS which in turn calls a class in MY_SHARED which then based on #if WINDOWS_APP would call the service reference in MY_WIN8_SERVICE_REF. But it doesn't. It doesn't because working this way because #if WINDOWS_APP isn't returning true.

    It seems to be the case because it is being called from the library MY_CONTROLS, which is a portable library targeting both APIs. So there it is. In order to effectively use a shared library, it has to be called from a source which is targeted to a specific API. That sucks. this means no shared code for portable libraries. Meaning I would have to develop a distinct user control set for each API, in order to use a shared client. But If I were to go down that road, there would be absolutely no point in crafting a shared client, if the controls that call it can't be portable. I could just build the API specific client in the same project as the API specific controls which reference it.

    That really is not cool, because it means a big wasted of time to try to make it 'universal' if all the user controls need to be difference for each platform. So back to just making a Windows App OR Windows Phone App. Especially when it truly seems like I'm being held back because the compiler is not recognizing something it should (that I'm running from a base of WINDOWS_APP

    Anybody out there have thoughts on this? Is there a way to get a #if to recognize what API it's in even if fired from a portable (but being called from a Windows 8 app)

    Thanks,

    Matt




    • Edited by Ososky Saturday, May 31, 2014 2:16 AM more spelling
    Saturday, May 31, 2014 2:15 AM

Answers

  • Hi Matt,

    Conditional compilation directives only exist at compile time so they can't be used in a Portable Class Library (PCL) which is designed to be portable at runtime. The typical pattern you would use (Inversion of Control: IOC) is to export interfaces from the platform specific code and pass those interfaces into the PCL. The PCL doesn't need to know or care what platform it runs on, it just calls into the interface for the behavior it wants and that will call into the platform specific code.

    The shared library is the same code for both platforms but compiled separately. It isn't shared at runtime, and is essentially a convenience factor. You could approximate the same thing previously with linked files, but the shared library is easier to manage. In your case, MY_SHARED is actually part of MY_TEST1 and MY_TEST2. It's only separated out for convenience.

    The convergence of the Windows Phone and Windows Store API is new and is what allows the portable library to target both platforms. Prior to Windows Phone 8.1 Runtime apps you couldn't use Xaml controls in a portable library since Windows Phone and Windows Store used different sets of controls. Traditional .Net Portable Class Libraries can call only .Net classes and not the native Windows Runtime classes used in Windows Store and Windows Phone Runtime apps.

    If I understand what you're trying to do correctly then you shouldn't have any problems if the two SERVICE_REF libraries expose the same interface to the rest of the app. The MY_CONTROLS library shouldn't need to care which platform it is running on. It should call the same interface either way and the implementer of the interface can handle the interface methods in the platform specific way.

    --Rob

    (I'm assuming across the board here that by "Windows 8" you mean "Windows 8.1" and by "Windows Phone 8" you mean "Windows Phone 8.1 Runtime app")

    • Marked as answer by Ososky Saturday, May 31, 2014 11:25 PM
    Saturday, May 31, 2014 2:54 AM
    Owner

All replies

  • Hi Matt,

    Conditional compilation directives only exist at compile time so they can't be used in a Portable Class Library (PCL) which is designed to be portable at runtime. The typical pattern you would use (Inversion of Control: IOC) is to export interfaces from the platform specific code and pass those interfaces into the PCL. The PCL doesn't need to know or care what platform it runs on, it just calls into the interface for the behavior it wants and that will call into the platform specific code.

    The shared library is the same code for both platforms but compiled separately. It isn't shared at runtime, and is essentially a convenience factor. You could approximate the same thing previously with linked files, but the shared library is easier to manage. In your case, MY_SHARED is actually part of MY_TEST1 and MY_TEST2. It's only separated out for convenience.

    The convergence of the Windows Phone and Windows Store API is new and is what allows the portable library to target both platforms. Prior to Windows Phone 8.1 Runtime apps you couldn't use Xaml controls in a portable library since Windows Phone and Windows Store used different sets of controls. Traditional .Net Portable Class Libraries can call only .Net classes and not the native Windows Runtime classes used in Windows Store and Windows Phone Runtime apps.

    If I understand what you're trying to do correctly then you shouldn't have any problems if the two SERVICE_REF libraries expose the same interface to the rest of the app. The MY_CONTROLS library shouldn't need to care which platform it is running on. It should call the same interface either way and the implementer of the interface can handle the interface methods in the platform specific way.

    --Rob

    (I'm assuming across the board here that by "Windows 8" you mean "Windows 8.1" and by "Windows Phone 8" you mean "Windows Phone 8.1 Runtime app")

    • Marked as answer by Ososky Saturday, May 31, 2014 11:25 PM
    Saturday, May 31, 2014 2:54 AM
    Owner
  • Hi Rob,, thanks for the input here. I will make an attempt using interfaces to accomplish the task. I have not had a lot of tasks involving interfaces although I understand the concept. Probably in the mean time I will cave and just do a windows 8.1 (yes on the point ones) app solo. It's great the XAML classes can be shared between the platforms now. Next step for MSFT is either just combine the platforms or make the service references cross compatible to make my life easier.

    Thanks,

    Matt

    Saturday, May 31, 2014 11:24 PM