Adam Schweitzer

Greenhorn
+ Follow
since May 26, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Adam Schweitzer

I am trying to implement zoom functionality on an ImageView, similar to the built-in Photos app on iOS (I don't have a physical android device to make a more suitable analogy). Pinch-to-zoom would be nice to have, but zoom on double-tap is essential.

I've tried some sample code (ex. http://android-journey.blogspot.com/2010/01/android-gestures.html), but this does not work for me, for some reason; none of the event handlers fire (I may be omitting something simple?).

Can someone point me in the right direction?

For troubleshooting purposes, I used sample code unmodified from the above link, on an Android 2.3 emulator in an application with android:minSdkVersion=7 and the following layout:
13 years ago
I should elaborate a bit.
In the emulator, if you have not clicked on the first textbox prior to typing, it works as intended. If you click on the textbox and then type, it does not.
When deployed on a real device, it does not work either.

I have worked around this issue by using a TextWatcher (via addTextChangedListener() method of EditText) instead of an OnKeyListener.. but I have no clue why I am experiencing this behaviour.
13 years ago
Hi,
Can someone help me with this? I don't understand why this doesn't work - even the HelloFormStuff tutorial uses essentially the same code..
13 years ago
I added an OnKeyListener to an EditText widget.. the problem is, this event handler never gets called when tying in the widget. And I don't understand why. Can someone explain what I'm doing wrong?

Here is some sample code to illustrate what I'm trying to do. All it is supposed to do is fill a second text box with the value of the first. But it doesn't. (Clicking on the button, though, does function as desired - and the two event handlers have the same code).



and the associated layout:
13 years ago
G'day mate! (Do Australians actually say this? I don't know!)

For a long time now, I have wanted to visit this great and unique country - the question has been when/how to do it. There is so much to see and do that I don't believe my three weeks of vacation time would be anywhere near sufficient to take it all in.

One option I am considering is a "working holiday" visa, which would allow me to live/work in Australia for up to one year (although only up to six months for any one employer).

The only issue with this is it is my understanding that most people who visit Australia on this visa end up working in the hospitality industry or picking fruit - neither of which hold any particular appeal for me. What I would like to do is find software development work (ideally working with an outgoing group of people who would be willing to show me the sites outside of work), but I am not sure how realistic a possibility this is.

What I would like to know is:
1) Is this feasible?
2) How should I go about doing this (ie. where should I look, would it be possible to line up my first job before I leave home, recruiters, job boards, etc)?
3) What sorts of things would help my chances (ex. certs)?
4) Any other advice..

Thanks!


14 years ago
Can anyone help me with this? (Maybe I should ask on an XSLT forum?)

Perhaps I didn't explain it well in my last post. Here is a bit more detail:


I am having a problem with trying to export an application which performs XSLT transformations as a .jar file. The issues are twofold:
1) The transformer looks in the wrong location for the included stylesheet.
2) The transformer does not look for the included stylesheet in a jar file.

Here is the relevant code:

code snippet:


stylesheet, s1 (location: stylesheets/s1.xsl):


stylesheet, s2 (location: stylesheets/s2.xsl):



ISSUE 1:
The code as written executes successfully, with expected results. The problem is when I try to change line (1) to be compatible with the stylesheet being in a .jar file:


When I execute the program, an exception is thrown saying that it could not compile the stylesheet, because it could not find s2.xsl. It is looking for it at the program root rather than in the stylesheets folder. If I move s2.xsl outside of the stylesheets folder, the program executes correctly. I do not understand why it is looking for s2 in the wrong place?


ISSUE 2:
When I export the application as a .jar file (with copies of s2.xsl in both places (why?) where it may be looked for), the program throws an exception when I try to run it. Instead of looking for s2.xsl inside the jar file, it looks for it on the file system.

Any ideas what I can do to fix this?

Adam
14 years ago
Well, the reason I'd like to have a single file is it makes things a bit easier and less prone to errors on the part of users (ex. if they don't copy all the necessary files). And I know in a Java EE context, there are .war and .ear files to bundle apps together. Anyway, not a big deal..

I have run into a problem, though, with replacing File's with InputStreams:

BEFORE:


AFTER:


In either case, I can successfully read the file. However, when I try to use the InputStream as an xslt stylesheet and perform a transformation using the Saxon XSLT processor, I get the following error:

Error at xsl:include on line 77 of file:/C:/Documents and Settings/aschweitzer/workspace/XMLPublisher/:
Failure reading file:/C:/Documents and Settings/aschweitzer/workspace/Common/variables.xsl: no more input

The relevant line in main.xsl is:
<xsl:include href="../Common/variables.xsl"/>

I don't understand why it is looking for this file in the wrong location:
file:/C:/Documents and Settings/aschweitzer/workspace/Common/variables.xsl

instead of:
file:/C:/Documents and Settings/aschweitzer/workspace/XMLPublisher/Stylesheets/Common/variables.xsl

Can someone explain this? This is only a problem when the stylesheet includes another one(otherwise, it works fine).
14 years ago
If I'm understanding you correctly, this means I end up with three files:
library.jar
referencedProject.jar
mainApplication.jar

Is there not a way to package this up so I only have one file in the end?
14 years ago
I have a Java application that I run using the Eclipse IDE. I need to export this such that my coworkers will be able to use it, preferably without having to install Eclipse as well. The problem is, when I export a jar file of the program, it does not work. I have identified two possible reasons why this may be so (I have been able to successfully distribute other applications that did not have these complicating factors):

1) The application links to another project in Eclipse. By default (am I missing a setting?), Eclipse does not include this when I export as a .jar file. The solution (workaround?) is to manually select this other project. This does not completely solve the problem, however, as the linked project uses a library .jar (the Saxon XSLT processor, FWIW) file which is not included in the application .jar no matter what I have tried.

2) The application reads from files contained in the project. This is fine in Eclipse, but not when I export - as these files (XSLT stylesheets, FWIW) are located inside the .jar file, and cannot be read (ie. (new File("Stylesheet.xsl")).exists() returns false).

How would I go about resolving these issues?

14 years ago
I bought the Sierra&Bates SCJP 5 book a couple of years ago (alas, I haven't actually gotten around to doing the exam yet.. ). I figure now that the SCJP 6 exam is out now, I'm better off writing that - but do I need to buy the new book (I'd probably go with the Sierra&Bates one again - I thought it was pretty good - unless there are some recommendations on better ones), or would it be sufficient to study from the SCJP5 book, and do a bit of reading/coding with the newly testable material (Console, NavigableSet/Map)?
Figured out what was going wrong - I need to read the file in using UTF-8 as well.

I had:
BufferedReader reader = new BufferedReader(new FileReader(inFile));
which appears to be what was mangling the UTF-8 characters.

replaced with:
BufferedReader reader = new BufferedReader(new InputStreamReader(new FileInputStream(inFile), "UTF8"));

It all makes so much sense now
16 years ago

Originally posted by Ulf Dittmer:
The degree Celsius character is \U2103 in Unicode, so it can't be represented in 8 bits. That means it will occupy two characters in the file. This is how UTF-8 works, and shouldn't cause a problem.


It's actually just the degree character - I guess my example was a bit unintentionally misleading.

The original XML file (generated by Adobe Framemaker) is encoded (or, at least, is declared to be encoded.. maybe that's the problem..) in UTF-8, and this character shows up fine in it..

[ UD: fixed URL ]
[ March 06, 2008: Message edited by: Ulf Dittmer ]
16 years ago
Here's the scenerio:
I'm modifying (really just doing some find and replace) and saving XML files (at this stage, they're just text files for all intents and purposes - I'm not using any XML APIs), which are then used as input for XSLT transformation using the Saxon 6.5.5 processor.

Here's the problem:
If I use the following code to write the file:
FileWriter writer = new FileWriter(new File(outDir, inFile.getName()));
writer.write(tempString);
writer.flush();
writer.close();

when I later go to do the XSLT transformation on one particular file (it doesn't show up on any others.. reason unknown) I get the following exception:
Error at byte 122254 of file:/C:/testboardno/test_in/c14404000mn024/c14404000mn024/WP130700.xml:
Error reported by XML parser: bad continuation of multi-byte UTF-8 sequence (code: 0x3f)
javax.xml.transform.TransformerException: org.xml.sax.SAXParseException: bad continuation of multi-byte UTF-8 sequence (code: 0x3f)
at com.icl.saxon.om.Builder.build(Builder.java:273)
at com.icl.saxon.Controller.transform(Controller.java:977)


I guessed that the problem is that the FileWriter wasn't outputting with the correct character encoding, as all of the XML files are declared as using UTF-8:
<?xml version="1.0" encoding="UTF-8"?>


So I tried replacing the FileWriter with the following code:
OutputStreamWriter writer = new OutputStreamWriter(new BufferedOutputStream( new FileOutputStream( new File(outDir, inFile.getName()) )), "UTF8");

And, in fact, this does solve the problem. The XSLT processor does not throw an exception. However, this creates a different problem. For some reason, whenever there is a "degree" character in the original file, ex:
�C
in the output, I get the following:
��C

Any ideas what's going on here, and how I can make this work?
BTW: Using java 1.4.2 on windows XP.
16 years ago
So I just picked up the Head First EJB book a couple of weeks ago. Perhaps not paying as much attention as I should have (one of the disadvantages of buying online.. can't browse through the book!), I didn't realize that it was published in 2003.. and hence uses J2EE 1.3 ( ).. what's worse, when I go to http://java.sun.com/j2ee/1.3/download.html, I cannot even download J2EE 1.3 ( )!

Two questions:
1) Where can I download J2EE 1.3? Alternatively, would a newer version be compatible with all of the content of the book?

2) Has the technology changed so much that learning EJB from this book is no longer worthwhile (I certainly hope not!)?
16 years ago

Originally posted by Sergio Tridente:
It compiles fine under java 1.5.

The only problem would come when trying to create an instance of the inner class: you'll need to explicitly use an instance of the outer class.

The following: MyInner m = new MyInner()

- Will work inside a non static method. It is interpreted as: MyInner m = this.new MyInner()
- Will not work in a static context.


Yup, that's all true..

It just seemed odd to me that the book said static methods in the same class as the inner class had to use the MyOuter.MyInner syntax, because MyInner should still be in the symbol table (or Javac's equivalent) and hence visible to the static method.

I believe this is an error in the book, and it's not in the "errata" post.