I am working on a way to rapidly mock up Android applications using Android Studio, i.e., to rapidly prototype Android applications on the fly, and little snippets of code help to make this happen. For instance, this snippet of code shows how to show a popup dialog to prompt a user to enter information into a text field:
I was going to write a little application to let me annotate my MacOS screen during presentations, but the Ink2Go product looks like it does exactly what I was thinking. As I’m creating a video presentation, such as when showing how to write some Scala or Android code, I want to be able to draw on the screen, such as writing text, arrows, circles, and boxes to highlight parts of the screen. Ink2Go looks like what I want.
I wrote earlier about how to use the
javapackager command to create a macOS application bundle from a Java application, so I won’t repeat all of that information here. Instead, in this article I just want to show how to display an image that’s stored in the Contents/Resources/Java directory of a Mac/Java application bundle.
If you’re interested in packaging Java applications on macOS, this is a good `javapackager` video on YouTube.
I recently learned how to use the Java javapackager command to build a macOS application bundle — i.e., a regular macOS application — from a Java application. In this tutorial I’ll show how to create a Mac application bundle from a simple Java class, in this case a Java Swing class.
If you’re using the Oracle AppBundler to build a Mac/MacOS application bundle from a Java application and run into this error when running Ant:
NoSuchFileException: <directory path here> Info.plist
I have found that the problem is that I have not set and exported
JAVA_HOME. To set and export
JAVA_HOME on MacOS 10.12, I use this command in the shell script I use to build my Mac/Java app:
I was surprised to learn that when you sign a macOS application, the signing process doesn’t sign every file under the .app application directory. Here’s a quote from the Apple developer docs:
“Your app’s executable code is protected by its signature because the signature becomes invalid if any of the executable code in the app bundle changes. Note that resources such as images and nib files aren’t signed; therefore, a change to these files doesn’t invalidate the signature.”
Over the last two days I’ve gotten a Mac/Java app ready for Apple’s Mac App Store, including bundling the application as a macOS “.app” application bundle, and signing it so it can be submitted to the Store.
A relatively quick look at my browser history shows that I needed to hit over 260 URLs to get that done. As a wise professor once told me, “Keep learning, keep learning.”
Three assumptions in this process are: