Programming for Android

Chris English

Chris English

Registered
I've got a university project coming up where we have to develop an Android app and I want to do mine using rFactor 2 to make a button box/live telemetry app which shows speed, gear, shift light etc, then a swipe or press on the screen changes it to the button screen.

Just wondering how difficult is it to get the telemetry data live from rF2 into an Android app and what's required?

I will be using Eclipse for development - I'd say I'm an intermediate programmer having done it in university for the last 3 years this will be my first attempt at an application that I want to do and not a university set application.

Thanks in advance for any help,
Chris.
 
Hi,

great idea but I'm afraid I can't help you on the technical.
Here's what I know: you've probably seen this: http://isiforums.net/f/showthread.php/1573-Tutorials-Modding-Downloads

Otherwise, some guy from http://www.symprojects.com/ mentioned that the plugin system was similar to rf1. So maybe you can look for manuals for rf1 plugins in the meantime.
http://www.eksimracing.com/ have just released an Android app supporting RF2.

If you need a beta tester for your work: I have a Galaxy Tab 10.1 and a Samsung Galaxy Nexus.

Good luck with your project!
 
Hey,
Thanks for the links :) They should help.

Will have a look at the example plugin - I thought that thread was just for car/track modders so thanks for turning my attention to it again. :)

If I need someone to test will give you a shout. If my tutor won't give me the go-ahead for it then I'll do one anyway in the summer. :p
 
Hey this sounds great! i could also test with a Galaxy Tab 10.1 and Samsung Galaxy Ace 5830...are you planning on bluetooth or USB connection?
 
I'll be doing it through Bluetooth or WiFi (coursework spec states it should be wireless). I've got the go-ahead to do it, as yet undecided if I want to release it or not.

Still looking for help for how to get data from rF to the phone. C++ isn't my strong point (this will be done in Java). I know I need to create a UDP connection - which possibly rules out Bluetooth, but will need to look into the protocol more first.

At the minute doing designs and diagrams for it. Programming won't start until the start of next month.

Still looking for any input which may help particularly sending packets from rF to Android - may help as a reference to any other want-to-be Android programmers too! ;)
 
Chris English said:
I'll be doing it through Bluetooth or WiFi (coursework spec states it should be wireless). I've got the go-ahead to do it, as yet undecided if I want to release it or not.

Still looking for help for how to get data from rF to the phone. C++ isn't my strong point (this will be done in Java). I know I need to create a UDP connection - which possibly rules out Bluetooth, but will need to look into the protocol more first.

At the minute doing designs and diagrams for it. Programming won't start until the start of next month.

Still looking for any input which may help particularly sending packets from rF to Android - may help as a reference to any other want-to-be Android programmers too! ;)
Click to expand...
One possibility is to create a TCP server in the plugin which you then connect to. I also think TCP is to recommend instead of UDP. I am pretty sure you want to know what you receive? I don't have that much UDP experiece but there might be a risk that you lose data on the way which might be tricky to handle on the client side. There are a lot of examples of how to create the server in C++.
I haven't done much Bluetooth programming but why do you rule out that??
I am still working on my project using any of SharedMemory or TCP. Plugin is done and most of it on the client side where I am using WPF and maybe later a Silverlight app. My TCP server is sending 1800 bytes each update (every ~200ms, will experiment with that later).
 
Since you will develop in Java because your project is on Android. I would make a telemetry Java class, and add some JNI code that would load the the plugin example dll. In the DLL, you should have a buffer of telemetric data ( of size n * TelemInfoV01 ) and share this buffer between the dll code and the JNI code ( http://msdn.microsoft.com/en-us/library/h90dkhs0(v=vs.80).aspx ).
You'll need to make sure that you always get the latest update, and that your Java Thread isn't going faster than the plugin and request old data ( if it's going faster just don't update, e.g. : If Java is going at 120hz and the game at 60hz, 1 time over 2 time you won't have to update since you will request the same data ).
I would do the client server connection on the Java side since it's much easier to do ( you can use ServerSocket in Java : http://docs.oracle.com/javase/tutorial/networking/sockets/clientServer.html ). You can even serialize the Telemetry class and send it to the client. Then you'll make your GUI in java.

I wanted to do the TCP IP in c++, but it end up slowing down the game, I had to do a thread and so on... I went to a much easier path, and I did most of the work in Java. It's working well so far.

That's pretty much what I did. Good luck.
 
mikla521 said:
One possibility is to create a TCP server in the plugin which you then connect to. I also think TCP is to recommend instead of UDP. I am pretty sure you want to know what you receive? I don't have that much UDP experiece but there might be a risk that you lose data on the way which might be tricky to handle on the client side. There are a lot of examples of how to create the server in C++.
I haven't done much Bluetooth programming but why do you rule out that??
I am still working on my project using any of SharedMemory or TCP. Plugin is done and most of it on the client side where I am using WPF and maybe later a Silverlight app. My TCP server is sending 1800 bytes each update (every ~200ms, will experiment with that later).
Click to expand...
Thanks for the info - I'm going to carry on trying to do UDP. I think it'll be a better option, and have had other advice to use UDP.

dlecoutre said:
Since you will develop in Java because your project is on Android. I would make a telemetry Java class, and add some JNI code that would load the the plugin example dll. In the DLL, you should have a buffer of telemetric data ( of size n * TelemInfoV01 ) and share this buffer between the dll code and the JNI code ( http://msdn.microsoft.com/en-us/library/h90dkhs0(v=vs.80).aspx ).
You'll need to make sure that you always get the latest update, and that your Java Thread isn't going faster than the plugin and request old data ( if it's going faster just don't update, e.g. : If Java is going at 120hz and the game at 60hz, 1 time over 2 time you won't have to update since you will request the same data ).
I would do the client server connection on the Java side since it's much easier to do ( you can use ServerSocket in Java : http://docs.oracle.com/javase/tutorial/networking/sockets/clientServer.html ). You can even serialize the Telemetry class and send it to the client. Then you'll make your GUI in java.

I wanted to do the TCP IP in c++, but it end up slowing down the game, I had to do a thread and so on... I went to a much easier path, and I did most of the work in Java. It's working well so far.

That's pretty much what I did. Good luck.
Click to expand...

Thank you very much - exactly the sort of guidance I've been looking for! :)

I'll be getting my new Android phone this afternoon, so this project will start very soon!
 
Using UDP should be faster but how do you know or how do you handle data that you don't receive but should? Just curious...
Don't understand how you can say that TCP in C++ slowed down the game since you had to do threading? So it should be better and faster to do an extra Java program instead? And what is that Java program then...a thread... And no way Java is faster than C++, much easier probably. I had some issues with my TCP server in the beginning but it turned out that I had missed a few things myself concerning threading. Fast, threaded, no slowing down of game, no issues at all now. :)

Developing in Java for Android isn't obvious these days.....Mono Droid = C#.

If the mayor thing is to make it work, use whatever you are comfortable with :)
 
mikla521 said:
Using UDP should be faster but how do you know or how do you handle data that you don't receive but should? Just curious...
Don't understand how you can say that TCP in C++ slowed down the game since you had to do threading? So it should be better and faster to do an extra Java program instead? And what is that Java program then...a thread... And no way Java is faster than C++, much easier probably. I had some issues with my TCP server in the beginning but it turned out that I had missed a few things myself concerning threading. Fast, threaded, no slowing down of game, no issues at all now. :)

Developing in Java for Android isn't obvious these days.....Mono Droid = C#.

If the mayor thing is to make it work, use whatever you are comfortable with :)
Click to expand...

Maybe I didn't explain myself clearly. Right, I would have had to do threading in c++ cause the TCP/IP was slowing down the game, but I didn't go that way. Yes c++ is faster, but Java was an easiest and fastest solution for me. Both solutions are good, just pick the one that fit you the best.
 
You can run a server from the plugin if you want.

Like the others are advising as well, I'd start with TCP rather than UDP at first. It's easier to set up and you won't be saturating the network anyway unless you run the telemetry at full speed (and even then...).

This is not complete code, but it should help you get started :)

Declare this:
Code: 
    static DWORD WINAPI AcceptConnections(void* p);
    static DWORD WINAPI AcceptReadSocket(void* p);
    
    static SOCKET _listenSocket;
    static SOCKET _clientSocket;
    static void sendData(const int buflen);
    static char* _sendBuffer;
    static char* _readBuffer;

When the plugin starts, start the network and create a thread to accept connections:

Code: 
    WSADATA wsaData;
    _listenSocket = INVALID_SOCKET;

    sockaddr_in service;
    service.sin_family = AF_INET;
    service.sin_addr.s_addr = INADDR_ANY;
    service.sin_port = htons(port);

    WSAStartup(MAKEWORD(2, 2), &wsaData);
    _listenSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    bind(_listenSocket, (SOCKADDR *)& service, sizeof (service));
    listen(_listenSocket, SOMAXCONN);
    // + set additional socket options via setsockopt()
    DWORD nThreadID;
    CreateThread(0, 0, AcceptConnections, NULL, 0, &nThreadID);

Create the static function that acccept incoming connections (which runs in the separate thread):
Code: 
DWORD WINAPI RacePadPlugin::AcceptConnections(void* p) {
    while(1) {
        _clientSocket = accept(_listenSocket, (sockaddr*)&ClientAddress, &nClientLength);
        DWORD nThreadID;
        CreateThread(0, 0, AcceptReadSocket, NULL, 0, &nThreadID); // create thread to read data
}

Function to read incoming data:
Code: 
DWORD WINAPI RacePadPlugin::AcceptReadSocket(void* p) {
    int nBytesRecv;
    do {
        nBytesRecv = recv(_clientSocket, _readBuffer, RECV_BUF_MAX_SIZE-1, 0);
    } while(nBytesRecv > 0);
}

Function to send data, store your data in the _sendBuffer and send it to the client
Code: 
void sendData(const int buflen) {
int nBytesSent = send(_clientSocket, _sendBuffer, buflen, 0);
}

In the UpdateTelemetry() function you can then send the data you want. This function is called very frequently, but you can send the data only every nth call to throttle it.
Code: 
void YourPlugin::UpdateTelemetry(const TelemInfoV01 &info) {
   ZeroMemory(_sendBuffer, SEND_BUF_MAX_SIZE);
   int buflen = sprintf_s(_sendBuffer, SEND_BUF_MAX_SIZE, "stuff your data in here");
   sendData(buflen);
}

Your app can then create a connection to the plugin, read out the data and do whatever it wants with it :)
 
98395A7C8BB444283303C95223BA2EE9B5E3607C
 
LOL! I thought it was new, I never looked at the date.

Why on earth did marsalcrow register on this forum to place just one post in a 6 year old thread? :D

Ah well, perhaps my post will be useful to someone some day :P
 
You must log in or register to reply here.
Back
Top