Site Sponsors:
XML IO Using Generics - Before Java 1.7 
In as much as we often teach students who are using an older version of Java, we decided to put together another demonstration. -An example that can readily be targeted for earlier versions of Java.

Remember - the use of Java Serialization is NOT required. In order to use the XML serialization technique, all we need is a POJO!

First, the I/O Demonstration (note that checking for nulls (etc) has been omitted so as to enhance conceptual review):

package com.soft9000.file;

import java.beans.XMLDecoder;
import java.beans.XMLEncoder;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.FileInputStream;
import java.io.FileOutputStream;

public class XmlClassIO<T> {
public String sLastError = "";

public boolean write(String fileName, T ref) {
try {
XMLEncoder encoder = new XMLEncoder(new BufferedOutputStream(
new FileOutputStream(fileName)));
encoder.writeObject(ref);
encoder.close();
return true;
} catch (Exception ex) {
this.sLastError = ex.getMessage();
return false;
}
}

public T read(String fileName) {
try {
XMLDecoder decoder = new XMLDecoder(new BufferedInputStream(
new FileInputStream(fileName)));
T result = (T) decoder.readObject();
decoder.close();
return result;
} catch (Exception ex) {
this.sLastError = ex.getMessage();
return null;
}
}
}

Next, the testable class:

package com.soft9000.file;

import java.util.List;
import java.util.ArrayList;

public class BigBadFoo {

private ArrayList<String> list = new ArrayList<String>();
private String foo;

public BigBadFoo() {

}

public void setList(List<String> someList) {
this.list = new ArrayList<String>(someList);
}

public List<String> getList() {
return this.list;
}

public void setFoo(String string) {
this.foo = string;
}

public String getFoo() {
return this.foo;
}

public boolean equals(Object obj) {
if (obj instanceof BigBadFoo) {
if (super.equals(obj))
return true;
BigBadFoo ref = (BigBadFoo) obj;
if (foo.equals(ref.foo) == true) {
return list.equals(ref.list);
}
}
return false;
}

}

Finally, the test case:

package com.soft9000.file;

import java.util.ArrayList;

/**
* Proof of concept.
*
* @author Profnagy
*
*/
public class Main {

public static void main(String[] args) {
ArrayList<String> SomeList = new ArrayList();
SomeList.add("one");
SomeList.add("two");
SomeList.add("three");
BigBadFoo foo1 = new BigBadFoo();
foo1.setFoo("12345");
foo1.setList(SomeList);
com.soft9000.file.XmlClassIO<BigBadFoo> io = new XmlClassIO<BigBadFoo>();
io.write("test.xml", foo1);

BigBadFoo foo2 = io.read("test.xml");
if(foo2.equals(foo1) == false) {
System.out.println("Serialization Failure.");
System.exit(-1);
}
System.out.println("Serialization Success.");
}
}

Notes


The above has been designed to be cut-and-pasted.

Be sure to re-format the code after doing so.


Enjoy,

-Rn

Student Note: Regression


While fine for illustrative purposes, over time things can change.

In as much as we might want to be sure that things actually break when they should, it is always nice to add-in a few "should break" tests, as well. Such will help us a-lot as we perform feature regression tests, over time:

Here is a simple example:
      
foo2.setFoo("shazam");
if(foo2.equals(foo1) == true) {
System.out.println("Assignment/Equality Regression.");
System.exit(-1);
}


[ add comment ] ( 2093 views )   |  permalink  |  related link
XML IO Using Generics 
When it comes to reading and writing Java-hosted classes, why not use generics?

package com.soft9000.file;

import java.beans.XMLDecoder;
import java.beans.XMLEncoder;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.FileInputStream;
import java.io.FileOutputStream;

/**
*
* @author profnagy
*/
public class XmlClassIO<T> {
public String sLastError = "";

public boolean write(String fileName, T ref) {
try {
XMLEncoder encoder = new XMLEncoder(new BufferedOutputStream(
new FileOutputStream(fileName)));
encoder.writeObject(ref);
encoder.close();
return true;
} catch (Exception ex) {
this.sLastError = ex.getMessage();
return false;
}
}

public T read(String fileName) {
try {
XMLDecoder decoder = new XMLDecoder(new BufferedInputStream(
new FileInputStream(fileName)));
T result = (T) decoder.readObject();
decoder.close();
return result;
} catch (Exception ex) {
this.sLastError = ex.getMessage();
return null;
}
}
}


When our classes adhere to a few common conventions, not only do we no longer need to use 'Serializable', but we can avoid creating the usual set of encoders / decoders, as well.

BigBadFoo



For example, suppose we have a class (BigBadFoo) to save in the XML. Better still, let's suppose that the class has used an ArrayList: (*)

        ArrayList<String> SomeList = new ArrayList<>();
SomeList.add("one");
SomeList.add("two");
SomeList.add("three");
BigBadFoo foo = new BigBadFoo();
foo.setFoo("12345");
foo.setList(SomeList);
com.soft9000.file.XmlClassIO<BigBadFoo> io = new XmlClassIO<>();
io.write("test.xml", foo);

By upcasting the getter / setter to use List, even collections can be quickly converted to XML:

    public List<String> getList() {
return list;
}

public void setList(List<String> list) {
this.list = new ArrayList(list);
}

Here is what the entire class looks like:

public class BigBadFoo {

private String foo = "noneya";
private ArrayList<String> list = new ArrayList<>();

public BigBadFoo() {
}

public String getFoo() {
return foo;
}

public void setFoo(String foo) {
this.foo = foo;
}

public List<String> getList() {
return list;
}

public void setList(List<String> list) {
this.list = new ArrayList(list);
}
}

Here is what the above XML-test writing of BigBadFoo looks like:
<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_04" class="java.beans.XMLDecoder">
<object class="console01.foo">
<void property="foo">
<string>12345</string>
</void>
<void property="list">
<void method="add">
<string>one</string>
</void>
<void method="add">
<string>two</string>
</void>
<void method="add">
<string>three</string>
</void>
</void>
</object>
</java>


Beware the NULL?


Curiously - while completely understandable - it seems that saving default-objects will do little in the XML. Hence, while we might righteously feel that the word "noneya" (the initialized default) could appear somewhere, doing things like:

        io.write("test.xml", new BigBadFoo());

Results in absolutely nada being saved to the XML:

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_04" class="java.beans.XMLDecoder">
<object class="console01.BigBadFoo"/>
</java>


So while a default object will indeed be returned by the decoder, note that if our defaults ever change, that we will loose any previously-defined default value(s).

-It's an .isNull() type of 'thang.


Enjoy,

-Rn

(*) Before Java 1.7?


Note that if we are not using Java 1.7, then we will have to fix that new "Diamond Notation" (as used above.)

So to make the examples work on previous versions, simply add the "String" back in so as to change ArrayList<>, to ArrayList<String>().

After adding the string - and thru the miracle of type replacement on archaic versions - all will work just as well elsewhere.

Caveat Outsourcing?


Moving forward, be prepared to note the ever growing host of new, anal-retentive, style-not-grammar warnings & errors. Designed to suppress personal style, freedom of expression, and change?

[ add comment ] ( 2090 views )   |  permalink  |  related link
Jacked-in WiFi Support: A Fix for ALL Operating Systems 
Anyone who has been loving Linux for any length of time knows the pattern: You have a cool device. You hack the kernel to get it working, only to have it fail on an upgrade.

Hack, upgrade, fail; fail, upgrade, hack. --It is enough to make you want to go back to CP/M... Then, one day, just when you are considering going back to Windows ... lo and behold, on your next upgrade, everything simply works ... just great!

You feel all fuzzy-warn inside.

It is a religious experience.

You donate to your favorite Open-Source Project. (2 out of three?)

WiFi Woes


That is how WiFi support on Linux USED to be. Indeed, when it came to running WiFi under Ubuntu, a few years back the NDIS Driver threatened to make all WiFi as easy to use as the NE2000 did for the wired-world.

Then suddenly - for reasons best not to discuss here - ubiquitously easy WiFi support went the way of the NeXTStep Computer. --Today, when it comes to setting-up far-too-many a wireless adapter, the Linux world has devolved back into the stone age. Far too often we are left to Google, point-and-grunt, gedit then restart ... (if not gcc, make, and reboot.)

Nuts!


So it was with a recent upgrade: In as much as we had coaxed our Atheros WiFi Adapter into working on 10.04 LTS (without so much as a #include), we pretty much assumed that the upgrade to Ubuntu's 12.x LTS would at least preserve our 10.x hacks. --Indeed, in as much as the change was limited to our /etc/network/interfaces File, one might reasonably - perhaps - hope for some ifconfig wlan0-driver continuity?

Yea, well .... NOT!

A New Approach


Tired as I was from hacking the kernel, let alone 'Googling for yet more inane speculation on how to ever-fix the same problem (a problem that only seems to be getting worse with every upgrade,) we instead opted to save some time & simply disable the wlan0 entirely. We then struck out to find an Ethernet / RJ45 Wireless Adapter.

Requirements


While at-home and in-the-office any wireless bridge-device would do, for many of us mobility is important. We want a small, discreet appliance. One that would look to the kernel like a simple, plain-old eth0 network.

No muss. No fuss. No driver support! -Something we can hang from a ceiling fan when the signal is bouncing off of a solar flare (or vice versa :)

After a few failed attempts at an array of devices (cheap hardware, quick return-after-failure,) we discovered the ASUS 6-in-1 Wireless Adapter.





I suppose what I love most about this adapter (AFTER the fact that it just plain-old works) is the above size. Next closest to that appreciation, however, is the ability to either power the device via USB (communication is thru a classical Ethernet / RJ45 Port, remember) ~or~ via a nice little, yes-it-is-included, 125 VAC converter.

Why the power converter, you might ask? --Because of our "ceiling fan" requirement.

Indeed, as I blog this, I am doing so thru the device hanging off of a 14-foot Cat5 Cable. -By using that 125VAC option, I have been able to string the WL-330N3G from the nethermost reaches of my own back-yard, far away from the computer. -Like the star on the Christmas tree, it is hanging off of a nearby palm tree. (To be sure, we also tested the USB power option, as well. Both work great (solar-flare not included).)

Conclusion


So if you - like me - are tired of doing the "WiFi Wriggle" (or is it a cringe?) every time we upgrade, then consider turning that built-in WiFi adapter off. Disabling a dysfunctional wlan in the /etc/network/interfaces file will eliminate that 3 - 4 minute boot-up delay.

#auto wlan0
#iface wlan0 inet dhcp
#wireless-ap any
#wireless-channel auto
#wireless-essid any
#wireless-mode managed
#wireless-rate auto

Not only will using that RJ45 connection virtually guarantee universal OS Support (even though Linux is not listed on the box (apparently for SOFTWARE CD reasons?)), but using the ASUS WL-330N3G 6-in-1 Wireless-N Mobile Router gives us a (1) Wireless Router (2) Wireless Access Point (WAP) (3) Universal Repeater (4) Ethernet Adapter (5) Mobile Hotspot and (6) A 3G WiFi hub for ad-hoc network with our buddies, as well.

Sharing is caring!

-Rn

(Oh yea: Because we are using the eth0, this "dump the wlan0" driver-strategy works just great on our virtual machines, too!)

Blogatchalater ...


[ add comment ] ( 3059 views )   |  permalink

<<First <Back | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | Next> Last>>