Is there a limitation on the length of a URL Scheme for an iOS App?
We have a number of apps and want to prefix them with the name of our 14 character company name to prevent ambiguity. I don't see any mention of a limitation in the documentation and I can enter an arbitrarily long string in Xcode.
I know that the shorter schemes are preferred but is there a limit on the length of the scheme?
I'm pretty sure that its the same as the normal URL scheme.
This question goes over a similar topic, you might find more information in here.
Related
I have a website in multiple languages with a language detection system.
If a user types the URL http://the-domain.com, and assuming that the system detects the Portuguese language, which is the best solution?
Show the contents in Portuguese at the same URL http://the-domain.com
Redirect to http://the-domain.com/pt and display the content in Portuguese
NOTE: this question is about homepage link
The problem with different languages on the same URL is, that different people will get different results. Which could be confusing and it might not help with SEO.
So I would recommend the redirect.
Update:
This answers the "multiple languages on the same url" question:
https://webmasters.stackexchange.com/questions/47390/seo-implications-of-having-multiple-languages-available-at-same-url
I am writing an Instagram client for Ubuntu in Vala. And I'm using Gtk.Labels to display post title, comments etc. Problem is, sometimes received data contains special symbols like smiles etc. And currently they are displayed incorrectly, like in the picture (these squares containing 6 hex numbers):
I guess that's not the problem of my application because I've seen such behavior in other apps (for example, Pantheon Files). But anyway, this is not the way I want my program to behave, I want these symbols to be displayed correctly.
So, my question is: is it possible to achieve the behavior I want? And if it is possible, then how?
There was indeed an issue with the font I'm using. I just installed ttf-ancient-fonts package (according to the https://www.kirsle.net/blog/entry/make-emoji-work-in-linux) and now it is working.
I recently generated promo codes for the iOS app store and at least one contains some combinations of letters that you better not pronounce on TV (to say the least). Is there any way to return or change such codes? I mean, I can't send that code to a reviewer, not even to a friend.
Edit: with "generated" I mean that I used iTunes Connect to get promo codes, i.e. Apple creates them and I just download them as a text file. One of the codes reads xxMFxxxxANAL. No joke! (x=arbitrary character not disclosed here). Not exactly the kind of code you want to send to somebody whom you would like to review your app...
Is there anything I can do about this? For example returning the code and getting a new one? And do you have to check every code Apple gives you by hand? If you want to give a batch to a website to give them out to their users, such a code could slip through easily.
Remove vowels from your character set?
Before returning the generated promo code, check it against a list of words you don't want to send. If it is in that list, regenerate it.
EDIT
However, that is really not the best solution. It might serve you well to change how you generate the code.
One possibility: in C# there is a Guid class that generates a guaranteed unique string. You may be able to use a subset of a Guid as your promo code.
Another Possibility: You could alternate letters and numbers.
Is it possible to customize Recaptcha to display text in English only words?
As recently, I found that text could be displayed in other language like Hebrew.
Here is example:
To be honest it is not possible to type such words for ordinary users having keyboard with Roman alphabet and not many know that image can be redrawn.
AFAIK, via the API you may only customize the interface, not the images.
reCAPTCHA uses scans from the real books, so sometimes, even in latin books there are some non latin characters too.
But there should be no problem here. reCAPTCHA displays always two words: one unknown even for the reCAPTCHA (probably the Hebrew in this case), and the other one, which is really checked.
So the user may misspell the Hebrew, but it's OK when he types the other one (latin) word as expected.
(Only guesses, but I think that's how this thing works).
Have you looked at: http://code.google.com/apis/recaptcha/docs/customization.html#i18n?
That's the API. It talks about setting the translation, but I've never used it, so I'm not 100% sure whether it can do what you want.
Due to where Recaptcha gets its captcha string from (text scanned from books), it could very well be limited to languages that use the Latin alphabet.
I bet that Reviled is the challenge word (the one scanned from the book) and the other is the test word (the one it uses to verify whether or not the person who typed the challenge word is actually typing something legitimate or not).
It seems like most (if not all) QR readers on my iPhone handle URLs without the http:// just fine but I was wondering if that is universal? Android? BlackBerry? Is there an RFC somewhere that I should be reading
I'm building a QR management/url shortener system and was wondering if it was absolutely necessary. If not, I can drop 7 characters from my QR's URLs and make them the lowest level of complexity (16 characters or less). Which, from everything I've read, is a Good Thing™.
I haven't found any absolute documentation that says it must have it. But... After testing a number of QR reader apps, it's clear that many of them will 'guess' at a url if there is no http:// in it. But many do not and display it as just a string. Since it's a URL, it really does need it. And if any apps won't read it, then I have to bow to them and add it for all of them.
Hey Dan I am the dev of Barcode Scanner and just saw your question. I have a few more tidbits of info which may help.
There is no real 'standard' for this; I suppose the HTTP specification is the closest thing and technically it does say you need "http://". This wiki has everything we think we know about standards and de facto standards in this area.
I can tell you that QR codes have special modes to encode digits only, and alphanumeric-only text. The alpha mode includes only capital letters, but does include key punctuation like colon and slash. So, HTTP://EXAMPLE.ORG/BAR ought to be encodable in QR codes in fewer bytes than http://example.org/bar.
URLs themselves are case-sensitive however. It's not necessarily OK to uppercase a URL. But the server application may be case-insensitive. If you control the endpoints and know you can use all uppercase, this is a way to perhaps squeeze into version 1.
Finally I'll say that version 1 QR codes are a little weird since they have no alignment pattern. Without a fourth point to find, it can't (well, the dumb-but-effective process employed by Barcode Scanner and by extension a lot of scanners) account for perspective distortion. It happens to work with only small tilt. But version 2 actually has a small advantage for decodability with that alignment pattern.
QR readers usually identify as a URL any text that conform to ANY of this conditions:
Text starts with http:// (or HTTP://)
Text starts with www.
Text starts with MEBKM: (NTT DoCoMo format for web bookmark)
You should be fine without http if your url starts with www. but it's not your case.
As Sean points out, you should use all-caps urls instead.
You can fit up to 24 alphanumeric characters in a Version 1 level L QR, wich is just enought for a url shortener.
Example:
HTTP://1QR.ES/AAAAAAAAAA
Fun fact: Samsung Galaxy phones (e.g. S8 and S9) will open a QR code with a URL that has "HTTP" or "HTTPS" (in uppercase) in their text editor. Create the same URL with lowercase "http" or "https" and the same URL and it will open in a browser as expected.