I am trying give a name for a file that I am creating. I just want to know that
what is the max file name length in Android ?
Is there a specification for a file name? Can I use characters like - or > ?
It is apparently unsafe to use labels over 127 bytes on Android. AFAIK, the 255 limit is a goal, but is a WIP. I trashed my Galaxy Tab 10.1's sdcard file system last week when music sync software generated some filenames of around 160 characters. Limiting the filenames to 127 solved the issue. Be safe, unless you are sure of your particular release... stick to a limit of 127.
About the characters: Reading here, looks like - is not a reserved character, so it may be used. > however, is reserved therefore may not be used.
About the maximum length: Since I couldn't find anything specific to Android, and since java does not restrict the length of a file name it works with (As you can see here), I'd say the maximum length is like the most widely used limit, which is 255 bytes.
In the specific case of resource names, like images, I've found that the max length is 100 characters, extension included. I've checked this in Android Studio 1.2 beta. I'm sure there must be something about this in the Android documentation.
I have found that '-' (period) is a standard in naming as a rule. Frequently you will see special characters to create readability, such as the '.' Yet, the period is a constant for separating the filename from the filetype nomenclature regardless of the OS. This rule goes back to the earliest days of computing. The thing that younger users do not realize is how rigid the rules were in those early years. Modern protocol, on the other hand makes more use of assumptions to shorten code so it takes less space. Just as your smartphone is smaller than an old IBM360, so too is modern instruction set.
max file size in Android is
255
Related
I am trying out mXparser in an android app and I almost have it working. But, if I parse the following expression "10/3" then it returns: 3.33333333335. Why this rounding in the end? and how do I tell mXparser to return 3.33333333333 instead?
I am writing the app using kotlin and has added mXparser through Maven.
Alternatively, do you know of a better/more used/more maintained math parser library for Android?
The reason is that computers calculate in base 2, not base 10. The number 10/3 has an infinite expansion in both base 2 and base 10 meaning it must be truncated. The decimal expansion of 10/3 is 3.333..., which when you cut it off simplifies to a bunch of 3's; while the binary expansion is 11.010101010101... and when you cut it off and convert back to decimal, it's totally believable that you could get the 5 at the end.
I'm not sure you can get around that when using a computer since computers have to use binary and they also have to truncate the binary expansion.
Any system based around IEEE 754 double precision will give the same answer. That includes all major programming languages. This is a very frequent SO question. See for example Is floating point math broken?
The solution is to never use the default Double.toString() method for your output. Use and output with specific number of decimal places and the problem goes away.
A more complex solution is to use a ration representation of your numbers, so the result of 10/3 is stored internally as a rational number {numerator:10,denominator:3}. This works for basic arithmetic but can't work with function like cos(x) or sqrt(x). The Jep parsing evaluation library does have options to allow ration number. (disclaimer I'm one of the authors of Jep).
I am using File.length() to get file size, and I hardcoded file sizes in an array in app. If the file (downloaded file) is not the same size of recorded size, I delete it and request user to download it again.
Is this correct? if not what is the best approach to validate downloaded file?
Can file length be different per device / android version?
A downloaded file length will not be different per device / android version, not unless you have written a compression code or any modification of the image.
Now as for the approach, yes the approach is correct. But it's all about the underlying algorithm used. Algorithms vary, some increases the precision. You can read about File.length() here at the Androdid Developers Page.
Then decide if that's what you want to use, or another logic written by you or someone else.
You should verify file checksum. 2 files can have same length but contain different data.
Can file length be different per device / android version?
If you are saving it as binary file - no, it's plain data.
I'm a word puzzle junky in my spare time, so I've spent a LOT of other spare time working on a helper program that allows wildcards in search patterns. It works great. On my Dell Laptop (i5, 8GB RAM) the search of a 140,000-word "dictionary" for wildcard matches for words has an almost imperceptible and definitely acceptable delay that occurs only if tens of thousands of words are returned. Java rules. So does its implementation of regex and match().
I was hoping to port it to Android. I worked all day getting a more-or-less equivalent app to compile. No chance with given code architecture.
The problem is that leading wildcard characters can (must) be allowed. E.g., ???ENE returns 15 matches--from achENE to xylENE and *RAT returns 22 matches--from aristocRAT through `zikuRAT--i.e., all 140,000 words must (?) be searched, which is going to take aaaaaaaaawhiiiiiiiiile on most (all?) Android devices. (Each took less than a second on my laptop.) (It takes my PC 3 seconds to return all 140,000 words and a little longer to eyeball them all.)
Since some word puzzles allow variable numbers of letters in words, disallowing leading wildcards cuts the heart out of the app for such puzzles. But if the search pattern had to start with a letter it would be easy enough to then do a binary search (or something quicker). (And it still might be unacceptably slow.)
Anyway, I was wondering if anybody might know some algorithm or can think of some approach that might be applied to speed up searches with leading wildcard characters.
I believe that the optimized version of what you are trying to do is widely known as the Unix/Linux utility "grep", which, if I remember correctly, uses the Boyer-Moore search algorithm.
Under the covers, Java's Pattern class uses Boyer-Moore. And it supports regex, so if you can write something to turn your wildcard search patterns into regular expressions, you can use Pattern.
There's an interesting Java implementation of grep at http://www.java2s.com/Code/Java/Regular-Expressions/AnotherGrep.htm
It uses memory-mapped files. I'm guessing that you won't be able to fit your entire word list into memory, but you could split it up into a bunch of smaller files - the implementation above memory-maps one file at a time. You'd have to do some testing to find the optimal size of a file.
I just Googled and found having a second list reverse alphabetized might be a way to then have a leading wildcard become trailing, opening door to binary search for pattern start. Interesting. But *a???ene* is also a legal search pattern in the program. What then? (Yeah. How often would you need such a search.)
I just found this about Apache Lucene:
Leading wildcards (e.g. *ook) are not supported by the QueryParser by default. As of Lucene 2.1, they can be enabled by calling QueryParser.setAllowLeadingWildcard( true ). Note that this can be an expensive operation: it requires scanning the list of tokens in the index in its entirety to look for those that match the pattern.
This question already has answers here:
Is there a "glyph not found" character?
(8 answers)
Closed 7 years ago.
On Android, I want to be able to detect if the font used can display a certain character or not, but as I understand it this is not possible with conventional means as indicated by Check if custom font can display character
To detect this I'm writing the character I want to check to a bitmap and then I write another character that I know is missing to another bitmap and compare the content of the bitmaps. If they are equal the character is missing.
The question is, is there any unicode character whose glyph is (more or less) guaranteed to be missing on fonts typically used on Android phones?
The Unicode replacement character sounds promising when reading about it on Wikipedia:
It is used to indicate problems when a system is not able to render a
stream of data to a correct symbol. It is most commonly seen when a
font does not contain a character, but is also seen when the data is
invalid and does not match any character
However after doing a bit of testing I see that this character is not used to represent missing glyphs on either my Windows 7 computer or the Android phone I've tested with (Motorola Atrix).
There isn't any designated Unicode value for the glyph that is used to render glyphs that are missing in the font used. In the actual font, glyph id 0 should always be the .notdef glyph which is used for all characters that are missing a glyph. However it is not possible this information from the fonts on Android, so it's not possible to use the .notdef glyph directly.
In Unicode there are many reserved/unassigned code points and my limited testing indicate that these code points are rendered using the .notdef glyph. So by using U+0978, which is a reserved code point in the middle of the Devanagari block, I can detect if some other valid, known character exists in the font I want to test.
This is not a future proof solution since new glyphs may be added to reserved code points by the Unicode Consortium in the future. But for my needs it's good enough since what I want to do is a temporary thing that is not relevant any more in the near future.
Update:
The solution to look at U+0978 did not work long. That character was added in the Unicode 7.0 release in June 2014. Another option is to use a glyph that exists in unicode but that is very unlikely to be used in a normal font.
U+124AB in the Early Dynastic Cuneiform block is probably something that doesn't exist in many fonts at all.
It's good to have consistency in file names.
MyActivity.java contains the public class MyActivity
I would like the xml file with its layout to be called res/layout/MyActivity.xml
But I get an error message saying "Invalid file name: must contain only [a-z0-9_.]"
So two questions:
Why is the character set so limited (not even upper case? Come on!) - Ah - this restriction is probably in place so you will never be screwed by filesystems that don't make a distinction between upper and lower case, like Apple's HFS+ (although see Wikipedia for the gory story http://en.wikipedia.org/wiki/Comparison_of_file_systems#cite_note-note-35-77 )
Which filenames are restricted - all of res? just res/layout? res/layout plus some other folders?
Can anyone confirm 1, and give details on 2?
Thanks,
Peter
Why is the character set so limited
Because the name has to be a valid Java identifier, so you can use constants like R.layout.foo to identify the layout at runtime.
Which filenames are restricted - all
of res? just res/layout? res/layout
plus some other folders?
Anything in res/
Not sure of the reason for #1. Never seen an explanation in any readings about Resources. For #2 from my experience anything that will be used as a id in java e.g., R.drawable.marker, R.string.default_message has to follow those rules of [a-z0-9_].
When using MacOS X as a development platform, almost any developer dealing with cross platform code will sooner or later run into the issue that source code from a Linux/UNIX project cannot be built after download/checkout/clone because the project has two identically named files in a single directory that only vary in case; and on OS X that means you end up with just one file as the second one will overwrite the first one.
Of course HFS+ can be case-sensitive, but this can only be configured when you format a partition and by default all Macs come with preinstalled OS X on a preformatted partition with a case-insensitive HFS+ (as that is the default mode for HFS+). So you would first have to reformat your newly bought Mac and reinstall OS X to achieve that goal. And then be prepared for trouble as many apps rely on case-insensitivity on the Mac; a very famous example is Steam (you cannot run Steam from a case-sensitive HFS+).
And it's not just MacOS. FAT is case-insensitive and while NTFS can be case-sensitive (just like HFS+), it isn't by default. Also I think SMB isn't as per protocol spec (at least older versions). The filesystem used on CDs isn't, and so on.
So I guess to avoid any troubles straight from the beginning, Google thought it's a good idea to force files to be all lower case, in which case it doesn't matter what filesystem you are using or how it is configured. Of course, that's a bit stupid if you can still run into that issue with your source code files, however that these may be mixed case is a decision that predates Android and that has been made by Sun many years before Google even dreamed of that system.