0

I'd like some advice on how to implement the following in Objective C. The actual application in related to an AB testing framework I'm working on, but that context shouldn't matter too much.

I have an IOS application, and when a certain event happens I'd like to send a log message to a HTTP Service endpoint.

I don't want to send the message every time the event happens. Instead I'd prefer to aggregate them, and when it gets to some (configurable) number, I'd like to send them off async.

I'm thinking to wrap up a static NSMutableArray in a class with an add method. That method can check to see if we have reached the configurable max number, if we have, aggregate and send async.

Does objective-c offer any better constructs to store this data? Perhaps one that helps handle concurrency issues? Maybe some kind of message queue?

I've also seen some solutions with dispatching that I'm still trying to get my head around (I'm new).

Ev.
  • 7,109
  • 14
  • 53
  • 87

1 Answers1

1

If the log messages are important, keeping them in memory (array) might not suffice. If the app quits or crashes the NSArray will not persist on subsequent execution.

Instead, you should save them to a database with an 'sync' flag. You can trigger the sync module on every insert to check if the entries with sync flag set to false has reached a threshold and trigger the upload and set sync flag to true for all uploaded records of simply delete the synced records. This also helps you separate your logging module and syncing module and both of them work independently.

You will get a lot of help for syncing SQLite db or CoreData online. Check these links or simply google iOS database sync. If your requirements are not very complex, and you don't mind using third party or open source code, it is always better to go for a readily available solution instead of reinventing the wheel.

Community
  • 1
  • 1
Swapnil Luktuke
  • 10,385
  • 2
  • 35
  • 58
  • Thanks - that's a nice idea. Although I actually don't mind if some of these messages get lost, especially if the app is restarted. I'm also concerned about overhead so I want the solution with the smallest footprint. Having said that, I'll definitely be looking into this idea and doing some measurements. Thank you. – Ev. Jun 16 '15 at 05:53
  • Core data can easily work with in-memory data without any persistent store or database. So you can still implement a similar solution without a physical database. – Swapnil Luktuke Jun 16 '15 at 05:58
  • I've just had a hunt around re: Core Data and I actually think that might be exactly what I'm looking for. Will update when I learn more (I'm new to obj-c) – Ev. Jun 16 '15 at 07:03