How can I get the active application title using Java in OSX? - java

I'm writing an application to collect information about a users behavior in front of the computer in order to study usage patterns. I've looked into JNA but can't find any information about how to capture the active application for platforms other than Windows.
Are there any libraries (such as JNativeHook) to capture the active application in OSX?
I would like to capture the active application rather than the active window title in order to avoid integrity concerns for the user study. Also, I know that Java is not really meant to work outside the JVM and capture this sort of things, but since there are a lot of database interaction and a limited amount of time Java was chosen and the project is completed except for this component.

Sure, for a "user study" ;) ;)
In Objective-C, you would do something like:
NSWorkspace.sharedWorkspace().activeApplication()['NSApplicationName']
I may be off on the exact code, as I don't have access to a Mac right now, and doing that from memory/APIs, but I think that is close. The important starting point is NSWorkspace. Now, how you go about calling that using JNA, I haven't the foggiest.

Related

If Java is truly platform independent, why is there no one-for-all clearConsoleOutput libraryMethod?

I wanted to write an application for windows/mac/linux and I chose java because a java developer friend told me Java is platform independent.
I came to a problem where I wanted to clear the console (to make the reading easier on the user).
I've tried System.out.flush(); and Runtime.getRuntime().exec("cls");.
It seems the only real solution is to use a hack (and smelly code is bad) - Java: Clear the console (check "Dyndrilliac" answer).
The reason using this hack is bad, as other users have commented on "Dyndrilliac" answer, what happens when Microsoft or Apple changes the command name from "cls" or "clear" to something different? It pretty much breaks your application and you get an error (such as "command not recognized") from the OS Company.
So my question is: did Java decide not to implement a library that handles clearing console outputs due to keeping it up to date whenever Windows/Macs/Linux decides to change it's command names? Or did Java implement a library for handling this, and I just can't find it?
Java is independent in the way that it's not run directly on your OS. java run on jvm (java virtual machine) and because of that it should work the same in all OS. But the console that you print to it's the specific OS console and therefore, every OS will have it's own clear console command (because it's not the same console). You can build program with UI (using swing or other library) And control your output, or use some technics like in the post you linked to, it should work fine.
A) because there are many many more platforms java is running on that might have extremely different views on what a console is.
B) in order to give decent tooling for console based applications, you need much more than simple "clear" commands (think nurses here!)
And finally: when Java came into existence, anything was about applets and ui. Probably nobody wanted to invest much energy in supporting "legacy style" command line programming. (that last point is probably closer to an opinion than a hard fact).

Alternative technologies to replace applet?

I have an (unsigned) applet that let you draw a logic circuit and test it on-screen (a bit like Electronics Workbench), and it then serializes the circuit (the internal form, not the visual representations) and sends it to the server where a bunch of automated tests are run and a performance report is produced. This is a small but crucial part of a much larger web app.
However, the latest Java plug-in now says this:
Running unsigned applications like this will be blocked in a future release because it is potentially unsafe and a security risk.
Now, self-signing it will still apparently work (for now), but then the code runs OUTSIDE the sandbox, which strikes me as a stupid way to do things, even though my code is of course completely bug-free! (Can I interest you in buying a bridge?) Reading further on the Oracle website I see this:
The platform will not deny the execution of Java applications... Future update releases may include additional changes to restrict unsafe behaviors like unsigned and self-signed applications."
(Which sounds like it means "Future updates will deny the execution of Java applications" -- unless you pay money to Thwaite or Verisign on a regular basis AND expose users to code running outside a sandbox.)
They also say
"Even the smallest changes in user experience are sometimes troublesome".
(No kidding.)
"We have considered how changes affect user experience. Given the current climate around Java security in the browser, code signing is a valuable security control for protecting Java users."
Well, I don't see how I can continue using Java under these circumstances. The goalposts have been moved (again), and now I'm looking for a different football team... or more precisely, I'm looking for an alternative technology that will let me continue to do what I do now: drag & drop circuit elements, create connections by dragging between input and outputs or other connections, and finally take the internal form of the diagram and squirt it to the server in a form which can be decoded and exercised, preferably by exactly the same code that created the diagram to avoid versioning headaches. And something which is safe, which can't trash the local filesystem or whatever just because I've signed it.
Can anyone suggest where I should be looking next, now that Oracle has made my life a nightmare?
(Which sounds like it means "Future updates will deny the execution of Java applications" -- unless you pay money to Thwaite or Verisign on a regular basis AND expose users to code running outside a sandbox.)
A signed applet launched using JNLP can still be sand-boxed.
But if you really wish to avoid it..
I think what you described can be provided using JavaScript for the logic and and an HTML 5 canvas for the rendering.
I would avoid Flash, since it is also susceptible to security bugs. It would be like digging yourself a brand new hole to get trapped in.
I can't comment on what you found about applets, since I never wrote one.
If you want to move away from them, maybe your only option (while staying with Java) is go for web applcations, where the code is most on server-side and you interact with your software directly in your browser. On the client-side javascript (and js-related libraries like JQuery) is used, though I can't elaborate about it more since I'm don't know the Java EE stack very well yet.
I'm not sure if you can get 100% the same user experience as you currently have in your applet, above all for an electronics application. But it may offer the highest code-reuse of most of your Java classes.
I've used Vaadin, it's a framework that moves almost all your coding to the server-side (you only need to code the client side if you want to create addons). I've heard about Zk too, but I've never used it, so I can't say anything about it.
You can still run unsigned java applets in your web pages if you block your Java plugin in the browser to the version SE 7 U11 (jre-7u11-windows-i586.exe) Of course you will have to block automatic Java update with "C:\Program Files (x86)\Java\jre7\bin\javacpl.exe"
I hop you can survive for a while this way, before you find an alternative to JAva applet.
In HTML5 the tag to call an apllet is now object and the syntax is a bit different:
<object codetype="application/java"
classid="yourApplet.class"
codebase="http://www.yourserver ..."
archive="YourJarFile.jar"
width="x" height="y">
<param name="paramName1" value="paramValue1"/>
<param name="paramNamei" value="paramValuei"/>
</object>

Auto-update of Java application converted to a Windows installable

I found a lot of discussions around this point but speaking either of a Java program running from the jar (in this case it is easy to replace it) or a C# application (I do not have knowledge on C#).
I use a tool (install4j, ..) to generate an installable file for Windows from the jar of my java swing application. My product installed and running on Windows should be able to "auto-update" itself, so I must have a component in my application that checks online if a newer version was to download and put in place of the currently executing.
I do not know how my application is installed in Windows (where are put the files? in one place? ... ) So what can I do to replace the current version being run with a new version (probably from a new installable file télchargé in this case) ? what's the best way?
how can I hide the questions like "do you accept ...?" and keep the original configuration during the update?
The problem for me is that my client wants/does not necessarily install java
Use the Deployment Toolkit Script to ensure the client has a suitable minimum version of Java installed. Then deploy it using Java Web Start to provide auto-update. I realize you don't want to make the client install Java, but you might be making the client install Windows if you make an executable. You'll typically lose more users by forcing them to install Windows, than by forcing them to install Java.
Now, when I give this advice to some people, they say words to the effect:
But my client only uses Windows OS! It will never be run on Mac OS or Linux/Unix.
And to that I would point out:
OK fine, but it seems yo are trying to make a left-hand turn at a right turn only intersection. If you need to turn left, you should have done that 6 blocks back.
What I mean by that is: Windows has its own languages and IDEs specialized for Windows. Being a language designed for Windows would mean it has:
Better ways to delve into the OS. Java keeps its functionality to a core set of functions that can be reliably supported across all major platforms. Anything beyond that requires native code.
Faster development time for any GUI elements. Java GUIs need to be designed using layout managers which are harder to learn and not conducive to Drag-and-Drop GUI design, which can be much faster.
A Windows based language probably has a slew of APIs and tools for providing auto-update, or if not, more free or reasonably priced 3rd party APIs for that.
..there are customers who imposed to not install java..
There is something you don't seem to understand. The GNU Compiler for the JavaTM Programming Language compiles code to natives. That is the only way to 'turn a Java app. into an executable. The GNU Compiler..
..supports most of the 1.4 libraries plus some 1.5 additions.
It does not even claim to support all of Java 1.3.
There are other utilities to install Java apps. with a private JRE. It might seem the JRE installation is invisible to the average user. But the power user would not be fooled. E.G.
Look and Feel
A Swing based app. using the Native Pluggable Look and Feel might look 'much like' a Windows app., but many people can still tell the difference. Swing does particular components differently to native Windows components (most notably JFileChooser, but there are others), and although the rest of the components look a lot like Windows equivalents, they are not exactly the same. Even the AWT based FileDialog looks different to the Windows file dialog.
Security
If the user has a problem with their PC and decides to kill a misbehaving app. they might type the following command sequence to bring up the Task Manager: Ctrl Alt Del
Even most non-power users know that key combo.
Now, let's say I am a potential customer that thinks 'Java is insecure - I don't want it on my PC'. Your app. comes along, I look at the box, no mention of Java. Good so far. Look at the one or two screenshots of it on the back of the box - looks much like a Windows app., OK.
So I fork out $24.95 for it.
I get it back to the office, install it and run, thinking:
It has an odd feel to it, but I'm too busy now, I'll check it out later.
Then I go surfing off to the net, visit a site infected with malware, and that malware causes MS Word to lock up. So I go to kill MS Word in preparation for restarting it, but.. As I'm scrolling down the available processes I notice.. Java is running.
What the huh..?
I immediately kill every Java process and see.. your app. drop off screen.
Let's go even further to assume the Malware (that is still running) goes on to cause $2000 damage to my hardware & wipes the client database I spent 3 years putting together ($50,000 loss).
I would get on the phone immediately to my lawyer and take you to court, suing you for the sum total of $1,052,024.95.
Later, in court:
Judge: What is the million collars for?
Me: Mental stress, your honor. The defendant lied to me and now I have become paranoid. Since that malware was installed, I've lost my business, my home, my wife and my peace of mind. It has caused me to become deeply depressed and I am experiencing suicidal thoughts.
Who do you think the judge is going to side with? Do you really think you can prove that your app. was in no way responsible for the problem?
Sure, you can put a disclaimer on the box:
No claims of responsibility, use at own risk.
But there are any number of US states as well as other entire countries, that will toss that entire End User Lisense Agreement right out the window and hold you responsible.
What I'm getting at, is that you are taking a huge legal risk to pretend that a Java app. is anything but a Java app. So don't do that!
I am also very keen to know that, as per my knowledge, I deployed my application using JNLP (java network launch protocol) after signing your jar file, Client's jar itself replace with the newer version.
The confirmation question "Do you Accept" in JNLP is because of the certificate windows security and JVM certification didn't recognize that.
here is tutorial for JNLP
http://www.mkyong.com/java/java-web-start-jnlp-tutorial-unofficial-guide/

Running The JVM From Within An MXML Component

Thinking outside of the box here...
What possible basic approaches could be taken in an effort to create a Flex component that could run Java?
I know I can easily use flex to browse to or launch a Java app, but there are things I can only do if I can run the Java from WITHIN an MXML Component.
I the strictest sense, I know it's not impossible (ie: if you had all the source code for flex and for the jvm), but what's the least impractical means to this end?
Edit:
Lots of people are interested in the reason WHY someone might want to do this. I see it as irrelevant to HOW to do it, but here goes: I have over 100 proprietary pixel-reading windows programs that I could port to Mac in this way, much easier than any other way. But instead of arguing the premises, the winning answer will ignore the reasons why, and focus on the HOW.
Showcase your creativity.
This sounds crazy insane to me. My answer is to not go down this route. It may be a fun technical challenge for fun; but has little practical value that I can see.
Answer the question, Why would you want to run a JVM inside a Flex app?
Also, How would you use a Flex App to browse or launch a Java App? As best I understood, the security sandbox of the browser prevents you from launching other local applications.
I don't believe you are correct about not being able to accomplish certain things you "can only do if I can run the Java from WITHIN an MXML Component". With proper communication set up, you can have the Applet and the SWF simply communicating with each other through an external set of processes.
The easiest way to accomplish this is to "fake it". Load a Java Applet (This should be possible by use of the SWF's ExternalInterface API -- generate the Object tag and add it to the HTML around the swf. To make this even more convincing, use CSS to have to Applet appear "on top" of the swf. ) and have it communicate with the original swf through JavaScript calls. If that is not possible, then it may be possible to have the Java Applet generate some form of pseudo-server which the swf could then communicate with.
If neither of those work, then there is always the SWF bytearray syntax. It would need to load a ByteArray, manipulate the internal data, and then send it... somehow.
A while back I prototyped something like this. I exposed a window / native app via a VNC server and then used an open source VNC client library to connect to the VNC server. It was totally hacky but it worked. Performance was not great but was usable. Here is the Flash VNC client library I used:
http://www.wizhelp.com/flashlight-vnc/index.html
I'm with Flextras, you need to explain why before a reasonable solution can be proposed.
Unreasonable solution:
Implement the jvm in AS3. Read jars in as bytearrays. Pass the bytearrays to you new jvm.
Reasons for unreasonableness:
Implementing even a partial jvm would be at least thousands of man hours of work.
Running a virtual machine inside of Flash's already (relatively) slow vm would be like riding a golf cart that's being towed by a tortoise: either one by itself would be faster.
You can interface between Air & a Java app using merapi (although that's just communication, not actually running the api inside air)

android internals and memory/processor constraints?

I'm considering creating a screen reader for Android. My questions are as follows. One how much of the internals of Android are exposed through the Java API? I'm looking for things such as system wide notification when text is displayed, notification of a new application being launched, etc. I'd rather not have to modify the kernel source and only allow my app to run on a developer phone. Two, how much processor and memory are left over on the G1 assuming no applications running? Three assuming average use of applications on the phone how much processor and memory are left?
More info
I'm aware that applications should not be designed to work on a specific phone. I picked the G1 because it's the most popular phone currently running Android that I know of. I am looking for lower end system specs that my program would have to fit in, it may run great on a netbook with Android installed but use to much memory and processor to run on most Android handsets.
Update:
There are now two screen reader projects that use Android 1.6, they can be found at
http://google-opensource.blogspot.com/2009/10/talkback-open-source-screenreader-for.html
http://spiel.thewordnerd.info/
AFAIK, screen content (text, graphics) of other apps will for security reasons not be exposed in Android. Otherwise one could grab contact info or whatever personal information gets displayed and harvest that for malicious purposes. So developers currently cannot create an Android app that speaks the text displayed by another application, nor capture the screen. This situation is different from Microsoft Windows on the PC, where applications can do pretty much anything they like, such that the user must decide for himself whether the source of any given application is trusted.
Sadly, there is still no screen reader for Android on the market, so it would be great if you or someone else could create it, but it looks like only a direct arrangement with Google could provide the level of trust needed in view of the above security limitations. Since Google is actively working on improving the TTS and integrating it into Donut, it would seem a fairly simple extra step for them to create a basic Narrator-like (as in Windows) screen reader, or offer a similar touch-based accessibility solution as with VoiceOver on the iPhone 3G S.
Best regards,
Peter Meijer
The vOICe for Android
http://www.seeingwithsound.com/android.htm
(1) Depends on what you are looking for. You better check for yourself. I am not ware of any assistive technologies in place, but I wasn't looking for them either.
Regarding the two specific capabilities you asked for:
(a) Notifications are part of the API.
(b) I am not aware that you can be notified on applications being started.
(2/3) I don't the general amount of RAM that is available for apps, but I can give you an practical answer. Your app's process will be killed if it tries to grab more than 16MB.
I don't know the exact clock speed, but on the android-dev list it was mentioned that the G1 doesn't run at full speed. The rationale behind it is that among other things more speed would run down the battery much more quickly.
Just another practical matter regarding this question. If you want to discuss the constraints go to the android-dev list.

Categories

Resources