I would like to remote control my Sonos System as well as my home automation system with my old IOS devices I do not use anymore. I have in multiple rooms multiple devices installed, so I'd like to develop per room a separate screen, which allows me to execute certain functions.
For instance in my garden I'd like to turn on the radio, change volume, change radio station switch on the light, dim the light.
I would like to have one screen showing me several buttons as well as slider.
Button1 labeled "mute" shall mute the Sonos system by calling a URL:
http://myphpwebserver/pagetocontrolsonos.php?mute=true
Button2 labeled "louder" shall mute the Sonos system by calling a URL:
http://myphpwebserver/pagetocontrolsonos.php?louder
and so on ....
The php page does not provide any feedback, but only calls the Sonos.
The PHP page is already developed and works fine. I just want to have native buttons in a native iPhone app.
In addition calling the Sonos I'd like to call my Home-Automation System to switch an dim ma light.
Slider1 labeled "light" shall call a URL from Home-Automation Server based on slider setting.
In case slider is set to the middle it shall call:
http://myhomeautomationserver/lamp.php?dim=50% - while 50% is the slider setting.
What do I need to perform to call a URL from a button or a slider?
Can someone help?
You can use NSURLConnection to send URL requests. Have a look at this tutorial for an introduction on how to do so.
Related
As a little holiday project I want to control an app via an accessibility switch which is connected via 3,5mm headphone jack to the iOS device.
This is the switch and the plug:
My problem is that I don't have any clue what kind of signal is fired when I press the button - I assumed that it acts similar to a headphone's remote control.
Is there a way to measure the input of this or does anybody know how to get the input of the button on iOS?
Your button is a "Big Buddy Button Switch," designed by AbleNet for persons with moderate to severe upper extremity and motor disabilities. It is not designed to plug into an IOS device nor into any mobile tablet or phone.
There is an "Hook + Switch" interface ($185 at this moment) that is designed to go between this button and an IOS device, allowing connection of two such buttons to the lightning connector. When connected in this way, the button press can be detected and mapped to many different kinds of IOS actions using apple accessibility settings. That's a lot of money, but since new iphones don't even have audio jacks it may end up being worth it.
A link to your button is here.
A link to the Hook+ Switch Interface is here.
A link to Apple information on accessibility switches is here.
The Big Buddy Button is a passive momentary action switch. The mono TS plug attached is connected internally to the momentary action normally open switch, so pressing the switch will short TIP to SLEEVE.
Plugging this TS plug into an ios device designed to receive a TRRS plug will short RING1 and RING2 and SLEEVE together even when the button is not pressed, which will not accomplish anything useful. Pressing the button will further short TIP to RING1 and RING2 and SLEEVE. There is no way to read such a button press from ios internals if the TS plug is plugged in directly.
If you want to hack together a solution that will work for many mobile devices (e.g., android) you can do so simply by replacing the TS plug with a TRRS plug (or wiring up an adaptor) as follows:
One of the two Big Button conductors should be connected to the SLEEVE, which carries power (for a microphone) and is the source of the voltage that is sensed internally for volume changes and switching. The other Big Button conductor should be connected to RING2, which is the ground line for both earbud channels and the microphone. Nothing should be connected to TIP or RING1.
Pressing the Big Button will momentarily short Sleeve to Ring2, which is the same as pressing the switch on an earbud cable. If you wanted to simulate a volume up or volume down command, you would connect a resistor in series with the button (220 ohms for volume down, 600 ohms for volume up).
The electrical connections for the audio jack are the same for iOS devices as for Android, but there's an extra hurdle you must get over if you want to connect up buttons and have them be detected within iOS. As part of their MFI (Made for iPod/iPhone) program, Apple uses a startup recognition chirp sequence when anything is plugged into the audio jack (or the lightning connector). Your device must have the correct chip inside it (or emulate the behavior of that chip) or else the button controls interface will be disabled when you fail to respond to the authentication request. The protocol seems to have changed over time, because aftermarket products that worked with one model of phone did not always work with another. Apple insiders have stated that the MFI chips contain a serial number that Apple can read upon connection. They say that reverse-engineered authentication works today, but that Apple could prevent it from working at any time.
If you want to design this as a product, you can apply for the MFI program here.
If you just want to build a handful of devices, you won't be able to get accepted into the MFI program. In that case you'd need to purchase the Hook + Switch interface (or something like it) or else you'd need to add a small microprocessor like an Arduino or a Teensy to emulate the authentication chirp, as David Carne did here.
If you just want to build one working button, the easiest way would be to use an existing pair of headphones that contain the necessary chip, and simply put your button wires in parallel with SLEEVE and RING2. If I were doing this I'd get a TRRS extension cord and splice the Big Buddy Button wires to the correct two wires of the extension cord. Your Big Button should work so long as a pair of apple-certified headphones are plugged into the extension to provide the authentication. You would then detect the button press as usual (described here).
EDIT: I tested connecting an accessory button to SLEEVE and RING2 of a TRRS extension cable that's plugged into the iPhone, and as long as a functioning headset is
plugged into the extension cable, the accessory button does work. This way the
accessory button ends up in parallel to the built-in button, without
having to cut apart the headset.
There are other alternatives you could pursue. For example, you could build a circuit that transmits a mic-level tone across the two conductors whenever the button is pressed. You'd then plug that signal into the iOS device between SLEEVE and RING2, and then write an iOS program to listen for the sound and treat it as a button press. MFI authentication would not be needed for this approach, and there are existing utilities that would get you 90% of the way there. You can find an example here.
It's also possible to connect to iOS through BLE without signing up for MFI, and since Apple Accessibility includes the ability to use a bluetooth device to control certain iOS functions, you may be able to do this without needing authentication.
An image showing the connection schematic for TRRS connectors on most mobile devices (including iPhone) is here.
Reproduced here for convenience.
Function/Mic == SLEEVE
Common/Gnd == RING2
Right/R+ == RING1
Left/L+ == TIP
If it was as headphone jack, you can handle it using
override func remoteControlReceived(with event: UIEvent?) {}
and toggle inside of it event?.type.subType something like this.
override func remoteControlReceived(with event: UIEvent?) {
if let e = event , e.type == .remoteControl {
if e.subtype == UIEventSubtype.remoteControlPause {
// do something
}else if(e.subtype == .remoteControlPlay){
//do something else
}else if(e.subtype == .remoteControlTogglePlayPause){
// do something else
}
}
}
Apples wired 3.5 mm headphone with volume control have 4 conductors. In your picture I see only 2 conductors. So your switch can't be sending the Apples's own headphone remote commands - since the the microphone ring for sending data is missing.
I'd guess your switch just makes contact between the two conductors.
Here is what I would do.
Verify with a multi meter the resistance of your switch in the open and closed position.
I'd expect on close the resistance is low or close to zero.
Now find an (old) pair of Apple 3.5 mm headphones with volume control. Disassemble the volume control of the headphones and solder your accessibility switch to the volume control pads. Now your accessibility switch simulates pushing the volume control.
Alternatively look at http://david.carne.ca/shuffle_hax/shuffle_remote.html
So use a micro controller to simulate the headphone volume control and use your accessibility switch to control the micro controller. It looks like a fun project - enjoy.
I'm developing a custom keyboard for iOS. When I'm e.g. in Safari using my custom keyboard, I have a button in my keyboard to jump to to keyboard containing app. Then in my keyboard app I have the iOS specific "<- Safari" button in the top left corner to jump back to Safari.
Is it possible to programmatically jump back to the source application (in my example Safari)?
Or can I send the original url scheme to my containing app and then open the previous app (could be ANY) by the url scheme?
It must be somehow possible, because the app Scandit Wedge does exactly what I want. I created an empty test app without any url scheme and with the Scandit Wedge keyboard I can go to Scandit app, read barcode and it goes automatically back to the source app.
Here's a video I recorded:
https://www.youtube.com/watch?v=UiHH4NanlkA
To achieve this you have to implement inter-app two way communication using x-callback-url. x-callback is just a "protocol" to format the NSURL to ease the data processing at the receiver end and also allowed the source app to receive the correct callback function. You can explore more this with evernote and this tutorial.
I would like to execute some code when user presses one of home, power or volume buttons(it doesn't matter, which of these).
I would like to catch events even application is minimized to background and device is sleeping.
So primary task is processing events, when device is inside user's pocket and the user presses button, but not takes out the device.
Is that possible? If it isnt't possible for power button, may be it's possible for volume or home buttons? How can I do it?
Your application cannot interact with the hardware buttons on an iOS device. Your application can receive notification that it has entered the background (which may be a side-effect of the use pressing the home button, for example) but that is about all
There is idea about volume buttons, if you create player instance you can get notifications about volume change, not sure that is still work but you can try.
see answers here: program access to iPhone volume buttons
I came to know that iOS does't support widgets this is what i have read.But i am making application on Security in iOS, i want the user to perform some action when he is in need of help without opening the application.
I know iOS supports few background modes like play audio,receive location updates,voip etc.
Can anyone suggest me any alternative to fire some methods without opening the application like pressing some button when in dangerous situation to call those methods.
I don't know whether we can do it or not.
But have a look.
You said we can implement background modes like audio, location, voip updates etc.
Let take the example of Audio mode. It has previous, play/pause, and next button in the lockscreen.
What you can do is play an audio when the application is in background mode.
Check whether the any of the music buttons are pressed more than 3 times. If this is the case trigger alert messages for security and send them to appropriate persons or do your own action.
I don't know whether we can do this or not. Even if it is possible, I can't say Apple will allow such false actions for buttons which are meant for some purpose.
Also see whether we can get detect volume button presses when in background mode. If that is possible you can do that. Because even my LG mobile has an SOS mode which is enabled when I press volume buton in lockscreen 4 times. Apple may allow this action if it possible
I am using AVPlayer to playback a continuous internet radio stream. I set up an AVAudioSession and my Info.plist to continue playback while the app is in background, and handle the remote control events to play, pause and stop.
On iOS there are controls for next and previous track in the multitasking bar, in the lock screen, on connected Bluetooth devices and so on. With these controls available and not "grayed out" the user assumes he could skip to another "track". But this is not possible in my scenario. There are no single "tracks". The app can only consume what is played by the icecast server.
Question: Is it possible to hide or disable these controls, so the user understands that it is not possible to skip to another "track"? (And if yes, how?)
No. Just don't respond to those controls. Respond only to the controls you do respond to (e.g. playpause button).
In this example from one of my apps:
The "next" and "previous" buttons do nothing; they are meaningless. But I've never gotten a complaint from a user.