NXT-Spy – Implementation of most of the active components

So here is the list of the event handler I have created during the last two days :

  • CheckedChangeEventHandler <- android.widget.CompoundButton.OnCheckedChangeListener
  • ClickEventHandler <- android.view.View.OnClickListener
  • CreateContextMenuEventHandler <- android.view.View.OnCreateContextMenuListener
  • DateChangedEventHandler <- android.widget.DatePicker.OnDateChangedListener
  • DateSetEventHandler <- android.app.DatePickerDialog.OnDateSetListener
  • DialogCancelEventHandler <- android.content.DialogInterface.OnCancelListener
  • DialogDismissEventHandler <- android.content.DialogInterface.OnDismissListener
  • DialogKeyEventHandler <- android.content.DialogInterface.OnKeyListener
  • EditorActionEventHandler <- android.widget.TextView.OnEditorActionListener
  • FocusEventHandler <- android.view.View.OnFocusChangeListener
  • HierarchyChangeEventHandler <- android.view.ViewGroup.OnHierarchyChangeListener
  • ItemClickEventHandler <- android.widget.AdapterView.OnItemClickListener
  • ItemLongClickEventHandler <- android.widget.AdapterView.OnItemLongClickListener
  • ItemSelectedEventHandler <- android.widget.AdapterView.OnItemSelectedListener
  • KeyEventHandler <- android.view.View.OnKeyListener
  • LongClickEventHandler <- android.view.View.OnLongClickListener
  • RatingBarChangeEventHandler <- android.widget.RatingBar.OnRatingBarChangeListener
  • ScrollEventHandler <- android.widget.AbsListView.OnScrollListener
  • SeekBarChangeEventHandler <- android.widget.SeekBar.OnSeekBarChangeListener
  • TextChangedEventHandler <- android.text.TextWatcher
  • TimeChangedEventHandler <- android.widget.TimePicker.OnTimeChangedListener
  • TouchEventHandler <- android.view.View.OnTouchListener

And all the active components :

  • ActiveAlertDialog <- android.app.AlertDialog
  • ActiveAutocompleteTextView <- android.widget.AutoCompleteTextView
  • ActiveButton <- android.widget.Button
  • ActiveCheckBox <- android.widget.CheckBox
  • ActiveDatePicker <- android.widget.DatePicker
  • ActiveDatePickerDialog <- android.app.DatePickerDialog
  • ActiveGallery <- android.widget.Gallery
  • ActiveImageButton <- android.widget.ImageButton
  • ActiveImageView <- android.widget.ImageView
  • ActiveListView <- android.widget.ListView
  • ActiveProgressBar <- android.widget.ProgressBar
  • ActiveProgressDialog <- android.app.ProgressDialog
  • ActiveRadioButton <- android.widget.RadioButton
  • ActiveRatingBar <- android.widget.RatingBar
  • ActiveSeekBar <- android.widget.SeekBar
  • ActiveSpinner <- android.widget.Spinner
  • ActiveEditText <- android.widget.EditText
  • ActiveTextView <- android.widget.TextView
  • ActiveTimePicker <- android.widget.TimePicker
  • ActiveTimePickerDialog <- android.app.TimePickerDialog
  • ActiveToggleButton <- android.widget.ToggleButton

And the other classes :

  • ActiveActions
  • ActiveButtonControl
  • ActiveButtonState

So as you can notice, I cannot really detail in-deep all my classes (methods, attributes, output values) so I think I am going to do a more complete API in the wiki in the next few days.

I haven’t tested all these classes and most of them have some functionality missing but the core of the main graphical components implementation is done.

Supervisor’s comment:

This represents a lot of work and a real step forward to have JCSPae is fantastic. Well done.
We have arranged a meeting time Tuesdays at 14:00. This provides a real basis for further development within a consistent parallel environment. The initial goal of getting the awt to work was very sensible because it then provided instant feedback on the operation of the phone. The next step is to get Wi-Fi and Bluetooth integrated to enable communication between each of the parts of the project.

NXT-Spy – More problems about active components solved…

When I thought the active components problem solved, I fell on an other major problem : The good old “CalledFromWrongThreadException : Only the original thread that created a view hierarchy can touch its views” that I had already encountered in this post.

I didn’t have this problem in my last attempt because I was not writing anything to the UI (I was just writing in the console). But as soon as I created my ActiveTextView component, my program stuck.

So first of all I tried the solution I had found in this former post (add a runOnUiThread(this) call in the constructor), but it didn’t work neither. After a lot of thoughts about this problem, I finally found a way to solve it (even if it is probably not the cleanest solution to this problem!) : I encapsulated the while loop contained in the run method in a inner runnable class as below :

[cc lang=”java”]
public void run()
if (configure != null)
while (true)
final Object message = configure.read();
((Activity) context).runOnUiThread(new Runnable() {public void run() {
/* All the UI modifications */
if (message instanceof Configure)
((Configure) message).configure(this);

NXT-Spy – First successful implementation of JCSPae

It now made more than one week that this black screen problem was getting on my nerves so today I decided to look more in deep in my program :

– First, I removed my Parallel call from my test app to see what happens if I just create an ActiveTextField and a channel without running anything, and it worked : as predicted, it just displayed a little text input on my screen.
– I then tried to just remove the run method call from the Parallel call and it worked : no black screen. So the problem could still come from anything in my JCSPae implementation.
– I finally tried to remove the while(true) loop contained in my little CSProcess and oh surprise, no black screen! This final discovery led me to understand that my problem was a thread problem : it seemed that my Parallel call was running in the same thread as my main app, and so the while(true) loop was leading my app to an endless loop that avoided it to run all the rest of the application, and because my Activity’s “onCreate” method is called before that app draw anything, I just had a black screen displayed.

So to solve this problem, I finally created a new Thread Class in my test case called “ParallelThread” where I just copy-pasted my Parallel call and oh miracle! It worked, my program was working as respected : every time I typed a letter in the ActiveTextField, it printed itself on my console.

So I now have the core of my JCSPae implementation working. In the next few days, I am probably going to code the rest of the active components.
I will also have a lot of work on this implementation if I want to be able also to do my Wi-Fi and Bluetooth requests using JCSP (I will probably have some troubles with the drivers that are probably not that same as the ones in a computer).

NXT-Spy – Unsuccessful JCSPae implementation.

So here I am, I worked a lot on my JCSPae implementation with no results :

– First of all I imported JCSP sources into a new Android test project to see which classes were causing problems. I fixed a little XML issue in org.jcsp.net, removed org.jcsp.demos.util because it was useless for me, and removed the org.jcsp.awt package because it was no use for me to keep it as Android doesn’t support AWT, and I have created the package org.jcsp.android.view instead to put all my active components in.
– I started to code my first active component, the ActiveTextField component based on android.widget.EditText component from Android’s API. I haven’t encountered many difficulties to do it : I coded it taking JCSP’s AWT ActiveTextField as an example but replaced all the events, event handlers and listeners because JCSP was using awt.event, that is not available to me.
– I finally coded a small test app that just involves an ActiveTextField, a channel and a small CSProcess that just writes on the console the channel’s output. I attached the event to the ActiveTextField’s “addTextEventChannel” event handler.

So I codded all that… and I get no errors, no exceptions but a black screen on the phone and nothing in the console output… I am going to do some more testing to find where the problem comes from but it is really annoying because I don’t know at all where the problem comes from.

Supervisor’s comment:

We met on 9-910 to discuss the progress made over the summer holiday. Essentially, in the first instance there are three main aspects; PC to phone by Wi-Fi, phone to robot by Bluetooth and phone to PC of camera images by Wi-Fi. The last two are working albeit slowly. The real problem is the camera and image transfer. We discussed how the robot might be able to work autonomously without user interaction say inmoving balls to specific locations. We also discussed putting JCSPre on the Android phone. Suggested he looked at Alex Panayotopolous’ project on my home page. Also discussed how the image could be communicated as a set of deltas ( Arnaud had already thought of that). We did not fix a standard time as he has not yet got his timetable. For the next meeting suggest he reads around some of the ideas we discussed