My First UWP Application
So, over the past few weeks I completed a task that technically began months ago while tackling a completely different problem and completed my first UWP Application. Figured I would write some thoughts on the experience.
The piece that started months ago was a server side OData service on top of my existing NHibernate DAL for my wife's store front application. And the piece which started weeks ago was the actual Universal app client. It didn't take me weeks to write. Especially not the actual client app. The UI work was a few hours in the making, and while it isn't "done" it is functional.
The OData service and the client for that took the longest. The client is a UWP DLL, and that was a large part of the reason the OData side took so long.
The service itself also took some time. I'm using Fluent NHibernate and not EF, so I didn't get a nice project scaffolded and generated for me out of the box. I also wanted to make as much code as possible re-usable, so it was refactored several times. The current implementation is "acceptable" for me. All of the controllers are basically empty extensions of an abstract class. So aside from any entity specific code, everything is literally in one place except the class definitions. The class building the OData service could probably be more generalized, but that isn't huge. This piece doesn't have anything to do with UWP, but wanted to paint a bit of background, because the timelines above sound pretty bad.
Also on the speed front would be that with the toddler running around, work and other interests I was only spending a few hours of a few nights each week, and thanks to the first points below, some of that was spent learning and understanding things I had always taken for granted.
So, onto UWP code. The thing that took the longest is rather disappointing. It was, as stated already, a client for the OData service. Add Service Reference wasn't working (may be fixed by now) and there were no generic classes for automating serializing to, or deserializing from JSON. I COULD have finished this piece in a fraction of the time. What I did instead was used reflection and built a largely generic set of libraries for this. My brother also runs one of my apps in his shop, so I will likely be able to make use of that code with minor modifications again. It also means no tweaks in that layer are needed, should I ever rewrite or add entities. I will be the first to admit though... the real reason was, I just wanted to tackle it that way.
It does highlight an issue for existing .Net developers. The language isn't as mature and complete as "big" .Net. There are a lot of things you would have taken for granted in the past that aren't here. Not just 3rd party stuff, but also core .Net features. I didn't go scouring for 3rd party solutions in NuGet or online, so I may have reinvented the wheel. But I wouldn't have needed to look outside of .Net for JSON serialization in the past.
The other part of that, is of course, the OData client itself. In the past I would have gotten both a client and serialization "for free" by adding a service reference. I had started this prior to GA for Windows 10, so it is possible this has been fixed, but building a nice, structured, general use OData client is also a bit of a pain in the butt. Again, I was intrigued to see if I could build one to suit my needs, so I'm not complaining. But, if you are a .Net developer looking into UWP, I think it is important to illustrate the sorts of things you'll need to double check before committing.
Once I had the serialization and client done and a test library that proved that everything I built would work it was onto the UI.
Having built a few Windows 8/8.1 apps before (even dabbled in some WP apps) and WPF apps before that, this piece was easily the quickest and easiest. I was just building a companion app for my wife's real application, and really just mocking something simple up to start. I hadn't worked with Windows 8 apps for a while though and the set of controls is different from WPF, but it was all XAML and C#, and in that respect it was very familiar. If you have Windows 8 App Store dev experience, UWP should be mostly painless. In addition to the obvious paradigm changes and completely removed namespaces and class, there are some instances, like GridView where the same control exists in both, but isn't actually the same any more.
After a few hours I had a working prototype and after a few days of tweaking I had something I was happy enough with for a proof of concept. The next step was getting it off of my dev machine and onto the one it would actually be running on.
Honestly, this wasn't difficult, but it was also not an obvious process unless you had sideloaded in Windows 8.
For those interested, you don't need a dev license. Instead you turn on developer mode. Beyond that however it is the same, use the power shell script generated when you built the package and let it install the dev cert and deploy the app. Might be another way. It is really hard at the moment to find documentation on this at the moment though. Ideally Windows 10 would have not just a UI for enabling Sideloading and Developer mode, but also one for actually consuming the appx files. Beyond that a reliable way to network deploy to a non-domain joined device on the same network.
Aside from a small miss on the fact that I needed to enable private internet access to the app, it just worked. Exactly as expected. While the power shell approach is annoying... it is easy enough. Especially for a small scale LoB app I have no need or want to post in the store.
But here is the big one. I had noticed that one of the possible debug environments for my apps in VS was a Windows 10 mobile emulator. So, I decided to try and deploy this thing on my phone which is part of the Insider program and on the mobile build. Took a bit of time to find out how to push it to the phone, but once I found it and tried... it also just worked. No need for any extra UI or any other projects, just deployed the ARM version instead of the x86 which my 32 tablet used (and my dev laptop is 64 bit, so I tried all permutations). THAT was exciting.
I wasn't using any of the responsive layout stuff and I hadn't written it with a phone in mind originally, so it looked TERRIBLE. But even it JUST worked. I simplified the UI a bit to look better on a phone... and now my wife is super psyched. Both her and her sister have Windows Phone devices, so once they go to Win10, they'll both be able to use this app to manage their work.
But yes, literally, not a single code change to get it to run on the phone. I will say it, at this point it really does feel like UWP is living up to the hype. Sure, in many cases I would either want separate UI's for different device categories or, at the least, some responsive layout if screen size is the only important factor. But it did run on 3 different device types (laptop, tablet and phone) spanning 2 operating systems (Windows 10 and Windows 10 mobile) and 3 architectures (ARM, x64 and x86) and all without any code changes to make it support any of those permutations.
It is also promising to know that I may be able to get this running on the Xbox One soon as well or even HoloLens without changing anything unless I wanted too.
And there you have it. The language is not all there yet. And I don't think I would easily find community projects for gaps either. I hope it does though, because once you get past those, it truly was magical to see something thrown together so quickly run so easily in so many places.
The piece that started months ago was a server side OData service on top of my existing NHibernate DAL for my wife's store front application. And the piece which started weeks ago was the actual Universal app client. It didn't take me weeks to write. Especially not the actual client app. The UI work was a few hours in the making, and while it isn't "done" it is functional.
The OData service and the client for that took the longest. The client is a UWP DLL, and that was a large part of the reason the OData side took so long.
The service itself also took some time. I'm using Fluent NHibernate and not EF, so I didn't get a nice project scaffolded and generated for me out of the box. I also wanted to make as much code as possible re-usable, so it was refactored several times. The current implementation is "acceptable" for me. All of the controllers are basically empty extensions of an abstract class. So aside from any entity specific code, everything is literally in one place except the class definitions. The class building the OData service could probably be more generalized, but that isn't huge. This piece doesn't have anything to do with UWP, but wanted to paint a bit of background, because the timelines above sound pretty bad.
Also on the speed front would be that with the toddler running around, work and other interests I was only spending a few hours of a few nights each week, and thanks to the first points below, some of that was spent learning and understanding things I had always taken for granted.
So, onto UWP code. The thing that took the longest is rather disappointing. It was, as stated already, a client for the OData service. Add Service Reference wasn't working (may be fixed by now) and there were no generic classes for automating serializing to, or deserializing from JSON. I COULD have finished this piece in a fraction of the time. What I did instead was used reflection and built a largely generic set of libraries for this. My brother also runs one of my apps in his shop, so I will likely be able to make use of that code with minor modifications again. It also means no tweaks in that layer are needed, should I ever rewrite or add entities. I will be the first to admit though... the real reason was, I just wanted to tackle it that way.
It does highlight an issue for existing .Net developers. The language isn't as mature and complete as "big" .Net. There are a lot of things you would have taken for granted in the past that aren't here. Not just 3rd party stuff, but also core .Net features. I didn't go scouring for 3rd party solutions in NuGet or online, so I may have reinvented the wheel. But I wouldn't have needed to look outside of .Net for JSON serialization in the past.
The other part of that, is of course, the OData client itself. In the past I would have gotten both a client and serialization "for free" by adding a service reference. I had started this prior to GA for Windows 10, so it is possible this has been fixed, but building a nice, structured, general use OData client is also a bit of a pain in the butt. Again, I was intrigued to see if I could build one to suit my needs, so I'm not complaining. But, if you are a .Net developer looking into UWP, I think it is important to illustrate the sorts of things you'll need to double check before committing.
Once I had the serialization and client done and a test library that proved that everything I built would work it was onto the UI.
Having built a few Windows 8/8.1 apps before (even dabbled in some WP apps) and WPF apps before that, this piece was easily the quickest and easiest. I was just building a companion app for my wife's real application, and really just mocking something simple up to start. I hadn't worked with Windows 8 apps for a while though and the set of controls is different from WPF, but it was all XAML and C#, and in that respect it was very familiar. If you have Windows 8 App Store dev experience, UWP should be mostly painless. In addition to the obvious paradigm changes and completely removed namespaces and class, there are some instances, like GridView where the same control exists in both, but isn't actually the same any more.
After a few hours I had a working prototype and after a few days of tweaking I had something I was happy enough with for a proof of concept. The next step was getting it off of my dev machine and onto the one it would actually be running on.
Honestly, this wasn't difficult, but it was also not an obvious process unless you had sideloaded in Windows 8.
For those interested, you don't need a dev license. Instead you turn on developer mode. Beyond that however it is the same, use the power shell script generated when you built the package and let it install the dev cert and deploy the app. Might be another way. It is really hard at the moment to find documentation on this at the moment though. Ideally Windows 10 would have not just a UI for enabling Sideloading and Developer mode, but also one for actually consuming the appx files. Beyond that a reliable way to network deploy to a non-domain joined device on the same network.
Aside from a small miss on the fact that I needed to enable private internet access to the app, it just worked. Exactly as expected. While the power shell approach is annoying... it is easy enough. Especially for a small scale LoB app I have no need or want to post in the store.
But here is the big one. I had noticed that one of the possible debug environments for my apps in VS was a Windows 10 mobile emulator. So, I decided to try and deploy this thing on my phone which is part of the Insider program and on the mobile build. Took a bit of time to find out how to push it to the phone, but once I found it and tried... it also just worked. No need for any extra UI or any other projects, just deployed the ARM version instead of the x86 which my 32 tablet used (and my dev laptop is 64 bit, so I tried all permutations). THAT was exciting.
I wasn't using any of the responsive layout stuff and I hadn't written it with a phone in mind originally, so it looked TERRIBLE. But even it JUST worked. I simplified the UI a bit to look better on a phone... and now my wife is super psyched. Both her and her sister have Windows Phone devices, so once they go to Win10, they'll both be able to use this app to manage their work.
But yes, literally, not a single code change to get it to run on the phone. I will say it, at this point it really does feel like UWP is living up to the hype. Sure, in many cases I would either want separate UI's for different device categories or, at the least, some responsive layout if screen size is the only important factor. But it did run on 3 different device types (laptop, tablet and phone) spanning 2 operating systems (Windows 10 and Windows 10 mobile) and 3 architectures (ARM, x64 and x86) and all without any code changes to make it support any of those permutations.
It is also promising to know that I may be able to get this running on the Xbox One soon as well or even HoloLens without changing anything unless I wanted too.
And there you have it. The language is not all there yet. And I don't think I would easily find community projects for gaps either. I hope it does though, because once you get past those, it truly was magical to see something thrown together so quickly run so easily in so many places.
Comments
Post a Comment