I wrote an iPad app to control a proprietary "robot" (based on a 3d-printer). With respect to providing a GUI to the robot, the iPad (mini) is ideal in a way, since it avoids additional I/O devices like e.g. a mouse or a keyboard and obviously comes with a display.
The app currently interfaces with the robot via WiFi (utilising WebSockets). While this basically works, every once in a while, latency seems to be an issue. At the same time, the WiFi interface to the robot seems to be a bit of overkill, since the iPad is physically mounted to the frame of the robot with a physical distance to its motherboard of less than 3 feet. - Also, the robot can be beautifully controlled from a serial terminal over UART (e.g. from macOS). - Therefore, I would like replace the WiFi/WebSocket communication with a simple serial interface.
Unfortunately, though, "/dev/tty.iap" does not seem to be accessible on iOS/iPadOS unless you enroll in Apple's MFI program, which - in this case - also appears as overkill, since our app will only ever be used internally. redpark.com makes (expensive MFI certified serial) cables and a library, which I consider a last resort ...
Jailbreaking the iPad might also be way to go. - However, I have no experience with this and would really like to avoid bricking the iPad. On the other hand, I have no basic objections against jailbreaking my device, which is exclusively used to control the robot.
Can anyone recommend a safe (e.g. jailbreak) route towards accessing "/dev/tty.iap" for in-house apps ? Would "/dev/tty.iap" be immediately accessible on a jailbroken iPad ? - Would the iPad have to be jailbroken again, everytime it is re-booted ? What would be a suitable Jailbreak tool for my purposes (candidates are iPad mini 5 with iPadOS 15.1 or iPad mini 2 with iOS 12.5.5) ? Are there any alternative routes towards accessing "/dev/tty.iap" for in-house apps (avoiding jailbreaking or MFI) ?
Thanks!
EDIT1 one more thought: There are numerous unpublished APIs providing access to normally "hidden" iOS-features. - While employing such APIs would disqualify any app for the AppStore, in "my" case, publishing the app is not even considered. Hence, if somebody is aware of unpublished functions that provide the desired access to "/dev/tty.iap", respective hints would also be appreciated very much.
Related
I have this solution for my customer's retail stores - they have iPad Air 2, with iOS 8.1.3, router and workstation with large TV and it's absolutely necessary that the iPad will stay connected only to WiFi I am providing with those routers. If anyone changes to another hotspot, the solution won't work. So I am looking for some ways that will prevent that, either in settings or via some app..
Also, it might work with apple configurator, but I couldn't find any site where it is mentioned.
Thx for advices
Unfortunately there is no means to restrict iOS devices to a single WiFi, even with an MDM and device supervision. I have a close relationship with Apple and this has been ask from education and retail partners for over 4 years now. I feel your pain.
A "workaround" for this would be possible if you happen to be using a single app that you have developed to access these resources. If that is the case you can either interrogate which SSID the device is attached to and throw a warning if it is not correct. There are also a myriad of other examples like this to detect the wrong SSID or spoofed SSID but no way to currently lock the device to the correct SSID.
I'm currently developing a mobile website with jquery mobile, not exactly responsive web design. I know I can develop the project in the browser on my desktop PC with some plugins or use some online services or simulators available. But I'm not sure if I missing something really important for test.
Example:
touch/swype events or viewport rotation.
Is necessary purchase some physical devices (smartphone/tablets) to develop/test the project? Why?
Intro
First don't let anyone tell you it is not necessary to purchase a real devices for a test purpose. I will tell you why from an Android perspective, same thing, just in a much smaller manner also goes for iOS development.
Good sides of an emulator testing
It is free, you only need a computer which will run your emulator.
You can test your applications in different cases (different screen resolutions, different OS versions)
Faster I/O and network operations but this is not so much a good point if you calculate how much everything else is slow.
Bad sides
It is slooooooooow, if you never tried to use it you can comprehend how slow it is (iOS emulator is fast like hell in a comparison). It doesn't matter if you have a top of a line hardware PC or Mac it is just that slow.
Emulator is simply to darn buggy, there will be a lot of times when application will work just fine on a read device and it will brake on an emulator.
This also goes other way around, sometimes application will work just fine on an emulator but will brake on a real device, in some case it will not work at all or it will not work on some devices. This is usually a case when working with hybrid applications. for some reason Android web view acts differently on real devices and on an emulator.
Emulator simply don't have some functionalities to interact with a hardware nor it can successfully emulate it. Hardware connection it can emulate even don't work correctly sometimes.
I have talked about how slow it is (because of a converting ARM bytecodes to x86 ones on the fly) but from a graphics standpoint it tends to be even slower so don't expect to do any game development on it.
Real devices comes with much more preinstalled software which may slower your application or in some ways enhance its functionalities.
Real world GPS testing is out of a question
Final notes
If you are intending to work with iOS only emulator can be used to do much of a development. Sheer lack of different screens sizes and hardware diversity makes it a perfect platform for a test purposes. Android on the other hand is completely different story, its emulator is simply useless for test purposes. I have several real Android devices, ranging from Android 2.1 + , different screen sizes and finally hardware architecture. You don't need to believe me but everything I mentioned play a significant role while testing Android applications.
If your main concern is testing your jQuery Mobile application I would still advise you a use of a real device in case of Android while in case of iOS you can successfully use emulator. Android is problematic because transition effects are to darn slow and that includes everything else that requires animations. Swipe will not be a problem and I can vouch it works just fine. Second real problem is a device rotation. jQuery Mobile sometimes can have a problem with it, mostly when used with non responsive 3rd party jQuery plugins (carousels, sliders ....). Third problem is mentioned in my list of bad sides, basically web view used in a emulator acts different then one in a real phone so sometimes you will see one thing in your real device and one thing in your emulator.
It is not necessary to purchase such a device.
For Android there is an emulator provided by the Android Development Kit (ADK). You can use it to configure multiple emulated devices with defferent screen sizes, etc. to test for multiple resolutions and Android (browser) versions.
[edit] Though to really test it for iphones you would need that emulator too I suppose, to make sure the website is correctly displayed in the provided browser.
[edit 2] To test "real" smartphone apps (not webapps), it is better to have a real device at hand.
This very much depends to which level you want to test it before you are happy to hand it over for the usage. After you do that and someone reports a defect, will you be able to see where is the problem (if it works on your PC)?
The development itself can be done in your browser, you can even simluate swipe events by dragging mouse. You don't even need any simulators, you can just make chrome window smaller (most of the devices are using some version of webkit, same as chrome).
However, once it comes to testing, I wouldn't feel great if I didn't know how it looks on the device itself. So I think having at least one device (ideally two with different OS and resolution) is always beneficial.
I would also be unsatisfied if I was working on something of which I could not see the result :)
I'm learning iOS development and I need to know what hardware I need to test my apps.
Is the iPhone/iPad simulator in Xcode sufficient? Or do I need the hardware? I have an iPad 2, and an iPhone 3G. The iPad 2 is one generation old, while my iPhone 3G is three generations old.
My first project is a basic card game with networking, based on a tutorial.
Opinion: Considering the number of questions I see of the form "this works great on the simulator but not on my device" I'd say that having hardware for testing is necessary. I don't think you need every possible device but certainly ones that cover the features that your app uses.
It depends on features you need.
Example of things you can't test in the simulator:
Push notifications
Performance of an OpenGL game (usually you need a wide set of device to test OpenGL)
The simulator can be used for development, but the simulator is not relevant for efficiency. It is very recommended to testing on a real device too. Some of the services can not be developed on the simulator:
the push notifications
in-app purchase
iCloud services
And you know, that the iPhone 3G is not able to be updated for the lastest iOS (your iPad is able).
The first answer is YES, you need hardware as there are differences between the behaviour of the simulator and the devices. They won't always act the same as the simulator is a bit more forgiving than the device.
For example the simulator will find files (images/sounds/models etc.) even if the case is different between the request and the file name, the device will not find them. And there are more.
An other point is whether to buy/have devices to hold different iOS versions. I don't have them all as this is too expensive for me but I can say that this is a problem. No matter how much you will try to consider the differences between the devices you will always miss something and your app might not work or crash on this device.
Still you can consider this question by looking at the apps that you are going to work on. I would say that if your apps don't use the device hardware (camera for example) and don't have features that might cause problems on different devices you will be able to start with out the devices.
Bottom line is that if you want to deploy good working apps, in most cases it will be better if you could test your apps on a variety of devices.
It's not a requirement to have a equipment to test, but certainly very important. You can test FPS of your app, even not containing hand-made OpenGL. All features that you use on your app, like view effects, are tested for sure on a device. Since simulator uses your mac memory, you won't see any side effects from memory shortage. I believe your best chance is to have a iPhone 4 and your iPad 2.
I'm working on my senior engineering design project and I need your help! For this I have my iPhone app receiving images from a external camera circuit, which I built.
To interface my iPhone app to the camera circuit, I have looked into the following approaches:
Build a bluetooth module on the camera circuit, to transfer images to the iPhone
Use Eye-Fi SD card to transfer images to my app somehow! link:http://www.eye.fi/products/iphone
Build a circuit, to make a wired connection to the iPhone with the 30-Pin dock connector
Here are the problems I'm facing with each of these. My actual questions for you guys are highlighted in BOLD:
The iOS BlueTooth framework (4S only), only supports Low Energy Devices. Looking at the the modules out there like this one, I'm doubting it will work for image transfer, which seems to be a bulky task for low energy bluetooth. I know there are jailbreak apps on the cydia store, which do regular bluetooth transfers, but I was unable to find those private APIs for such a task. (NOTE: I'm making this app for my purposes, so feel free to suggest any private/unofficial APIs). Question#1: How can I interface to a regular bluetooth device (not another iPhone) and transfer data?
EYE-FI card sounded amazing as a consumer because the company has their proprietary iPhone app to transfer the images from the EYE-FI SD card. Problem is I can't figure out how to easily interface with the EYE-Fi card in my code. I researched the iOS CFNetwork framework, but haven't had any luck. Question#2:How can I interface with the EYE-FI card in my app?
Building a circuit seems simple enough with this development board, but I read somewhere that the iPhone may not recognize an "un-registered" accessory. I have a developer license but not a MFi licence. Question#3: Do I need to be registered as a MFi developer to create and use this external accessory in my App for my own purposes???
You might try setting something up through a serial port since joining the MPi program is prohibited for individuals. You could possible use a connector like this one http://www.amazon.com/neXplug-Ultra-Small-Micro-Adapter/dp/B0055PCVDO/ref=sr_1_1?ie=UTF8&qid=1339309918&sr=8-1
The Apple website recommends individuals/hobbyists to use " recommend that you use a third-party solution which will allow you to connect iOS devices to serial devices and to write iOS apps that communicate with these serial devices" (from mfi.apple.com/faq).
I am also working on an external camera that can hook to the iphone/ipad. I will be using a serial port in order to get around the MFi requirement for external iphone/pad devices. Trying to use bluetooth is too complicated and the data stream isn't big enough for pictures. the wired version will work much better.
I hope this helps and that your college term and project are not already finished. Best of luck.
As T Reddy has already mentioned, if you want to create hardware the interfaces with external hardware framework, you have to sign up with the Apple MFi program which you, as an individual, can not do.
I'm not sure of how the Eye-Fi system works but it sounds to me that it basically syncs the images to their server and once you download their Apple App, the app can sync the photos for you.
Whether you are using Bluetooth or the 30-pin connector, there is no way to interface to an external device unless that device is MFi compliant and a part of the MFi program. I suggest you try the following options to solve this delimma--
If this is a "Senior Project" at some University, see if your University is part of MFi. Apple will not let individuals join the program, so if you are going to gain access, you have to access it through another organization or, possibly, an educational institution. I don't know if Apple has worked with schools in this regard, but you never know. It might be possible.
If your school isn't in the MFi program then you may want to consider re-writing your application for an Android device. Android devices are not locked down like iOS devices, so that may be a more reasonable approach.
I hate to bring bad news but circumventing these hardware restrictions on an iOS device is excessively prohibited. Your options are quite limited and none of them are probably what you either want or need to hear.
I am working on a major product release for my company. We are designing a new device that we would like to integrate into an iOS app. (FYI, we have recently been accepted into the Apple MFi program so we are past that step.)
What we desire is to create a hardware/software eco-system where our users can start our iPad app (yes, it is specific to the iPad and the not iPhone or iPod Touch devices) and the application will automatically discover and link up with any close-proximity hardware that we've developed.
This means that I will need to implement some form of device connection process on both the iPad and within the hardware.
Is there any way to code automatic connectivity to a Bluetooth device from within an iOS application?
I am aware of the Core Bluetooth Framework which has this capability, however, it only works with the new iPhone 4S. That's not an option.
I've also researched about the External Accessory Framework, which can be used to connect to external devices whether they are connected via the iPod port or Bluetooth. This is an option but, if my understanding is correct, our hardware must already be paired with iPad before the iOS software can connect to it. This is less than preferable because although many of our devices may not be in immediate vicinity at one point in time, our customers could potentially own 100's devices that they may desire to connect to with our software.
What are my reasonable options or alternatives? The end goal is to provide a very easy means for our users to be able to connect to our devices, from within our software, on an iPad.
NOTE: I MUST NOT jailbreak the iPad or break any Apple TOS agreements.
UPDATE (3-7-2012) I saw today that the 'New iPad' (as it is being officially called) will be Bluetooth 4.0 capable. I assume this means that this iPad device will be able to use the Core Bluetooth Framework. This doesn't immediately solve my problem because we do want remain compatible with at least the "last generation" iPad device, but this is worth pointing out for others who may be looking for such an answer.
You cannot connect an iOS device to a bluetooth device without pairing first. It is purposely built that way by Apple to reduce the likelihood that someone could connect a bluetooth device without the user knowing about it. If pairing each device is unacceptable (and it sounds like it is), and you don't want to develop a dongle, the only remaining path I can see is to make your devices capable of relaying data between them like a mesh network. That way the user would only have to pair with a single device, and that paired unit would relay communications between the other devices and the iPad.
One of your alternatives would be going WiFi (AdHoc or Infrastructure) with Bonjour. For example you would be able to detect the device nearby (if it is maintaining it's own AdHoc then by SSID; if it's in infrastructure network then by service being announced). One big drawback would be that you couldn't connect directly (from app) to the device's network - user would have to do it manually.
As for BT: big drawback is lack of a serial protocol (not implemented in iPhone/iPod/iPad).