URLConnections are carried on separate threads and UI updates are packed in a new thread that will be queued and "runOnUiThread".
URLThread creates an in depended URLConnection thread , read string input and when it calls back to URLCallBack(String response) in a given class that implements the interface URLThread_CallBack
final Activity currentActivity=this;
new URLThread("URL HERE", new URLThread_CallBack()
{
@Override
public void [URLCallBack](src/yoga1290/schoolmate/URLThread.java) (String response)
{
//queue this back on in the UI
currentActivity.runOnUiThread
(
new Runnable()
{
@Override
public void run()
{
findViewById(R.id.SOME_UI_Comp)
.doSomething();
}
}
);
}
}, "Optional POST DATA HERE,otherwise GET is used").start();
- Locally stored file, used for storing user data for later use and transfer data between Activities
- Implementation: getData():JSONObject & setData(JSONObject):void in Connect
In-App Socket Server that handles couple of things:
-
If OAuth permission dialog was accepted, Service provider will make callback to the Web server (my AppEngine) handling the access token, the web server will later on pass the access token to the in-App Server localhost:1290?ServiceName_HERE?access_token=TOKEN_HERE where the user access token will be extracted.
-
Later, the access token is used to establish a URLConnection to retrieve the users data (e.g: Facebook/Foursqaure ID)… but KEYS from their JSON responses may clash with others in the Connect.json… so, before storing any data, there will be URLConnection CallBack Handlers to avoid JSON Keys collision
- Sociability (Audio Streaming+Messaging)
When the in-App Server accepts a client, it uses the 1st line of input as an CMD
Raw Audio data is streamed in case of the LISTEN CMD that is played on separate AudioTrack DataTransferThread
PCM-16 constants are stored in AudioProperties class
My implementation is very close to what's on Google Blog but I don't care about saving data
- Avoiding duplicated messages
If it's receiving a POST or a LISTEN command,then it'll add its address to the received list before passing the data to other peers that aren't mentioned in the next line.
-
Connect/MainActivity , It should be starting as the very 1st view and whenever there's a need for an access token
-
ProfileActivity , starts after the Connect Activity and on profile picture click in the view_class_stream
-
ClassActivity , starts on button press in the ProfileActivity, having some Swipping-Views; view_class_details to show data about class with current_class as an id, view_class_stream view for displaying the received messages and social sharing.
-
GET method for getters & POST method w id/pin Example of requests/responses for getters & setters:
{ "classes":"1,2,3,…", "fbid":"870205250" }
classes: IDs of joined classes fbid: Facebook id; used to send notifications
-
GET /schoolmate/staff?id=…&pin=…
{ "schedule":"39,100,25,94,110,74,…", "students":"1,2,3,…" }
students: IDs of students in this class used for generating charts where (schedule) is a 6-element array representing the 6 daily periods, each integer is a binary mask in form of 0bSMTWtFs (Sunday,Monday,Tuesday,Wednesday,thursday,Friday & saturday in order)
- POST /schoolmate/student?id=…&pin=…
- POST /schoolmate/staff?id=…&pin=…
- POST /schoolmate/class?id=…
I'm switching to Bluetooth Socket Server connection; more independent and w a fixed address.
- Bluetooth device discovery implemented in ClassActivity
- BluetoothServer as Server
- BluetoothServerRequestHandler as ServerRequestHandler