iOS Programming what I think is a simple background app

[GregJobs]

So I have a need to take an iDevice and do, what I think is a simple set of functions to 1 end.

• I wanted to collect data on a device, maybe 10 basic things, serial number, free space, used space, device name, owner, network address, etc. Simple things, I imagine.
• Take that data, put it in a file with a specific name.ext.
• Ping a server to make sure it's available.
• Upload the file to a share on the server.
• Repeat this in 24 hours, every 24 hours.

So, I was thinking of harvesting the data. Then running the next steps as functions to...

Build the file
Ping the server
Upload

I have written in many other languages and haven't started yet in XCode 4.2 but my question (finally) is... for a beginner in XCode, how tough is this going to be with my experience in OTHER languages and can anyone offer any advice?

 

[robbieduncan]

An application that does this sort of thing is not one of the very small number of app types allowed to run in the background. So you will not be able to do this on the App Store. In addition I am not sure all of the things you want are available to apps using any public API.

 

[GregJobs]

So this isn't as straightforward as I assumed it would be huh? This would be in an enterprise environment, so the App Store doesn't really come into play.

 

[robbieduncan]

You code will still have to claim to be a navigation app (for example) to be allowed to keep running once launched. And if the user chooses to kill it via the task switcher that's it: you cannot force the app to be re-launched or to launch at startup. Finally XCode is an IDE, not a language.

 

[GregJobs]

This is probably a noob question then. How does PUSH work then where it can continue to "run" I guess receiving information from a server to effect the device. I imagine I can do that too where I have the server signal a broadcast to it's devices to run the program, harvest the data and send it back. No?

 

[robbieduncan]

No. Push does not automatically start your app. There are a very limited number of things you can do in response to a push message, for example badge the app. You cannot auto-start the app: the user has to confirm this and can cancel it.

 

[GregJobs]

Robbie,

I appreciate all your timely and concise replies but you're painting a grim picture here!

I know it's possible to do SOME of this, like harvesting the data, and dumping it to a file right? That's 50% of the job done.

The remaining external communication (sending OUT the data, or having the data picked up) and the 24 hour schedule are a maybe?

 

[robbieduncan]

Some of the data. As I said I think some of what you want may not be accessible.

Scheduling anything to run without the user approving it each and every time is pretty much a definite no unless you lie about what the app is doing and are not going via the app store (which you are not). In which case you still have to rely on the users starting the app and not terminating it.

Edit: It seems, reading between the lines a bit, that you are part of an enterprise that is giving iOS devices to employees and you want to be able to ensure they are being used appropriately. Have you considered the using enterprise configuration profiles to control the devices? Some documentation...

 

[GregJobs]

Actually I want to just keep some daily asset data on each iDevice we've got.

I will look into the documents you linked.

 

[jonnymo5]

To do what you want you need to work with jailbroken iPhones or you need to switch to Android. Just the nature of the beast.

 

[xStep]

Actually I want to just keep some daily asset data on each iDevice we've got.

If you have an enterprise app, perhaps just piggy back off of that.

 

[Canning.]

Seems like you're tryign to harvest personal info... why would you want to do that?

With a serial number you can socially manipulate Apple into sending you a replacement phone, but I doubt you knew that

 

[jnoxx]

Actually, you could totally fake it. Like doing so ->
Asking your device to use Location in the background, this will trigger methods even if it's in the background, or killed. and in that delegate method, call a method that will harvest them.
It's a very dirty workaround, but i'm just saying what came up x)