For my internship I'm working on a App that uses GPS data! That's already implemented and I wrote a class which converts the double-value the mapView sends into an user-picked format for Geo Coordinates (Degrees, Degrees-Minutes or Degrees-Minutes-Seconds)! Now there are also text fields the user should enter some coordinates in for adding waypoints!
What's the best technique here to get a the seperate numbers out of a string in a format similar to this 57° 14' 03" N!
Since it's a user input, the format won't be this, it's only similar! So is it better to parse these out the string or maybe limit the users input method from a textfield to something more strict which only allows one format (separate textfields for each number f.ex.)!
Actually a question to UX rather than a how-to-do!
Acting as the delegate of the text field and not allowing invalid content / format is a good first step.
For parsing the string, NSScanner is the appropriate class to use to split out the parts. If you tie the format down though, you could use componentsSeparatedByString: to separate each number by the space between them.
First, a comment. Ending all your sentences with exclamation points is silly!
As to your question. Yes, you should enforce a strict input format on your users. If you look in the software developers's dictionary, user is a synonym for idiot.
I would suggest separate UITextFields for each numeric value of each lat/long, with the symbols drawn in place with labels. The user would enter degrees, and the input would jump to minutes. The user enters minutes, and the input jumps to seconds. The user enters seconds, and the input jumps to degrees on the longitude.
Validate each input as a well-formed number.
If you want to use free-form input of strings like "57° 14' 03" N!", you might want to create a regular expression to validate it, plus range-checking on the numeric parts. If you Google it you should find online docs on regular expression. I don't use them often enough to be able to write a regular expression off the top of my head.
Related
I made a binary calculator with bitwise functions (bitand, bitor, bitxor, ect.) in google sheets (yes I am aware that there are built in functions to do this, this seemed more fun). It is an 8 bit calculator, and I currently have addition and subtraction implemented. Multiplication is planned, but seems way too hard at the moment
One of the things I came across is once a calculation is done, the user has to manually 0 out the addends/minuend and subtrahend one digit at a time. I would like to optimize this process.
I can easily create a script that will input 0 into all the cells and hook that up to a button. I have a feeling that's the route I'm going to have to go. But I want to challenge myself in making cool stuff, so I want the coolest solution.
My question is: is there a way I can do this without a script attached? I've been experimenting with ARRAYFORMULA and VLOOKUP, but I don't have a clear answer yet.
Expected behavior:
User inputs their calculation. User records the answer. User selects both 8 bit binary numbers (currently residing in A1:H2) and presses backspace. Google Sheet automatically translates those blank cells to 0's.
take a look into custom internal formatting. any text can be converted to "0"
then see shifted arrays:
={"", "x"}
formula from G9 will print "0" into H9. also, you can anytime enter value in H9 to "overwrite" the zero and after you don't need the entered value you just clear it with backspace or delete key and it will be filled with "0" again.
also, note that after you enter value in H9, G9 will error out and such error cant be suppressed so see hidden cells:
not sure if it's cool enough but it works (with compromises)
What encoding/encryption/manipulation would turn the following values from what you see on the left to what's on the right?
146.00 => 4046401A36E2EB1D
36.30 => 4042266666666666
76.22 => 40530E147AE147AE
3865.20 => 40DA06683E8C7FD4
0.200 => 3FC999999999999A
I am working with an XML file from a software application we use at work. I am trying to set up a tool that helps interpret and manipulate the XML files outside of the software, to allow work to be done while off of the limited licenses we have. In the software, users populate fields and can import/export XML files containing the info they have entered. When I open these XML files in a text editor, all the fields are clearly labeled as they would be in the program itself. The user input data is "encoded" however (hoping that's the accurate term), and it appears to be hexadecimal.
I have been able to take string and integer inputs and convert them back and forth to what's in the XML file, although the strings are backwards (the hex decodes to "w im 9" when the user input "9 mi w"). However anything the user enters as a decimal number is giving me trouble [edit: I determined the trouble is with fields that have associated units]. Some preliminary research has brought me to the idea of "attributes", but I don't know enough of XML to make use/sense of it. Below are two lines from the XML, the first one where the user data plays nice when trying to decode, and the second where something else is happening:
<BRIDGE_ID HEX="true">#31</BRIDGE_ID> Here the user just entered "1" for the Bridge ID
<LENGTH Units="23" HEX="true">#3FD381D7DBF487FD</LENGTH> Here the user entered "1" for length and the program forced it to 1.00 before exporting. This field is in feet.
I have discovered that the fields which assign units to the values are the ones that are not reversing nicely. Any field without units, i.e. no attributes in XML, works great in a simple web decoder. So the attributes complicate it somehow. In the first 5 examples at the top, the first value is in feet (Units="23"), while the second and third fields are both degrees (Units="52").
I know this is all over the place! Thank you anyone who can make sense of it and help me out!
For the 2nd, 3rd, and 5th values, the 16-digit hex string is simply the hex representation of the internal 64-bit double-precision IEEE floating point value whose decimal representation appears on the left.
That doesn't work for the 1st and 4th values, where the hex string is the representation of 44.50 and 26649.628817677338 respectively. Since you talk about units, perhaps there might be conversion from American units to metric involved?
This question has nothing to do with XML. Just because the data is wrapped in XML tags doesn't make it an XML question.
I'm quite at a lost on this subject. I've read pretty much every post about it here on SO, I would very much appreciate it if somebody would nudge me in the right direction.
I have a PDF and I would like to extract it's text, I'm only interested in words and spaces. I have setup a CGPDFScanner and it's callback methods. What I have read is that I only need to consider 4 operators TJ, Tj, qout(') and doubleqout(") as far as extracting text goes.
I guess I also need to keep track of the text space to be able to determine whether the letters should be put together to form a word or should be separated by a space. But I have no idea how I would have to do this.
In the PDF, all text is in the format
[(X)-24.2524(X)-24.2524(X)-24.2524(Y)-24.2524(Y)-24.2524]TJ
but I have not been able to figure out (using the PDF specification) what these numbers mean. Somebody on SO said that you should not be scared of the PDF specs but frankly I do not find them very easy to read/understand.
I have studied the PDFKitten code which was helpful.
Any help would be greatly appreciated.
I cannot give you advice how to extract words from PDF, but the format of
[(X)-24.2524(X)-24.2524(X)-24.2524(Y)-24.2524(Y)-24.2524]TJ
is explained for example in the PDF 1.7 Specification, section "9.4.3 Text-Showing Operators". The description of the TJ operator is:
Show one or more text strings, allowing individual glyph positioning.
Each element of array shall be either a string or a number. If the
element is a string, this operator shall show the string. If it is a
number, the operator shall adjust the text position by that amount;
that is, it shall translate the text matrix, Tm. The number shall be
expressed in thousandths of a unit of text space.
So the numbers are adjustments to the distance between the letters.
I've seen a number of QR codes that contain a URL but also have extra some text after it. Something like:
http://www.example.com Thanks for scanning this QR code!
I've experimented with using a number of different delimiting methods (several spaces, a question mark, two dashes, one or two returns) and all work to varying degrees on various scanning programs.
Some respect the space character, others respect the return. Some think the URL isn't a URL at all when I use a return. Long story short, it's all over the map how the various scanning programs (NeoReader, iNigma, Qrafter, Beetag, OptiScan, etc.) treat characters after a URL.
Is there any consensus on weather (a)this is even a good idea or not and (b)if so, what is the 'correct' (best practice) way to do it? (I know I should go read the RFC for the exact definition of a URL but since the reader programs are all over the map, I suspect they didn't read it either.)
You can make it work by converting the text message into valid URL, while trying to keep readability.
In your case it can be:
http://www.example.com?Thanks_for_scanning_this_QR_code
It's not perfect, but it can help on web analytics side to distinguish all QR code users.
Spaces are definitely not part of a URL, so, in that sense a space definitely should delimit the end of a URL.
The entire string is not a URL, taken as a whole of course. So yes it's asking for trouble.
As you've found, the empirical answer is that not every reader does what you want. Barcode Scanner for instance understands the split here, but does not prompt the user to launch the browser since the payload isn't a URL per se.
So: it's a bad idea.
Right now I have two fields for cost. One for dollars and one for cents. This works, but it is a bit ugly. It also doesn't allow the user to enter the term "free" or "no cost" if they want. But if I only have one field, I might have to make my parser a bit smarter. What do you think?
On the server side, I combine dollars and cents to store them as decimals in my database. Mainly so that I can gather statistics (cost averages, etc.) quickly.
Do you think it is better to store the cost as a string? Then whenever I actually use the cost for stats or other purposes, I would convert it to a decimal at that point. Or am I on the right track?
There is a rule in database design that states that "atomic data" should not be split. By this rule a price, or cost is such an example of atomic data and therefore it should never be split among multiple columns just like you shouldn't split a phone number among multiple columns (unless you really have a very good reason for it - very rare)
Use a DECIMAL data type. Something like DECIMAL(8,3) should work and it's supported by all ANSI SQL compliant database products!
You can consult Joe Celko's "Thinking In Sets" book for a discussion of this topic. See section 1.6.2, pages 21-22.
EDIT -
It seems from your question that you are also concerned with how to accept user's input in a form that resembles the price (xxxx.xx) - hence the two input boxes, for the whole dollars, and the pennies.
I recommend using a single input box and then doing input validation using Regular Expressions to match your format (i.e. something like [0-9]+(.[0-9]{1,3})? would probably work but could be improved). You could then parse the validated string to a Decimal type in your language, or just pass it as a string into your database - SQL will know how to cast it to a DECIMAL type.
Keep the whole cost as decimal. If it's free, then keep the cost as 0. In presentation if cost is zero - write "free" instead of 0.
I generally store the cost as the lowest unit (pennies) and then convert it to whole dollars later.
So a cost of $4.50 gets stored as 450. Free items would be -1 pennies. You could store free things as 0 pennies as well, this gives you the flexibility to use 0 and -1 to mean two slightly different things (free vs no sale?).
It also makes it easier to support countries that don't use cents if you choose to go that route.
As for presenting the data entry field, I personally don't like it when I have to keep switching fields for tiny things (like when they break up phone numbers into 3 fields, or IP addresses into 4). I'd present one field, and let the users type the decimal point in themselves. That way, your users don't have to tab (or click, if they are unfamiliar with tab) to the next field.
Use cents, use 450 for $4.50 this will save you problems that are arising very often
from the fact that floating point operations are not safe. Just try the following expression in irb:
0.4 - 0.3 == 0.1 will return false. All because of floating point representation
innacuracies.
In my models I'm always using:
attr_accessor :price_with_cents
def price_with_cents
self.price/100.00
end
def price\_with\_cents==(num)
self.price = (num.to_f * 100.00).to_i
end
And the name of column is just price and integer type.
I don't have much experience with decimal columns and their representation in ruby (which can be float that is problematic as i've shown at the begining).
Don't allow garbage to make it to your database. If you're expecting a dollar amount on a field, than make sure it's valid before it gets in there. This will allow you to report better on the data and allow simpler formatting on output.
I suggest making this a single field with validation on update or insert.
if field != SpecialFreeTag then
try to convert to decimal
if fail then report to user
otherwise accept value
Use try parse or regular expressions to help with the validation.
I would store the cost as decimal with the scale being no less than 2 and maybe even 3-5. If something is bought in bulk the unit cost could easily include fractions of a cent. Free items have a cost of 0. If the cost is unknown then allow null values also.