I am creating an iOS application which needs to send and receive data at the same time while being in one viewController rather than a CentralView and a PeripheralView. Is this possible? I have been using apple's sample code for bluetooth but I can only get half the data I need from that. How can I send and receive data from bluetooth simultaneously while in one viewController?
API is asynchronous so there is no problem
view controller should not do it. Write some class/service which will be manged by view controller, its life time should be different than view controller (depending on application).
Related
My scenario is:
Another (whatever app it is) try to retrieve the value from a Bluetooth device, But Bluetooth device doesn't send data other than our application.
Another application wants Bluetooth data it needs to call our app in background mode to perform an operation also in the background.
In short:
Retrieve data from Bluetooth in the background and share that content to another application.
If I tried using Custom URL it's open our application into the foreground. So, this one not covers our expectation.
Is that possible with Widget kind of? or any other method.
If any info missed let me know to understand my scenario.
I am loosely following this tutorial
https://www.raywenderlich.com/85900/arduino-tutorial-integrating-bluetooth-le-ios-swift
to write an app which reads streaming data from a BTLE peripheral. The app clearly demonstrates how to send data from my ViewController to the BTLE service to my microcontroller but I can't figure out how to get data in the other direction.
I have access to the data in the BTService object and I can print it out in the console but how would I update say a textBox from the BTService object?
I can find tons of iOS Swift tutorials but they all seem focused on things being triggered from the view controller. I can't find much on observing data in real time from the view controller.
I'm looking for the class that handles call duration UIView ( Or caller name ) for iOS 8
, So i could hook into it and find its frame position
What i tried and found so far :
I looked up the TelephonyUI private framework headers classes and Found nothing after so many hours of digging and trying
Sounds to me that it's related to MobilePhone.app but couldn't also find anything
syslog mostly logs data from it under Core Telephony Framework
On iOS 8 the in call UI no longers runs in MobilePhone or SpringBoard. It actually runs in a separate process - InCallService.app. It's works just like MFMessageComposeViewController I researched here. MobilePhone or SpringBoard (don't know for sure and it doesn't really matter), displays, what is called, remote view controller for in call view - it's a view controller which is being displayed in your app but the actual logic behind it runs in a separate process.
For example, when you display MFMessageComposeViewController to send SMS message from your app you actualy using proxy object which connects through XPC to another process where actual view controller code runs. Your app only sends user input to the process and displays results that it returns to you - remote view controller forwards method calls through XPC connection. You don't actually have any control over the controller - you can manipulate it through a very limited API provided by XPC service that implements the logic.
Obvious purpose of these remote view controllers is security. On iOS 5 there wasn't any and MFMessageComposeViewController was implemented just like a regular view controller. It meant that you could reverse engineer it to send SMS messages without user permission. And that exactly what some people did - there was AppStore apps that could send SMS messages silently using this code. Starting at iOS 6 that code requires special entitlement that AppStore can't have. MessagesViewService.app has it and through remote view controller running in it you can send SMS messages from AppStore apps but now you can't do it without the UI and user interaction.
Same with in call UI. You can test it by doing a call and then killing InCallService.app process - in call view will disappear. So in order to change something you need to hook InCallService.app. Unfortunatelly I didn't research it to tell you exactly which methods you need to hook but at this point it will be very easy. I suggest you start looking at PHInCallRootViewController, PHInCallRootViewControllerActual and PHCallParticipantsView. The latter has a very interesting method setSingleDurationTimerLabel:(id) which modifies _singleDurationTimerLabel ivar. It looks like duration label view.
I created an iOS app that has 3 Sphero enabled flows. I ended up rewriting setupRobotConnection and handleRobot online in each viewDidLoad then closing the connection in each prepareForSegue method. It works for the most part but the NavigationController's Back button can screw things up. I'm thinking this isn't the best way connect to a Sphero and maintain the connection.
For my app, each flow had slightly different handleRobotOnline needs
Flow 1: No driving, needs dataStreaming and AsyncData
Flow 2: Multiplayer classes for sending commands.
Flow 3: Joystick Driving with 1 view that required dataStreaming and AsyncData
My question is: for a multi-view app, where is the best place to:
1) Subscribe to app Notifications?
2) Subscribe to robot online/offline notifications?
3) Check if the app has the correct type of connection to the robot (driveControl, sharedMultiplayer, dataStreaming)?
I can paste code if necessary
It is best to manage your connection to Sphero and open/close it in one place. I find it is easiest to do this in the AppDelegate or the RootViewController.
For AppDelegate:
Open connection on applicationDidBecomeActive and applicationWillEnterForeground
Close connection on applicationWillResignActive and applicationWillTerminate
Register for robot state notifications in application didFinishLaunchingWithOptions
If you want to manage the connection in your RootViewController, register for robot notifications on load as well as the same application state notifications mentioned above and do the same connection handling.
By connecting in your AppDelegate/RootViewController you can allow your other ViewControllers to not care about handling the connection. You can either have them assume a Sphero is connected if you have logic to notify the user in AppDelegate/RootViewController, or you can share the state.
As for the particular use cases you mentioned I would recommend the following:
1. Add the data streaming and response observer on viewDidLoad, you should also enable data streaming here. Remove the observers on viewDidUnload and disable data streaming.
2. Use the multiplayer classes here as you normally would.
3. Add the data streaming and response observer on viewDidLoad, you should also enable data streaming here. Remove the observers on viewDidUnload and disable data streaming. Send joystick roll commands normally.
If you would like information about the robot connection state changing you can register/unregister for the connection notifications in each views viewDidLoad/viewDidUnload calls.
I'm looking into using the Channel API to push messages to my iOS client. I haven't completely wrapped my head around it, but the only way would be to use a hidden UIWebView that triggers an Objective-C method.
Would this work? To have a hidden UIWebView listening to channel messages? How would the web view be notified of new messages by the channel? How would I trigger an Objective-C method when a new message is received, such as an alert saying "You've received a new message."?
Are there any downsides to this approach?
I'm doing the opposite. I'm using Urban Airship to send iOS notifications to my iOS app, which is really an iOS wrapper around a UIWebView.
GAE Channels aren't particularly robust in my experience, I've noticed messages not get sent, especially when you have to re-establish a connection. I wonder if the UIWebView connection will get disconnected when the app goes to the background.
I'm doing what you are asking. There are two things you need to be able to do: make calls from Objective-C into the UIWebView, and get events from the UIWebView to call back in to Objective-C. To do the first you call UIWebView's "stringByEvaluatingJavaScriptFromString" method. To call back into Objective-C, you register a web view delegate, and then in the "shouldStartLoadWithRequest" method you look for a "fake" protocol (e.g. "js-callback" or something like that) so that in your javascript you navigate an iframe to "js-callback:informationForObjectiveCToOperateOn". This blog post explains the procedure: http://blog.techno-barje.fr/post/2010/10/06/UIWebView-secrets-part3-How-to-properly-call-ObjectiveC-from-Javascript/.