Well, you'll need a transmitter and a receiver :-).
Infrared
You mention disadvantages like limited range and having to direct the transmitter, and it will depend on the setting how bad these are. Obviously a large auditorium will be more of a problem that a 20 seat room.
Suppose we go for IR, what do we need? There's the protocol and a few codes (at least next and previous slide). For the protocol you can choose an existing one, and even use existing codes, but if you make both transmitter and receiver yourself you can also devise your own protocol. Advantage: you can make it as simple as you like, especially regarding decoding, which is more complicated than sending. One of the most simple protocols is Pulse-Pause Modulation, where you send a series of fixed-width pulses, and encode the bits in the time between pulses.
Transmitter
This is the easiest. Basically a microcontroller, a transistor and an IR LED. Microcontroller is asleep, and wakes up when you press a button. Start sending the modulated code until button released and go back to sleep. The finished product tomorrow morning on my desk, OK? ;-)
Receiver
An IR receiver is quite complex, and you don't want to make this yourself. Especially AGC is no fun. So we buy a receiver module, like from Vishay. This gives you the decoded signal which can be used directly by the microcontroller. Note that when the IR receiver modules don't receive a signal the AGC will lock to the noise and output that: a lot of garbage. But no worries: when a code is received this is as clean as can be, no noise whatsoever.
RF
The alternative is RF. You can use the same protocol and codes, and the transmitter will look almost the same. Just output the (unmodulated!) codes to an RF transmitter instead of the IR LED.
RFM70 modules are small, cheap (around 5 dollar IIRC, I think Wouter knows them well) and easy to interface.
I recently did a similar design for fun with an iphone sending http requests to a webserver running on a MSP430. I also looked a little at security. I think if you want to make your project "more secure and not easy to hack" then you should look into encrypting whatever communication channel you are using. I'm sure you could encrypt the payload you send from the android phone, and decrypt on your endpoint.
The problem I hit was the code to support something like https key negotiating was way too big for my little device. I ended up going with their built in AES encryption engine, and just sharing the keys between the devices ahead of time.
In any event that's where I would start, once you can encrypt your payload, your transport mechanism starts to matter less and less.
Best Answer
Since you are new to microcontrollers, your best course of action would be to get an Arduino (there are several types). While they are designed for beginners, they also have a lot of flexibility.
Peripherals for the Arduino are called shields, and they have many options for doing wireless. One option you might want to consider is Bluetooth, which can cover up to 100m out in the open, and quite a bit less indoors. You didn't say whether you will be indoors or outdoors. There are many Bluetooth shields, such as this one. In almost all cases, the antenna is already included on the board.
If battery life on the remote device is a factor, you might also want to investigate Bluetooth Low Energy, which has a range similar to "classic" Bluetooth but consumes much less power. It is quite new (there is no native support for it in Windows 7, for example), but since you will be providing both ends of the wireless link, this should not be a problem.