Controlling Arduino through Internet and Bluetooth
If I were you, I would separate the "hardware" from the "software". This is quite an interesting "pattern". It's used by almost every Operating System, to assure compatibility with devices all around the world.

But how?

Layers

The "OSI-model" typically describes a few layers. But to me, the most interesting part is the difference between "Host layer" and "Media layer".

Media Layer

The media layer(s) typically handle the transportation of your bits, addressing and data collision. In "the internet" you can 'simply' change from copper to glasfiber without it being noticeable in your end application (apart from being faster).

Host layer

The same for the host layers, whatever PC or network adapter you have, your program will run fine (if this abstraction/integration is done well).

Applying this

So how do we apply this? In a basic, small application.



We want our Host to not care too much about which Media(layer) it is using.
The Arduino has to be able to be configured or detect which media layer it is using.

Something like this is neccesary (this is not actual code, more pseudo code):

String messageBuffer = "";

void Setup(){
   setupWifi(pin1,pin2);
   setupBluetooth(pin3,pin4);
}

void Loop(){
   messageBuffer = getWifiMessage();
   handleMessage(messageBuffer);
   messageBuffer = getBluetoothMessage();
   handleMessage(messageBuffer);
}


If you set up this correctly, you'll only have to write the buffer handling code once. Which is very useful!
Handling buffers along with all the logic/effects it will cause, should be solid. You (probably) don't want different behaviour when you use bluetooth as when you use WiFi. Imagine your web-browser only working when you use copper, but not when you use glasfiber :)

Protocol

Your message should be exactly the same for WiFi and bluetooth. This way you won't have to deal with two different protocols and it will be easier to implement this at the other (control) side.

A good protocol/message can be this:

"@12#13,255,255,0;"


I use the @ as an start indication. This is very usefull for receiving, since you know where to start (obviously?).
You'll have to make rules for what will follow (maybe a set amount of characters, in my example, between @ and # it will indicate an "address". When you send it to multiple devices, you only want (in my example) device 12 to react. This often is handled by the bluetooth or wifi already, but it can be good to have some sort of unique header. So that random messages (which might look alike) won't be seen as one of your messages.
An message ID is useful, you kinda want to have different types of messages, for either "LED brightness" or "debug request" or "set output".
Each message could have an x amount of parameters, it's often better to separate these. It's important that you specify the maximal amount of parameters and what behavior they will cause.
Some protocols use a set length, but an end delimiter ";" is often the best way to let the other device know your message is completely received.


Some notes


Try to aim for existing protocols, it will be cool if your device is compatible and creating yet another protocol isn't particularly useful.
Mind that possible transmitted text does not include your start/end delimiters. You could use the message length or exclusions/inclusions in this case.
Be wary that the protocol adds overhead. But usually being able to "read" a message will make it much more easier to program a handler or generally work with it.
Check if the message is fully received and does not have errors. If you have an error, be sure your system can handle it and will respond with a message telling so. In no way your system should lock down on error or not provide a reaction (which makes debugging a pain).


The server

From whatever device you're sending your stuff, it should have bluetooth and/or WiFi. Bluetooth is fairly easy and should get you started quite fast.

If you're using WiFi, you should check if your device can make a TCP/IP connection. TCP/IP is basically a "shell" around your message, to shoot it over the internet ;D it comes with some neat addressing and error checking built in (but you can't be 100% sure there will be no error between your receiver and arduino).

But why?

Not only is it useful to learn how to do this, having to write the handler and protocol specification for both the Wifi and bluetooth (and possible usb, rf, ethernet etc). 
Apart from that, in embedded systems, you want to be sure that something works, using different handlers for different physical layers will create vague specific errors and might rip up your program logic. Also, if your protocol/application is used/reviewed by more people, you'll be more certain that it works well.