I want to make an app that can receive a signal from an external button without any cables involved.
For example, I've seen apps doing this with electronic door locks. When the door gets locked/unlocked the user gets notifed via the app.
In this case, I just want an external button, and when it's pressed the user gets notifed.
I'd love any tips on what I can use, thanks!
You probably want a Bluetooth Low Energy device that will be able to notify an app of an external change. There are many chipsets, such as the TI CC2540 family which can be used as a base. You'll then need an app that is able to discover this device, connect to it, discover its services and characteristics, ask for notifications, and act upon them.
However, your question is probably way too broad for anyone to provide a precise answer.
Related
I have written an Android application which, even after termination, still runs a service that listens for phone state transitions. This way, the application was able to detect new phone calls and trigger a certain event, for example the dialog partner's number was stored in a database.
Now I am eager to implement this application on iOS as well, but I cannot figure out if it is even possible to listen for phone calls in a similar way. For all I know so far about iOS, whenever my application is terminated by either the user or the OS, it is not possible anymore to detect new phone calls.
Is there any way I can achieve this, or have I already reached a dead end?
EDIT: As it was said to be too broad:
I want to detect both incoming and outgoing calls at any time. It there a way to do this on iOS 10? I do not want code, I just want to know if it is possible.
Please investigate further App Sandbox principe that Apple is using.
In short:
App Sandbox is Based on a Few Straightforward Principles By limiting
access to sensitive resources on a per-app basis, App Sandbox provides
a last line of defense against the theft, corruption, or deletion of
user data, or the hijacking of system hardware, if an attacker
successfully exploits security holes in your app. For example, a
sandboxed app must explicitly state its intent to use any of the
following resources using entitlements:
Hardware (Camera, Microphone, USB, Printer) Network Connections
(Inbound or Outbound) App Data (Calendar, Location, Contacts) User
Files (Downloads, Pictures, Music, Movies, User Selected Files) Access
to any resource not explicitly requested in the project definition is
rejected by the system at run time. If you are writing a sketch app,
for example, and you know your app will never need access to the
microphone, you simply don’t ask for access, and the system knows to
reject any attempt your (perhaps compromised) app makes to use it.
On the other hand, a sandboxed app has access to the specific
resources you request, allows users to expand the sandbox by
performing typical actions in the usual way (such as drag and drop),
and can automatically perform many additional actions deemed safe,
including:
Invoking Services from the Services menu Reading most world readable
system files Opening files chosen by the user The elements of App
Sandbox are entitlements, container directories, user-determined
permissions, privilege separation, and kernel enforcement. Working
together, these prevent an app from accessing more of the system than
is necessary to get its job done.
I was wondering how social networking apps, such as Twitter, Facebook and WhatsApp update their user interface in real-time when another user interacts with the user of the app. To use the best example I can think of: when you have a chat window open in WhatsApp, the UI updates automatically (without any user actions required) when the user you're chatting with interacts with you. Messages appear on your screen without refreshing and the "last seen" status at the top of the screen updates automatically when your chat partner either goes offline or comes back online. I can think of two ways to achieve this:
Remote push notifications: this approach strikes me as the 'cleanest' way to do this, but it's probably also the riskiest way. Using silent notifications (content-available) to pass data to another device at the moment a user does something, would probably save you a lot of HTTP requests and therefore would make your app consume a lot less data and CPU usage. The risk of this approach is that a user can easily disable ALL push notifications to save battery power (including silent notifications) and then your app wouldn't be able to get notified on events remotely.
Local UI refreshing: This approach is obviously the safest, but I think it's really 'nasty' and eventually everyone would feel the downside of it. Constantly refreshing the UI and re-retrieving data from the database to make sure the latest messages and statuses are displayed to the user would be safe in the way that your app doesn't have to rely on the device's battery and background mode settings, but the downside is that this will make your app consume a lot of data and battery power, which would be bad for the user's data plan and his device. I also don't think Apple would approve of an app that's consuming so much data and power.
I've just implemented a chat function into my own app, and I want to enable the same real-time UI updating that WhatsApp uses. What would be the best way to do this? Should I use one of the two methods above or can someone think of another way to do this? By the way, I'm a relatively new programmer who just recently learned how to develop iOS apps (Swift). I'm very far from being a pro, so please go easy on the explanations and work method capabilities. Thanks!
The chat apps make use of WebSockets to create a constant connection with the client and a backend server.
This article on Appcoda can help you start learning about Socket.io. It answers your questions and also helps you to create a demo app.
I was trying to get a specific info before a IOS App development task which I searched but couldn't find anything relevant.
Wanted to know whether this requirement restricts (non compliance issue as per publish guidelines) the app to be published in App Store with features as below
User scans and lists all available wifi connections in a tableview
Selects one of the Wifi connection and connects on button click
Stores the password and SSID for future connections.
Would there be any compliance issue related to the same functionalities when submitting to IOS app store. One of my colleague have advised me about the same but not able to explain why? Which I tried to find out searching the internet, but too specific to find anything relevant. Deeply appreciate an Expert advise on this.
Thanks in advance.
I can't find anything in the Review Guidelines that would object your app idea: https://developer.apple.com/app-store/review/guidelines
A couple of areas where you should have a more detailed look:
2.5.1 Apps may only use public APIs.
2.5.9 Apps that alter the functions of standard switches, such as the Volume Up/Down and Ring/Silent switches, or other native user
interface elements or behaviors will be rejected.
5.1 Privacy
Technically, I'm not sure if it's even possible to change the WIFI not via the settings app, so I'd have a look their first. (https://apple.stackexchange.com/questions/1592/is-there-an-ipod-app-to-easily-switch-wifi-on-and-off)
I don't believe I've ever seen an app or a way to change SSID outside the Settings app. I explored a way to detect network changes, connects, disconnects, which work fine while the app is running. I was never able to influence how the user connected, just that a change happened. It also falls apart pretty quickly when the user backgrounds the app. Trying to keep a background task open long enough to poll the current connection fails pretty fast.
I wish Apple would provide some system level notification of Wifi connect events. This could be very useful to developers that want a little more control than Background App Refresh events.
I work as a software developer, but I am absolutely new to Apple in general. We have the following case in a project, and we have not been able to figure out a solution for it, I would really appreciate some advise to find a solution (or drop the case if not possible)
A (potential) customer with multiple retail stores is interested in having a very simple app to display some content (this could an image or html, nothing too complicated) and periodically update this content from a server (this requirement is important). So it is very simple case, to use the device screen as advertising space
But here is the catch, users should be able to go out of this app and check out the device's system and other apps, and then the content should come back on the foreground when the device is idle. So basically we need something like a screensaver app that fetches the content (images) from a server and keeps them updated.
We have been looking at the guided access mode, but we are not sure it fulfills the requirements, because of the following issues
- Allowing the user to check out the device system and other apps. As far as we understood guided access restricts the device to one app.
- Re-launch the app (or bring it to the foreground) when the device has been idle for a period of time.
Note that we should account for a variety of devices (iPhone and iPads) with different OS versions
I appreciate your help and ideas. Thanks.
Apple does not allow apps to run continuously in the background except for a small limited group of exceptions. (music playing apps, for example.)
It's possible to set up your app to pretend to be a music playing app, and stay running in the background, but that means you will not be allowed on the app store.
Your client may be able to use the enterprise program to create apps for use in their retail stores. Enterprise apps don't have to go through the app store approval process.
I did this for a client recently (for an enterprise app.) As I recall I would have the app request background processing as soon as it moved to the background, and when it was notified that it's background time was ending, I would play a short "silence" sound and request another block of background time. Unfortunately it was work for hire and the contract ended, so I did not retain the source code.
There are 2 iPhone applications. One application running in the foreground and the other running in the background. Is there any way to get the background application to send data over USB without coming into foreground? Ideally we want to keep the foreground app in the foreground, while the background app process some data. Once the data is processed it will inform the foreground app that the data has been processed.
No it cannot. It cannot even do this without the use of private frameworks, unless you're in the Made for iPhone program. If you are, then your organization will know, based on the documentation made available to you, what you can and cannot access, when and how.
Should you be in the Made for iPhone program, and are unclear as to what you have access to and when, contact the person in your organization who is the technical contact with Apple for this program, they will be able to give you the details.
If the task is started while the app is in the foreground and you call the appropriate beginBackgroundTask/endBackgroundTask methods, you should be able to have it continue running after the app is backgrounded.
Note that access to USB is restricted (see jer's answer) and that there's no officially sanctioned way to communicate between different apps on the same device. Also, you can only buy/download one app at a time in the App Store and I can't see Apple approving an app that required you to download a second app for it to work. So you may have bigger problems to solve first.
It would help significantly if you told us what you actually wanted to achieve. For example, "I want MyApp on the user's phone to communicate with MyApp on the user's computer".
The absolute easiest way is to send data between the phone and a computer is to require that they're both on the same Wi-Fi network. Several iPhone apps incorporate a web server (this was the easiest way of "file sharing" before OS 3.2), and many more iPhone apps connect to a computer running server software.
Your other options, more or less:
Reverse-engineer the Bluetooth side of GameKit and reimplement it on the computer-side. I'm not aware of anyone who's done this. Loosely, I think it's IP over Bluetooth PAN plus some sort of Bluetooth service discovery.
Audio input/output, e.g. the headphone jack or certain pins on the dock connector. I'm not entirely sure how the mic side works (the resistance was a bit high for a carbon mic when I checked), but you might get lucky and find a way to turn it into "line in" or find "line in" pins on the dock connector.
A webcam pointing at the iDevice screen (and the iDevice camera pointing at the computer screen). Ewwwww.
Join the MFi program.