So I have created a website in Wordpress to market a mobile app service that I provide. Once a user signs up on the website, I want to detect the device that they are on and send them to the appropriate app store to install the app to make it a seamless transaction for them. So far, I have been using a javascript library called MobileDetect that is based on a PHP MobileDetect project. It is basically based on deciphering the useragent string to determine the device. This has been working fine for awhile, but recently with iOS 13, I can no longer detect an iPad because Apple has changed the useragent because they don't want mobile versions of websites popping up automatically on iPad Pro, they would prefer full desktop versions of the webite to appear. So if a user signs up on a Android or an Amazon Fire device, I can still send them to the appropriate app store. But I am not able to distinguish between whether they sign up on a computer or an iPad as MobileDetect now sees them as both the same.
How can I detect an iPad running iOS 13 so that I can send them to Apple's App Store to download my app after they sign up???
Related
I am working with a platform on ASP.net that does not have a native mobile version.
I am tasked with debugging a problem that is only for mobile users however searching the codebase for "mobile" or "useragent" does not return anything meaningful that I can use to reverse engineer to find the root problem. It appears that the only mobile checks on the platform are from jQuery regex checks against the useragent and are very very minimal checks to disable a button and not set any global or local variables.
I have tried using Chrome's Mobile Simulator but it seems that only changes the screen resolution rather than simulate a real mobile device. I have also tried modifying the user agent using browser extensions to no avail.
How can I force my desktop browser to load the mobile version of the website for debugging?
Where does ASP.NET determine the device type at?
ASP.NET Form. If running a form in a browser on a small (Android) device with a barcode scanner, will the scanned barcode go into the ASP.NET textbox? Or I need to add something to the application?
Well, it going to depend on which of the 150+ barcode scanners you decide to grab from google play.
However, the answer is yes, or no. It will depend on the kind of scanner.
If you download just a scanning application (software based - not built in scanner).
The reason is Android (and even iOS) don't allow one application to set focus, get/grab/take data from other applications. Nor is the reverse allowed. If that was possible, then the app could also get/grab/take values from when you are say running your on-line banking application.
I don't think Android thus supports focus to another application during scan that has focus. Now if this is factory supplied software on the phone? Then yes, this works like a desktop keyboard "wedge". That means the program does not know if you are typing from keyboard, or input is from the scanner (hence the name keyboard wedge). These will work with a web form.
However, we now seeing the rise of software based keyboard wedges. That means the software scanner is installed on android as a custom keyboard. And this in case, then once again, it will work in a web form.
So, for devices with a built in scanner? yes, that will work in all applications. For a software only (uses built in camera), then again, this is possible if the software in question works as a keyboard/wedge scanner.
If you going to adopt android scanning? then use a purpose built Android scanner.
And another possible if you want to use a software scanner? Write a small android application and have it talk to your web site. This I think is the best solution, but of course means you have to adopt some Android dev tools.
So how this works will depend on if the android device has a built in scanner, or it is a software + camera based scanner. However, it would seem that even now installable software based scanners in theory can be made to work for any application since the application is running and behaving as a user installed keyboard.
So, you have to check the particular device. The answer is not in all cases, and the answer depends on if you using a Android device with a built in scanner, or you looking to use any Android phone as that scanner.
I saw this working in a phone shop. Its like a perfect screensaver app with information. How can this work on a non jailbroken phone?
https://youtu.be/HN9L1yBJr98
Cheers,
Andrew
since I am new in the world of developing apps for watches, and the fact that it exists for smartphones the following frameworks:
Xamarin
PhoneGap
appcelerator
kony
Cordova
...
I wonder if there exists for watches apps similar frameworks? So that you code once but run overall.
Thanks
Edit 1:
At this day (12.05.2015) regarding to the answer of a nativescript maintainer here. I will go with nativescript to start writing app for wearables.
Cordova/PhoneGap apps don't work directly on the wearable devices/watches. Cordova/PhoneGap is basically a javascript API which can run on WebKit/WebView on all the mobile OS's. But the Android Watch and Apple Watch doesn't support WebKit and so the apps developed with Cordova don't work directly on Watch devices. But if want to extend some of the features from the existing Cordova app to the wearable app, you need to create the extension app in native language and the extension should be able to communicate with the paired app on the mobile device. The extension on the Watch will have only UI and the bussiness logic etc runs on the Cordova app on the mobile. It is possible to establish communication between these apps which will drive the display on the watch devices.
I am not sure about the other frameworks you listed above on how much they support wearable devices.
As #kiran and #NRimer have mentioned, these cross platform frameworks are relying on the WebKit/WebView which is the almost universal layer supported on every mobile device. They dont run directly on the device, but device runs WebKit platform that runs these cross platform apps. So comparing the capabilities of the native app with cross platform app, native app is bigger, because it can have a hands on device hardware related features. The thing particular to the smart watches is that they mostly rely on other smart phone device, and it uses it's communication protocols, that are hardware specific, and WebKit doesnt have its hands on it.
It depends on what you're looking to do with the framework. Watch apps build off data provided by their containing app. For example if you want to provide custom notifications on the watch, the app (or server for remote notifications) constructs them. When your watch app needs information, it makes a request to the containing app. Lets say you have a group of apps that you want to provide the same notifications or functions on each of their watch apps, you could make a framework that handles these functions for the containing app. As for the watch portion, think of it as more of a display of information provided. Unfortunately i dont think there's a way to generate frameworks for watch apps yet. If you're looking to have a lot of code within the watch app this might be more difficult but for simple display of information you should be alright.
I was asked to see whether apple pay will work with mobile safari and if possible to integrate into our current mobile website/website. When i did my research I found that it only works with a native app. Is that true and if so why it does not work with mobile safari? Mobile safari or any other browsers in this case is also an native app and why cant apple expose the apple pay for browsers that websites can use using a javascript API?What are the risks?
As of now Apple pay APIs are only available for native iOS apps. Javascript API though is obvious future of Apple pay, is sadly not available with iOS 8-9.
Javascript API and browser (safari) is considered not secured enough (hackable) to be pass EPOS information from browser to website.
Chrome is integrating Wallet with browser as first step and hopefully in future we will have payment API to websites as well as for native apps.
Apple Pay uses NFC to get connected to EPOS for contactless payment and hence it follows device perspectives.
Apple Pay allows to interact with EPOS like PayPass,PayWave or online payments using the encrypted cards which we stored in the PassBook App(accessed with Your Touch id) but it does not doing any payment procedures Thats why third party payment processors are listed on the official website.
http://techcrunch.com/2014/11/27/identity-wars-why-apple-pay-is-about-more-than-payments/