search

pyxyyy / gesture-drumkit

a real-time gesture based interactive drum kit
0 stars 2 forks source link

Brief walkthrough of existing Android code #19

Open alexfjw opened 5 years ago

alexfjw commented 5 years ago

AndroidManifest.xml All activities & services are declared here. It tells you what screen shows up first, what screens exist, what orientations are supported and so on.

transmission/ReceiverService.kt (not impt) Provided by Samsung. Runs in the background when app starts. Listens to connections from watch. Connects to some official samsung app to do this. (you should have been prompted to install the app when pairing phone with watch)

transmission/SensorDataSubject.kt Singleton. Written with RxJava. Receives data from ServiceConnection & lets any amount of subscribers connect to it. Reactive programming is pretty fun.

transmission/ServiceConnection.kt (not impt) Class that Samsung requires to get data from watch. Probably represents the connection between watch & phone.

RecordingActivity.kt Connects to SensorDataSubject and logs sensor data to file. Currently logs files at sdcard/drumkit_record/.

StartingActivity.kt Routes user to other activities. Doesn't really do much.

alexfjw commented 5 years ago

If interested... @senyuuri @pyxyyy

senyuuri commented 5 years ago 
What are the differences between communicating with accessory devices using the Accessory SDK 
and using legacy connectivity mechanisms (such as Bluetooth and Wi-Fi)?

The Samsung Accessory Protocol uses the concept of a Service to simplify implementations. 
Applications define a service profile for communication between peers to support specific use cases.
The Accessory SDK and the Samsung Accessory Service Framework provide an abstraction layer to
manage connectivity and service profile messaging between applications. 
You do not need to rewrite basic use case code of a service profile for specific connectivity methods.

Source: https://developer.samsung.com/galaxy/accessory#5

Found this in Samsung Accessory SDK's Q&A session. This probably hints that the underlying connection could be either bluetooth or WiFi, depends on the link quality.

We may need to either force SensorDataSubject.kt to use BLE or simply turn off WiFi during testing to ensure the latency is consistent.

alexfjw commented 5 years ago

We can just delete the wifi item in accessoryservice.xml or smth along those lines to disable wifi

alexfjw commented 5 years ago

The apps cannot communicate through wifi in the latest commit. Have tested, latency doesn't change. I suppose the devices were communicating with BT anyway. Just to be clear, they communicate through BT right now, rather than BLE. BT is a bit faster.

image From wikipedia, BLE page

senyuuri commented 5 years ago

Nice! We have one less thing to take care of.