I'm just starting out on Android and Java programming, coming in from a C++ background. I was wondering - whats the best way to go about making a library/UI widget/component that I can license to third-party developers?
In C++ I'd ship the customers my headers and *.a files, but I don't know the equivalent in Java.
Are there any good resources or links about this, maybe even from general Java development standpoint.
you can define activities/services that are available for any other application running on android:
"A central feature of Android is that one application can make use of elements of other applications (provided those applications permit it). For example, if your application needs to display a scrolling list of images and another application has developed a suitable scroller and made it available to others, you can call upon that scroller to do the work, rather than develop your own. "
http://developer.android.com/guide/topics/fundamentals.html
Activities and services have some use but there is a whole class of functionality (fancy table viewer for sql) that isn't covered. You can do jars but I don't think you can have android resources in that file. The work around would be to have a Jar and require the user to copy and paste some text into the apps resource directory. You can look at the admob.com android SDK for an example of this.
Not sure about how Android handles this, but the typical distribution of Java code is a .jar file. A .jar is basically a zip file containing all of the compiled .class files in a Java project. There might also be resource/text/etc. files within the .jar. There is no concept of a header file in Java, so all you need are the .class files, and possibly a manifest file to provide some additional meta info about the .jar.
http://java.sun.com/docs/books/tutorial/deployment/jar/
(This is just a general Java answer, it may or may not apply to Android)
Related
I'm working on a project that requires to add some features to an existing java application using Netbeans. After searching the net, i founded that I should use "plugins". I didn't hear of plugins before.
I have a java application that I should download it from the net, then lets say I have to add a button, when clicked, calls a function that is written in some class in the application. In other words I want to make a new class that is able to access the classes and functions that are written in this application.
What I understood from searching the net is that:
-In the downloaded project's folder there is a folder named plugins.
-This folder contains zip files that contains classes and other stuff.
-I should make a plugin and add it to this folder in order to add a specific feature to the application.
That's what I know, if there is something wrong in what I said, I'll be thankful to correct to me.
Now, my question is that I want a link or website that can teach me how to create and add a plugin to an existing java application. Thank you :)
That entirely depends on the java application you're talking about. Not every application has a Plugins functionality. And not every Java Application uses the same Plugin API. The best bet is to go to the site of the App you're talking about and see if they offer a documentation about their Plugin API.
This is a bit of a basic question/s and pertains to project structure. It's just a basic concept I have missed in android. (as a result of being self taught).
With an app that has many classes, activities and fragments, it's becoming busy in both the java and res folders.
I am unsure what is the best way to proceed with managing larger projects.
For instance, if I have a various sections, bluetooth, wifi, gps, etc. And for many of these they are reusable code "packages" or "modules" (I am not sure of the correct word).
How should I go about formatting my project?
Using packages?
Is there a dll concept equivalent?
There is this question here:
Is there any DLL or DLL like concept in Android?, but it doesn't really help clarify this issue for me.
Any feedback is appreciated.
How should I go about formatting my project?
It depends on your needs. If you want to move some part of logic to a library, you can do that by creating an android library project. See Library Module section: https://developer.android.com/tools/projects/index.html
Is there a dll concept equivalent?
If you want to have a compiled version of that library project (like DLL) you can generate a .jar file. Refer this link: How to create jar for Android Library Project
So, you can link android library project directly, or, compile it first, and then include as a .jar file.
I need to load "configuration" type files for my program in Android, they are both .bin files containing dictionary data for the NLP library. I'm a bit new to Android still, and I'm having trouble finding a folder to place the files in so I can access them when the activity starts.
I also need to create/save/load a filetype specific to my program, and I don't know where to put it either. All I've been able to find on here is people using the getAssetManager() function to fetch input streams, but I explicitly need File objects for me to be able to load them into my pre-existing desktop software code I'd like to reuse (plus the libraries require them anyway)
I've also seen people using a "res/raw" folder, however the ADT did not generate this "raw" file when I made the project - so I'm not sure what to do there either.
Here is how I usually start the software in the desktop version, but I need to fetch these files in an Android environment:
brain.start(new File("memboric.core"), new File("en_pos_maxent.bin"), new File("en_sent.bin"));
core = brain.getInterpreter().getCore();
The memboric.core file can be generated, but I need to know WHERE and HOW to do so.
Thank you very much for your time, feel free to direct me to other resources if you feel this question is inadequate.
TLDR; how do I load "static" files for the software to function (needs to be included with software), and how to create/load/save "personal" files into an appropriate area of the device?
Use Context.getFilesDir(). Your application can read and write files in that folder and they'll automatically get deleted if your application gets uninstalled.
From that point forward, you can create, delete and read from files like any other Java application.
the "raw"-folder you can create it on your own. So check this out, which shows how to handle files in Android: http://developer.android.com/training/basics/data-storage/files.html
I'm trying to read pdf files in my android application. I don't want to use the default pdf reader and simply open a new intent because I need my own GUI, and want to use the first page as a cover. Therefore I need to make my own pdf reader. I did some research and came across muPDF and Android PDF Viewer Library.
I tried to follow tutorial to implement Android PDF Viewer Library, from the github description. But the problem is that it loads pdf file forever. Do I need to do something else than just the steps in the description?
I can't find any tutorials for the muPDF library, are there any? How to implement it?
If there is no useful answer for the previous two questions, are there any good pdf library out there with tutorials and good documentation?
Thank you, hopefully, I will be able to solve my problem
MuPDF is a very good library, you can definitely use it. If you need a complete example of Android app using MuPDF, I suggest you to take a look at this customizable magazine app on Github.
first of all, if you want to use MUPDF inside an existing android app project you can follow the guide you find at this link (all credits go to the author, I didn't write this).
I am trying as well to integrate a very simple PDF reading/printing solution inside my app and i am struggling to strip down/simplify the MuPdf application demo you get by following that guide. I already managed (somehow) to remove annotation and file-picking features, but i would really need some help as well to get all the job done. There's really a lot of stuff and absolutely no documentation about this. I am simply trying to read the code and figure out what is needed and what is not, removing features one by one and being driven by the errors you get in catlog.
Also, as we both (if I understood correctly your needs) need just the PDF rendering features, would be great if someone points out how to (if possible) disable some of the unnecessary features built in the MuPDF library when building it from source (as DjVu support, just as an example).
Hope this helps, even if it is not a real answer to your question.
This is how I succeeded in building a MuPDF lib on windows with Cygwin, android-ndk
Download MuPDF 1.3 Source from https://code.google.com/p/mupdf/downloads/list
unzip to folder c:/mupdf-1.3-source
Install Cygwin:
Download and run Run setup-x86.exe from http://cygwin.com/install.html
when installing cygwin, make sure you selected make packages and C++ compilers
Make generate. open cygwin terminal, run
cd /cygdrive/
cd c/mupdf-1.3-source
make generate
Install android-ndk:
download android-ndk-r9d-windows-x86.zip and unzip it to
c:/android-ndk-r9d
Build mupdf lib: on windows cmd console:
preparation:
cd c:/mupdf-1.3-source/platform/android
copy local.properties.sample local.properties
edit local.properties, uncomment
#sdk.dir=C:\\Program Files (x86)\\Android\\android-sdk
and change to
sdk.dir=REAL andforid-sdk Folder
build:
while still on c:/mupdf-1.3-source/platform/android, run:
/android-ndk-r9d/ndk-build
Upon the completion of the build, a folder named libs will be created under
c:/mupdf-1.3-source/platform/android
Create android apk.
Open eclipse, create a new android project from existing code, browse to c:/mupdf-1.3-source/platform/android, now you can create a mupdf apk.
Starting with Android 5.0 you can also use Android's internal PDF renderer and for manipulating PDF you can always use iTextg - just some alternatives for the future.
This SO answer lists some steps on how to rip essential pieces from the MuPDF Java sample app to one's own.
Preferably, I'd like to have a "ready to use" Java library I could attach to as a dependency. Is JNI preventing this or is it simply that no-one's gotten up to doing one?
Well, jmupdf is there (mentioned in this duplicate) but that lists Windows and Linux (not specifically Android) as the tested platforms. It seems desktop and dead to me (no changes in 12 months). At least compared to the vibrance of MuPDF itself.
I wanted to know where should I keep my resources like I am displaying some images, playing some media files while making executable jar? Should I include it in executable jar or I should keep outside the executable jar?
If I keep the resources outside the jar what URL location URL should I pass in my program to access the images?
Actually the problem is I want to make distributable copy of my jar file.
If I give location of my local system for accessing the images and media files it will work in my system but what when I distribute it in other systems?
It depends on your application.
You can pack resources into the jar. Typically it is good for resources that are never changed: company logo, icons etc. You can read them using getClass().getResourceAsStream().
Other solution is to download the files from server (e.g. over HTTP). This solution is good for media that you do not want to pack together with application. For example video clip you want to play to user. Or, probably localized icons from the previous example or localized messages for multi-lingual applications.
The resources that you are downloading can be cached. You can use User's temporary directory (System.getProperty("java.io.tmpdir")) or sometimes using preferences API.
This isn't a radical answer but you could, in essence, create a resources project for images, properties and the like (media even).
You can then add your resources project (henceforth referred to as "MyProjectWsResources") as a child to your code project (henceforth referred to as "MyProjectWsClient"). Since MyProjectWsResources is in MyProjectWsClient's build path, it makes referencing your resources easier. If you're unclear of what putting something in your project's build path entails, it's saying anything in MyProjectWsResources's src folder is in MyProjectWsClient when it goes to referencing for information (as long as you're not using absolute paths :))
Why go for the approach of multiple projects? IMO, it separates code from resources so you download resources and code separately and your clients need not download the resources projects repeatedly when there are updates to your code only (I feel updates to code are far more frequent as compared to updates to resources). Lesser server bandwidth (important if you're using Java WS or any other packaging/system which I now realize you probably aren't).. still, hope this helps :)
I want to make distributable copy of my jar file.
Fist I will address the only sentence in your question that was not a question.
A great way to distribute a Swing desktop application to multiple users from the click of a link on the net, is Java Web Start.
Deployment with JWS would mean the resources would need to be in a Jar. For best results with the 'auto updating' nature of JWS, the Jar(s) for media would be:
referenced from a separate, sand-boxed, extension so they can be shared with other applications, and loaded/updated separately and lazily (as needed).
Compression:
uncompressed, for video, sound and image
compressed for textual information (HTML, RTF, CSV..)
Put in a path in the Jar that is known to the application. (e.g. /resources/video/vidNNN.mp4)
Resources in Jars are an embedded-resource and must be accessed by URL (or InputStream as mentioned by Alex, but URL is more robust). Quoting the info. page.
URL urlToResource = this.getClass().getResource("/path/to/the.resource");
During development, it is generally best to arrange a build that assembles the resources in the same way the end user will get them - to build the app. each run.
In other cases you might want to leave the resources at a public location on the server and access them as needed, but this effectively makes the server necessary for running the media related parts of the app. It seems your resources are both static (user does not change them) and an 'application resource'.