I'm not really understanding why I'm seeing this error crypto.randomUUID is not a function when viewing said web app on iOS Simulator's Safari, when simulating any of the devices (iPad, iPhone, etc). I understand what the error means, I'm just surprised that randomUUID is not supported. It works on any other desktop browser, including physical iPad and iPhone devices. Is the simulator lacking something that I'm not understanding that needs configuration? I assume the simulator should be faithful to the actual hardware.
No one has answered this yet and you've probably solved this on your own already. Most of version 15 doesn't support crypto. IIRC versions 15.0 through 15.3 (maybe i think even to 5); Anything after that is fine. I say maybe because Apple doesn't state this anywhere as far as I'm aware. I've discovered this on my own through testing for work.
This hacky but you can get around this by adding a polyfill (I know it stings) I wouldn't expect Apple to remedy this any time soon because it feels like they gave up on Safari IMO.
Related
I've installed osx 10.10 ( Yosemite ) and since then the device (NI-USB 6210) is not working anymore.
The problem is obviously driver related. I called National Instruments and they confirmed the issue, and they also told me that the problem will be probably fixed in the next release of the nidaqmx, that will happen not so soon.
So their suggestion is to downgrade to Mavericks, which kinda suck.
They also told me to check the compatibility table
http://www.ni.com/labview/os-support/i/
in order to know when if will be supported, until then I have to struggle with downgrade or find a workaround which would be the best thing. anybody found a solution to this problem lately?
Depending on your device and how you program it, you should be able to get it working on Yosemite using NI-DAQmx Base 14.0 [1].
NI-DAQmx Base 14.0 does not claim Yosemite support, but after inspecting the installer and running a few tests, here is what I have determined:
The installer, kernel extensions, frameworks, and applications are signed by National Instruments, which means Gatekeeper won't interrupt you with "are you sure you want to do this?" questions.
Both 32-bit and 64-bit LabVIEW APIs are provided.
Both 32-bit and 64-bit C APIs are provided, but a C or Cocoa application emits a warning on exit. It appears one of the components in the driver attempts to access UI elements from a background thread. My suspicion is that the LabVIEW Run-Time Engine, in which the DAQmx Base C API runs, is doing that.
Links
[1] NI-DAQmx Base 14.0 for Mac
http://www.ni.com/download/ni-daqmx-base-14.0/5060/en/
I had this same problem, and spent an evening figuring out the problem.
Apparently, the NiDaq framework tries to send a message setHandler:withData: to the appdelegate. On yosemite, this handler no longer exists, causing the exception.
If you haven't implemented such message in your own app delegate, things go bad.
But you can simply implement a dummy handler by adding this to your application delegate class :
- (id)setHandler:(id)a withData:(id) b
{
return nil;
}
this way, the framework doesn't crash !!! I still have to test if the measured data is correct, but at least i'm running again !
I want to make a little painting program. So i am going over if it's even possible. As with all good painting programs it needs to have pressure sensitivity. And i don't think i have ever come across anyway to get pressure sensitivity of mouse/tablet. Is there a workaround.
The thing i have come closest to is touch event that is supposed to have pressure property.
This question has been asked before but that was like in 2009. I am hoping that there would be something available this time.
Chrome apps are also an option.
As far as I know only Firefox support this through a proprietary property on the event object:
var pressure = event.mozPressure;
which keeps a value between 0.0 and 1.0.
Wacom has a plugin that can be installed to give browsers an API to read these sort of values from but I guess it only works with their own tablets.
Hello from the future world of 2022!
There is a PointerEvent API that appears to be supported by major browsers, and pressure can be read out from the PointerEvent.pressure property.
tldraw is an example of a project using this API.
Notes on operating system support for this:
macOS
I can confirm pressure-sensitivity with tldraw's drawing tool works for me on macOS, with either Chrome or Firefox, and a cheap Wacom tablet. Safari did not.
Linux
Chrome on Linux works out of the box; I used the Flatpak version. Your mileage may vary with the .deb or Snap package.
For Firefox, you may need to do this or this to get pressure-sensitivity working. There seems to be a regression with Xinput 2 support being tracked by bug #1207700, so maybe this will be fixed some day.
Windows
I don't imagine you'll have any problems on Windows, but I'm unable to test.
If you were interested in creating a web-based paint program in 2022, you might have a look at Pressure.js, which claims to support both pressure input and "3D Touch" present on some Apple devices in a single library. I have no first-hand experience with this library, though, so I can't back up those claims.
It's true this comes 9 years too late for your project. Sorry about that. But this question ranks high in search results for "pressure sensitivity javascript api," so perhaps it can still be useful to someone.
I've just installed ios7 on my iPhone, however I have not yet downloaded xCode5, so I've been producing my archives using iOS6 SDK and using TestFlight to test them on my phone. When running my app on iOS7, I'm noticing a lot of bugs that I didn't see in iOS6 (some that are unpredictable and very difficult to fix). I've been avoiding downloading xCode7 because I'm not yet ready to make the commitment to the new UI elements, but I'm wondering if I did produce my app using the iOS7 SDK, is it possible some of these bugs could be eliminated?
This is a very broad question. iOS 7, despite its advanced beta count, is still very much a work in progress. There are bugs that should be reported to Apple that should not happen. But beyond that, there are changes in the internal API that influence how the app behaves. Apple has done its best to try and preserve SDK 6 apps as much as possible, but there is breaking API which can cause crashes. One example off the top of my head is the class cluster they are now using with ABPersonViewController. Subclassing that in iOS 6 works fine, but in iOS 7, even when compiled with SDK 6, causes a crash in most cases. These issues can be resolved even with Xcode 4.6 and SDK 6.
Compiling with SDK 7 may help you fix some issues, but it will come with a plethora of issues of its own. Depending on how complex your view hierarchy is, you may have to invest a considerable amount of effort to support the new API and functionality. You don't really have a choice, as this is the future, but you should be prepared for this, and arrange your schedule accordingly.
I'm trying to build a crossplatform (Android-ios) mobile application, using Titanium SDK. I didn't have a chance for a long time to build it for ios, I only used my Windows-android combination, to test it, and it works great on the Android system. But when i try to build it on the mac for the ios, i get this message, and the application shuts down in a second:
The application has crashed with an uncaught exception
'NSInvalidArgumentException'.
Since i can not provide any relevant code, because the exception doesn't show what's the problem with my javascript code, and I certainly didn't write any native, ios specific code, i have no idea, what to do.
From the few posts i have found here is what i have tried:
Restart Titanium Studio
Clean the project
Made sure to close any ResultSet, and DB objects when done with
them (as suggested here: topic)
Test the code on both 3.0.0 and 2.x.x versions
I'm looking forward to any advice, on how you solved this problem, if you had it!
Thanks in advance!
Update:
The problem was the following: I called hasOwnProperty on Titanium UI elements, and on the ios version these elements don't have this function (which is weird, since every javascript objects have it, if i'm not mistaken).
If you have similar problems, i recomend reading this article, besides mr.VVoos answer, it helps a lot in avoiding the problems i had!
I'm developing with Titanim and iOS & Android for a long time. Usually there are many differences between iOS and Android parts of the code.
In most cases this exceptions means that an operation is called that is not available for the called class. (In Java this would mean: Class.method() -> Class has no method called method()).
You can try to run the app in debug mode (on iOS Simulator). There is a big advantage debuggin iOS compared to Android. Usually the iOS simulator stops if there is an exception and it shows the JavaScript code that caused the exception. Unfortunately this doesn't work all the time and it only works on simulator.
If this does not provide any further information you can do the following:
- go to your app.js and set a breakpoint in one of the first lines.
- start app in debug mode.
- move on this breakpoint each time until your app crashes - maybe then you are able to detect the error or provide further information.
One last tip: Check your code if there are any platform-specific parts. (Like Android Intents and something that is not available on iOS).
I know that this can be very ugly but we had to solve many of these nasty issues while migrating from iOS to Android.
I've read several of the posts on stack overflow already about this topic, but none of them seem to have real answers.
Here is my question:
The Apple documentation clearly shows what OS is required for each method, so why isn't there a tool to let me know if I'm using any methods that require an OS later than my deployment target?
If there is such a tool I'd like to know.
I'm currently building an App that I think will run fine on iOS 3.2, but I want to make sure. It seems to work fine in the 3.2 iPad simulator, but like I said, I want to make sure.
I don't want to go through each method one by one, and I don't want to set the deployment target to anything >= 4.0 because of how many people with 3Gs phones haven't upgraded to 4.0.
BTW:
I'm running XCode 4.0.2
Generally one sets this to the oldest firmware version one has tested on, if you aren't entirely sure about what APIs you're using.
Protip: Get an old device if you want to test on old versions. Set your deployment target ALWAYS to the oldest firmware version you've tested on.
It looks like there is no tool that does exactly what I'm asking. If anyone else discovers something, please let me know. It seems like it would be fairly easy for Apple to implement something like this.