On mobile based device Andriod/iOS limiting bandwidth is key. We used WCF JSON (if I was doing it now would use WebAPI MVC4) and Msmq to ensure message delivery. Server pushes data to mobile device by placing into a Msmq. Wcf always reads from Msmq for any requests
Mobile device stores data in SQLite and uses local queue to send and relieve data.
I am not familiar with IOS but I assume local data store can be used as a queue
Let's look at the broader question first. In some ways, your question boils down to the balance of pragmatism versus the theoretical "best way" for coding. I'm in the pragmatic programming camp, especially with your particular situation. Pragmatic coding means we work around the limitations that the current software stack imposes.
In your particular case, with your particular understanding of the stack, you're running into a challenge. You've identified a work-around and you've made things work for the time being. Part of those challenges are possibly introduced by your use of global variables, but as you stated, it made sense for the information that needed to be stored.
I think using a TestingClass
is a perfectly valid approach since you're fulfilling the purpose of testing (making sure things operate as expected) and you're also working within the constraints, as you understand them, of the application you created. You certainly wouldn't be the first to put a test harness in place during development and then remove it prior to releasing the app.
You do run some risks with that approach. Specifically, if you forget to disable that class before releasing to production, that could create problems for you. Likewise, you effectively have to duplicate all of your code between the main path and the testing path. So you run a risk of a bug escaping if the testing path doesn't exactly reflect how the main path operates. Finally, it does build up complex test cases which can be more difficult to debug because you have to unwind things to understand where it broke.
So, as far as the particular approach that you've taken - it's valid enough.
It may not be "pure" in the sense of following traditional, automated unit testing, but I think that pragmatism needs to rule the day. People don't buy your application because of the unit tests, they buy your app because it works. Your approach to unit testing provides regression testing and allows you to keep focused on developing new features.
Best Answer
You have some options:
1 - Convert them to class. So you can inherit from
NSManagedObject
and do the rest like the tutorials you usually find in internet.2 - Make a rapper around any struct you want to store in core data. For example if you have some struct like this:
it will be wrapped like this:
but be careful about differences of a value type and a reference type and a nested mixed type. You can even make some of the implementation more private to make extra codes more transparent.
3 - You can make your structs conform to
NSCoding
and encode it directly to the database. but unfortunately as it seems, you can not perform well efficient queries on them.4 - Use other libraries instead of CoreData. There are some libraries out there supporting structs out of the box and some of them are written on top of the CoreData.
5 - Don't use database at all! I don't know your use case but if there is no relations between objects, You usually don't need a data base at all. A simple file system can do all stuff.
Oh and one more thing, If you are new to CoreData and you just want to play with it until you learn it, stick to the first option. Once you get used to it, examine other options as well.
Good luck.