How many characters can a string variable contain in App Inventor?
And a textbox?
When it comes to numbers, what exactly are we talking about?
What values / precision can they reach?
For example 1 / 3 how many decimal places return?
Here are some metrics from experimentation:
-
How many characters can a string variable contain in App Inventor? a lot. I once placed the entire text of the novel Treasure Island into a variable See Treasure Island ebook
-
And a textbox? possibly the same. It works with a Text Block; the answer might be different with a TextBox control.
-
When it comes to numbers, what exactly are we talking about? App Inventor 2 uses the Android math library, so the following applies: How many characters can a string variable contain in App Inventor? see Android Decimal Format. I believe all that information also applies to AI2.
Homework assignment: Write a small Project to divide 1 by 3. What value do you get? You can use the format as decimal block on your answer.
Someone might have a more specific answer to your question. Wait and see what is posted. In the meanwhile, you might experiment and confirm these observations yourself.
2 Likes
I’ll address the question in three parts as the actual answer is somewhat complicated. In particular, it’s important to know that at the core of App Inventor is an implementation of the Scheme language called Kawa.
Theoretical String Length
There are two different internal string types in App Inventor. Kawa provides a mutable string type called FString and then there’s Java’s standard String type. Conversions are done from FString to String on an as needed basis to interact with the parts of the system written in Java. For both of these types, the theoretical maximum number of Unicode code units is 2^31. Therefore, if your text sticks to the Basic Multilingual Plane (BMP), you can have slightly over 2.1 billion characters. Unicode code points outside of the BMP are encoded as a pair of surrogate code units. If you were to use only Unicode code points outside of the BMP, then you would halve the number of code points you could effectively store, resulting in over 1 billion code points.
Theoretical Number Precision
The Scheme language provides for near infinite precision arithmetic operators in the form of exact numbers. For example, if you divide 1 by 3 you aren’t handed by a IEEE-754 double floating point number like you would in many languages used today. Rather, the computation results in a RatNum (Rational number) object that further operations compute with. The RatNum object internally stores its numerator and denominator as near infinite precision integers (IntNum). IntNums are implemented as a Java int[] (int array), which means the value stored in them can be up to +/-2^(6.87e10).
Exact numbers are coerced to inexact values when they are passed to any Java code requiring a float/double. Generally, we try to keep the numbers in exact form until no longer needed so that large sequences of math operations don’t introduce precision issues. However, some operations do cause coercion to inexact values, at which point the operations from that point forward are dealing with floating precision computations using the IEEE 754 double (64-bit) floating point type. The downside of this approach is that the math is a bit slower since more of it is done in software rather than hardware.
Practical Considerations
Inevitably, all this code has to run in a machine with a finite amount of space, e.g., your phone or tablet. In the case of Strings, your 2^31 code units will need 4 GB of memory to store. Likewise, if you wanted to store the largest IntNum you could store, you would need just over 8 GB of memory. If you wanted to store, say, the smallest rational number greater than 1 that could be represented in your device, you’d need roughly double that (16 GB). In practicality, though, most Android apps are given a heap of anywhere from 16 MB to 64 MB, which depends on a number of factors including Android version and physical capacity of the device. Also, Android doesn’t have a virtual memory swap like desktop operating systems have, so that puts a hard cap on the amount of memory available. With a 64 MB heap, you’d be looking at a maximum length string of around 33 million Unicode code units. Lastly, the Java class format and the Dex bytecode format have a fixed upper bound on string constants of 65534 characters, so you you might only be able to do strings smaller than that without using a join block to reconstruct larger text.
For number values you could still store some quite large values. However, once you start passing these back in the Java/Android world they will eventually need to be turned back into types that can be used in those environments. In the case of Strings that means turning the mutable FString type into a String, which will require making a copy. For number values, they get coerced down into ints, longs, or doubles as needed, which puts you back into 32- and 64-bit value territory.
14 Likes
(added to Limits FAQ)
1 Like
Just a quick example, a 1.7mb image, taken with the camera, converted to a base64String. Attempting to load this into a label can cause the app to crash, without an error message. The base64String is just under 2,500,000 characters.....
1 Like