I've made a plugin for NetBeans which parse a Java file and generate 2 files. I'm writting it to the disk with standard operations (i.e., normal java.io.File). It works, but it takes a while (usually 10 seconds or +) to show on the project (folder) tree.
I was wondering if there is a more efficient way to create this file using the netbeans platform api.
The FileSystem API is the place that you should probably start. You may want to focus on the FileObject and FileUtil classes.
Related
I'm creating a RN app that is meant to be some kind of wrapper. It should have multiple targets (like in Xcode) and all its content (images, text, etc.) should be target dependent. Unfortunately, I cannot find any useful informations about how to achieve this without opening Xcode or Android Studio project and create those targets manually (like here). Is there any other solutions for this?
I was still struggling with described problem but I finally found a solution. It's not easy, needs writing a bit of boilerplate code and looks more like a workaround but I hope it will help someone in the future. What I did is I have completed my wrapper app with the resources for one of my targets so I can have visual effect. In the project's root directory I've created a folder with subfolders for each target. Inside each I have put files (images, source code files, other assets) that are target-dependent. Then I've created bash script that takes one argument - target's name. Based on it, it replaces all the target-dependent files from target's subfolder to the original file's destination in the project structure. In this proces all meta-data informations are also replaced so after firing .sh file I can build the app and upload it to both stores. It's really time consuming to create all these apps separately and publish them and it's maybe not the best solution, but at least it works!
On android, you can edit build.gradle files, java or properties, without having to launch Android Studio (which simply uses Gradle)
You can build different type flavours by only changing app/build.gradle
On iOS, that's another story. Project file (.pbxproj) is a mess,and other Workspace/Scheme files are not easy to read or script. So XCode is the way to Go.
I tried to have dynamic target & Info.plist, there are tools to script that like PlistBuddy
in the end, I saw there are many ways to launch a React Native app for developpers. Some prefer the command line, and only VSCode.
Others want to play with native IDE.
By the way, native IDEs are VERY useful.
e.g. : you want to fine-tune your application performance, using XCode view hierarchy debugger or android Studio Layout Inspector (and be sure you don't use to many views), or use any other performance tools these IDEs offer...
In the end, I used react-native-config along with multiple almost similar configs (Info.plist < target < Scheme for each), here's a post giving an overview of the setup.
Fine uploader is 400kb of javascript code and 140kb minified. Since I am not using the UI and only using the API, I would like to build the library without the integrated interface (and hopefully get a smaller lib consequently). Is this possible?
Could not find this in the downloads section.
I've also setup the build environment and built the package myself, but all the files in the _dist dir seem to be bundled with the UI.
Fine Uploader is only 40 kB gzipped, which is compression that pretty much every web server already utilizes. The build is not currently setup to create a bundle without the UI. If you'd like to create such a build, the modules.js file will need to be modified. One place to start would be with a copy of the fuTraditional module sans the #fuSrcUi module. Then, a corresponding entry would need to be added to the concat.js build file. This doesn't seem worth it to save a few kB in my humble opinion, but it's all very possible.
If you're interested in a much more modular upload library where almost every feature is represented as an optional standalone module, take a look at Modern Uploader, which I am slowly developing as time allows. Feel free to open up issues in the repo if you have any questions regarding the future of that product.
I'm using JavaFX to build a GUI for the software I'm working on. I call it software but it's actually a series of automated steps, compiled into a standalone .exe file. I have about 6 of these executable files, which is why I'm building a GUI to act as the front-end, main menu of sorts.
Ideally I'd have the entire package (GUI, exes) combined into one file Jar which I'd then send to clients, or wrap it with JSmooth or Launch4j.
Questions:
1) Is it possible to combine all 6 .exe files into a package along with the GUI.? So if I click button 2 on the GUI, it runs .exe #2, etc. Which concepts should I understand?
2) Is this best practice, or is there a better method? I'm new to Java which is why I haven't built the entire software with it, just the GUI.
3) I've read that its best to extract the exe from the parent jar (or exe?) into a temp file on the users PC. Is this correct? Even for multiple wrapped exes?
Any answer is helpful. I'm trying to avoid building something only to realize I can't do what I needed. Thanks
It would be much easier to write an answer if you were a bit more specific regarding what those 6 .exe files do. Nevertheless, a few things can be pointed out. Answers are in the same order as questions.
Yes, you can package exe files into a jar. No, you can't run exe from within the jar. A common solution is to unpack exe either temporarily (while your application is active) or permanently, and then tell OS to execute it.
I'm not entirely sure what "best practice" refers to in your question. Ideally, your logic (back-end) code would be written in Java and all your 6 exe files would be a part of a single Java application. I respect that you are new to Java, so in your particular case having a front-end to your executables is perfectly fine. However, do keep in mind that your solution is Windows specific, unless you plan to provide other OS executables too.
Yes, you will need to extract the exe files. It doesn't really matter what parent executable you use (exe or jar). For the sake of simplicity, I'd go with the jar, because you won't need to use any 3rd party software to build such a jar.
Just to sum up, considering your situation, package your JavaFX app and the .exe files into a single executable jar. When the user needs to execute an ".exe", extract that ".exe" into the same directory where JavaFX is running from. When the app exits, delete all ".exe" files from that directory
I'm working on existing (not mine) Maven project which generates pretty big .war file ~37MB. More than 20MB is made of ExtJs 4.1 files (.js and .css).
I'm not sure which files are really required and which can be removed. I found out that I can remove unnecessary files with Sencha CMD but I'm not sure if it is compatibile with ExtJs 4.1. However, I tried to run it, but it always says Command must be run from an app or package folder.
Here is structure of my project: http://prntscr.com/4o97zy
Any help is apperciated!
In production you can just ext-all.* and remove rest of them which reduces size application size by 10MB. Here is the bare minimum structure that you can have in production. If you use any additional plugins include them as well. I would suggest to keep ext-all-debug.js/css as well, use maven profiles to take care of copying ext-all.* or ext-all-debug*.
The above structure is of size 2.5MB, more or less that will almost be sufficient. You can miniify these files and put it into your war. There are multiple ways of doing it. You can use ycompressor to compress and put it in your webapp or from server side you can compress files whenever user requests(Google-web utilities).
What is the difference between using ext-all.js and ext-all-debug.js?
Does changing to ext-all.js from debug.js improve performance?
Can I assume that switching from debug to normal file will not have any other impacts on the application?
Also, can any one suggest what ext-base.js do?
Ext-all is basically the minified verion of the debug one. The gain is that it greatly reduces the files size so that clients have to download less. Ext-base are the core functions of ext. If you only use those you could just include that file instead of the huge complete set in ext-all.
On the ext site there used to be a custom js builder where you would pick just the functions you need and it would create a custom js for you with just those modules
Ext-all-debug is provided so that you can debug through the extjs code. It performs extactly the same operations that ext-all.js does. Using ext-all.js will improve performance since the size of the file is much smaller, hence clients can download and access them faster.
Same is the case with ext-base-debug and ext-base.js. These contain the operations on which ext-all.js depends on, for example Ajax operations. Interchanging these files will not have any effect on your application.
Use the ext-all-debug and ext-base-debug during development. Switch to ext-all.js and ext-base.js when in production.
THIS INFORMATION HAS CHANGED FOR THOSE USING ExtJS4.1.
After implementing and optimizing an application, I like many, was confused with which process was optimal for 'production implementation'.
This most current documentation for this turned out to be this document on Sencha:
http://docs.sencha.com/ext-js/4-1/#!/guide/getting_started
It was difficult to identify, but the key for me was step #3. Deploying Application.
For which these four steps are conducted:
cd to root
sencha create jsb - this creates a manifest of classes used.
- it can also be modified prior to build, in case it is needed.
sencha build - creates two files(all-classes.js, app-all.js)
- all-classes.js is non min for review.
- app-all.js is the production ready file
Setup for prod - these are the remaining includes needed in your production file:
ext-all.css //minified-css, concatenated and dusted is optimal.
ext/ext.js //non-debug
app-all.js //minified, concatenated, app + framework files (only classes used).
Hope this helps someone. : )
differences between "ext.js" and "ext-debug.js" are:
"ext-debug" is not compressed (or "minified").
"ext-debug" is not run through the Cmd optimizer.
These files otherwise contain exactly the same code. Further, both flavors download required classes from the "src" folder. In short, both of these files are intended to support debugging.
In order to improve the performance,To reduce the downloads to as few files as possible you can use Sencha Cmd. some thing like this
sencha fs minify -yui -from=ext-debug.js -to=ext.js
For Cmd topics ext 4.2.2 doc set is the more current and you can access the dec here
hope this may help you.