iOS Help needed in solving this mess.

[troop231]

The networking code goes off and does it's own thing during the setup. That takes time. Exiting before that finished cause my app to crash as you described. Perhaps there is a better way, but I didn't find it. I doubt ARC will help here.

jnoxx's suggestion is the likely solution, but...

You can connect the back button to a local method, do the things you need done there, and then send the view controller the exit message. I think the final line in that method would be this;

[self.navigationController popViewControllerAnimated: YES];

Here is what I did to stop the activity indicator:

-(void)viewWillDisappear:(BOOL)animated { [UIApplication sharedApplication].networkActivityIndicatorVisible = NO; 
    [webView stopLoading];
    
}

That also takes care of stopping the webView too.

Edit: I solved the crashing just now, here's what I had to do:

I moved

[toolbarStop release];
    [toolbarRefresh release];

from the -(void)dealloc method to the -(void)viewDidUnload method, it works perfect now!

 

[xStep]

Edit: I solved the crashing just now, here's what I had to do:

I moved

[toolbarStop release];
    [toolbarRefresh release];

from the -(void)dealloc method to the -(void)viewDidUnload method, it works perfect now!

That's interesting. I wonder if you've just delayed the issue somehow, or fixed it by accident. There is just something about it that is nagging me.

 

[jnoxx]

viewDidUnload is only getting called normally when an Memory Warning level 1 is sended to your controllers, so you normally need to release & set to nil in the viewDidUnload and the release is when the controller gets released.
But, if you are autoreleasing objects, know that you should NOT release them again. Like xStep said, i think you are just delaying the issue and not actually fixed it. Have u tried memory leaking against it?
Command+Shift+B or run it through analyzer vs Leaks. I thinnk you're going to have some issues.
If you can't figure it out, i'll try to find my code when I last dealt with webview

 

[troop231]

viewDidUnload is only getting called normally when an Memory Warning level 1 is sended to your controllers, so you normally need to release & set to nil in the viewDidUnload and the release is when the controller gets released.
But, if you are autoreleasing objects, know that you should NOT release them again. Like xStep said, i think you are just delaying the issue and not actually fixed it. Have u tried memory leaking against it?
Command+Shift+B or run it through analyzer vs Leaks. I thinnk you're going to have some issues.
If you can't figure it out, i'll try to find my code when I last dealt with webview

I was not able to run the analyzer, Xcode says: "The scheme 'OutdoorRules' is not configured for Analyzing." Tried to fix it to no avail. If it helps, this project is an older non ARC one (based on OS 3.0 code)

Any help is appreciated.

 

[xStep]

I was not able to run the analyzer, Xcode says: "The scheme 'OutdoorRules' is not configured for Analyzing."

A Google search came up with suggestions on Stackoverflow. Seems your scheme messed up.

 

[jnoxx]

I never used ARC, so I'm in the same boat, so all I can say is, try to recreate your schemes, if you know how to go to your schemes (otherwise google it), there is a button to REMOVE, and then autocreate. Try again
Gl

 

[troop231]

I made this flowchart to describe what I'm after, doesn't seem so bad right?

[Click for larger]

 

[xStep]

I understand what you're trying to do. Perhaps title them if you are going to show them to others.

Flowchart 1 suggests the action is from a list of states. So I'm guessing that you will download all PDFs for a state and fishing/hunting combination when the user requests a download.

Flowchart 2 suggests to me that you will display the update request button when the user has a document open, allowing single PDF updates. You might also want a general update request button on the main screen.

In the first chart, just a nit-pick on wording. The "(I.E. first app store download)" is not correct. They may not have the state they are looking for, but may have others already downloaded. Also, don't display a blank webView. In that case, either keep the user at the level they were at when they initiated an action, or back up a level if needed.

Some constructive criticism/suggestions...

I do have a suggestion, that I think I already mentioned. Instead of having the user press a button to do a check, why not do the check when they first start up the app. You could do that on a background thread. If a change is detected, then put up a update request button where you wish. Otherwise it isn't needed, except as perhaps an aid to user satisfaction. Use of a notification (perhaps UIApplicationDidBecomeActiveNotification) in the app delegate to trigger a (successful) check say once a day, GCD (Grand Central Dispatch) to kick off the thread, and another notification or KVO (key value observing) to observe a flag or object of updates which would display the update request button if needed.

If you are thinking of listing all the states even when some states do not have documents, I think that is a mistake. If you insist, then do some coloring trick to distinguish those from states that have documents. If it were me, I'd only list the states that have local documents, and I'd have a + button on the right side of the navigation bar when in the states listing so users could request applicable documents for a missing state. I'd also implement a method to allow users to delete states, and documents within states.

Of course those suggestions change your flow chart.


Just curious, how will you get the UIProgressIndicator to work. I haven't used the web download tools yet so I'm wondering how that works.

BTW, what app did you use to create the flowchart?

Did you sort out your scheme issue? If so, what was the solution?

 

[troop231]

I understand what you're trying to do. Perhaps title them if you are going to show them to others.

Flowchart 1 suggests the action is from a list of states. So I'm guessing that you will download all PDFs for a state and fishing/hunting combination when the user requests a download.

I wasn't planning on a combination at all, if the user wants fishing for Alabama, then that's what he/she will get, not hunting with it.

Flowchart 2 suggests to me that you will display the update request button when the user has a document open, allowing single PDF updates. You might also want a general update request button on the main screen.

I was just wanting to always have a refresh button on the navigation bar permanently, maybe in future it could be conditional (focusing on baby steps after all lol)

In the first chart, just a nit-pick on wording. The "(I.E. first app store download)" is not correct. They may not have the state they are looking for, but may have others already downloaded. Also, don't display a blank webView. In that case, either keep the user at the level they were at when they initiated an action, or back up a level if needed.

I mean that it will only check for the selected table cell/ animal category, the other states will be downloaded individually and not in bulk.

Some constructive criticism/suggestions...

I do have a suggestion, that I think I already mentioned. Instead of having the user press a button to do a check, why not do the check when they first start up the app. You could do that on a background thread. If a change is detected, then put up a update request button where you wish. Otherwise it isn't needed, except as perhaps an aid to user satisfaction. Use of a notification (perhaps UIApplicationDidBecomeActiveNotification) in the app delegate to trigger a (successful) check say once a day, GCD (Grand Central Dispatch) to kick off the thread, and another notification or KVO (key value observing) to observe a flag or object of updates which would display the update request button if needed.

If you are thinking of listing all the states even when some states do not have documents, I think that is a mistake. If you insist, then do some coloring trick to distinguish those from states that have documents. If it were me, I'd only list the states that have local documents, and I'd have a + button on the right side of the navigation bar when in the states listing so users could request applicable documents for a missing state. I'd also implement a method to allow users to delete states, and documents within states.

Of course those suggestions change your flow chart.

You're right, but I don't think my knowledge is that great at the moment, and it would aid user satisfaction.

Coloring sounds neat, just not sure how to implement it at the moment.

Just curious, how will you get the UIProgressIndicator to work. I haven't used the web download tools yet so I'm wondering how that works.

Shouldn't be too hard, it checks for a certain amount of bytes expected and changes the progress accordingly. One thing I'll need to be careful of is to limit the download rate so Apple doesn't reject the app. Isn't it 5MB a minute max? Another thing, if the user minimizes the app to the home screen, I'll need a way to background the download pdf task so it doesn't stop every time the user multitasks.

BTW, what app did you use to create the flowchart?

Gliffy online based flowchart tool http://www.gliffy.com/gliffy/#templateId=blank&signup=1

Did you sort out your scheme issue? If so, what was the solution?

I didn't yet

Thanks for your thoughts again! I enjoy the collaboration and brainstorming

 

[xStep]

You're right, but I don't think my knowledge is that great at the moment, and it would aid user satisfaction.

Coloring sounds neat, just not sure how to implement it at the moment.

Here is some pseudo code for an idea how I think it could be done. My thought here is to change the background color. You could also change the text color. A more advanced method would be to add a custom background view to make it look exceptional.

- (UITableViewCell *) tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
	UITableViewCell *cell;
	NSString *cellIdentifier;

	someObject = [data objectAtIndex: indexPath.row];
	
	if ([someObject hasPDFs]) cellIdentifier = @"cellWithData";
	else cellIdentifier = @"cellWithNOData";

	cell = [tableView dequeueReusableCellWithIdentifier:cellIdentifier];
	if (cell == nil) {
		cell = [[[UITableViewCell alloc] initWithStyle: UITableViewCellStyleSubtitle reuseIdentifier: cellIdentifier] autorelease];

		if (![someObject hasPDFs]) {
		[[cell  backgroundView] setBackgroundColor: [UIColor lightGrayColor]];
		}
	}

    <what ever you do here>

    return cell;
}

Thanks for your thoughts again! I enjoy the collaboration and brainstorming

It's fun and gives me a chance to think about how something might work and look.

Those baby steps your taking will get you to a more advanced product, just a little slower. That isn't a bad thing. It is more important to keep your product stable.

 

[troop231]

Is there any way I can check to see if a documents directory exists? I know I can check to see if there is a file in the mainbundle, but what I'm wanting to do is check to see if the user has already downloaded and stored a pdf in the NSDocuments directory. Also, if no NSDirectory exists, I hope that the function would be able to determine that as well.

 

[xStep]

NSFileManager and other calls are available. Perhaps these two samples, ripped from my own code, will lead you in the right direction.

+ (NSString *) appRootPathString
{
	NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
	NSString * documentsDirectory = [paths objectAtIndex: 0];
	return documentsDirectory;
}


if ([[NSFileManager defaultManager] fileExistsAtPath: videoPath] ) {

 

[troop231]

NSFileManager and other calls are available. Perhaps these two samples, ripped from my own code, will lead you in the right direction.

+ (NSString *) appRootPathString
{
	NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
	NSString * documentsDirectory = [paths objectAtIndex: 0];
	return documentsDirectory;
}


if ([[NSFileManager defaultManager] fileExistsAtPath: videoPath] ) {

I tried this in my code:

NSFileManager *fileManager = [NSFileManager defaultManager];
    NSString *documentsDirectory = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
    NSString *path = [documentsDirectory stringByAppendingPathComponent:url2];
    if(![fileManager fileExistsAtPath:path])
    { UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Woops!" message:@"You haven't downloaded this regulation yet, would you like to?"  delegate:self cancelButtonTitle:@"Cancel" otherButtonTitles:@"OK", nil];
        [alert show];
        [alert release]; 
        
    }
    
    else { NSURL *url = [NSURL fileURLWithPath:path]; NSURLRequest *requestObj = [NSURLRequest requestWithURL:url]; [webView loadRequest:requestObj];
        timer = [NSTimer scheduledTimerWithTimeInterval:(1.0/2.0) target:self selector:@selector(loading) userInfo:nil repeats:YES];
    }

But I don't think it's working correctly. url2 is set in the rootviewcontroller to read a value in the plist which indicates the file name:

NSString *url2 = [dictionary objectForKey:@"URL"]

plist screenshot:

What I don't understand is, I have Alabama.pdf in the main bundle, and it's not being loaded into the webView, but rather the UIAlert gets shown. This is actually what I want in the long term, but why isn't NSFileManager detecting the files that are currently in my main bundle?

I'm getting alot closer to what I want Thanks in advance again!

 

[xStep]

I haven't looked into the details yet, but as I understand it, the main bundle is separate from the apps document path. For all I know, the document folder is just another folder within the main bundle. Like I said, I haven't reviewed the details. Your code is looking into the apps document path which upon first startup has no data in it.

Upon first startup, you would want to copy the appropriate resources to their appropriate places in the apps document folder. You'll need a method to avoid overwriting newer versions of the documents that have been later downloaded into the document folder structure.

Based on the information you provided, the fileExistsAtPath: statement is trying to confirm a folder exists within the document folder. Something like "~/Alabama", where the tilde represents the document folder. Don't use a tilde on iOS.

Also, it doesn't look like you are building your url properly in the area you are trying to load the existing file. You are only pointing to the folder, so what would the request load. At best, you'd see a listing of the folder. I haven't used webViews so don't really know.

Put some NSLog statements in to see the results of your path and url variables. That will help you understand what the paths actually look like.

 

[troop231]

I haven't looked into the details yet, but as I understand it, the main bundle is separate from the apps document path. For all I know, the document folder is just another folder within the main bundle. Like I said, I haven't reviewed the details. Your code is looking into the apps document path which upon first startup has no data in it.

Upon first startup, you would want to copy the appropriate resources to their appropriate places in the apps document folder. You'll need a method to avoid overwriting newer versions of the documents that have been later downloaded into the document folder structure.

Based on the information you provided, the fileExistsAtPath: statement is trying to confirm a folder exists within the document folder. Something like "~/Alabama", where the tilde represents the document folder. Don't use a tilde on iOS.

Also, it doesn't look like you are building your url properly in the area you are trying to load the existing file. You are only pointing to the folder, so what would the request load. At best, you'd see a listing of the folder. I haven't used webViews so don't really know.

Put some NSLog statements in to see the results of your path and url variables. That will help you understand what the paths actually look like.

Thanks again! I was able to figure it out, as I've now got a bulk of what I needed to do accomplished now. Wow! I can't believe everything I got done in 24 hours, as indicated by the Red X's:

Now another question, is there a way I can check to see when a file was last modified so I can compare that date to the date in the documents directory?

The reason I ask, is this would be easier than the other way I have planned, which would be to create a plist and add a key called 'Number' and set it to an integer. The app would then read the locally saved plist and if local 'Number' is less than server 'Number' key, show an update.

Edit: Would something like this work well?

NSDictionary *dictionary = [[NSFileManager defaultManager] attributesOfItemAtPath:filePath error:&error];
    NSDate *fileDate =[dictionary objectForKey:NSFileModificationDate];

Side note, I'm so happy that my app is only going to be about a 1MB download from the App Store after I get this update rolled out, that sure beats the current 843MB app download size

 

[xStep]

Using any of the dates for a file entry is not the right thing to do. The reason is that devices have different time zone or potentially could be out of sync with accepted reality. The differences could cause your code to suggest a change is always present. Also, your server may not have the date you expect. Without being able to control these factors, those dates would be considered unreliable.

The 'proper' way to do this is something independent from file time stamps, such as your number sequence technique. Frankly, coming from a corporate database background and having maintained a document control system, I'd track each document by a date and perhaps the time too. Since you probably can't get accurate dates from your all of your sources, I'd use the date you downloaded or processed the downloaded file to your server. Just the date would likely be fine as I doubt it common for a state to update one of those documents more than once a day, even if they find errors. Also if your check is only once daily, that would be enough resolution of a noticed change.

If you know each document has a definite date or other document tracking number, you could use that as your tracking key. The real thing to note will be a change from the previous key to the new key. What that key actually is, is likely irrelevant.

The number of documents involved is likely small enough that a plist will be fine performance wise. The next step up would be to use Core Data.

Oh, forgot to add. I don't trust the system modification. Seems I recall that OS X, and I'd assume it is possible for iOS, sometimes alters that date even when I think it shouldn't.

 

[troop231]

Using any of the dates for a file entry is not the right thing to do. The reason is that devices have different time zone or potentially could be out of sync with accepted reality. The differences could cause your code to suggest a change is always present. Also, your server may not have the date you expect. Without being able to control these factors, those dates would be considered unreliable.

The 'proper' way to do this is something independent from file time stamps, such as your number sequence technique. Frankly, coming from a corporate database background and having maintained a document control system, I'd track each document by a date and perhaps the time too. Since you probably can't get accurate dates from your all of your sources, I'd use the date you downloaded or processed the downloaded file to your server. Just the date would likely be fine as I doubt it common for a state to update one of those documents more than once a day, even if they find errors. Also if your check is only once daily, that would be enough resolution of a noticed change.

If you know each document has a definite date or other document tracking number, you could use that as your tracking key. The real thing to note will be a change from the previous key to the new key. What that key actually is, is likely irrelevant.

The number of documents involved is likely small enough that a plist will be fine performance wise. The next step up would be to use Core Data.

Oh, forgot to add. I don't trust the system modification. Seems I recall that OS X, and I'd assume it is possible for iOS, sometimes alters that date even when I think it shouldn't.

Thanks for your input!

I'm deciding that I will allow the user to check for updates whenever they want, because they are the ones who wanted this feature in the first place. My blue "Updates" button that's in the navigation bar will be shown only after the first PDF is downloaded, because if they haven't downloaded anything yet there's no reason to show it (already got that part figured out yesterday)

So here is how I'm thinking about going about the checking for updates procedure:

This will be the plist that resides on the server, and will download along with the associated PDF file as well.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>UpdateNumber</key>
	<integer>1</integer>
</dict>
</plist>

So, whenever I want to add a newer PDF to the server, I simply edit and add +1 to the integer in the plist, ex:

<integer>2</integer>

The app will compare the server's integer in the plist to the integer of the plist stored locally for the associated PDF, and if the local plist integer is not equal to the server's integer, then there is a new PDF (update available)

This is totally doable correct?

 

[xStep]

Doable? Yes.

One thing I thought of is that you have cases where there are several documents for a category. Have you considered how you are handling that? How about cases where a category has a new document added?

It might be redundant but I think I would put the document file name in the plist also. Just a thought.

 

[troop231]

Doable? Yes.

One thing I thought of is that you have cases where there are several documents for a category. Have you considered how you are handling that? How about cases where a category has a new document added?

It might be redundant but I think I would put the document file name in the plist also. Just a thought.

Yes, some categories will have several documents. The way I'm going to do it is like this: (url scheme)

server.com/PDFS/Alabama/AlabamaHunt.pdf
server.com/PDFS/Alabama/AlabamaFish.pdf

and I will have a .plist for each pdf file in the same state directory, ex:

server.com/PDFS/Alabama/AlabamaHunt.plist
server.com/PDFS/Alabama/AlabamaFish.plist

 

[xStep]

Ah, but California has two fishing documents, freshwater and saltwater, and Alaska has five hunting guides. So you might need another directory level to distinguish hunting and fishing, I suppose this would work too;

server.com/PDFS/California/CaliforniaFishingFreshWater.pdf
server.com/PDFS/California/CaliforniaFishingSaltWater.pdf
server.com/PDFS/California/CaliforniaHunt.pdf
server.com/PDFS/Alaska/AlaskaHuntBigGame.pdf
server.com/PDFS/Alaska/AlaskaHuntSmallGame.pdf
server.com/PDFS/Alaska/AlaskaHuntTrapping.pdf
server.com/PDFS/Alaska/AlaskaHuntWaterfowl.pdf
server.com/PDFS/Alaska/AlaskaHuntFalconyManual.pdf
server.com/PDFS/Alaska/AlaskaHuntFish.pdf

I'm not convinced keeping plists for every PDF is a great idea, but it does keep the implementation simple enough for now. It likely keeps the bandwidth lower because you aren't exchanging a large dataset every time someone checks in.

I can't wait to try it out!

 

[chown33]

Ah, but California has two fishing documents, freshwater and saltwater, and Alaska has five hunting guides.

There are also boundary conditions. Literally. The Colorado River is a boundary river and has specific rules, regs, and licenses. Enforceable in the states of Arizona, California, and Nevada, on the river, its lakes (dammed), and some tributaries.

 

[troop231]

Ah, but California has two fishing documents, freshwater and saltwater, and Alaska has five hunting guides. So you might need another directory level to distinguish hunting and fishing, I suppose this would work too;

server.com/PDFS/California/CaliforniaFishingFreshWater.pdf
server.com/PDFS/California/CaliforniaFishingSaltWater.pdf
server.com/PDFS/California/CaliforniaHunt.pdf
server.com/PDFS/Alaska/AlaskaHuntBigGame.pdf
server.com/PDFS/Alaska/AlaskaHuntSmallGame.pdf
server.com/PDFS/Alaska/AlaskaHuntTrapping.pdf
server.com/PDFS/Alaska/AlaskaHuntWaterfowl.pdf
server.com/PDFS/Alaska/AlaskaHuntFalconyManual.pdf
server.com/PDFS/Alaska/AlaskaHuntFish.pdf

I'm not convinced keeping plists for every PDF is a great idea, but it does keep the implementation simple enough for now. It likely keeps the bandwidth lower because you aren't exchanging a large dataset every time someone checks in.

I can't wait to try it out!

Yeah, at first I thought about using just one plist, but it quickly grew to almost 100KB in size, so now I'm using individual plists which are only about 200 bytes. This cuts down on the latency and makes it almost instantaneous.

Right now all I have left to do is try to figure out how to migrate everything to download asynchronously, as right now everything is synchronous

 

[xStep]

Regarding the downloads. Your getting out of my area of experience. One thing to keep in mind is, if you are want to download several documents simultaneously, don't over do it as too many would give bad performance.

I have thought of one consideration. What will users do when they next update and find they don't have their documents because the update doesn't come with them?

An idea might be to post an update that keeps track of what documents they look at. Immediately upon startup of the 'new' non-preloaded document version, let the user know that they need to download those tracked documents.

At the very least, in your app changes entry, make it as clear as you can. Maybe even in the first description lines, for those that look at that kind of thing. I doubt though many current customers will see either though as they will just update. A large group of people don't even do an update.

 

[troop231]

Regarding the downloads. Your getting out of my area of experience. One thing to keep in mind is, if you are want to download several documents simultaneously, don't over do it as too many would give bad performance.

I have thought of one consideration. What will users do when they next update and find they don't have their documents because the update doesn't come with them?

An idea might be to post an update that keeps track of what documents they look at. Immediately upon startup of the 'new' non-preloaded document version, let the user know that they need to download those tracked documents.

At the very least, in your app changes entry, make it as clear as you can. Maybe even in the first description lines, for those that look at that kind of thing. I doubt though many current customers will see either though as they will just update. A large group of people don't even do an update.

I just submitted the app for approval I can't believe what all I accomplished in the last week, it should make for a fine upgrade for existing users, and attract new customers more now.

The app's download size should now be 1.4MB or so

I think I made my app changes entry pretty clear. Whether people read it or not is a whole different matter

Thank you again for all of the wisdom and information you've provided me; I hope you enjoy the update also!

 

[xStep]

I just submitted the app for approval I can't believe what all I accomplished in the last week, it should make for a fine upgrade for existing users, and attract new customers more now.

The app's download size should now be 1.4MB or so

I think I made my app changes entry pretty clear. Whether people read it or not is a whole different matter

Thank you again for all of the wisdom and information you've provided me; I hope you enjoy the update also!

Congratulations!

I'll try to remember to check it out. I'm on the road for a few days and starting a new job, so I'll be pretty busy for the next week or three.