With that, I’m taking several courses from Udemy:
The Web Developer Bootcamp
All seem to be worth the $10 I’ve spent. However, I was struggling trying to find a project that’d interest me enough to practice. That’s when I discovered Google’s Web API which has a framwork which allows for interaction with Bluetooth LE devices from inside the browser! Now I’ve got some projects.
Below is a sample of the project. Currently, it is merely a BLE serial terminal–but I’ll attempt to develop it into a TinySafeBootloader, like my C# projects.
This is the main app.js
Below is the module which controls the Bluetooth LE functions.
Here is the Terminal module. This is meant to encapsulate the code responsible for displaying the sent, received, and system information.
One of the issues I’ve had in the past with the Lumi projects is manageable UI. The project will start out pretty straight foward, but soon, I’m switching between device types, checking if hardware is ready, and routing callbacks based upon the device selected. It becomes spaghetti code quick. On Lumi4, I’ve decided to bite the bullet and implement MVVM.
After about 20 hours struggling with setting up Lumi4 as an MVVM project I’ve dervied two conclusions:
Apple spoils developers with MVC baked into Xcode
MVVM in C# and UWP isn’t simple. It seems like there is a lot more boiler-plate coding necessary for MVVM than MVC in Xcode. Eventually, I broke down and downloaded the NuGet package Prism, as a MVVM helper. This helped alleviate some of the code necesssary for Commanding (which I still don’t understand well enough to implement without Prism).
Below I’m going to take a look at a couple of controls I’ve written MVVM on. Finding documentation for MVVM in Universal Windows Plateform (UWP) is tricky. It is similar to XamarinForms and WPF, but overall, there are syntax differences which make generalizing the documentation difficult.
First, taking a look at the four text boxes which will hold the network IDs and host IDs the user is to type in:
This sets up the binding to the variables HostIDOne, HostIDTwo, NetworkIDOne, NetworkIDTwo. However, there’s plenty more boilerplate code before things start working.
To setup a ViewModel it’s best to setup an abstract class which can be inherited. This saves on creating boilerplate. Below is the abstract class the internet told me to make:
This code handles the property changing notification for all properties declared in classes which inherit from the MainViewModelBase. Such as the MainViewViewModel which is used in Lumi4
Moving on to the actual implementation of the bound text boxes. Each text box will have a property associated with the string value in the Text attribute. However, before this will work, the DataContext must be set for the MainPage.xaml. This is done in the MainPage.xaml.cs file.
(I told you it was a lot of work to setup. Well, compared to Xcode’s MVC.)
Ok, everything should be in place, time to implement the bound properties. In the MainViewViewModel I’ve the following code:
The if statement under the setter checks if the value about to be set is the same as the value is currently. Note, there is a helper in Prism which will prevent one from having to rewrite this for every attribute. However, I implemented the above code before I downloaded Prism and decided to write this article while it was still fresh in my mind. I’ll probably correct these to use the Prism helper before moving.
The code so far should allow for the properties setter to be called whenever the user types something in one of the four textboxes. On caveat, it seems the setter is not called until the user removes focus from the textbox. I’ll probably need to change the binding of the properties, but for now, it works well enough.
Well, this is all fine and gone, but what about Commands such as Button Click Events? Pretty simple, but with more boilerplate code.
First, bind to the command in the View
Next, and this is the part I don’t understand without Prism helping, there needs to be a delegate which will fire an event whenever the commad is called. In Prism there is the DelegateCommand type which takes care of a lot of the work. The DelegateCommand has to be initialized with two event handlers CanExecute and Execute. These methods will be called in that order every time the DelegateCommand property is accessed.
And that’s it for now. Had to make sure I jotted down my notes while the challenge was still fresh in my head.
Apparently, a Prism ViewModel should inherit from BindableBase instead of the custom ViewModelBase the internet told me to write. Also, to get the prismProp code snippet it looks like you have to download the Prism template packet:
I mentioned in an earlier entry that I had the hardest time differentiating between unit and integration tests. But this distinction was critical for implementing tests which could cover frameworks designed to interact with embedded systems. At least, in my perspective. Below is an outline of how I’m structuring tests for the Lumi4 code base.
In an earlier entry I reviewed the epiphanic difference between intergration and unit tests. The intergration tests are really meant for code which relies on outside systems; database query result, characters from a filestream, or characters from a UART device. For Lumi4 there are three systems which the program is depedent.
Remote Bluetooth Device(s)
Remote Wifi Device(s)
Intel HEX Filestream
For the first two I’ve decided to focus on integration testing rather than mocks and stubs. My reasoning is two fold, I will most likely be tweaking the firmware of the remote devices. Secondly, I don’t understand mocks and stubs yet. Trying to focus on MVP.
Of course, when I finally put together a plan of action a new struggle arose. A lot of my Bluetooth and Wifi handling was depedent on asynchronous callbacks. And this isn’t the easiest thing to tackle in MSTesting (which is the testing package I’m using for this iteration). Eventually though, I hacked together the following logic
There are a few inputs which most be manually provided to the test, for example, the LocalIP and the target device’s IP. Scoped at the top of the method is a flag which will identify whether the device was found. It then takes this information, sets up a in method delegate (callback), and attempts to contact the device. Lastly, there is an async delay whose purpose is to allow the search enough time to properly execute. If the test finds the device within the given time, the callback is fired, and the flag set true. Otherwise, it returns failed.
Not sure of the validity, but it’s what I got (so far).