Currently Being ModeratedJan 15, 2013 5:00 PM (in response to LilyGE)
Apple very deliberately keeps users from programmatically setting form field focus
Perhaps an alternate explanation is that user hasn't bothered to search for answers on either the developer forums or Google.
Currently Being ModeratedJan 15, 2013 6:50 PM (in response to etresoft)
Wow. Thanks for the helpful and positive response.
I've actually been searching for information on this for days. I have found many many people with the same issue, but no one with a solution. Initially, people were logging the focus issue as a bug, but the majority conclusion has been that Apple decided to prevent programmatic form field focus because it automatically brings up the keyboard, which would be annoying to users. Most webpages that contain any kind of form will set a field to autofocus, so Apple unilaterally suppressed the ability to programmatically set focus on a field.
I've seen several work arounds proposed, including setting a Timeout delay, or simulating a click event. I haven't been able to get those to work on Safari mobile. (It all works great on any other browser.)
So my question is simply whether anyone has solved this issue, and has been able to figure a workaround to Apple's block on form field autofocus in iOS.
Thanks to anyone who has any positive and helpful input!
Currently Being ModeratedJan 15, 2013 7:56 PM (in response to LilyGE)
Sorry. I didn't notice you were talking about Safari. I saw scan gun and assumed you were writing an app. Apple had made a number of changes in Safari for iOS to make it work better on a low-bandwidth, touch-based interface. A web app probably isn't appropriate for this application.
Currently Being ModeratedJan 15, 2013 8:46 PM (in response to etresoft)
That's what I'm struggling with. Still assessing different possibilities. iPods don't seem to be much in use for this sort of thing. Motorolas are the most common, but I've had a lot of problems with firmware corruption, and keep ending up with $2000 bricks. Maybe WASP is better. Expensive, though, and bulkier than the warehouse folks want. No ideal options exist that I can find. (i.e., stable, fast, robust, small, mobile, and not hideously expensive.)
Currently Being ModeratedJan 16, 2013 5:03 AM (in response to LilyGE)
It is very rare to see any Apple product used in a business setting. When people are buying technology for themselves and every penny counts, they are more likely to buy Apple products. When millionaires are buying something that they will force other people to use, they are going to pay much more for over-priced junk because it comes with high support costs and kickbacks. If your market is business, target those Motorolas and join the local country club. If you really want to make something for an Apple device, add a "scan" button that uses a native control to process that input.
Currently Being ModeratedJan 16, 2013 5:07 AM (in response to etresoft)
"It is very rare to see any Apple product used in a business setting. "
I'm very surprised to see this coming from you because this is no longer true.
Currently Being ModeratedJan 16, 2013 4:35 PM (in response to Michael Superczynski)
I can only comment on what I have seen. I have not seen every fortune 50 company. I have seen iOS devices used in some specialty shops, but that's about it. I don't doubt that there are managment at bigger companies that get iPhones. In production operations - never. For most people, anything made by Apple is a second-class citizen in corporate IT.
Currently Being ModeratedJan 16, 2013 4:39 PM (in response to etresoft)
I know what you mean.
I worked in corporate IT for 30 years and if I mentioned Apple or Macintosh I would get laughed at.
I'm so glad I'm retired from all the BS.
Now I make the IT decisions for my business and those decisions don't include the junk they use in the corporate shops.
It's understandable why they are so resistant to Apple's products: if they replaced all the Windows boxes with Macs running OS X, the staff could be cut by 90 per cent.
Currently Being ModeratedJan 16, 2013 5:22 PM (in response to Michael Superczynski)
I suggested using a Mac just a couple of years ago and actually did get laughed at. These same people recently installed a local version of some low-level open-source that didn't match the other libraries version and disabled 4 out of my 6 Linux servers. If only someone had tested that software and told them there was a problem. No, wait, I did that in August. Not to worry. We have a plan in place to fix the problem using virtual machines.
Apple does not target this market for good reason. There are certainly some people, even in corporate IT, who know what they are doing and still buy Apple products. However, they must make do with what Apple sells for the consumer market and hack it up on their own. I would not suggest that anyone market a product for business users of Apple products. In those cases, purchasing decisions are typically made by old-school IT types.
Currently Being ModeratedJan 16, 2013 7:23 PM (in response to etresoft)
We have given up on the idea of the iPod for warehouse use. We want to program in Sencha Touch 2, and have the IMS software be web-based (infinitely easier to maintain), so we are trying out the Samsung Galaxy 5 inch. Nice big screen. Decent operating system. And we can get about 10 of them for what one outdated, fragile-firmware, chunky and clunky Motorola with uber-advanced Windows Mobile 6.5 costs us.
Thanks for weighing in on the iPod for business use. They might have worked if we could have solved the form field focus issue. They were small, strong, fast, did well in drop tests, and did (almost) what we needed.
Currently Being ModeratedJan 17, 2013 4:34 AM (in response to LilyGE)
There is no law that says you must use a web browser with a web-based service. Ideally, all you would need is a stable REST URL to use with a POST request. An iPod will do what you need as long as you use the proper tools. It is true that having a scanner send input via a text field is an old-school, tried-and-true kludge, but it was never anything more than a kludge. Such things do tend to break when you change platforms. Why use Sencha Touch if you are only supporting one, HTML-based platform anyway?
You could make a great inventory control system that works on any platform. Or you could kludge one up that works with one specific platform. With the kludge, you will save a few hours in up-front development costs in exchange for many cumulative hours of trouble during operations. I will leave it as an exercise for the reader to guess which option would be the choice for typical corporate IT.
Currently Being ModeratedApr 28, 2013 9:36 PM (in response to LilyGE)
We are currenty developing a web-app inventory management system with symbol bluetooth scanners. The original plan was to make them work with the client's existing iPads. Obviously it works flawlessly on any desktop browser, but it also works on WinMo 6+, Windows Phone, and Android. While aging, we gave it a shot to make it work on the iPad as well. After reaching a dead end with mobile Safari, this gave us a great reason to recommend the upgrade all tablets to Surface.
I've been on dozens of threads, looking for a solution. Increasing production time by another month, and maintaining a seperate development cycle through an exclusively native iOS app is not worth our time, and is not what the customer wants.
"A web app probably isn't appropriate for this application." - etresoft
I disagree, we have deployed our inventory management web-app in many business with great success and user satisfaction, and mobile devices are a natural progression. While iOS is obviously a walled garden, jailbr3aking doesn't offer any solutions either. iOS is a sinking ship, the only solution is to jump boat to any one of the superior platforms.
Currently Being ModeratedApr 28, 2013 9:48 PM (in response to T3kB0i)
You have a problem with a web app on iOS thus "iOS is a sinking ship".
Currently Being ModeratedApr 28, 2013 11:16 PM (in response to LilyGE)
I'm not trying to start a flame-war with narrow-minded sheep. Your comment provides no benefit to users seeking for guidance and support.
As you mistakingly suggest, the problem does not lie within the web-app. If you were able to read, you could see that our app doesn't have any problems. In fact, it works on every single platform. It doesn't work with iOS, that's why using logic (see: Vulcan) we can infer that the problem resides within iOS. See how we did that? =D It wasn't so hard, now was it?
I am not expecting your intelligience to comprehend this problem from a developer's point of view. This is not a question about the iPads having poor battery life after an update, or something simple like that. This is an inherent flaw of iOS that has no "work-around" as the OP requests. Run along now and go back to playing Angry Birds on your iPad 4, the big kids are trying to get work done here.