Core Data Mutlithreading

After some consideration I decided that updating indeed needed to be done on its own separate thread. I did a bit of reading on how its recommended to use two contexts if multiple threads need to access a common persistent store. So I made a small test app for the sake of experimentation.

In the app, I made 3000 simple managed objects and saved them. Afterwards, I started another thread to do updating on them, but with a different context. After the updating done, I enumerated over all the objects in the new context, got their object IDs and made the call:

[self performSelectorOnMainThread:@selector(updateMainContextWithObjectID:) 

                                  withObject:anID 

                             waitUntilDone:NO];

In the updateMainContextWithObjectID: method I did: 

NSManagedObject* changedObject = [originalContext objectWithID:anID];

[originalContext refreshObject:changedObject mergeChanges:NO];

[coreDataDelegate saveContext:originalContext];

This ended up actually locking down my app until all the objects were updated. What I ended up discovering was the waitUntilDone: part should be YES. This gave me a true multithreaded feel.

Moving along, I found that changing the updateCoreDataStore methods of each of the XML data controllers to be run on a separate thread was relatively painless. However, there is one curious problem I ran into that in all my google-ing, I haven't found an answer. How does one handle managed objects deleted in one context and still around in another? That's what I'm going to be pondering for tomorrow.

In the mean time, I wouldn't be surprised if my svn update actually ended up breaking things. It compiles and runs, but I'd question the accuracy of the data presented. Well, at least I can hide behind the excuse that this app is still in alpha for now.

Character Updating

Character updating sort of works at the moment. However, there is still the issue of skills in training and this is where my knowledge of the matter is hazy.

When a skill completes training in-game, there is a small delay in which the skill training is finalizing. I've seen this delay be instant up to 30 seconds. What I don't want to be doing is querying the data so often as to bog down the API server. Is there a formula to determine exactly how long this delay is? From my readings online, the character sheet and skill in training XML files both use a short cache style, each with an hour in between cache expirations. However, whenever I make a change in-game and query a new XML file before a supposed cache expiration, the changes are reflected in the new XML files. Am I misreading something or is the information I have out of date?

That being said, there's also the issue of updating character information. Currently, on my computer, whenever I do an update on a character's skills there is a 2-4 seconds pause in the app where it locks up. This is because all the processing is done on the main thread. For now it's something I can live with. However, if a player is handling multiple characters, each with a large set of skills, then this delay may end up turning into an unacceptable 15-20 second delay. I'm really dreading having to move all the core data updating on a separate thread. All my readings indicate that Core Data just isn't easy to work with in a multi-threaded environment.

Just stuff for me to think about while I continue on with my work.

User Prefs

Never had to deal with NSUserDefaults up until now but found it very easy to understand. Later on I know there will be other preferences to store but for now I've got it set up that whenever you add a character, it will add it to the list of characters in the preferences file. Next time you relaunch the app, it will automatically load from the file. Fortunately, the data for that character is already stored in the Core Data database so there's virtually no wait on having everything load. The only thing missing in all of this, however, is the ability to remove a character.

The only other minor issue with this is the name of the file. Normally, the format would be "com.CompanyName.AppName.plist." The "CompanyName" in this case, though, is my full name and I'm not sure I like having my full name spread around that much. I'm still up in the air about what I should set it to be.

FYI

For those initially downloading the app and testing it out: The first time you compile to run it, it will take a while to load. That's because it's building the initial Core Data database and will take roughly 30 seconds to do. Afterwards, it should be smooth sailing. If you have any kinds of problems, deleting the contents of ~/Library/Application Support/EVE Mac Suite/ will probably solve the majority of them.

First submission

Well, the source code is officially in the repository. The link to it is here. 

You'll notice there isn't a release. That's because it's not quite ready for one. Here are a list of major things that need work to make it even partially useable.

• Storing character info upon quitting.
• Getting information about the current skill in training.
• Having the character information automatically update on a timer.
• Loads of error handling is missing.

Over the weekend I'll be tackling the following problems:

• Saving character data in as a plist prefs file (~/Library/Preferences/com.vadim.evemacsuite.plist?)
• Fix a Core Data update bug while importing character data. Getting this error and not sure what's causing it: Can't do regex matching on object ("Mizuki Yori"). Mizuki Yori happens to be my character's name, btw.
• Starting and hopefully finishing implementing current skill in training stuff.

Well, kind of a sad way of spending a friday night but nothing a Sam Adams can't fix.

Coming soon...

First, the obligatory long intro post.

Hi, my name is Vadim and I'm, well, a lot of things. I'm a Ukrainian, a student at WPI, a software developer, a husband and a casual EVE Online player. My interests in Objective-C started about a year ago when I got hired by Savant for a summer internship. I had an amazing time working there (not to mention being out on the Cape); the only thing I regret was having to leave. For six months I was exposed to quite a few Apple development technologies such as Cocoa, AppleScript, Core Data and Core Animation.

The purpose of this blog is to share my experiences as a developer. I'll admit that I'm not a complete expert with everything I'm doing. In a way, doing this project is a learning experience.  I know initially the vast majority of people coming to read this are completely clueless about Objective-C and just want to get the SourceForge link. However, if you happen to be a developer, particularly an Objective-C developer, your input would be appreciated.

Now, what this blog is not is a support forum. I know that initially there are going to be a lot of kinks to work out to make it somewhat stable before continuing on to newer features. I get that. I'll help out with the common problems but for all the minor quirks, time is needed to iron them out.

For now, I'll be the only developer. I'm doing this project as my Major Qualifying Project (MQP) for my college (sort of like a thesis). It'll probably be about 7 weeks before I'll need to submit what I have. Afterwards if you happen to want to help out I'll definitely consider it as I'll still be continuing to improve on it.

Currently I'm getting an approval from SourceForge. The program does a decent job of downloading the necessary data and updating the values. The screenshot there is pretty much where my current status is at. If you haven't already figured it out, the "currently training" stuff is bogus and is just serving as a placeholder. Also, the skill queue doesn't work, yet. As of this moment, I'm working on implementing caching. The data downloads but, however, its not updating itself yet. Oh, and yes, that is my character. If you're into EVE, you can tell this character has only been around for a couple months. And its poor. I will gladly take donations of ISK if you appreciate my work >.> . 

Anyways, hope to report soon on any updates. Also, I tend to read blog comments often so if you post to mine, you can be pretty confident I'll read it.