"Modulairity" of the wifly GSX driver

Jul 9, 2012 at 3:37 PM

I received multiple feature requests for the wifly driver I created. I am grateful for the enthousiasm everyone shows in working with and extending my code. I also wish to implement as many features as possible, but with a micro framework, there's one big rule in my humble opinion: "Keep it small and simple".

Of course, this doesn't mean features can't be impelemented, but I would like to create a more modulair approach. I'm not sure yet how to do so, so I want to create a discussion about this.

My first idea would be making some private methods protected, so other files could communicate with the main class. I'm curious to other thoughs about this.

Jul 9, 2012 at 3:56 PM

Here are my ideas,

Creating an interface for the wifly, and having base classes for different behaviors.  This would be kind of nice, you could do WiflyGsx wifly = new AutoConnectOnUartWifly, and have the constructor take in the additional parameters needed for this mode(using my auto connect on uart data mode as an example).

Or keeping the wifly class, and using the strategy pattern for sending requests.  I am not as sure about this one, as some of the modes can be pretty different.


I would be kind of nervous 'un-privatizing' methods, although if we added checks to make sure you couldn't do anything stupid(checking which mode we are in for example). 

Jul 18, 2012 at 10:38 AM

I think it'd be a great idea to implement some additional features for the driver. I certainly agree that the core driver should be as simple as possible to keep things slim.

For what it's worth, I've already extended and created some functions to add support for a few other useful commands for the module (scan for networks for instance). I'm happy to share with the project, but it's probably not that helpful just yet until some further direction is made on how is the best way to implement further functionality.

Jul 18, 2012 at 10:50 AM

Thanks both, for replying.

I hope by the end of this month, or in the first week of August, I can work on this. I'm think the approach will be to make a few methods protected.

Aug 20, 2012 at 10:26 PM

Just wondering if you need any assistance with getting this going? I'm happy to help out, if you've got a plan of action!

Aug 22, 2012 at 10:04 AM

Sorry, I haven't looked into this much recently due to some other stuff that's on my mind :)

To keep things small and compact (as supposted to with a micro framework imho), I think the easiest way will be making some protected hooks.
I think the best way to start, would be to make the CommandMode-methods protected. Also, add in a check to see if a socket connection is active (command mode shouldn't work in those cases).
I think most addons could be done with command mode.

I hope to have some free time soon, so I can work this out.

Aug 23, 2012 at 11:21 PM

@garrcomm No worries, completely understand that you've got better stuff to do! :) That sounds good - I'll see if I can make a start on sorting that out!

Sep 12, 2012 at 6:47 PM
Edited Sep 12, 2012 at 8:30 PM

Guys, has anyone had any more thoughts on this discussion. Is there any move to adding socket server functionality (instead of just client) to this driver? Also, the link in the source to the Roving PDF appears broken (http://www.rovingnetworks.com/files/resources/WiFly-RN-UM-2.31-v-0.1r.pdf.) Can anyone get me the link to the correct file?

Edit: I found the link to the user manual. http://www.rovingnetworks.com/resources/download/93/WiFly_User_Manual