Thursday, January 30, 2014
Monday, December 16, 2013
DDWrt Data for iOS support FAQ
1. What do I need for DDWrt Data to work?
Well first and foremost you need to be running DD-Wrt on your router. DDWrt Data uses the web interface to access the data it needs so that needs to be enabled (it is enabled by default). The historical monthly view is stored on the router so you need to make sure that "Wan Traffic Counter" is enabled under the "Services" tab of your DD-Wrt router.
2. What network interfaces are supported?
By default when you add a new router DDWrt Data adds 3 interfaces for WAN, Wifi and LAN. Any interface name is supported by editing an existing interface and editing the Advanced settings.
3. Can I use SSL?
Yes, edit an existing interface and switch SSL on in Advanced settings. You may have to enter a custom port when changing this setting.
4. Can I use a dynamic IP service like NO-IP?
Yes you can. Enter your DNS name into the address field when adding a new router (or edit an existing interface).
5. What is the red vertical line that appears on the live graph.
Its a break in time longer than 5 seconds. DDWrt Data shows you the data you have missed because of a network error or because the application was in the background.
6. Can I view historical data usage?
Yes, swipe back on the live graph for a month view and swipe back again for the previous month.
Tuesday, October 1, 2013
NSTableView binding with MvvmCross
Although Mac support in MvvmCross is in its infancy a lot can be accomplished by following the patterns used for iOS. This post assumes you can get the necessary plumbing working for a basic Xamarin.Mac application using MvvmCross. Most of the setup required for a Mac app can be copied from the iOS code but its beyond the scope of this post.
A NSTableViewSource is what the NSTableView uses to source its data. This is what we want to bind. We want to be able to do the following in our binding code:
This is a standard MvvmCross "Fluent" binding. See Stuarts excellent binding documentation for more information. To achieve this I have created bindable versions of NSTableViewSource, NSTableColumn and NSTableCellView. My code uses a "Cs" prefix instead of NS for the bindable versions. Of course once (if) this code makes its way back into MvvmCross it will use the standard Mvx naming convention.
One of the big differences between the NSTableView and the UITableView is that the former has a concept of columns. What we want is to be able to specify a binding expression for each column we require. We use the editor in Xcode to do this. In the example below we have setup our NSTableView with a few columns. Notice how the binding expression for the "Process Name" column is specified as a "User Defined Runtime Attribute" in the inspector.
"Title" is a property in CsTableCellView that simply sets the default NSTextField. Description is a property on my model class that is part of the IEnumerable in my view model.To setup a view as above follow the following steps:
A NSTableViewSource is what the NSTableView uses to source its data. This is what we want to bind. We want to be able to do the following in our binding code:
This is a standard MvvmCross "Fluent" binding. See Stuarts excellent binding documentation for more information. To achieve this I have created bindable versions of NSTableViewSource, NSTableColumn and NSTableCellView. My code uses a "Cs" prefix instead of NS for the bindable versions. Of course once (if) this code makes its way back into MvvmCross it will use the standard Mvx naming convention.
One of the big differences between the NSTableView and the UITableView is that the former has a concept of columns. What we want is to be able to specify a binding expression for each column we require. We use the editor in Xcode to do this. In the example below we have setup our NSTableView with a few columns. Notice how the binding expression for the "Process Name" column is specified as a "User Defined Runtime Attribute" in the inspector.
"Title" is a property in CsTableCellView that simply sets the default NSTextField. Description is a property on my model class that is part of the IEnumerable in my view model.To setup a view as above follow the following steps:
- Use a regular NSTableView.
- Add the columns you require and change the Custom Class to CsTableColumn as below
- Set the bindingText in the "User Defined Runtime Attribute" as mentioned earlier.
If your model class implements INotifyPropertyChanged any changes to a property will reflect automatically in the column that binds the property.
The code is currently sitting in gists until I get a chance to put it somewhere permanent.
Friday, July 12, 2013
Xamarin PCL Support - Hoorah!
Are we there yet?
Looks like it. Initial tests are promising. Last night Xamarin released Mono3.1.1 which amongst other things included the PCL reference assemblies.
Creating a new Portable Library
Go ahead and create a new Portable Library. If you drop down the References folder you will see that System, System.Core and System.Xml are all in red. To fix this double click on the project and go to Build/General for the following dialog:
Make a selection there, click OK and now you should be able to compile :)
MvvmCross
A barebones MvvmCross application with a Core PCL and Touch project compile and work with no hassles. Previously you had to jump through many hoops to get to this point.
I also added a Xamarin.Mac project just to test if I could reference my PCL Core and that also worked just fine.
Time to start using MvvmCross the way Stuart envisioned. I'll certainly be changing from a linked file solution to a PCL solution over the next few weeks. Hoorah!
Thursday, June 6, 2013
Custom Presenter for UITabBarController
I recently decided to introduce a UITabBarController into our MvvmCross iOS application. The navigation stack was getting a bit deap and the tabs provide a quick way back to the root. Stuart Lodge has a excellent video series on MvvmCross and just so happens to have one on using Tabs.
In the video he shows how to hide the navigation bar of the root UINavigationController so that you don't land up with a double bar on top. This is all fine for demo purposes (Stuart has thick skin and is only interested in progress) but what we really want is is for the UITabBarController to be the root controller. Apple recommends this approach and I have experienced some weirdness when not following this rule (especially when applying themes).
Unfortunately the presenter below does require a small change to the MvvmCross libraries.
HomeView is your MvxTabBarController which we will keep a reference to. Show is overridden to save the reference and sets HomeView as the root view controller using the base method. If anything else but the HomeView is shown the base Show is called. MasterNavigationController will return the UINavigationController of the currently selected tab. The idea is that you have a UINavigationController as the root controller in each tab. CurrentTopViewController simply returns the top most view of MasterNavigationController.
The change in the MvvmCross library I mentioned earlier is in MvxTouchViewPresenter. In order for the above to work the following change is required:
What we really need is a base presenter that doesn't force a UINavigationController as the root. Of course you can roll your own Presenter from scratch (MvvmCross is flexible that way) but that's a lot more code. Something to work on for next time...
In the video he shows how to hide the navigation bar of the root UINavigationController so that you don't land up with a double bar on top. This is all fine for demo purposes (Stuart has thick skin and is only interested in progress) but what we really want is is for the UITabBarController to be the root controller. Apple recommends this approach and I have experienced some weirdness when not following this rule (especially when applying themes).
Unfortunately the presenter below does require a small change to the MvvmCross libraries.
HomeView is your MvxTabBarController which we will keep a reference to. Show is overridden to save the reference and sets HomeView as the root view controller using the base method. If anything else but the HomeView is shown the base Show is called. MasterNavigationController will return the UINavigationController of the currently selected tab. The idea is that you have a UINavigationController as the root controller in each tab. CurrentTopViewController simply returns the top most view of MasterNavigationController.
The change in the MvvmCross library I mentioned earlier is in MvxTouchViewPresenter. In order for the above to work the following change is required:
What we really need is a base presenter that doesn't force a UINavigationController as the root. Of course you can roll your own Presenter from scratch (MvvmCross is flexible that way) but that's a lot more code. Something to work on for next time...
Tuesday, April 23, 2013
Using Mvx Messenger for loosely coupled communication
A ViewModel often needs to know of some status change in a service class. For instance you may have a network connection that you keep open to your platform. The ViewModel may want to know when this connection goes up and down.
.NET Events
When your ViewModel is created it subscribes to the event you interested in monitoring.
This works just fine. When the connection state changes you get notified and raise the fact that the IsConnecting property on your ViewModel has changed. Any UI that is bound to this property can update accordingly.
The problem with this approach is that the INetworkConnection outlives the ViewModel. Whats supposed to happen is when the View leaves the screen it gets garbage collected along with the ViewModel it owns. Now the INetworkConnection has a reference to the ViewModel (created by the event subscription) effectively preventing the ViewModel from getting GC'd. Of course we can make sure we unsubscribe from the event at some point but this has its caveats and becomes messy. We need a better way...
This works just fine. When the connection state changes you get notified and raise the fact that the IsConnecting property on your ViewModel has changed. Any UI that is bound to this property can update accordingly.
The problem with this approach is that the INetworkConnection outlives the ViewModel. Whats supposed to happen is when the View leaves the screen it gets garbage collected along with the ViewModel it owns. Now the INetworkConnection has a reference to the ViewModel (created by the event subscription) effectively preventing the ViewModel from getting GC'd. Of course we can make sure we unsubscribe from the event at some point but this has its caveats and becomes messy. We need a better way...
Enter the MvxMessenger
OK so these Message Aggregators have been around for a while. I've used TinyMessenger in the past when using V2 of MvvmCross. V3 introduces an MvxMessenger in the form of a Plugin. To get started make sure you register the plugin in your Setup class.
In this example my ViewModel registers interest in a message inside its constructor.
MessageHub is a property on my ViewModel base class that just returns an instance of the IMvxMessenger plugin we registered in the beginning. Something worth noting is that the token returned is stored in a field within the ViewModel. MvxMessenger uses a WeakReference to the Action<TMessage> when you subscribe. If you don't hold on to the token the reference gets lost and you wont receive your message. Something else to consider is the thread where your Action delegate (the one you passed to IMvxMessenger.Subscribe) gets called. In this example it will be called on whatever thread the INetworkConnection calls the IMvxMessenger.Publish() method on. Checkout IMvxMessenger.SubscribeOnMainThread which is especially important if your Action code calls into the UI. Using RaisePropertyChanged in your Action code is a prime example.
The Publish() method (already mentioned above) is used to send a message to subscribers. In this example its called by the INetworkConnection when its state changes. CoreStatusMessage is a MvxMessage that you can customise as you please.
In this example my ViewModel registers interest in a message inside its constructor.
MessageHub is a property on my ViewModel base class that just returns an instance of the IMvxMessenger plugin we registered in the beginning. Something worth noting is that the token returned is stored in a field within the ViewModel. MvxMessenger uses a WeakReference to the Action<TMessage> when you subscribe. If you don't hold on to the token the reference gets lost and you wont receive your message. Something else to consider is the thread where your Action delegate (the one you passed to IMvxMessenger.Subscribe) gets called. In this example it will be called on whatever thread the INetworkConnection calls the IMvxMessenger.Publish() method on. Checkout IMvxMessenger.SubscribeOnMainThread which is especially important if your Action code calls into the UI. Using RaisePropertyChanged in your Action code is a prime example.
The Publish() method (already mentioned above) is used to send a message to subscribers. In this example its called by the INetworkConnection when its state changes. CoreStatusMessage is a MvxMessage that you can customise as you please.
Conclusion
The great thing about this is you don't have to be concerned with holding on to objects and causing memory leaks. Consider using this instead of regular events in your MvvmCross app's. Especially where short lived Views need event's from some of your long living service classes.
Subscribe to:
Posts (Atom)