Home

ASAPJava first

We assume:

• Your are familiar with the ASAPJava
• You implemented (a little) ASAP/Shark app.
• You plan to implement an Android GUI for your app and to use protocols provided by your Android device.

Your app logic needs no changes

You application logic uses ASAPPeer or even better SharkPeer to deliver messages with your ASAP P2P network. Here is the good news. Both interfaces are available in Android if you use this library. The is no need the change a single line in your application logic.

The recommended way is this:

1. Implement your application logic.
2. Test it in a pure Java environment, see ASAPJava lib
3. produce a lib (Produce JVM byte code. Go to your class files root directory. Produce a jar file with the jar command.)
4. Setup a new Android project. Add your lib (beside others) to this project.
5. Implement a GUI.

Suggested rules:

• Your Android project only implements a GUI, no application logic.
• You find a bug in your app logic (will happen) - go back to your Java program. Fix the bug. Produce a new lib and come back here. This procedure is much faster. It keeps your code split into application logic and GUI – separation of concern, MVC etc. are very effective principles. It gives you even the chance to implement an alternative (G)UI beside Android for your app if you like.

ASAPService - ASAPActivity

The library is split into to parts: application and service side. Developers only deal with application side. Good news: ASAPPeer and SharkPeer are available. You application logic works without any changes.

There is no need to read this section. It is just for your information.

Application Side

We strongly suggest and assume that your application logic is implemented and tested before your start implementing a GUI with Android. Activities are means to bring your application logic and a GUI together. You application logic works with an ASAPPeer or better a SharkPeer.

There are simple ways to provide you with an object reference to such a peer. What happens internally when you call a method? An Android service message is created in most cases. Method parameters are serialized into a byte array and become part of this message. It is sent to an Android service. In some cases, data are written directly to the file system.

There is an ASAPAndroidPeer that implements those algorithms. (There is no need to study this class. But have a look if you like). It acts as a stub as we would call it in RPC. Methods can be called. But this class takes all parameters and send messages to another part in the system that actually runs the algorithms. This part runs in a separate Android service. This class receives results from the services.

You application works with this stub and is not aware of the distributed nature of the library.

Service Side

Our ASAPService launches an ASAPPeer and wraps it into a SharkPeer during system initialization. Message can arrive from application side. They are processed by message handler and can lead to switching on a protocol (e.g. Bluetooth), connect a hub, send a message with ASAPPeer etc.

ASAPPeer can receive message from other peers. This fact must be announced to application side. We use broadcasts. Each ASAPActivity starts broadcast receiver that receives and processes message from the service and call your application back if necessary. This only works, if you activities derive from ASAPActivity.