Coffeehouse Thread

13 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

8.1 WinRT Api across platforms

Back to Forum: Coffeehouse
  • User profile image
    dvr123

    Hey All,

    Im getting questions around creating apps, especially with the new winrt 8.1 api's e.g. point of service etc to run on surface rt. Im looking at c# and xaml (coming from a web background with server side and back in the day vc++ doc/view). Small business customers are looking at the surface RT because of its price point compared to pro but Im hesitant that it will not run point of service and give me enough app capabilities when compared to a windows 'store' app running on surface pro. Im still trying to get my heard around 'store' in the context e.g. can a 'rt' app be deployed to surface RT without going through the store, my assumption is yes or more likely on the surface pro - could someone also clear this up for me?

    Later on in the app development process I would like to get a broad reach across surface rt, surface pro, and possibly windows 8/phone 8 using the sharing patterns described elsewhere, but initially I don't want to go down the html route due to a richer ui feature set under c# xaml as far as I can make out at the moment.

    I guess what Im trying to say is that will a windows store app that uses the 8.1 apis and runs on surface pro be able to run the same api's on surface RT? will a store app run the same on surface running rt or surface pro? I guess the api list in question is here http://msdn.microsoft.com/en-us/library/windows/apps/br211377.aspx

    the demo at build 2013 with the credit card scanner was on a surface pro I assume... thanks Dean

  • User profile image
    PeterF

    Windows 8 x86/x64/Arm all share the same WinRT API. To deploy to both Windows 8 and Windows Phone 7/8, you should look into Portable Class Libraries (PCL) to pull that off. In essence you program as much as possible in the PCL in the commonly shared API's and for all the platform specific stuff like downloading, files/storage etc. you define abstract inside the PCL which are implemented and injected in each platform. XAML/UI cannot be shared but large parts can be re-used with minimal changes.

    Enterprise deployment is a completely different chapter and can be read here: http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206943(v=vs.105).aspx

    Good luck,
    Peter

  • User profile image
    dvr123

    thanks Peter,

    I looked at some PCL stuff here 

    http://channel9.msdn.com/Series/Building-Apps-for-Windows-Phone-8-Jump-Start/Building-Apps-for-Windows-Phone-8-Jump-Start-19-Windows-Phone-8-and-Windows-8-Cross-Platform-Develop

    and from uk msdn Mike Taulty had some good info on this as well...

    http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2013/06/19/windows-8-and-prism-migrating-a-simple-example.aspx

    So am I right in thinking that the surface simulator in VS2012/13 runs your app regardless of CPU architecture or do you target each with varying functionality - from your post Im taking it as anything that runs winrt on surface pro(x86/64) will run the same on surface rt(arm)?

     

    thanks!

  • User profile image
    PeterF

    The 'Surface Simulator' in VS is your actual computer through an RDP session, and if you submit your app to the store, the package will contain both the x86 and ARM compilations of your app. If you want to debug the ARM version, you'll have to use remote debugging to a Windows RT device. (since you do want to test on ARM to check the performance!)

    It *should* run on both as long as any of your dependent external DLL libraries also have RT versions... if you have full source code then it's not an issue, but re-compiling common libraries will not give your apps the advantage of possibly smaller downloads due to the new shared library detection stuff added to the store, avoiding re-downloading of common DLL's within your app.

  • User profile image
    Jim Young

    @dvr123:One thing to keep in mind when considering something like a POS application on WinRT - If the application requires specialized devices like card readers or scanners you may run into a brick wall in regards to device support with WinRT.

  • User profile image
    kettch

    @Jim Young: In one of the sessions on Wednesday, they demo'd a POS application using a card reader that they "just bought on Amazon" implying that as long as it's USB, then it should work fine.

  • User profile image
    Jim Young

    @kettch:Yeah, I was just looking over the 8.1 documentation and the support for POS devices - It looks more hopeful. I've worked on a POS application before and one of the problems is that a customer may have a particular device that is mission critical for their operation that may not be supported or even USB. There's still a ton of RS232 devices out there in use.

  • User profile image
    davewill

    , Jim Young wrote

    *snip

    There's still a ton of RS232 devices out there in use.

    Absolutely. We still have folks who have devices that can talk either RS232 or USB and the general recommendation given out still steers them to choose RS232 because they avoid any hassles with the USB drivers and/or middleware like WMDC (windows mobile device center).

  • User profile image
    dvr123

    @jim et al

     

    thanks all is very useful, Im looking at a POS system, and pre 8.1 (or build 2013 Smiley ) I was very concerned about using a windows surface device as we're looking at card reader, and interactions with a cash register (though usb) - I was thinking that this would only be possible on a surface running pro and not 'store' sandboxed apps... but it looks like with 8.1 it a go on the surface RT

    other things to look at are storing and retrying processes if internet connection is lost etc.. so again there will be some questions around serializing a state of the app or possibly running an in memory 'lite' db (hey dictionary maybe) that can resume state even after a power down etc.

    If a customer already has the surface pro or pro desktop then the app should run fine on this...

    Jim what platform was your POS system? Is silverlight the xaml engine on windows phone 8 and is the xaml engine for windows store apps something else?

  • User profile image
    figuerres

    , davewill wrote

    *snip*

    Absolutely. We still have folks who have devices that can talk either RS232 or USB and the general recommendation given out still steers them to choose RS232 because they avoid any hassles with the USB drivers and/or middleware like WMDC (windows mobile device center).

    what about newer pc's that do not have any rs-232 ports and may not have expansion slots to add them with due to small form factor cases / all in one ?

    also there are Ethernet pos devices out there now.... wonder if the new api can talk to them ?

  • User profile image
    Jim Young

    , dvr123 wrote

    Jim what platform was your POS system? Is silverlight the xaml engine on windows phone 8 and is the xaml engine for windows store apps something else?

    It was ages ago on VB.Net. We had to use RS232 based devices, which was a pain because even back then RS232 was being phased out of the systems being purchased. Silverlight would not be my choice for writing a WP8 POS program - I'd go with native C++. Silverlight is nice for a lot of things but communicating directly devices is not one of it's strong points.

  • User profile image
    davewill

    , figuerres wrote

    *snip*

    what about newer pc's that do not have any rs-232 ports and may not have expansion slots to add them with due to small form factor cases / all in one ?

    *snip*

    USBG-232 is rock solid.  http://www.usbgear.com/USBG-232.html

  • User profile image
    kettch

    @davewill: ZOMG! Don't go to that page with your sound up!

    I'll check that out. I'm always looking for a good converter for interfacing with audio equipment.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.