I'm writing an iPhone and Watch app. I'm planning on supporting the ability to pair multiple watches to the phone.
The iPhone and Watch app will both read and write to a Core Data datastore, and I'll use WatchConnectivity to keep them in sync (using transferUserInfo:). The user will write/dictate something on one device, and it will appear on the other.
I'm struggling to figure out how to support multiple watches. Given the following scenario:
User is using Phone/WatchA
Over the course of the day, user adds 10 items
End of the day, they switch to WatchB
How will WatchB get in sync with the Phone/WatchA?
Will WKSession automatically replay the transferUserInfo calls that were made when WatchA was paired?
Do I need to somehow keep track of everything WatchB needs and replay everything myself?
Do I just send the entire sqlite database using the transferFile API (that seems a bit much)?
Will WKSession automatically replay the transferUserInfo calls that were made when WatchA was paired?
No it won't. The data only gets transferred to the paired watch.
When you switch back to the other watch, you'd have to specifically arrange to update its store.
Do I need to somehow keep track of everything WatchB needs and replay everything myself?
In short, yes, if that's the approach that you take.
One edge case would be if the user replaces an old/broken watch with a new/replacement watch, yet didn't unpair the old one. You wouldn't want to keep track of a growing number of changes for a watch that won't ever be paired again.
You'd also have to handle the case where the user upgrades their phone, and pairs the existing watches with the new phone. Your device tracking and syncing should continue to work across a different device pair.
Do I just send the entire sqlite database using the fileTransfer API (that seems a bit much)?
It really depends on the size of the database, versus the complexity of journaling and syncing data between three or more stores.
What new features would help me keep my watch up to date?
If you must maintain multiple stores, you should definitely take advantage of the background refresh task feature in watchOS 3 to keep your watch(es) up-to-date before the user launches the app, so the user won't have to wait for anything to sync.
This answer might be helpful, even if you aren't using complications.
What are my other options?
Apple recommends that you design everything around the different ways of interacting with the devices. A user might just want to glance at the watch for a couple of seconds to review some items, but rely on the phone for more complex tasks.
In that case, you could maintain a single store on the iPhone, and transfer any needed data from the iPhone to be displayed on the watch. If anything changes, push the updated data back to the phone.
A "Handoff" approach works best, where the phone and the watch know what the most recent items were, and the user can switch between the phone and the watch during the day.
Of course, this is contingent on whether the watch must operate independently or not while out-of-range of the phone.
Related
This might be asking for the moon but here goes...
Is it possible to have an iOS app receive data and then forward it all while running in the background?
We're a restaurant currently using an ordering system that uses a main iPad as the till, with a second iPad in the kitchen to receive orders, and another third iPad used by the servers to take orders. Orders are sent to the main till which relays orders to the kitchen.
Works great... Unless someone switches app on the main till iPad to our other (necessary) hosting app, then all hell breaks loose and all orders stop getting sent.
Developer (small team) has told us it's impossible to solve but I have done some digging into recent Apple APIs that allow simple tasks to run in the background and have seen a few promising options, or perhaps it's possible via the External Accessory Framework, or even syncing via iCloud? A question for the more knowledgable than me, but is there currently a workaround to solve this that I could suggest or are they right in that it's currently impossible in iOS?
Yes there are ways to have an app in the background receive data, generally using either:
beginBackgroundTaskWithName:expirationHandler:
or
beginBackgroundTaskWithExpirationHandler:
Take a look at the Background Execution section in the documentation for more info...
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.
This comes close to an opinion question, but I hope that someone can give a definitive answer.
I have written a game app and I save game data locally. But I also will want it to be cloud capable and I am currently writing the code but I keep hitting a mental barrier. In several places in the iCloud and Game Center documentation it says if I change Apple ID, I need to delete the local save game data/file cache. This is contrary to how my app currently works, which is OK if I can figure out the right way to do it. In the ICloud documentation it says to either user the cloud or don't use the cloud and only ask once, but there is a button in the settings to turn the iCloud Drive on and off.
The core of my dilemma seems to be that an IOS device is not tightly linked to one Apple ID. I understand that multiple devices can be associated with one Apple ID, but not why it should be true the other way around.
This can be seen as either added capability or enough rope to hang oneself. As a user I can, using my Apple ID, get on to another device not associated with my Apple ID and:
download an App/Song
log into Game Center and play a game we both own.
etc.
I know Apple deals with this and now I have to do the same.
As App Developer I see a world of questions about what this might mean, like "Well I'll do this or that but what do I do the first time this other thing happens?", etc.
For example, initially I thought I could consider "local" store the same as a very long airplane mode, and when the cloud became available I could sync the delta to the cloud and across devices, but this does not address changing Apple ID. Do I blow away the local data, keep the new user from playing the game, only allow local or cloud but not both?
Now Apple is adding Multitasking, and a login to iPad's used in schools, the problems become even worse.
I keep trying to find some profundity that will steer me to the correct answer but I am at a loss on how to deal with Apple ID changes.
I want to develop application same as UBER in which I need to show available taxis in the selected region and update as the taxis are hired, available, unavailable. Kind of auto refresh.
Calling the web service in the background after regular time interval is not a good option.
Can any one suggest me better and fast way to achieve this.
Thanks
Push
Use sockets when the app is running. This will give you immediate updates.
Use Push notifications when the app is not running (use notifications for critical changes), and ignore these notifications when the app is already running, in favor of sockets.
Pull
Use NSURLSession to refresh your local DB with some regularity. This is very resilient to network failure.
Use a combination of approaches, since speed and robustness are mutually exclusive. Ultimately, your objective is to keep your local DB in sync with your server's DB, and fire internal messages as data changes. No small task, hence the Firebase answer.
The Most Simple way is to work with Firebase . Its No sql database and you will have instant update as you change anything .
This Video will guide you how speedy you can get update without any loop for refreshing data in application .
Ask me any help you need regarding Firebase .
You can use silent push notifications to update your map with updated taxi locations.
I would suggest you take a look at CloudKit. There are several reasons.
If you decide to just build one app and somehow have driver
functionality that is different from users (maybe by having drivers
register and sign-in) then the app can post shared data to a public
online database accessible to all users. You could use information
in this scenario to post local notifications as the need arises.
As iOS updates you will not be dependent on third party libraries
If you decide to create a driver app and a separate user app,
CloudKit will allow you to share data across these apps.
Apple deals with the security and availability.
Overall the process is very easy to implement.
You can combine the local notifications with the public database to
schedule reminders, alert users etc.
CloudKit when done correctly will be essentially free. Just transfer
CKAssets rather than raw data and your transfer/storage limits
become negligible.
You can also access your CloudKit databases from external web
services/websites if you want to extend the data further.
You can use CloudKit subscriptions to sync up user information
automatically
NB - As pointed out in comments this is new technology. It is in the
second generation and I prefer it because if one uses it creatively
then you can simulate the external push notification behavior together
with background support. CloudKit removes the need for a third party web server from which to push the external notifications (as the real notifications take place by writing to the shared database).
Check out my detailed answer on SO for sharing the data between apps with CloudKit. Here is a link to some CloudKit videos that further describe how CloudKit works. Apple has lots of documentation and sample projects available. You can review the developer website for more info on CloudKit.
CloudKit Quick Start
I recently came across an app in the app store called Dataman Pro. It has a feature that lets you see the data usage per app basis (see the attached screenshot). I have been wondering what is it doing to get this sort of information.
See this post about getting the list of installed apps, and this git project.
Then about usage tracking:
If you wondered about any public APIs that give you network statistics out of the box - there's nothing there.
DataMan it self is an app that used to work in the background all the time, and bind to the network interfaces to track network usage. Which is one of the reasons that its data is never 100% accurate as it is not guaranteed to always work in the background. This is also the reason Apple kicked it from the AppStore after a few versions...
Now that app has returned, if I understand correctly, after making a few changes: Mainly avoiding "hacks" to stay in background, and using Location Services to get back online when the user moves around. I guess this is another hack but one that Apple did not oppose to, yet.
Edit:
After looking around the web for a bit, it seems that Apple found that trick also, and removed many apps from the AppStore due to staying in the background by using location. I guess right now it's not working more than 10 minutes in the background, so you open it when you want to measure current Activity, and it stops measuring after 10 minutes.
About the tracking code itself, its mainly C code, using CFNetwork framework, and you can find some answers on stackoverflow on this subject.
More, in response to comment:
Well, the part about seeing the installed apps list, and foreground app, is not exactly private APIs, but private plist, as you mentioned.
Apps which access private files do get through from time to time. When Apple finds that some "private" files are accessed and need to be kept safer - they change it in an iOS update, like they did with the call history file, which is sensitive. Old apps tended to use (around iOS <= 3.3) the call history db to do some stats, and on iOS4 they were obsolete by the file moving to a secure location.
Reading "private" files which are unprotected is pretty easy to do without getting caught by automatic analyzers.
When you know which is the foreground app, and you can count current network usage, you can associate it with the app... And get an estimation. So this is how they do it, most likely.
However, The techniques change from time to time, due to Apple re-reviewing apps and their own policies, and due to API changes, and if you track the history of such apps and even this specific app - you will see that from time to time they get kicked off of the AppStore and return with a twist. They adjust... So no technique is reliable and this is a major headache to maintain, which is probably why the developer charges 9.99$ for it. I would.