J2ME lacks the java.util.Properties class. Although it is possible to put application settings in the JAD file this is not recommended for many properties. (Since, some platforms limits the size of JAD file.) I want to put a configuration file inside my jar file and parse it. And I do not want to go with XML because it will be overshooting for my case.
Question is, is there an already existing library for J2ME that can parse properties files or something similar such as INI file. Or would you recommend another method to solve the initial problem?
The best solution probably depends on what is going to be generating the properties files.
If you've got other non-JavaME projects using the same properties files, then stick with them, and write or find a parser. (There is a simple one from GoBible available on Google Code)
However you might find it just as easy to keep your configuration as static final String myproperty="myvalue"; in a Configuration.java file which you compile, and include in the jar instead, since you then do not need any special code to locate, open, read, and parse them.
You do then pick up a limitation on what you call them though, since you can no longer use the common dot separated namespacing idiom.
Related
The vapi file that is available for librsvg-2.0 contains a lot less than what the actual library contains
vapi: http://valadoc.org/#!wiki=librsvg-2.0/index
library: https://git.gnome.org/browse/librsvg/tree/
I would have expected to have access to components like an RsvgNode to be able to access and alter the SVG contents directly, but neither the vapi nor the header files that are installed with the devel package contain a lot of what's in the library headers. I assume this has something to do with making the library GObject friendly, but I'm interested in more than what's there.
Is there a way to add headers, extend the vapi, and use the structs and functions that I need?
It's possible that this is not even what I should be doing, the contents of the library use the G_GNUC_HIDDEN macro pretty liberally suggesting that they don't want to give you access. But then I'm wondering how you can edit an SVG document/element live while displaying it in a Cairo context? I'm sure I could edit it using libxml, but I don't know how to refresh the context without reloading the SVG data and recreating the surface.
Thanks.
Just asked Christian Persch about this on IRC. His response was:
that's right, all that stuff is not exported, and it's not in any state to be exported. there is no way with librsvg to change the svg without creating a new context and loading the new svg xml into it
If the library doesn't export the stuff on the C level there isn't really a lot you can do at the Vala level. Creating bindings wouldn't be very difficult, but the API that it binds really needs to be public.
Depending on your use case, perhaps you'd be happier using Clutter?
Beyond allowing one file to use another file's attributes, what actually happens behind the scenes? Does it just provide the location to access to that file when its contents are later needed, or does it load the implementation's data into memory?
In short;
The header file defines the API for a module. It's a contract listing which methods a third party can call. The module can be considered a black box to third parties.
The implementation implements the module. It is the inside of the black box. As a developer of a module you have to write this, but as a user of a third party module you shouldn't need to know anything about the implementation. The header should contain all the information you need.
Some parts of a header file could be auto generated - the method declarations. This would require you to annotate the implementation as there are likely to be private methods in the implementation which don't form part of the API and don't belong in the header.
Header files sometimes have other information in them; type definitions, constant definitions etc. These belong in the header file, and not in the implementation.
The main reason for a header is to be able to #include it in some other file, so you can use the functions in one file from that other file. The header includes (only) enough to be able to use the functions, not the functions themselves, so (we hope) compiling it is considerably faster.
Maintaining the two separately most results from nobody ever having written an editor that automates the process very well. There's not really a lot of reason they couldn't do so, and a few have even tried to -- but the editors that have done so have never done very well in the market, and the more mainstream editors haven't adopted it.
Well i will try:
Header files are only needed in the preprocessing phase. Once the preprocessor is done with them the compiler never even sees them. Obviously, the target system doesn't need them either for execution (the same way .c files aren't needed).
Instead libraries are executed during the linking phase.If a program is dynamically linked and the target environment doesn't have the necessary libraries, in the right places, with the right versions it won't run.
In C nothing like that is needed since once you compile it you get native code. The header files are copy pasted when u #include it . It is very different from the byte-code you get from java. There's no need for an interpreter(like the JVM): you just feed it your binary stuff to the CPU and it does its thing.
I have read a few tutorials about iOS's tools and processes for i18n/l10n, and am unpleasantly surprised with what I'm seeing. It seems there isn't a solid way of externalizing user-facing strings out of objective C files. Am I missing something?
Description of the problem:
There is a tendency to place English strings directly into the .m file, and the Apple documentation seems to encourage this. While this is also possible in Android, as least in Android there is a clear distinction between externalized and non-externalized strings. With iOS, on the other hand, code that calls for a string tends to look like this:
NSLocalizedString(#"There was an error loading the image.", nil)
In this case, "There was an error loading the image." is the key for this string resource. Therefore if I want to make another reference to the same string in some other place we have to again write code like this:
NSLocalizedString(#"There was an error loading the image.", nil)
But now I have to make sure that I spelled these two strings the same and there is no compile time check to help me confirm that. I could write a helper function called createErrorString, but that's not fun. And I could replace "There was an error loading the image." with a more sensible key like "ERROR_IMAGE_LOAD", but that does not seem to be a common practice, and Apple seems to discourage this sensible behavior. Here is what their documentation states:
"A common convention when developing applications is to use a key name
that equals the value in the language used to develop the
application."
It looks like Apple is recommending that you put the full English string in your source code. So I'll have to try to convince my colleagues to go against Apple's guidance.
Now that I've got all of these user-facing English strings (or keys) in the source code, Apple includes a tool called genstrings that parses the .m files, and spits out a Localizable.strings file that I can then send out for translation. This might work if you are only going to get your app localized one time, but in our company localization is an ongoing iterative process. Look at what the Apple documentation recommends:
"For subsequent runs, it is a good idea to save a copy of your current
strings files before running genstrings. You can then diff the new and
old versions to determine which strings were added to (or changed in)
your project. You can then use this information to update any already
localized versions of your strings files, rather than replacing those
files and localizing them again."
That doesn't seem very good. In Android and Windows8, you internationalize your source tree one time, and from that moment on your externalized strings are owned in the xml files where they belong; in iOS they are owned in source code (sort of) and then tabulated into some intermediate file (or is it?) by some crazy tool. Is the Localizable.strings file an intermediate file or should it be committed into git - we are still debating this at my company.
(And from what I can tell, this is only the beginning. In xib-land, which is where 90% of your user-facing strings live, there also seems to be an inefficient mechanism for l10n. Wil Shipley's article describes this at length.)
Does anyone have any suggestions on a good way to externalize strings in iOS? My main question concerns objective-C strings, but answers pertaining to xib files would also be much appreciated. Thanks!
I found the recommendation to name the key like the english string strange, too.
I name the keys, value e.g "Menu1SettingsTitle" = "Settings".
I dont need genstrings tool, just externalize manually.
And no, the string files is not an intermediate step, they should be in git.
However with that approach i noticed three drawbacks:
1) I detected duplicate names, but that can be moved to a common section for strings like "cancel, delete"
2) If you forget to put a string into that language file, it cannot be found and then the key is displayed, which looks very strange, of course. Otherwise with apples reccomendation, If the key is the english word, it looks "only english" but not worse.
3) The translation process is easier if english is always left, instead of "Menu1SettingsTitle". to solve that i put a comment above, but dont know if the translation service would be happy with that.
After a couple of hours searching I decided to use two different approaches: one for the storyboards and one for the text inside the .m files. The result are two files Localizable.strings for the Objective C text and the internationalized storyboard.
The update_storyboard_strings.sh can automatically extract translatable strings from storyboards and update strings files. The source code (by mikezang) can be found at:
http://forums.macrumors.com/showpost.php?p=16060008&postcount=4
For the objective C NLS I use another script around the xcode-tools by Frédéric Sagnes:
https://github.com/ndfred/xcode-tools
I had to call it for each language in order to get the desired results:
python scripts/xcode-tools/update_strings.py --import=MyProject/Base.lproj/Localizable.strings MyProject/Base.lproj/Localizable.strings
python scripts/xcode-tools/update_strings.py --import=MyProject/de.lproj/Localizable.strings MyProject/de.lproj/Localizable.strings
Now put both in one script and add it to your Xcode project as a last build phase.
I'm building a program that uses Delphi Packages (BPLs) as plugins, but I'd like to use a custom extension to show that the files have a specific purpose instead of just being BPLs. That works well enough until I end up with one package having a dependency on another. Then the compiler automatically creates the binary with the extension BPL built in.
This wouldn't be too hard to fix with a hex editor, but that's sort of an extreme solution. Is there any way I could make the compiler generate the packages with the right dependency names in the first place?
EDIT: The answers so far seem to have not understood the question.
I know exactly how to create the packages with my custom TEP extension instead of a BPL extension. But if I have package1.TEP and package2.TEP, and package2 depends on package1, and then I try to load package2, it gives an error because it can't find "package1.BPL". What I want is to find some simpler way to make package2 look for the correct filename, "package1.TEP," that doesn't involve editing the binary after it's been created. Is there any way to do that?
Use the {$E} directive.
The simplest solution would be to use a post build event to rename your destination file from *.BPL to whatever specific extension you are requiring.
EDIT:
You could write a separate patch program to search for and patch the offending binaries and run it as part of the post build process. If a patch is made to the compiler, then you can remove your step easily.
I'm developing a BlackBerry application in which I need to unpack a zip file compressed with PKZIP. The package could have one file in it, or it could have 10; it will vary in each case. I know that the BlackBerry API has native support for GZip and Zlib, although I'm pretty sure that these methods aren't going to be helpful in my case. It doesn't look as if I can extract the individual files using these calls.
I've tried JZlib (http://www.jcraft.com/jzlib/), which compiled fine, but again it doesn't look as if the methods contained therein are going to allow me to pull the individual files.
It appears as if this is possible, as there's an application called Ziplorer (http://www.s4bb.com/software/ziplorer/) that claims to do perform this exact procedure. How they're doing it, however, escapes me.
So here I am after hours of Googling. I'm welcoming any insight into my problem with open arms.
"zip" algorithms are typically offshoots of the Lempel-Ziv-Welch algorithm. They are a fairly efficient stream compression algorithms, but because of how they function, you can't start to decompress at random points in the file, you have to start from the start.
Any product that claims to be able to decompress one file from a zip still has to decompress everything before it in the zip file in order to know how to decrypt the given file, or even, for that matter, where the file is in the archive.
If you can tolerate GPL code in your application, then this library http://jazzme.sourceforge.net/ that might work. However the project (and its parent project http://sourceforge.net/projects/jazzlib/) don't look like they're being developed.