Site Sponsors:
XML Serialization for Java 
I wanted to share the following article - it is an excellent overview of the history of Java Serialization as well as an unusually good overview of using XML with JavaBeans.

Along the way, Mr. Winchester also whets the appetite for learning more about using XML for the serialization for non-JavaBeans-conforming objects by using delegates.

Upon reflection (pun intended), the article will also provide the student with an understanding of the assessor / mutator refactoring operation of NetBeans & other popular Java IDE's:

[XML Serialization of Java Objects]
"Java serialization was initially used to support remote method invocation (RMI), allowing argument objects to be passed between two virtual machines. RMI works best when the two VMs contain compatible versions of the class being transmitted, and can reliably transmit a binary representation of the object based on its internal state."

NOTE: Students unfamiliar with JavaBeans might also enjoy reading the [Wikipedia JavaBeans Page.]




[ add comment ] ( 2184 views )   |  permalink  |  related link
Cognetic Word Lists 

The Problem


They annoy everyone - people who think they are smart by putting a few words together, then handing out a do-noting web site to sell the combination. Doh!

Cyber Nuts


No matter if they are grabbing your ideal name before you think of it (cyber squatting), or after you release it (cyber poaching), the one thing these nut cases have in common is that they have absolutely no intention of actually doing anything with the URL. Indeed, many are merely squatting on the name, hoping to sell it back to us at some point in time.

--Personally, I hope they hang onto those names forever ...!

Cognetic Word


In as much as so many of my friends and I have lots of neat products and web sites we want to share, we thought it high time to release a little tool I wrote years ago. I used it to help put together many of the web and other names you might have seen used here.

Cognetic Words


For the moment we decided to host the "Cognetic Words Project" at SourceForge.net. The official description reads:

"This tool allows us to mix phrase lists together. The results can be used to create memorable web site names using 'Cognetic Word Lists' -Sniglets designed to defeat the name-hijacking of URL squatters, hackers, & other menaces to on-line innovation."

Like many a NOJ these days, this tool uses Java. Will work anywhere... even in your browser.

Enjoy!

-Rn



[ add comment ] ( 2051 views )   |  permalink  |  related link
Java Threads in Android 

Android Threads


Those looking to port threads to Google's Android Operating System are often frustrated: While the classic thread classes are there, using threads in your application can cause some pretty tough-to-debug problems.

Indeed, while 'googling around the 'net, one is often told not to use threads. We are told that using a Handler is better.

While using handlers is sage advice for supporting small lightweight duties, sometimes you just want to use a little thread, anyway. Indeed, as processors, battery, and RAM become less and less of an issue in our pockets, many lean-and-mean anti-thread discussions sound much like the CGA -v- VGA display-support discussions we had at Informix while writing Wingz in the early 1990's. When all is said and done, it seems that - at the moment - most technical limitations simply fade away...

The best reason why most use an honest-to-goodenss thread on android is to do heavier number crunching. By doing computer-intensive work away from the main user experience, we all know that things simply work better. (Even in user interfaces it seems, nobody likes a jerk! ;-)

Thread Hangups


Typically, one is crunching data for a reason: To eventually display something interesting. For this reason, one of the first head-scratchers we encounter when using a thread in an Android App is how it can completely trash an application. In fact, the most certain way to lock your 'App occurs whenever another Android Thread touches the GUI API in any way, shape, or form.

Consider the following:


import java.util.Timer;
import java.util.TimerTask;

public class TimeTicker extends TimerTask {

Date date = new Date();
Date dateLast = new Date();
private boolean bRunning = false;

@Override
public void run() {
dateLast = date;
date = DateX.GetToday();
if (bRunning) {
mainActivity.setDialogResult(DateX.FormatRfc822Date(date), iId);
}
}
}


In this example, our standard Java TimerTask implementation is running every second (not heavy-weight, I know - but it is the classical "hello world" example in the timer world.) Whenever we want it to send a timer event, it will do so using the setDialogResult() of mainActivity.

All well and good.

Once inside of mainActivity, we can easily update a few basic elements. When we try to invalidate the drawable surface to show the update however (a GUI function) at the time of this writing, things will go boom:


public void setDialogResult(String sResult, int iId) {
switch (iId) {
case BUTTON_MARK:
{
this.vtBanner.sText = sResult;
this.invalidate(); // BOOM!
}
break;
// ...
}
}


Maddeningly, until we understand Android's thread model, the reason things suddenly go south is not readily apparent. Indeed, if we use an Android Dialog Activity, things work just fine!

By way of example, the following View.OnClickListener will update the GUI via that same setDialogResult() member function, just as easy as expected:


public void onClick(View arg0) {
dialog.bOkay = bSetValue;
this.dialog.dismiss();
if (bSetValue) {
Editable eString = dialog.editTextName.getText();
mainActivity.setDialogResult(eString.toString(), iId);
}
}


It can even Toast!


public void setDialogResult(String sResult, int iId) {
switch (iId) {
case BUTTON_NEXT:
{
// Toast t = Toast.makeText(this.getContext(), sResult, 600);
// t.show();
this.vtBanner.sText = sResult;
this.invalidate(); // Works Fine!
}
break;
}
}


Why can one listener-laden Activity manage the Canvas, while even the lightest Thread, cannot?

One Thread to Draw Them All


Believe it or not, the reason why one class is blessed and another is cursed is simple: In the above example, even though the code is written as part of the main Activity class, our TimerTask is still effectively executing the code. Unfortunately, the timer running the TimerTask is not part of the main activity thread. It is another thread.

The Dialog, however, is a completely different case. Because Android Dialogs are Views, they will all share the same, common, execution thread.

Insidious, no? ( Surely knowledge is power !-)

Fortunately, the Android Framework 'wizards foresaw our dilemma: By allowing us to enqueue certain whole-life methods on-the-stack, the problem of having a non-GUI thread manage a GUI-Thread's ... uh ... gui ... is very well supported, indeed:


public void setDialogResult(String sResult, int iId) {
switch (iId) {
case BUTTON_MARK:
{
this.vtBanner.sText = sResult;
this.postInvalidate(); // Another Thread = NOT thread safe!
}
break;
case BUTTON_NEXT:
{
this.vtBanner.sText = sResult;
this.invalidate(); // Another Activity = Same GUI Thread
}
break;
}
}


-We simply need to be sure that non-GUI threads never use GUI access routines directly. -It is a thread safety thing. (i.e. Even relatively speaking, providing millions of synchronizing gatekeeper operations would slow everything down. The logic here is that it is better to make the developers work a little, than to make the computer work-a-lot. (yea, that logic sounds a lot like another ancient (1970!) pro-assembly-language argument to be sure... but we like Java, C++, and C# anyway. Computers got a whole lot faster, cheaper, and better!))

Want to discuss the slow death of java.util.Vector, anyone? (--me neither :)

Executive Summary


To conclude, when it comes to using Java's classic timers & threads, we can indeed do so ... even on Android - with relative impunity. Nevertheless, when doing so we must remember to always manage those secondary threads carefully. No mater what mechanism we may cobble-together to update Android's display, we must always be sure to access that Android UI only from the main user-interface-thread!

For more information on threading and thread-related issues, you can read more under the painless threading topic on the Android Developer's Site.

[ add comment ] ( 3327 views )   |  permalink

<<First <Back | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | Next> Last>>