[Jonathan Engbrecht]

Terry,

Below find a good way to start the application on boot:

Writing the Startup Script

Having an application launch automatically on power-up is quite simple on the OCG. The easiest way to do this is first to write a Linux shell script that when executed launches all of the applications you want. A shell script can be created through making a new text file with extension “.sh”. At the top of this file include #! /bin/sh which signifies this as a shell script. Within the shell script add the command line components you want to run as you would in any shell script.

The shell script that you make should, by standard Linux convention, be placed in the /etc/init.d directory. This is where a lot of the important startup scripts and configurations are stored. After the file has been written test it out directly and make sure that all of the permissions on your directories are set appropriately. For more information on writing a shell script refer to one of the hundreds of references on the Internet.

Running the Script

In order for this script to run you must add this file to one of a few special directories that have scripts which are automatically executed on power-up. For custom built applications we recommend having your script be run from the /etc/rc5.d directory. Since we want the ability to enable or disable this script from starting on power-up without having to remove it entirely, we will use a symbolic link. You can think of this symbolic link as a file descriptor in the rc5.d directory that points to the script that we made in init.d. Having this symbolic link allows us to temporarily remove the link at some later time to stop the script from running while leaving the actual script it in the init.d folder so it can be enabled again in the future.

An important thing to note is that the name of the symbolic link you place in rc5.d must have a particular format. Since we are starting programs it must begin with the letter S followed by a number between 0 and 99, which determines when the script is supposed to run. It is also important that this number is not already used within the rc5.d folder. Typically we want our application to run as close to last as possible, but 99 is already taken in the standard build. We therefore recommend that your symbolic link start with S98. As an example, to create a symbolic link for a startup script called AppStart.sh use the following command:

ln -s /etc/init.d/AppStart.sh /etc/rc5.d/S98AppStart

After making the link you can try running it just like you would any shell script. After validating the symbolic link is good, the last thing to do is to try it out by simply rebooting the device. When the device comes back on your script should have run and any applications associated with it. For additional help refer to one of many articles about the Linux boot process on the Internet.

Hope that helps!

– Jonathan

[Jonathan Engbrecht]

Ian,

Here is an example of how to declare an array of these test classes:

Class[] tests = new Class[4];

tests[0] = MeasurementsSuite.class;

tests[1] = ProcessSuite.class;

tests[2] = TypesSuite.class;

tests[3] = UtilSuite.class;

Here is an example stubbed out suite class:

@RunWith(Suite.class)

@Suite.SuiteClasses({test.util.JSONObjectTest.class, test.util.ByteQueueTest.class, test.util.JSONArrayTest.class, test.util.CommandLineTest.class})

public class UtilSuite {

@BeforeClass

public static void setUpClass() throws Exception {

}

@AfterClass

public static void tearDownClass() throws Exception {

}

@Before

public void setUp() throws Exception {

}

@After

public void tearDown() throws Exception {

}

}

In this case there is no need to setup or tear down anything as this suite class simply calls a number of other JUnit test classes.

Here is an example JUnit test class:

public class CommandLineTest {

private static CommandLine instance;

public CommandLineTest() {

}

@BeforeClass

public static void setUpClass() throws Exception {

String[] args = {“Arg1”, “Arg2=Value2”, “Arg3=test=test=test”};

instance = new CommandLine(args);

}

/**

* Test of argumentPresent method, of class CommandLine.

*/

@Test

public void testArgumentPresent() {

System.out.println(“argumentPresent”);

String arg = “Arg1”;

boolean expResult1 = true;

boolean result1 = instance.argumentPresent(arg);

assertEquals(expResult1, result1);

boolean expResult2 = false;

boolean result2 = instance.argumentPresent(“FooBar”);

assertEquals(expResult2, result2);

}

/**

* Test of getValue method, of class CommandLine.

*/

@Test

public void testGetValue() {

System.out.println(“getValue”);

String arg1 = “Arg2”;

String expResult1 = “Value2”;

String result1 = instance.getValue(arg1);

assertEquals(expResult1, result1);

String arg2 = “Arg3”;

String expResult2 = “test=test=test”;

String result2 = instance.getValue(arg2);

assertEquals(expResult2, result2);

}

/**

* Test of size method, of class CommandLine.

*/

@Test

public void testGetNumberArgs() {

System.out.println(“getNumberArgs”);

int expResult = 3;

int result = instance.size();

assertEquals(expResult, result);

}

}

So the suite classes typically run the individual test classes or higher level integration testing. Then the suites or individual test classes are run in the main application, as demonstrated above. Also, if you are not doing this already I would try running a very basic test locally on your development platform. Let me know if this gets you any further! Thanks!!!

– Jonathan

[Jonathan Engbrecht]

Ian,

I actually used JUnit for developing the unit tests for the SDK. That said, I did not use ANT in this process at all. If you want to perform Unit or functional testing on the device, the easiest way to do it is using your existing development and build system. I did all of mine in NetBeans, but it should be the same for Eclipse or whatever you are using. All you need to do is create a new project called, AppTest or whatever you want to call it. Then add your application and the JUnit jar to this project as libraries. Next write all of your test classes and suites in the JUnit format using its built in classes and methods, etc… From the main method within your test application you will use something like the following:

Result results = JUnitCore.runClasses(tests);

printResults(results);

Where tests is an array of JUnit classes or test suites, see the JUnit javadocs for more detailed usage information. I have also included a sample of what printResults might look like below.

public static void printResults(Result results) {

System.out.println();

System.out.println(”

---

Test Results

---

“);

if (results.wasSuccessful()) {

System.out.println(“All Tests Passed!!!”);

System.out.println();

} else {

System.out.println(“Total Failures: ” + results.getFailureCount());

System.out.println();

}

List<Failure> list = results.getFailures();

for (int i = 0; i < list.size(); i++) {

Failure failure = list.get(i);

System.out.println(“Failure: ” + (i + 1));

System.out.print(failure.getTestHeader());

System.out.println();

switch (printLevel) {

case NONE:

break;

case MESSAGE:

System.out.println(failure.getMessage());

break;

case EXCEPTION:

System.out.println(failure.getException());

break;

case TRACE:

System.out.println(failure.getTrace());

break;

}

System.out.println();

}

}

Here printLevel is an Enum that I set as part of a command line parameter to detemerine the level of debug I want on the test output.

Once you have developed and compiled your test application using your existing development environment, you can copy it to an OCG and run it just like any other Java application. Let me know if this was helpful or what you were looking for! Thanks!!!

– Jonathan

[Author]

Posts